SOAP API Developer Guide

Getting Started
Reference
Using the API with Salesforce Features
Implementation Considerations
Outbound Messaging
Understanding Outbound Messaging
Understanding Notifications
Setting Up Outbound Messaging
Considerations for Security
Understanding the Outbound Messaging WSDL
Building a Listener
Data Loading and Integration
Data Replication
Feature-Specific Considerations
Glossary
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Understanding Notifications

A single SOAP message can include up to 100 notifications. Each notification contains the object ID and a reference to the associated sObject data. If the information in the object changes after the notification is queued but before it’s sent, only the latest data is delivered and not the intermediate changes.

If you issue multiple discrete calls, the calls are sometimes batched together into one or more SOAP messages.

Messages are queued locally. A separate background process performs the actual sending, to preserve message reliability:

  • If the endpoint is unavailable, messages stay in the queue until sent successfully, or until they’re 24 hours old. After 24 hours, messages are dropped from the queue.
  • If a message can’t 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. As a result, messages can be delivered out of order.
  • You can’t build an audit trail using outbound messaging. While each message is usually delivered once, it can sometimes be delivered more than once. If delivery can’t be done within 24 hours, a message isn’t delivered at all. Finally, if the source object changes after a notification is queued but before it’s sent, the endpoint only receives the latest data, not any intermediate changes.
  • Because a message can sometimes be delivered more than once, check the notification IDs in the notifications delivered to your listener client before processing.

Instead of polling, which was required in previous releases, you can now use outbound messaging to trigger execution logic when Salesforce raises an event. In previous versions of the API, client applications had to poll Salesforce to find out if relevant changes had occurred. Because most changes eventually trigger a workflow if a rule exists for it, you can use the workflow rule to trigger actions based on Salesforce events.

Note

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 after 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. For more information about setting up outbound messaging, see Defining Outbound Messaging.