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?

• Create an Oubound Message by going to Setup->Create-> Workflows and Approvals-> Outbound Messages -> Create New Outbound Message. Steps for this are mentioned in the following H&T document:-  https://help.salesforce.com/htviewhelpdoc?id=workflow_defining_outbound_messages.htm
• Create a Workflow rule that executes this predefined Outbound Message action when the Opportunity Stage is Closed Won.

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.

Salesforce.com allows you to access data stored in your external data sources within your organization. Previously this was possible by writing your own adapters in Apex that used web services to access that data. This method of accessing the external data within your organization is still valid and is widely used by customers who wish to have a single view of their data, internal or external. But this system is largely programmatic and requires developer skills to achieve it.

External Objects allow us to map tables in external data sources within Salesforce allowing a federated search of all your data and content. External Objects are similar to Custom Objects such that, they are defined declaratively although they, unlike Custom Objects, map to data outside your Salesforce organization. You can define up to 100 External Objects in Developer, Enterprise, Performance and Unlimited editions.

External Objects are Customizable, Searchable but are not Reportable and Securable. The visibility of the records of the External Object is not controlled by the Salesforce Organization’s security model; instead it is controlled by the external system and reflects within your organization depending on the Identity Type defined while defining the External Data Source.

External Data Source:

External objects rely on an external data source definition to connect with the external system’s data. Each external object definition maps to a data table on the external system. Each of the external object’s fields maps to a table column on the external system.

External Data Sources can use the following types:

• File Connect: Used for Google Drive, SharePoint 2010 or 2013, SharePoint Online or OneDrive for Business.
• Lightning Connect:Used with OData 2.0 or 4.0 to connect to external systems (e.g. ERP) , Salesforce connector for connecting two Salesforce organization (this is a pub-sub model) or Custom Apex adapters.
• Simple URL:Used for accessing data from another web domain.

More information about these types and defining the External Data Source could be found in the following Help and Training link: Defining External Data Source

Two ways of Defining External Objects:

Once you define an External Data Source, you get an option to Sync the Data source within the Salesforce Organization. The ‘Validate and Sync’, which is a onetime activity, automatically creates External Objects corresponding to the tables in the external system and custom fields on the External Objects corresponding to the columns of the table that’s compatible with a Salesforce metadata field type. Since this is a onetime activity it does not reflect any changes in the external system’s schema that might have occurred after the sync.

Second way would be to create the corresponding External Objects manually to customize the external object names and manually create the custom fields.

The steps for defining the External Objects can be found in the following help and training link: Defining External Object

External Object Relationships:

You can create lookup relationships with External Objects within Salesforce. There are three types of lookup relationships that can be created:

• Lookup Relationship
• External Lookup Relationship
• Indirect Lookup Relationship

 

The following table summarizes the types of relationships that are available to external objects.

Relationship	Allowed Child Objects	Allowed Parent Objects	Parent Field for Matching Records
Lookup	Standard Custom External	Standard Custom	The 18-character Salesforce record ID
External lookup	Standard Custom External	External	The External ID standard field
Indirect lookup	External	Standard Custom	You select a custom field with the External ID and Unique attributes

*Courtesy of Help and Training.

You can find more information about External Object Relationships and considerations in the following Help and Training link: External Object Relationships

Writable External Objects:

You can Create, Edit and Delete the external data source record by modifying the External object record within Salesforce organization. This capability is only available while using Lightning Connect with OData 2.0 or 4.0 or when using Custom Apex adapters. If you have used Lightning Connect for OData 2.0 or 4.0 as your type when defining the External Data Source within Salesforce organization then you get a checkbox to enable this feature. This feature is not available for other External Data Source types.

Summary:

External Objects simplifies your need to view your external data within Salesforce by providing a declarative solution. You can use External Objects with Lightning Connect when:

• You have a large amount of data that you don’t want to copy into your Salesforce organization.
• You need small amounts of data at any one time.
• You want real-time access to the latest data.

 

Happy Reading!