What is Salesforce Integration?
Salesforce Integration is a process of connecting two or more applications.Enterprise systems use many applications, many or most of which are not designed to work with one another out of the box.
Two systems will connect and communicate, meaning the exchange of data or information between them.
Types of Integration in Salesforce
App cloud empowers multiple types of integration, including API integration, data integration, business logic integration, and user interface integration.
How does Salesforce integrate with other systems?
Salesforce Connect: Salesforce Connect is an integration tool that displays information from external CRMs or ERPs as they were stored in Salesforce. It brings external data into Salesforce and has certain technical limitations.
Integration options available in Salesforce:
REST API, SOAP API, Chatter REST API, Analytics REST API, Bulk API, Metadata API, Streaming API, Apex REST API, Apex SOAP API, Tooling API.
Postman: Postman is an API(application programming interface) development tool that helps to build, test and modify APIs. Almost any functionality that any developer could need is encapsulated in this tool.
We are extracting data from Epic on the FHIR external system.
This is Test data from the Epic system. Here, the Patient's Name is Camila Lopez, and FHIR is the patient's ID.
Applicable resources refer to Patient details like Patient Info, Diagnostics Report, Procedure, Conditions, etc., or in simple words endpoints available for the patient.
In our case, we are storing this FHIR-Id in the SourceSystemId field so that if we add Flex Card on the record page then based on the source system ID Patient details will be displayed.
Note: Epic's work with FHIR means that any health system, hospital, or clinic that uses Epic's comprehensive health record system can connect to any app that also supports FHIR to exchange health information, including but not limited to the U.S. Core Data for Interoperability – or USCDI - data classes and elements.
Before that, let us perform the pre-requisites in the Org.
1. Integration setup
We are using a Generic Fhir Client(GFC) Application so this has to be enabled.
Once we enable GFC it will deploy the Mule Application to Cloudhub and a Named credential is created in the org.
Here you can see the Target URL: Anypoint (we use the Anypoint platform as a Cloudhub).
URL is the base URL for the external application.
App Name: genericfhirclientapp.
CloudHub: It is a service where you can deploy and run Mule Applications.
Note: To enable the GFC application we have to provide Clientid, ClientSecret, TokenUrl, etc since the GFC app is getting data from external systems. Data has to be secure.
We can see this in the Properties of RunTime Manager section in the Anypoint Platform.
2. Named credential
Need to Provide Name, base URL of the external system in the URL field, and Authentication Protocol whether its basic Oath, No Authentication, etc.Note: If we want to check or change the Password for this Application we need to log into Anypoint Platform(Cloudhub), in the API Manager section you can check the Password.
Note: A named credential refers to an external credential, and multiple named credentials can benefit from sharing a single external credential. For example, a Salesforce integration can access the APIs for Google Drive and Google Calendar with the same credentials.
Note: We can test our data coming from external systems in Postman and also in the Integration procedure.
Postman is used for backend testing where we enter the endpoint URL, send the request to the server, and receive the response from the server.
Calling External API in Integration Procedure
We have created an Integration Procedure and added an HTTP callout action to it. Note: Patient ID is stored in the SourceSystemId field on Account and we are extracting using Dataraptor extract with the name PMRN and storing in SetValues because we need to pass patient ID dynamically.
The HTTP method is Get - we are fetching patient details from an external system.
Named Credential Api name we need to provide here which is holding the reference to an external credential.
HTTP Path is dynamic since the Patient ID is coming from the Record SourceSystemId field.
Headers are optional based on the external API call. In our case, it is required.
We are using DataRaptor transform after the HTTP Callout because we want to transform the XML data to JSON and need to pass JSON data to Flex cards in record Pages.
This data is for the Patient Endpoint we are getting from Epic External System. Similarly, we can get the data from available endpoints for the Patient.
Note: Integration from an External system can be done using Flows as well. For more information refer to this - https://admin.salesforce.com/blog/2023/integrations-are-easier-than-ever-with-flow-http-callouts
Data field mapping and Flexcard:
We are storing external Patient FHIR ID in the Accounts Source system field. If we add Flex Card to the record page it will fetch endpoint details based on the record Source System Id value.
References: Get to know more about Integration with external systems-
Comments