Jeff
The addition of asynchronous Web service callouts to external services is a feature that developers have been requesting for quite awhile in Salesforce.com. Using the new @future annotation, your methods execute the callout when Salesforce.com has resources available. One of the great benefits is that it allows you to perform callouts during trigger executions.
Today, I developed the callouts from trigger. There are many limitations which I came across and which are documented very well by Jeff on his blog post http://blog.jeffdouglas.com/2009/03/16/restful-web-service-callout-using-post/
I kept on trying to use complex data types, unless i reached Jeff post and found that only primitive data types are supported in future methods. To paraphrase, following are the points to be taken note of when using the future annotation:
- No more than 10 method calls per Apex invocation
- No more than 200 method calls per Salesforce license per 24 hours
- The parameters specified must be primitive dataypes, arrays of primitive datatypes, or collections of primitive datatypes.
- Methods with the future annotation cannot take sObjects or objects as arguments.
- Methods with the future annotation cannot be used in Visualforce controllers in either getMethodName or setMethodName methods, nor in the constructor.
Also good note of points about asynchronous call outs can be read at Salesforce Blog
- Like any asynchronous method. the callout must be in a static method and return a void type.
- The system executes the asynchronous call when it has available resources – this means that you can’t assume anything about when the call will be executed.
- The asynchronous method executes in a different transaction context than the trigger. A failure of the callout will have no effect on the transaction controlling the trigger (i.e. changes will not be rolled back). You will have to build in suitable compensation logic yourself to account for any exceptions in the callout.
- Keep the governor limits in mind when making callouts. We are constrained by the interface provided by the remote web service. If the remote web service were to provide any kind of batch processing interface, choose that instead of making individual calls. It helps avoid hitting the governor limits and will be more performant as well since there are fewer round trips to make.
Recent Comments