Print this page

Duplicate Message ID in Outbound Messages and Repeated Outbound Messages

Knowledge Article Number 000205281
Description Every outbound message is associated with a unique Outbound Notification Id.  It is unique for every notification that the message receives. A single SOAP message can include up to 100 notifications. Each notification contains an ID that uniquely identifies a record, and a reference to the data in the record. Therefore, if the information in the record changes after the notification is sent, but before the notification is delivered, only the updated information is delivered. 
Resolution At times, we notice Duplicate message IDs with outbound messages and repeated outbound messages are delivered. The following are the possible causes for multiple outbound messages, 
  • If you issue multiple discrete calls, the calls may be batched together into one or more SOAP messages. There can also be many other reasons why multiple outbound messages are being sent - a bug in your listeners code (like not flushing a buffer, or a problem with exception handling), an issue with an intermediate device (your network firewall or reverse proxy) etc. 
  • OM is an "at least once" delivery service. What this means is that the server will attempt to keep delivering the message until your service has correctly acknowledged the message and importantly that the salesforce server has completed handling your acknowledgement. There are numerous failure scenarios where the salesforce service will decide to resend the message, even if your server sent a valid acknowledgement, and you need to design your listener with this in mind.  (e.g. keep track of successfully processed message ids, and don't do processing on messages Ids you've already received, or implement your listener such that its idempotent). 
  • 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.  Messages are retried independent of their order in the queue. This may result in messages being delivered out of order.  The 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. 

You can monitor the outbound messages which have queued up for failed delivery at Setup > Monitoring > Outbound Messages. The retry link in the outbound  messaging monitoring page can help you trigger a message when you can monitor your end. Tools like wireshark & soapscope can help you monitor  the http back and forth to you server. 


Outbound Message Actions
Outbound Message Notifications

promote demote