Apex Code Development You need to sign in to do that
Don't have an account?
KymLe Can SFDC Poll for Specific Inserts/Updates to Custom and Standard Objects and then Execute Apex Code?
I have quite a few triggers in my org that fire based on insert and/or update and execute a variety of business logic. I don't particularily like this approach because 1. I'm told triggers aren't very reliable and 2. using triggers makes my application very difficult to package and reuse in a different org since there are quite a few custom objects that may/may not be relevant to another org.
Theoritically, I would like to write a "service" in which it "listens" to changes on particular objects (standard and custom). When an insert and/or update occurs, the service then execute an apex class. So, basically, this could be solved if Workflows were able to access Apex classes.
Is there someone out there that has a good solution for this?
Thanks for any help/ideas.
Theoritically, I would like to write a "service" in which it "listens" to changes on particular objects (standard and custom). When an insert and/or update occurs, the service then execute an apex class. So, basically, this could be solved if Workflows were able to access Apex classes.
Is there someone out there that has a good solution for this?
Thanks for any help/ideas.
I also don't see how having workflow rules tied to particular custom objects would be any more portable than triggers - they are easier to change, certainly, but you couldn't deploy a workflow rule for an object that didn't exist in the target org.
The only way outside of triggers and workflow to be notified that a change has been made to an object is via the streaming API :
http://wiki.developerforce.com/page/Getting_Started_with_the_Force.com_Streaming_API
The way I would approach this would be to have very thin triggers that simply delegate to an Apex class that figures out what type of object has received an insert/update and executes an apex class defined via a custom setting or similar. This would allow you to package up the workflow action equivalent and then simply create the thin triggers (the workflow rule equivalents) in the target organization.
Thank you for your response. Here's my follow up:
I'm coming from a RDBMS background with Oracle and SqlServer; I've always followed the practice of limiting trigger usage because triggers are notorius for unpredictable behavior as well as difficulty in error catching/handeling. I'm not sure if SFDC is different in terms of the reliability of triggers executing and the error handling around them - but, that was my initial hestiation on using triggers heavily in my application.
In a perfect world, I would like to write a custom serivice where it polls certain objects for changes. When there's a change, the service will create a map of Id and Objects and pass that to an Apex class to execute business logic. The service could reference an xml file (or other config type file) to know what objects to poll. This (to me) is my preferred approach as it detaches the dependecies of custom objects to the application - meaning, if this application was deployed into a different org, there is no need or loss of functionality of the custom objects (if the org has no need for the custom objects, then there are no dependecies of triggers firing and executing logic that may effect other objects and/or triggers).
My comment about the workflow was more towards illustrating the "easy" solution and not necessarily stating that workflows would be easier to package and deploy than triggers.
Would you still suggest the API route or are triggers a more reliable solution?
Thank you for your input.