Versions Compared

Old Version 4

changes.mady.by.user Jodie Miners

Saved on

compared with

New Version Current

changes.mady.by.user Jodie Miners

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

  • Declarative - set up in Workflow Rules

    • Don’t have an option for when Workflow Rules are discontinued (if ever)

  • Asynchronous

  • Fire and Forget

  • SOAP based (see https://tddprojects.atlassian.net/wiki/pages/createpage.action?spaceKey=SF&title=SOAP%20vs%20REST&linkCreation=true&fromPageId=1310556236 ) uses the WSDL and sends in XML

  • Only work on one object.

  • Can send the Session ID plus any fields on the Object.

  • It sends the Org ID also

  • After 24 hours messages are dropped from the queue

  • No set order. If they fail, messages may be retried out of order.

  • Has a unique Notification ID

  • default retry up to 24 hours 30s, 1m, 2m, 4m etc up to 2 hours, then each 2 hours for 24 hours

  • Message may be delivered more than once.

  • A listener is implemented on the external system.

  • Listener sends back an acknowledgement.

  • Use the session ID to call back to Salesforce1 Message can contain 100 notificationscallback to Salesforce.

    • The SessionId that’s included in the outbound message is scoped only for API requests and doesn’t apply to UI requests.

  • 1 object only.

  • 1 Message can contain 100 notifications,

    • Notification ID

    • Record ID

    • Record data selected.

  • If you issue multiple discrete calls, the calls may be batched together into one or more SOAP messages.

  • Only the most up-to-date information is sent, eg if the record changes after the notification is created and before delivery it will contain the new information.

  • You cannot build an audit trail using outbound messaging. While each message should be delivered at least once, it may be delivered more than once. Also, it may not be delivered at all if delivery cannot be done within 24 hours.

  • Because a message may be delivered more than once, your listener client should check the notification IDs delivered in the notification before processing.

  • 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.