We're going to go to some extent into general integration concepts in the second post of this series.
I think it will be a good prerequisite on our road to Salesforce Integration.
Integration is the process of connecting systems, regardless of how many systems are involved.
Generally, there are two common architectural approaches:
i) Point-to-Point (coupled)
ii) Mediated (decoupled)
Although both achieve the same goal, they help us achieve it in different ways, with their own benefits and trade-offs.
Point-to-Point
Point-to-point helps connect two systems directly, without anything between them acting as a mediator or broker.
The communication can be implemented using different technologies or approaches such as REST, SOAP, RPC, and others. But the important point here is that the systems are directly connected, which can create tight coupling between them.
For example, assume Salesforce needs data from an ERP to process an order and move it to the next step.
Salesforce and the ERP need to communicate with each other. They could communicate through an API exposed by the ERP, such as a REST or SOAP API.
But here Salesforce has a direct dependency on the ERP's interface. If something changes in the ERP's exposed API — for example, its authentication process changes, the payload format changes, or a new API version is introduced — Salesforce may also need to be changed to work with the new interface.
This is what tightly coupled means here: changes in one system can directly affect the integration logic of another system.
This is just an example to understand the concept easily and doesn't mean that Salesforce and other systems are always integrated this way.
To reduce this kind of direct dependency, mediated integration comes in.
Mediated Integration
Mediated integration is another approach where the systems communicate through an interface or intermediary between them.
This intermediary acts as a mediator for communication between the systems.
This can be broadly differentiated into two approaches:
i) Simple Broker
ii) Orchestrator
Simple Broker
A simple broker mainly acts as an intermediary for routing or delivering messages. It doesn't become part of the actual business process or decide the sequence of business operations.
For example, suppose Salesforce wants some data from SAP.
Instead of Salesforce directly calling the API exposed by SAP, Salesforce can call an interface exposed by the broker. The broker then communicates with SAP and routes the request to the appropriate system.
If SAP's API changes, the broker can handle the required changes at the integration boundary, while Salesforce can continue communicating with the same interface.
The broker can also support request-reply communication by routing the response back to Salesforce.
The goal here is to reduce the direct dependency between Salesforce and SAP.
Orchestrator
An orchestrator goes a step further by becoming involved in the overall process flow.
For example, suppose Salesforce receives an order.
The orchestrator can coordinate the different steps involved in processing that order:
- Communicate with SAP to check product availability for the required region and quantity.
- Communicate with the payment gateway to process the payment.
- If everything succeeds, continue with the next step of the order process.
Here, the intermediary isn't simply passing messages between systems. It is coordinating the interactions between them as part of the overall business process.
Using this example, I hope you have understood the core basics of integration.
Under these architectural approaches, other integration concepts come into the picture.
For example, request-reply, publish-subscribe, batching, synchronous and asynchronous communication, along with concepts such as inbound and outbound integration and technologies or approaches such as REST, SOAP and RPC.
These concepts describe different aspects of how systems communicate, rather than being different types of point-to-point or mediated architecture.
We'll discuss these in further posts in this series.
And in the next one, I won't disappoint you with more theories and general concepts. It's going to include some Salesforce playarounds.
Stay tuned.
Top comments (0)