At the time when I was doing my higher education (2005) we touched the cloud computing topic in theory. Most of the systems we learnt and built were running on premise servers or in a data center. I started cloud computing as a Salesforce developer in 2009, then I worked for a middleware product company and now I am back to Salesforce.
Accordingly in businesses there are legacy systems which still function and add value. On top of this there are new systems running to cater new requirements. This leads to the requirement of integrating different systems. Cloud platforms become the first choice for new systems because of their fast development, less/no maintenance, reliability and pay-as-you-use pricing plans.
The integration architecture becomes very important for business use cases. It should align with the business strategy and should be based on business service level agreements. It should also support a mix of asynchronous and real-time processors. Integration architecture should have clearly defined standards for implementing different use cases. Last, it can be split into 3 categories: cloud to on-premise, on-premise to cloud and cloud to cloud.
1. Cloud to on-premise
In this pattern, most of the time Salesforce initiates the communication. The message is sent to a DMZ end point (either an API gateway, reverse proxy or firewall). This is where security authentication methods such as whitelist IPs, two way SSL and, basic HTTP Authentication occur. DMZ forwards the message to the on-premise infrastructure, typically an ESB which then may push the message to the SOA infrastructure, source system, Database, etc.
This can be implemented in a synchronous (in real time) or asynchronous (as a batch job) way, based on business requirements.
1.1 Real time integration
Let’s say you want to update another system whenever there is an object updated in Salesforce. In order to achieve this, developers can create triggers on Salesforce Objects and make a callout using a future method. This is a very good approach since Salesforce does not have any limitations on callouts. But it only supports up to 100 callouts per transaction, which is a very high limit. On the downside, if the other system is down when this happens, we need to design another flow for failed updates.
New to this is Queueable Apex where developers could implement chains of asynchronous processors (callouts) that depend on each other.
Salesforce also provides the streaming API where external systems can listen to Salesforce events. With this method, events are durable up to 24 hours. Also there is no requirement to expose on-premise system via a public IP (DMZ). Another advantage is there are no limits per day, except the number of subscriptions (That is 1000–2000 based on your licence).
1.2 Batch Processing
Salesforce has batch jobs that can be scheduled to run on periodical intervals. Batch jobs can be used to sync data from Salesforce to on-premise (ground) systems. One way to do this is to mark the updated records by using a trigger. Then you can get those records in the batch job and pass them on to the other system. Once successful, flags can be reset at the record level.
2. On-premise to Cloud
Salesforce provides Soap and Rest APIs to connect to your organization. There are different types of authentication mechanisms supported: Basic auth, Oauth 2.0. Most architectures use a middleware layer to connect to Salesforce. There are lots of connectors (adapters) developed by most of the vendors to make this integration easy and fast. E.g: Microsoft Azure connector , WSO2 ESB Connector etc. Some vendors even provide out-of-the box solutions (templates) that can be leveraged to send large data volumes.
Usually an API supports single sObject CRUD operation per call. Also there is a limit on the number of calls per 24 hours based on the org licence. If customized APIs functionalities are required, those can be developed as SOAP or Rest-based services using Apex.
3. Cloud to Cloud
Usually, different systems in an organization are not running on the same platform. Even with the Cloud there are different options. Most of these cloud systems provide APIs to integrate. Also integration products provide connectors/adapters for these systems. Mule ESB is very famous for providing adapters. Also there are iPaaS that run the integration of cloud services. Dell Boomi, IFTTT are such platforms, providing capabilities to build integrations to data analysts. Companies such as Mulesoft, WSO2 provide platforms for developers, where they can build their integration use cases. Also, integration can be built inside Salesforce using Apex.
Salesforce2Salesforce – a solution provided by Salesforce – can be used to connect to other Salesforce instances.
Conclusion
Salesforce provides a variety of options to integrate with other systems. Building durable and resilient integration solutions inside Salesforce is achievable but challenging. If the integration is simple and you have expertise, by using Salesforce, you can build the integration. Stay away from building complex integrations, use instead an iPaaS solution whenever possible. Building and maintaining an on-premise integration platform is complex and requires technical expertise. If the integration is very simple it does not make sense to build a platform.
