Outbound Integrations 
Sujit Kumar 
Zenolocity LLC © 2012 - 2024
Overview 
• Configurable Solutions 
• Outbound Messaging 
• SalesForce-to-SalesForce (S2S) 
• Testing Outbound Messaging with an External 
Web Service 
• Custom Integrations 
• Calling Web Services from Apex 
• HTTP Integration
Configurable Solutions 
• Outbound Integration achieved via 
configuration rather than custom code. 
• 2 Options – Outbound Messaging and S2S. 
• Need high degree of control over the design of 
both sides of an integration. 
• Highly cost-effective.
Outbound Messaging 
• Sends a Web service request to an endpoint URL using HTTP 
or HTTPS. 
• Outbound Message, described as a notification, is a simple 
SOAP message that contains one or more fields from a single 
object. 
• The configuration is entirely point-and-click. 
• Workflow rules determine the messages to be sent. 
• Messages are sent reliably, queued, and retried upon failure. 
• Retries continue for up to 24 hours until a message is sent. 
• Limitations – static service definition, no junction objects.
Configuring Outbound Messaging 
• 2 Step Process: create a workflow rule to specify when 
to send a message. Define the outbound message 
itself, which dictates the contents of the message. 
• Both the workflow rule and the outbound message 
must be created from the same object. 
• Trigger for a workflow rule – when an object is created 
or edited. 
• Enter the URL of the Web service to receive the 
outbound message. 
• Monitor: Administration Setup area , click Monitoring . 
Outbound Messages.
External Web Service to consume 
Outbound Messaging 
• Based on a WSDL. 
• Up to a 100 notifications in a single web service call. 
• Positive or a Negative acknowledgement for each 
notification in the outbound message. 
• Able to handle duplicate notifications. 
• Get the most recent data for a notification, use a 
session ID in the outbound message & use that to call 
back Force.com and get the most current information. 
• If the outbound message endpoint uses HTTPS, the 
endpoint server’s certificate must be issued by a 
Certificate Authority (CA) that is accepted by 
Force.com.
S2S 
• Allows sharing data between Force.com 
organizations, the tenants of the multitenant 
platform. 
• The data exchange takes place entirely within 
the servers that run the Force.com platform, 
eliminating all the overhead associated with 
traditional integration over the Internet, such 
as encryption, message formats, and transport 
protocols.
Configuring S2S 
• Establish a connection between 2 force.com orgs. 
Connections require manual initiation and 
acceptance by the administrators of each 
Force.com org. 
• Configure shared objects – one org publishes and 
the other org subscribes to it. The subscriber 
maps the object, fields & values to counterparts 
in it’s org. 
• Sharing records – records are forwarded by 1 org 
and accepted by the receiver.
Calling Web Services from Apex 
• Apex code can be generated from WSDL. 
• This produces methods for invoking an 
external Web service and representing the 
input and output data in native Apex data 
structures rather than SOAP. 
• No interaction with HTTP or XML is necessary 
because these details are hidden by the 
generated Apex code. 
• Little control over generated code.
WSDL Support and Limitations 
• Endpoints of external web services need to be 
registered under Remote Site Settings. 
• WSDLs containing apex keywords need to be 
suffixed with _x. 
• Limited set of WSDL schema types. 
• Supports the element and sequence constructs. 
• Blob, Decimal and enum are supported for call ins 
but not call outs. 
• WSDL files with imports are not supported.
Callout Limitations 
• Request and response messages cannot exceed the 
maximum Apex heap size, normally 3MB. 
• Apex code can make a maximum of 10 HTTP requests in a 
single transaction. 
• By default, a single request cannot run longer than 10 
seconds. If a transaction contains more than one request, 
the total time of all requests cannot exceed 120 seconds. 
• Request size less than 100kb 
• Timeouts can be between 1ms to 60s. 
• Circular references not allowed 
• Loopback connections to SF not allowed 
• End-point should be registered in remote site settings.
Asynchronous Callouts via @future 
methods annotation 
• Requires methods to be static and have a void return 
type. 
• Use this to make a callout from a trigger. 
• No more than 10 method calls per Apex invocation. 
• No more than 200 future method calls per SF license 
per 24hrs. 
• Parameters to future methods - primitives or 
collections of primitives only. No sObjects or objects as 
arguments. 
• Use @Future(callout=true) to signify a method will be 
making a calllout.
HTTP Integration 
• Full control over the preparation of requests and 
processing of responses. 
• Core Apex classes: HttpRequest, HttpResponse and 
Http. 
• HttpRequest – methods for working with the request 
body, HTTP headers, the HTTP method type, client 
certificates, HTTP compression and timeouts. 
• HttpResponse – methods for working with raw 
response body, HTTP status code, and HTTP headers. 
• Http – has a method called send that accepts a 
HttpRequest object as input and gives a HttpResponse 
object as output.
Other Utility Classes 
• Send a client certificate with your callout to 
authenticate a HTTPS connection. 
• XMLStreamReader class to parse XML coming 
back from response. 
• XMLStreamWriter class to create XML that is 
sent as a request. 
• EncodingUtil: This class contains methods for 
URL and Base64 encoding and decoding.
Crypto Class 
• Crypto class enables access to external 
services that require encryption. Crypto 
methods include: 
• generateDigest: secure one-way hash digest. 
• generateMac: computes a message 
authentication code given a private key. 
• sign: computes a unique digital signature for 
an input string. 
• getRandomInteger, getRandomLong

