API Led Connectivity in Mule 4

 API-led connectivity is a standard or concept which enables layers of services to integrate heterogeneous applications in a reusable manner. It breakdown the integration implementation basis on the usage or functionality of the API. Below are the layers of the APIs

1. System API: System API will be used to connect with backend systems like Database, Salesforce, Workday, Oracle ERP, SAP, Concur, FTP, etc.

2. Process API: Actual business logic will be done by Process API. This API will connect with System API and perform the orchestration, enrich the data, and perform some validation.

3. Experience API: This API will be exposed to the client or caller of the API with the required format of request and response data. It will call Process API and transform the request & response payload as per client need.

 

It's not mandatory to use all three system APIs in every use case. It depends on the requirement and budget of the customer and other factors too like security, the complexity of the use case, etc.

 Case 1: You can develop the integration with only one layer which will work for all the three layers like system, process, and experience. In this approach below are the advantage and disadvantages.

Advantages

• Design and Implementation will be easy
• Easy tracking of the execution flow

Disadvantages

• No Reusability
• If any backend system changed then the complete API may be revamped
• If the same set of data is required in another format for another client then another implementation will be required
• Tightly coupled
• Initially seems cheaper but later on becomes costlier

 

Case 2: You can develop the integration with two layers system and process or experience layer. In this approach below are the advantage and disadvantages.

Advantages

• Partial reusable
• If the backend system changes then no or minimal changes required in other API

Disadvantages

• Partial reusable
• If the same set of data is required in another format for another client then another implementation will be required
• Tracking becomes complex to debug execution flow

 

Case 3: You can develop the integration with all the three layers system and the process and experience layer. In this approach below are the advantage and disadvantages.

Advantages

• Completely reusable
• If the backend system changes then no or minimal changes required in other APIs
• Loosely coupled
• With the time becomes cheaper

Disadvantages

• Complex design and implementation
• Difficult to debug execution flow

Although the three-layer approach is complex in design and implementation and difficult to debug,  besides this Mulesoft recommends three layers approach. The question is why?

Let's understand it with the use case

If your organization is using Oracle ERP for financials and AP invoice details need to send to one supplier in JSON formats along with some set of data from salesforce. In this case, there are two backend systems that will provide the data separately, and then you have to validate and aggregate the data and at the end, you can produce the data as per the client's needed format i.e. JSON

IF you are using only one layer then you may have to create a single API that will connect with ERP and SFDC to get the details and the same service will aggregate and validate the data and  procedure the output in JSON format

But after some time one more supplier needs the same set of data but in a different format like CSV then with this approach, you have to create a complete API which will again cost similar to prior implementation and deployment. It means it will increase the overall cost 

If you are using two layers(System API and Process/Experience API) then in this approach only process API will be required to create again it will be less costly than the layer one approach. But what happens if some extra validation is required by calling another system i.e. SAP. Then you have to implement the validation part in each Process OR Experience API. It will again cost more in terms of effort and implementation.

If you are using three layers then validation will be done in only one layer i.e. Process layer and there will not be any change in other layers. So with time and usage, it will save the cost.

With multi-layer, you have to use correlation ID to track the execution flow and proper logging and error handling will be required. The same correlation ID will be passed to all the three layers to track the flow to identify the unique instance of the request otherwise very difficult to track the flow.