Outbound Messages:
Outbound messaging allows you to specify that changes to fields within Salesforce can cause messages with field values to be sent to designated external servers.
Outbound messaging is part of the workflow rule functionality in Salesforce. Workflow rules watch for specific kinds of field changes and trigger automatic Salesforce actions, such as sending email alerts, creating task records, or sending an outbound message.
Salesforce offers a point-and-click capability to integrate systems using Outbound Messages, this is a great capability of the platform without any major governor limits.
Outbound Messages work on SOAP protocol and do not provide any capability to add an authentication mechanism, but they proved the capability to include a session Id within the request body.
So we need an open endpoint on Salesforce that can accept a request without authentication, this can be achieved but leveraging force.com sites which are usually used to create a public site.
Things to remember for web-service call
- Outbound messaging uses the notifications()call to send SOAP messages over HTTP(S) to a designated endpoint when triggered by a workflow rule.
- A single SOAP message can include up to 100 notifications. Each notification contains the object ID and a reference to the associated sObject Note that if the information in the object changes after the notification is queued but before it is sent, only the updated information will be delivered.
- If you issue multiple discrete calls, the calls may be batched together into one or more SOAP messages.
Metadata for web-service call
The metadata needed for outbound messaging, including the definition of the notifications() call, which sends the outbound SOAP message to an external service, is in a separate WSDL. The WSDL is created and available from the Salesforce user interface once a workflow rule has been associated with an outbound message. The WSDL is bound to the outbound message and contains the instructions about how to reach the endpoint service and what data is sent to it.
See an example that is used to call a web service with Outbound Messages.
Below are the components that are involved on a high level and a brief description for each of them,
1)Local Message Object:
This object holds all the information about the data and actions that need to be taken
2) Workflow Rule:
Trigger the Outbound Message whenever a Local Message record is created or updated and also retry with a change in processing count.
3) LocalOMService:
This is an apex class with REST service that accepts the XML request from Outbound Messages over HTTP POST.
Once the request is received it passes the request body to OutboundMessageUtils to get the sessionId and the outbound message data. Once it has a session, it calls the LocalIdentityService to verify the session ID is valid for the current ORG (within the sandbox or production) and also validates the request originated from the same org.
This validation makes sure that the request is not malicious as the REST service is not secured. Then it calls the CasePredictionHandlers.
4) OutboundMessageUtils:
This class holds the utility methods to parse the SOAP request and to return positive and negative acknowledgment.
5) LocalIdentityService:
This is an apex REST service that validates the session Id passed on the Outbound Message is valid within this current ORG.
6) CasePredictionHandlers:
These are the apex class which is expected to be self-sufficient to handle the errors and process the outbound messages appropriately. This is also responsible for calling the External Web Services and marking the Local Message records status to complete/failed/retry appropriately.