SFDC Outbound Integrations

  • 1.
    Outbound Integrations SujitKumar Zenolocity LLC © 2012 - 2024
  • 2.
    Overview • ConfigurableSolutions • Outbound Messaging • SalesForce-to-SalesForce (S2S) • Testing Outbound Messaging with an External Web Service • Custom Integrations • Calling Web Services from Apex • HTTP Integration
  • 3.
    Configurable Solutions •Outbound Integration achieved via configuration rather than custom code. • 2 Options – Outbound Messaging and S2S. • Need high degree of control over the design of both sides of an integration. • Highly cost-effective.
  • 4.
    Outbound Messaging •Sends a Web service request to an endpoint URL using HTTP or HTTPS. • Outbound Message, described as a notification, is a simple SOAP message that contains one or more fields from a single object. • The configuration is entirely point-and-click. • Workflow rules determine the messages to be sent. • Messages are sent reliably, queued, and retried upon failure. • Retries continue for up to 24 hours until a message is sent. • Limitations – static service definition, no junction objects.
  • 5.
    Configuring Outbound Messaging • 2 Step Process: create a workflow rule to specify when to send a message. Define the outbound message itself, which dictates the contents of the message. • Both the workflow rule and the outbound message must be created from the same object. • Trigger for a workflow rule – when an object is created or edited. • Enter the URL of the Web service to receive the outbound message. • Monitor: Administration Setup area , click Monitoring . Outbound Messages.
  • 6.
    External Web Serviceto consume Outbound Messaging • Based on a WSDL. • Up to a 100 notifications in a single web service call. • Positive or a Negative acknowledgement for each notification in the outbound message. • Able to handle duplicate notifications. • Get the most recent data for a notification, use a session ID in the outbound message & use that to call back Force.com and get the most current information. • If the outbound message endpoint uses HTTPS, the endpoint server’s certificate must be issued by a Certificate Authority (CA) that is accepted by Force.com.
  • 7.
    S2S • Allowssharing data between Force.com organizations, the tenants of the multitenant platform. • The data exchange takes place entirely within the servers that run the Force.com platform, eliminating all the overhead associated with traditional integration over the Internet, such as encryption, message formats, and transport protocols.
  • 8.
    Configuring S2S •Establish a connection between 2 force.com orgs. Connections require manual initiation and acceptance by the administrators of each Force.com org. • Configure shared objects – one org publishes and the other org subscribes to it. The subscriber maps the object, fields & values to counterparts in it’s org. • Sharing records – records are forwarded by 1 org and accepted by the receiver.
  • 9.
    Calling Web Servicesfrom Apex • Apex code can be generated from WSDL. • This produces methods for invoking an external Web service and representing the input and output data in native Apex data structures rather than SOAP. • No interaction with HTTP or XML is necessary because these details are hidden by the generated Apex code. • Little control over generated code.
  • 10.
    WSDL Support andLimitations • Endpoints of external web services need to be registered under Remote Site Settings. • WSDLs containing apex keywords need to be suffixed with _x. • Limited set of WSDL schema types. • Supports the element and sequence constructs. • Blob, Decimal and enum are supported for call ins but not call outs. • WSDL files with imports are not supported.
  • 11.
    Callout Limitations •Request and response messages cannot exceed the maximum Apex heap size, normally 3MB. • Apex code can make a maximum of 10 HTTP requests in a single transaction. • By default, a single request cannot run longer than 10 seconds. If a transaction contains more than one request, the total time of all requests cannot exceed 120 seconds. • Request size less than 100kb • Timeouts can be between 1ms to 60s. • Circular references not allowed • Loopback connections to SF not allowed • End-point should be registered in remote site settings.
  • 12.
    Asynchronous Callouts via@future methods annotation • Requires methods to be static and have a void return type. • Use this to make a callout from a trigger. • No more than 10 method calls per Apex invocation. • No more than 200 future method calls per SF license per 24hrs. • Parameters to future methods - primitives or collections of primitives only. No sObjects or objects as arguments. • Use @Future(callout=true) to signify a method will be making a calllout.
  • 13.
    HTTP Integration •Full control over the preparation of requests and processing of responses. • Core Apex classes: HttpRequest, HttpResponse and Http. • HttpRequest – methods for working with the request body, HTTP headers, the HTTP method type, client certificates, HTTP compression and timeouts. • HttpResponse – methods for working with raw response body, HTTP status code, and HTTP headers. • Http – has a method called send that accepts a HttpRequest object as input and gives a HttpResponse object as output.
  • 14.
    Other Utility Classes • Send a client certificate with your callout to authenticate a HTTPS connection. • XMLStreamReader class to parse XML coming back from response. • XMLStreamWriter class to create XML that is sent as a request. • EncodingUtil: This class contains methods for URL and Base64 encoding and decoding.
  • 15.
    Crypto Class •Crypto class enables access to external services that require encryption. Crypto methods include: • generateDigest: secure one-way hash digest. • generateMac: computes a message authentication code given a private key. • sign: computes a unique digital signature for an input string. • getRandomInteger, getRandomLong