+ Start a Discussion
csbaacsbaa 

packaging application

Hello Helpers

 

I havea generic question about how  the package and deploy  code

 

I am working on an integration project  and I have a few  batch classe/triggers  and custom object

 

The classes/triggers  are referencing  some fields  on other custom objects wwhich are not part of my  application

those object are part of our core CRM  

My code rely on the existence  of  some fields in the other objects  otherwise when I import the classes with eclipse  I get compile  errors.

 

before deploying my code I use to manyally create the new  fields in the related objects  then  import the class / triggers  in Eclipse from the file system.

 

It is OK when I am doing  the deployment  but  I plan to handover   this to non-technical persons

 

The question is  it is possible  to  create a package which  creates the fieds itself?

 

I use Eclipse  to deploy  entire object  from a file  but how  to procede if the object exists  and I just want  to add a few fileds  or other metadata  components  like  custom butons for example?

 

There is  a solution for my problem?  I guess yes.

 

any ideas  or,  small examples or  link to article  in the knowledge base would be very usefull

 

thanks in advance

Csaba

 

Best Answer chosen by Admin (Salesforce Developers) 
sfdcfoxsfdcfox
You can create fields as I outlined in the third option. A Flash- or Java-based parser would be ideal, but requires client interaction. Apex Code can only do this if spoon-fed an already built zip file that meets the Metadata API specifications. All options will result in the same output; the Metadata will not fail so long as the fields match data types and names, or do not exist. It is essentially an "upsert" command that will update existing fields and create new fields at the same time. Apex Code won't be able to detect failures, but the other two options can.

All Answers

sfdcfoxsfdcfox
The package won't upload without being complete. This means that when you package for the AppExchange, those fields will automatically be included in the package. The only way to avoid this behavior is to use only dynamic field references where these fields are referenced (via DescribeSObjectResult.fields.getMap() or by using strings).

You are therefore limited a few basic options:

1) Don't use dynamic Apex Code field references. These fields will automatically be packaged. When you make a managed package, those fields won't conflict with the installation organization's fields.

2) Create a dependent package. You do this by having two developer organizations. The first has the core fields that you want, and then packaged and uploaded. The second organization has the package from the first installed, and then builds on that package's fields. This creates a situation where two installs are required; one for the fields, the other for the logic.

3) Use dynamic Apex Code. Your code should be able to either ignore the fields, or fail gracefully, telling them how to resolve the error. At this point, you have several options available to you. You can use a separate package, as in (2) above, but the code won't be specifically dependent on this package. They can be installed and uninstalled independently. Alternatively, you can write a "post-install" document that describes what fields should be created. You could also write a simple Java-based or Flash-based installer that runs in the browser, and is packaged with your app; the users can run this code post-install to create the required fields.

Use option (1) when available. It will simplify the install process. Otherwise, you'll make extra work for yourself and your customers.

Finally, if all else fails, you could actually create a metadata package (a ZIP file), have this uploaded as part of the app's static resources, and a post-install handler could invoke the metadata API against this ZIP file. I don't see any good reason why you'd use this method instead of just packaging the fields directly, and this is far outside the scope of a simple forum topic, but you should be aware that the option does exist.
csbaacsbaa

Thanks for your answer

 

I do not understand all  because I never worked  with packages or apex Exchange  so let me simplify my request

 

forget  about the deploying/packaging  code

 

I have a custom object

I want to add some fields  to this object

I do not want to do this from inside the org

 

There is any option to create these fields  based  on a file? (xml for example)

There is a way to deploy them  from  another org where the field  were already created?  Deploy  just the some fields not full  object.

 

My knowledge is limited here

I always  use Eclipse  deploy to server  or Import from file

but in these cases I can deploy/import  entire objects.

I want to be able  to add fields to an object from outside the org

 

If this is done  them I can deploy my code too.

 

I hope  I managed to explain better what I need

 

 

 

Regards

csaba

sfdcfoxsfdcfox
You can create fields as I outlined in the third option. A Flash- or Java-based parser would be ideal, but requires client interaction. Apex Code can only do this if spoon-fed an already built zip file that meets the Metadata API specifications. All options will result in the same output; the Metadata will not fail so long as the fields match data types and names, or do not exist. It is essentially an "upsert" command that will update existing fields and create new fields at the same time. Apex Code won't be able to detect failures, but the other two options can.
This was selected as the best answer