Complete Guide to Salesforce Integration – Beginner’s Basic 101

Integration, in simple terms, is communication between two systems. Integration can be for the transfer of data or logic as well as for other functions. Most of the integration on enterprise-level applications cater to different layers of integration such as Data, Business Logic, and User Interface.

Let us look into details, from the scratch we will try to go into as much details as needed in upcoming posts.

How to Integrate?

We use SOAP/REST based on the requirements. Check the difference between SOAP and REST.

<Client> ======== Integration layer (soap/rest) ========<Server>

SOAP API Terminologies

SOAP Integration Methodology

1. Create a webservice method on the server system.
2. Generate WSDL file for the created class and share it with the client to expose the webservice. 
3. Generate Partner/Enterprise WSDL on the server system to share with the client for authorization/sign-in.
4. Consume/Parse both the WSDL files in the client system to generate apex code. Two apex classes are auto-generated for the webservice WSDL: service class for synchronous service and a modified version for asynchronous processes. Parsing the other WSDL also results in four apex classes.
5. Invoke the webservice from the client system: Using the details from the WSDLs we instantiate the classes and pass required session details for authentication on the server. Thereafter, we pass the request parameters and process the response.

WSDL

Web service description language, an XML format file describing services as a set of endpoints operating on messages. Some pointers to remember.

• To expose a SOAP web service method we create an apex class 
• The apex class must be declared as global.
• The exposed method must be declared as static. It must use a webservice keyword.
• Remember, the webservice method always runs in the system context.

We have two types of WSDL: Partner WSDL and Enterprise WSDL to look into details.

Checkout this Beginner’s Basic 102 for demo on SOAP API Integration

A more efficient way to get session Id without parsing separate WSDLs for authentication is using a Connected App. For a connected app to request access, it needs to be integrated with the Salesforce API using the OAuth 2.0 protocol. 

Connected App

It is a framework that enables an external application to integrate with Salesforce using APIs and standard protocols, such as SAML, OAuth, and OpenID Connect. Connected apps use these protocols to authenticate, authorize, and provide single sign-on (SSO) for external apps. The external apps that are integrated with Salesforce can run on the customer success platform, other platforms, devices, or SaaS subscriptions.

1. Access data with API Integration
2. Integrate service providers with salesforce org for assessing hosted applications with salesforce being the identity provider.
3. Manage levels of access to third-party apps.
4. Provide authorization for external API.

OAuth 2.0

It is a token-based open protocol that enables authorization and secure data sharing between applications through the exchange of tokens. When developers want to integrate their app with Salesforce, they use OAuth APIs enabling users to work in one app but see the data from another.

When the client/end user authorizes through Oauth, the authorization server grants an access token for the client. The Client can now request access to the protected resource on the server along with the issued access token. The server delegating the authorization can now validate the token and provide the requested access.

Access Token

Instead of using the user’s Salesforce credentials, a consumer (connected app) can use an access token to gain access to protected resources on behalf of the end-user.
For OAuth 1.0.A, the access token is exchanged for a session ID.
For OAuth 2.0, the access token is a session ID itself and can be used directly.

Authorization Code

It is used in OAuth 2.0 with the web server flow. The authorization code is a token that represents the access granted by the end user. The authorization code is used to obtain an access token and a refresh token. It expires after 15 minutes.

For first-time authorization, we require sending credentials to salesforce to initiate the OAuth authorization flow. Salesforce sends access and refresh tokens as confirmation of successful authorization. Once the session is inactivated, the external app uses the refresh token from its initial authorization to get an updated session. More terminologies here…

Different OAuth flows in Salesforce

Web App Integration (OAuth 2.0 Web Server Flow)

To integrate an external web application with the Salesforce API, use the OAuth 2.0 webserver flow. With this flow, the server hosting the web app must be able to protect the connected app’s identity, defined by the client ID and client secret.

Mobile App Integration (OAuth 2.0 User-Agent Flow)

Mobile Apps built on Mobile SDK implements OAuth 2.0 user-agent flow for the connected app, to integrate the mobile app with your Salesforce API and provide authorized access to data.

Server-to-Server Integration (OAuth 2.0 JWT Bearer Flow)

For server-to-server integration, you can use the OAuth 2.0 JSON Web Token (JWT) bearer flow.

IoT Integration (OAuth 2.0 Device Flow)

To integrate devices with limited input or display capabilities, we configure connected apps with the OAuth 2.0 device flow. End users can authorize connected apps to access Salesforce data using a web-based browser.

Other OAuth API Integration Flows

OAuth 2.0 Refresh Token Flow
OAuth 2.0 Username-Password Flow
OAuth 2.0 SAML Bearer Assertion Flow
OAuth 2.0 SAML Assertion Flow

Single sign-on (SSO)

SSO lets users access other applications without logging in separately to each one—and without having to create (and remember) different user credentials for each app. Similar to the Google and Facebook social sign-ons we use every other day.

Identity Provider: A service that enables users to access other external applications without logging in again.
Service Provider: A service that accepts identity on behalf of the external application from an identity provider.

With Salesforce being the identity provider, we can use a connected app to integrate a service provider with your org. For this type of SSO flow, the connected app implements SAML 2.0 or OpenID Connect for user authorization.

SAML and OpenID Connect for Single Sign-On

Integrating a service provider with your Salesforce org, we can use a connected app that implements SAML 2.0 for user authentication. Users can log in to the external app with their Salesforce credentials. 

Like SAML, OpenID Connect is also a protocol that enables SSO between two services. Unlike SAML, OpenID Connect adds an authentication layer on top of OAuth 2.0 to enable secure exchange of ID tokens that contain user information alongside OAuth access tokens. The OpenID Connect scope passes user information in an ID token. Users can then log in to the external app with their Salesforce or Experience Cloud credentials.

Interested in Reading more technicalities? Read this interesting article on Medium!