Apex Code Development You need to sign in to do that
Don't have an account?
jtenganfoldings Packaging an Apex trigger for a Professional edition
I have created a apex trigger in my developer edition and I want to use it in my company's professional edition.
It is my understanding that to do that, I need to create a package and pass a security review. Is there anything else that I need to do (I have created a test class that covers 100%)?
Also, the trigger that I made works on a custom object as well as a built in object (case) with custom fields added. The custom object and fields already exist in my company's professional edition. How will that work? When I tried to use the deploy option in eclipse with the force.com plugin, I noticed that it gave me the choice to remove the action to overwrite the custom objects, but when I created the (unmanaged) package it didn't give me any similar options. Will the package automatically detect if the dependencies already exist or will it overwrite the objects (I would like it to NOT overwrite)? I did not recreate the custom object exactly as it is in my company's instance, just the fields that are needed in the trigger.
Thanks for any help.
I have only had experience with managed packages into a PE org but maybe this will help:
1. A security review is required to deploy a managed package with Apex code into a PE (unless you have paid extra to get Apex support in your PE). These reviews can take up to a couple of weeks and now cost $5,000 for the initial review plus $2,500 for each annual renewal. They are still free if your app is free (which I guess technically your internal solution woul be). I have never attempted to deply unmanaged packages to a PE, not sure if that is even allowed - you should check with SFDC support.
2. Once you get your security review and your package has been approved, SFDC does something to the org in which it was build (your DE) and you have to build the package again. This post review build must somehow include that approval indicator. No code changes are required (assuming a 100% native package) you just have to remember to do it ;)
3. The next to last step in the Eclipse Deploy to Server process is a validation step that will check to make sure any referenced objects and fields (custom or standard) exist in the target org. IFor example, if the code you are attempting to deploy references a field on a custom object and that field is not there, you will get a validation error and the deployment will not occur. There is actually an option on the last step of the process to manually run just the validation so you can check your deployments validity without having to actually commit to deploying.
4. The action of the Overwrite option depends on what metadata/components you have included in your project. For example, if you include just a couple of new fields to a standard object in your project that the deploy will just add those fields to the object in the target org.
NOTE: As of Winter 10, we have found that the Eclipse deploy process will not properly deploy additional fields added to an existing custom object. Works fine adding fields to a standard object and adding an entire new custom object but not adding fields to custom objects. When this occure we just manually add the fields to the custom object in the target org and do not include the custom object overwrite in the deployment.
All Answers
I have only had experience with managed packages into a PE org but maybe this will help:
1. A security review is required to deploy a managed package with Apex code into a PE (unless you have paid extra to get Apex support in your PE). These reviews can take up to a couple of weeks and now cost $5,000 for the initial review plus $2,500 for each annual renewal. They are still free if your app is free (which I guess technically your internal solution woul be). I have never attempted to deply unmanaged packages to a PE, not sure if that is even allowed - you should check with SFDC support.
2. Once you get your security review and your package has been approved, SFDC does something to the org in which it was build (your DE) and you have to build the package again. This post review build must somehow include that approval indicator. No code changes are required (assuming a 100% native package) you just have to remember to do it ;)
3. The next to last step in the Eclipse Deploy to Server process is a validation step that will check to make sure any referenced objects and fields (custom or standard) exist in the target org. IFor example, if the code you are attempting to deploy references a field on a custom object and that field is not there, you will get a validation error and the deployment will not occur. There is actually an option on the last step of the process to manually run just the validation so you can check your deployments validity without having to actually commit to deploying.
4. The action of the Overwrite option depends on what metadata/components you have included in your project. For example, if you include just a couple of new fields to a standard object in your project that the deploy will just add those fields to the object in the target org.
NOTE: As of Winter 10, we have found that the Eclipse deploy process will not properly deploy additional fields added to an existing custom object. Works fine adding fields to a standard object and adding an entire new custom object but not adding fields to custom objects. When this occure we just manually add the fields to the custom object in the target org and do not include the custom object overwrite in the deployment.