Outbound Messages : Implementation Tips and Considerations

Outbound Messages are one way and asynchronous method to send some information from Salesforce to External systems. Best thing about Outbound messages is that it is declarative and no coding is required for this.

Outbound message follows "Remote Process Invocation—Fire and Forget" Integration pattern.

If you are planning to appear for "SALESFORCE CERTIFIED INTEGRATION ARCHITECTURE DESIGNER" exam then this blog will be helpful.

Below are implementation tips which need to know:

Reliable

• Outbound Message has in-built retry mechanism. 
• Messages will be queued locally. A separate background process performs the actual sending, to preserve message reliability
• If the endpoint is unavailable, messages will stay in the queue 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.
• Messages are retried independent of their order in the queue. This may result in messages being delivered out of order.
• Source object may change after a notification is queued but before it is sent, so the endpoint will only receive the latest data, not any intermediate changes. Because a message may be delivered more than once, your listener client should check the notification IDs delivered in the notification before processing.

Security Considerations

• All Outbound messages are sent from Salesforce IP address. Make sure that Salesforce IP addresses are white listed in external system.
• Using SSL/TLS provides confidentiality while data is transported across the internet.
• You can pass user session Id in outbound messages so that external system can callback and update data back in salesforce.
• The organization Id is included in each message. Your client application should validate that messages contain your organization Id.

If your application (endpoint) server's SSL/TLS may be configured to require client certificates (two-way SSL/TLS), in order to validate the identity of the Salesforce server when it takes the role of client to your server. If this is the case, you can download the Salesforce client certificate from the Salesforce application user interface. This is the client certificate that Salesforce sends with each outbound message for authentication.

• From Setup, enter API in the Quick Find box, then select API.
• On the API WSDL page, click Manage API Client Certificate.
• On the Certificate and Key Management page, in the API Client Certificate section, click the API Client Certificate.
• On the Certificates page, click Download Certificate. The .crt file is saved in the download location specified in your browser.

Import the downloaded certificate into your application server, and configure your application server to request the client certificate. The application server then checks that the certificate used in the SSL/TLS handshake matches the one you downloaded.

How to prevent circular changes with outbound messaging?

It’s possible to create circular changes with outbound messaging. For example, user updates contact which trigger outbound message to external application. After this external application will update contact back in salesforce which can again trigger outbound message. To prevent these circular changes, you can disable a user’s ability to send outbound messages.

To disable outbound message notifications for a user, deselect Send Outbound Messages in the user’s Profile. 

We recommend specifying a single user to respond to outbound messages and disabling this user's ability to send outbound messages.

• Select Salesforce user while creating OM, to use when sending the message by specifying a username in the User to send as field. The chosen user controls data visibility for the message that is sent to the endpoint.
• Select Include Session ID if you want a sessionId to be included in the outbound message. Include the sessionId in your message if you intend to make API calls back to Salesforce from your listener. The sessionId represents the user defined in the previous step and not the user who triggered the workflow.
• The API Version for OM can only be modified by using the Metadata API not from UI.

Tracking Outbound Message Status

To track the status of an outbound message, from Setup, enter Outbound Messages in the Quick Find box, select Outbound Messages, and then click View Message Delivery Status. You can perform several tasks on this page.

• View the status of your outbound messages, including the total number of attempted deliveries.
• View the action that triggered the outbound message by clicking any workflow or approval process action ID.
• Click Retry to change the Next Attempt date to now. This action causes the message delivery to be immediately retried.
• Click Del to permanently remove the outbound message from the queue.

Capabilities of Outbound Messages

• Message can be delivered in out of order fashion as it is asynchronous process.
• Outbound Messages uses SOAP based calls. It can not be used for system which doesn't support SOAP API's.
• Organization Id is passed in all messages. 
• Session Id can be passed to implement 2 way communication by performing callback to Salesforce from external system

If you want to learn about Integration patterns then refer below blogs:

Integration Patterns and Best Practices for Salesforce - Part 1

Integration Patterns and Best Practices for Salesforce - Part 2

Hope this will help!!