Apex Code Development You need to sign in to do that
Don't have an account?
prakashedl Standard Objects and managed package
We are trying to create a managed package and host it on the appexchange. Our implementation includes standard objects like Leads, Contacts, Events and Campaign. Our concern at this point is the following
- We are creating records in these objects. WHat is the recommended approach to consider the required fields or other constraints the customers or subscribers may have for these objects? We are not aware of these constraints/required field and our record inserts may fail. Is this even recommended to use standard objects given this problem?
- In test classes to test the solution, we need to create instance of these objects to create data. Will these test classes fail in the subscriber's org because of missing required fields or validation rules/constraints.
Please help and advise the recommended approach. Thanks in advance for your help.
The standard objects, such as Leads, Contacts, etc. will not be part of your package, as the installer's org would have those objects available. Only custom fields, buttons, layouts, etc. that you may have created will be part of the package.
Now to your questions:
1. If your package code uses standard objects, you most likely will have to create their records in the test Apex classes. The only way for your test Apex code not to fail during creation of a standard object record because of a required field is to use Dynamic Apex to inspect the schema and dynamically populate the required fields. To save time you could use something like the SmartFactory: https://github.com/mbotos/SmartFactory-for-Force.com
2. If you don't populate a required field the code will fail (see point #1 above for a solution). As to validation rules, unfortunately, there's no way of avoiding failures, so if a customer has a validation rule that is fired when you issue a DML statment, the code will fail.
Relatively good news is that if you create a managed package, unit test failures won't negatively affect customer's org - they still will be able to deploy other code/apps into the org.
All Answers
The standard objects, such as Leads, Contacts, etc. will not be part of your package, as the installer's org would have those objects available. Only custom fields, buttons, layouts, etc. that you may have created will be part of the package.
Now to your questions:
1. If your package code uses standard objects, you most likely will have to create their records in the test Apex classes. The only way for your test Apex code not to fail during creation of a standard object record because of a required field is to use Dynamic Apex to inspect the schema and dynamically populate the required fields. To save time you could use something like the SmartFactory: https://github.com/mbotos/SmartFactory-for-Force.com
2. If you don't populate a required field the code will fail (see point #1 above for a solution). As to validation rules, unfortunately, there's no way of avoiding failures, so if a customer has a validation rule that is fired when you issue a DML statment, the code will fail.
Relatively good news is that if you create a managed package, unit test failures won't negatively affect customer's org - they still will be able to deploy other code/apps into the org.
Thanks Shamil. I also think since the actual application is creating the records and if validation rules exist, it will fail and not work for such customers. I wanted to confirm my understanding.