,

Understanding Outbound Messaging in Salesforce

Although most of the knowledge presented here has been taken from the Help & Training documentation provided by Salesforce.com, I have attempted to simplify it and put some important facts about Outbound messages in focus for the readers consideration.

Outbound Message is a XML message that can be sent as an action of a Workflow Rule. By definition:

“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.”

Use cases for the Outbound Messaging:

Let’s first see how we could use the Outbound messaging.  Here is a simple example:

When Opportunity closes positively, we would want the Order fulfillment system to get all the details of the Opportunity such as billing and shipping address and the Line Items to complete the order. Here we assume that the Order fulfillment system is a legacy system running outside Salesforce servers, may be on an in-house ERP server.

How can we implement the Outbound message mentioned in the above example?

Some important points to consider when using Outbound messages:

  • Outbound messaging uses the notifications() call to a designated endpoint when triggered by a workflow rule.
  • A single SOAP message could contain up to 100 notifications.
  • SessionID could be included in the original Outbound message which could then be used by the client to callback.
  • Each notification contains the ObjectID and a reference to the associated sObject data.
  • If the information in the object changes after the notification is queued but before it is sent, only the updated information will be delivered. Meaning intermittent changes do not reach the client.
  • If you issue multiple discrete calls the calls may be batched together into one or more SOAP messages.
  • 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 the message are dropped from the queue.
  • If a message cannot be delivered, the interval between retries increases exponentially up to a maximum of 2 hours between retries.
  • Messages are retried independent of their order in the queue. This may result in the messages being delivered out of order.
  • No audit trail is possible since the messages might be delivered multiple times or not at all.
  • Because a message may be delivered more than once, your listener client should check the ID in the notification before processing.

 

Having set the Outbound message to fire, we have to take the Outbound message WSDL to build the listener on the client side. In the above example we would have to build a listener for the Order fulfillment system to receive and process the message. The steps for building the listener could be found in any of the below mentioned documents:

https://www.salesforce.com/developer/docs/api/Content/sforce_api_om_outboundmessaging_listener.htm

OR

http://developer.force.com/cookbook/recipe/sending-outbound-messages-with-workflow

 

Is the Outbound Messaging a truly declarative solution?

In my opinion it is NOT; since we have to do some coding to build the listener at the client-side. A developer would prefer to use raw web-services API provided by Apex to build both the outgoing and incoming web-services instead of using the Outbound messages, although they do simplify the message creation.

5 replies
  1. Vince
    Vince says:

    Hi, very nice website, cheers!
    ——————————————————
    Need cheap and reliable hosting? Our shared plans start at $10 for an year and VPS plans for $6/Mo.
    ——————————————————
    Check here: https://www.good-webhosting.com/

  2. sirgliofrei
    sirgliofrei says:

    I like what you guys are up also. Such clever work and reporting! Carry on the excellent works guys I’ve incorporated you guys to my blogroll. I think it’ll improve the value of my website 🙂

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published.