Salesforce: Apex Callout Vs Outbound Messaging

As we know, Salesforce provides the following features to implement Outbound Integration(s),

• Apex Callout
• Outbound Messaging (OM)

While designing a solution, it is very important that we fully understand the capabilities of these features to make a right design choice. As part of this blog article, I intend to share the capabilities along with considerations to be applied to choose the right Outbound Integration feature.

1. Apex Callout, enable Apex to invoke external web services. This allows you to connect to 3rd party web services such as Google, Amazon, Facebook, and any other external web service.

Capabilities:

• Callout requires familiarity with Apex coding
• Transaction failure & retry logic should be explicitly coded
• Supports both SOAP & REST API Invocation
• Sync & Async requests handling is supported
• We can send multiple records (including related) in a single transaction
• Apart from Basic & Certificate-Based, other authentication (s) can also be implemented using “Named Credentials”
• Sync Callouts should be considered only in the following scenarios. Otherwise consider using Async callouts.
  • When the Target System guarantees the faster response time (SLA of ~ 3 to 5 seconds)
  • Transfer minimal data
• Callouts are generally launched from Triggers and Custom Buttons/Links
• SOAP & REST API Callouts can be implemented using WSDLtoAPEX and HTTP Objects

Consider using Callouts in the following scenario(s),

• Target system Web Services (SOAP/REST) can be directly consumed within Salesforce
• Sending Multiple/Multiple Related records
• Specific authentication method (say Basic) is required

2. Outbound Messaging (OM), allows you to specify that changes to fields within Salesforce can cause messages with field values to be sent to designated external servers.

 Capabilities:

• OM can be implemented using Point & Click tools without having to write any code in Salesforce
• Can be invoked from Workflow Rules, Approval Processes and Entitlement Processes
• Retry logic to reprocess failed records comes Out of the box. If the endpoint is unavailable, messages will stay in the queue (Salesforce) until sent successfully, or until they are 24 hours old. After 24 hours, messages are dropped from the queue. If a message cannot be delivered, the interval between retries increases exponentially, up to a maximum of two hours between retries
• Sends configured fields in the form of XML SOAP message to the specified end-point
• The destination end point should be setup in a specific way for it to accept the contents of the SOAP message being sent. We won’t be able to use existing web services of the Target system.
• The request & response format is predefined by Salesforce. Our solution should align to this format
• Only certification based authentication is supported
• We can only send single parent record fields in the SOAP message. Additional web service transaction should be issued back to Salesforce (from custom solution) using the session id sent in the SOAP message to get additional (related) records
• Max of 100 notifications will be sent in a single outbound message
• Only Async transactions are supported

Consider using OM in the following scenario(s),

• Leverage point & click tools, avoid coding
• If we are integrating with Target system using the intermediate (custom) service for any reasons, we could consider using OM feature

Hope this article helps to make a right choice while designing a solution for outbound integration. If you have any specific comment on the capabilities and considerations, please do share.

..Prashanth N..