This article is continuation towards my other articles related to Salesforce Integration & OmniStudio capabilities. Few years back, I was not ready to recruit a Salesforce developer without APEX & Integration skills. APEX and Integration used to be considered as premium Salesforce skills.
Things are changed completely in last few years and thanks to Salesforce innovation team. Today, as an architect, I am able to avoid APEX for most of the requirements. We are not at “No Code” stage yet, but we are able to deliver projects with “Low Code”.
In this article, I am going to design an Integration solution without writing a single line of code. I am not talking about using standard Salesforce API here. Solution is going to support all the decisions (IF / ELSE), Looping, Transformation and you do not have to write single line of APEX code.
As always, I am going to consider a real-life but hypothetical integration requirement and would be outlining the solution that we can use to achieve this.
Integration Requirement
ABC Enterprise is using Salesforce Sales Cloud to manage their Sales Organization and Salesforce Service Cloud to manage call center and support process. Salesforce is source of truth for Opportunities and Cases.
ABC Enterprise also maintains a custom-built portal application that is used by partners. This portal provides 360 Degree view of a client that includes client basic details along with active contacts, open opportunities, and open cases.
Also, we would like to define our own JSON attribute name and do not want to use a name with __c suffix for custom fields. We may need doing basic transformation like concatenating few fields and simple picklist transformation. Additionally, you may also want to log the request source in a custom object used for logging and auditing.
Potential Integration Designs
To meet this requirement, we need a Salesforce service that would receive a client Id (not salesforce Id) as input, and it would extract necessary data from Salesforce and do some basic transformation.
At high level I see two different solutions here:-
Using Salesforce Standard REST API with Middleware Tool
If we have middleware tool, we can use Salesforce standard API that may use composite API to get necessary details from Salesforce. Doing necessary transformation and passing the transformed message back to portal.
Having a middleware always moves complexity away from Salesforce. This can be accepted design here and can be evaluated if we have a middleware and we are not expecting any pre or post processing by Salesforce service.
Publish a Custom Service
This is the other approach that most of the time we have to go with for similar requirements. We have to publish our custom service that extracts, transforms and provide the necessary details as output. It can also do any pre and post processing as needed for this service.
We have been using APEX to create custom service in past and it provides all the flexibility. APEX can still be used for this requirement for publishing a custom service that external system or middleware tool can access.
With OmniStudio in place, we can use power of Integration Procedure. We can create an Integration Procedure that would extract the data using OmniStudio DataRaptor Extract action, will do simple transformation using formulas and can-do complex transformation using DataRaptor Transform action. It can also do any pre and post processing using different actions available in Integration Procedure palate.
Integration Design Decision
Since this article is focused on sharing power of Integration Procedure as a service, we would like to go ahead with this option. Exposing Integration Procedure as a service would be a great design for this kind of integration requirements if we have OmniStudio enabled. Some of the benefits are: –
- Integration Procedure is a configuration tool and it does not require any APEX coding
- Integration Procedure provides set a of actions that can be used to meet our requirements. Some of the actions that can be used in this scenario:-
- DataRaptor Extract Action to extract Account with Opportunities and Cases
- DataRaptor Transform Action to do any kind of complex transformation
- DataRaptor post action to create a log record for audit purpose
- Response Action to return the necessary output
- It is easy to maintain and modify the Integration Procedure
If you have not explored and mastered OmniStudio then this is the time. You can design complex business process and guided workflow without writing single line of APEX code. Integration Procedure as a Service is other great use case that we are discussing here.
High Level Solution Steps
I have listed high-level solution here. We just need to create a DataRaptor and Integration Procedure for this.
DataRaptor Extract Action
A new DataRaptor Extract action is created to extract Account with related contacts, related open opportunities, and related open cases. This would take Client Id as input to extract details. Refer below screenshot for reference and explore DataRaptor Extract in more details here
You can include the necessary fields, define the name for the JSON attributes. You can also create simple and complex formula in DataRaptor.
Integration Procedure
We need to create a new Integration Procedure that would be called by external system or middleware tool like a standard API. We can have very complex nested Integration Procedure for our integration requirements but for this requirement it is going to be simple few steps IP only.
We just need to use a DataRaptor Extract action to extract the necessary data from Salesforce. If we have to do complex transformation, we can have DataRaptor Transform action but in this case, it would not be needed. We can have a DataRaptor Post action to create a log entry. Additionally, we would require a response action to return the necessary output.
Below screenshot refers a sample Integration Procedure we created for this demo purpose. Make sure you test your Integration Procedure using sample data in preview to ensure it is working as expected.
Invoking Integration Procedure using REST API
We do not have to do anything else to invoke Integration Procedure as a service. Integration Procedure can be invoked as REST API. It can be invoked as GET or POST. This Integration Procedure just requires a single input so it can be passed as GET or POST but when you invoke an Integration Procedure that requires complex JSON, we can use POST. To get more details, refer Salesforce documentation here
This is the URL that I am going to use for Integration Procedure that I configured to use as a service.
/services/apexrest/omnistudio/v1/integrationprocedure/CRMView_GetAccountDetails/
We have to include namespace and type/subtype of Integration Procedure to form the URL.
/services/apexrest/{namespace}/v1/integrationprocedure/{Type}_{SubType}/API Testing using Workbench
We can test our Integration Procedure as a Service using Workbench or any other REST client.
Summary
Integration Procedure as a Service is a new way to design your integration with no code solution. This can be used to design a simple service to very complex service, and we do not have to write a single line of APEX code.
This article provides high-level solution for an Integration Requirement, and you have to do necessary changes to make it production ready.