SFDC Outbound Integrations

1. Outbound Integrations
Sujit Kumar
Zenolocity LLC © 2012 - 2024

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

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

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

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

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

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