Meta description:

This article discusses API-led connectivity's three-layer architecture (System, Process, and Experience API), and how it enhances productivity by streamlining data flow and reducing code duplication. It illustrates the benefits of API-led connectivity through a practical scenario.

IntroductionIn the first part of the series, we have understood the basic concepts of MuleSoft’s API-led connectivity and how it helps guide businesses towards composable, agile, and automated digital transformation, it is time to jump into the more complex aspects. In today’s blog, we will discover the structure of an API-led connectivity architecture and how it helps increase productivity.

Read more: MuleSoft API - led Connectivity (Part 1)

The three-layer cake

The first thing about API-led connectivity’s structure is that it comprises 3 layers and each has its roles, responsibilities, and functionality. Furthermore, each layer is represented using a particular type of API that fits those aforementioned requirements. As mentioned in the previous blog, “API-led connectivity is an architectural approach to connect data to application through reusable and purposeful APIs. These APIs are developed to play a specific role: unlocking data from systems, composing data into processes, or delivering an experience.”

We will now discover more about these APIs by going through each one.

System API

System API is the first and the only layer interacting with the data sources – the core systems of record. This type of API is used to access underlying systems and expose their data, often in a canonical format. Moreover, this layer provides a means of insulating the user from the complexity or any changes to the underlying systems. Therefore, users can fetch data without the need to learn or understand said systems and can reuse these APIs in multiple projects.

A few things worth noting about the System API:

• Fetching raw data from the backend systems is one thing but cleaning them up is also important to avoid cluttering the user with data. System API can do both.
• System APIs are generally deployed within a private network as they are responsible for exposing raw data from the core systems.
• System APIs are also responsible for exposing the data fetched from the backend systems to the upstream API (Process or Experience Layer) in a secure and reliable way.

Process API

Process API is the second layer, which sits above the System API layer. One Process API can call one or multiple System APIs in order to collect all data that fall into the same category or data that serves a specific business logic. Process APIs are responsible for shaping the data retrieved from various System APIs to implement the business logic, data aggregation, etc.

For Process API, there are also some checkboxes:

• Process API is the orchestrator of data as it orchestrates the calls to System APIs and decides which data is important to the underlying business processes.
• Process APIs, just like System APIs, are not generally exposed publicly and must be deployed in a private network. Because the business logic and processes of an organization are just as important as the raw data collected to implement them.
• Process APIs are responsible for exposing the aggregated and shaped data to the upstream APIs (Experience).

Experience APIs

Experience APIs, as the name suggests, aim to deliver an excellent experience to the end-users. Nowadays, people have access to information through all kinds of channels: newspapers, magazines, mobile applications, web applications, etc. Additionally, one piece of information can be displayed/exposed in a variety of formats depending on the channels. For example: an e-commerce company has a website and a mobile application, both of which can display information about their customer, but one will require JSON format while the other uses XML. What Experience APIs do is shape data that they receive from the downstream layers (Process & System) so that it fits the requirements of an end-user and exposes that newly shaped data to the end-user.

Assembling the layers above, we will have a three-layer cake that looks something like this.

Picture source: Salesforce.

As you can see here, this architecture creates a smooth and stable stream for data to flow through and reach its audiences. Each system API corresponds with one core system and will fetch data when there’s a request above. Each Process API is capable of calling multiple System APIs to aggregate data and using them to implement a particular business logic. And finally, the experience APIs will transform the data into the required format so that the end-users can see what they want to see.

How does API-led connectivity increase productivity?

To have a better understanding of the benefits that API-led connectivity brought to the table, let’s look at a simple scenario: Suppose we need to develop a web application to provide real-time order status and order history for the sales team to engage with customers. Assuming we have customer data in SAP and Salesforce, inventory data in SAP, and order data in an e-commerce system.

The old way of integration

In a traditional point-to-point integration approach, the IT team might possibly aggregate customer data by wiring customer data from both SAP and Salesforce with code. Then, the aggregated customer data is combined with the order data from the e-commerce system to produce both the order status and order history with even more code. Finally, these two data sources are fetched by an external API which is leveraged by the web application.

This method works as it satisfies the business logic and is delivered on time and budget. However, what would happen if the IT received a request to build a mobile app with the same process? Clearly, they cannot use what they had already delivered for the web app as the code that they wrote was specifically written for the web app. They have to start from scratch and that alone has already increased the cost of development. Moreover, the effort to build a brand-new app will further hamper the productivity of the entire project. Thus, we will stumble upon an undesirable “spaghetti” code pattern.

API-led connectivity to the rescue

But it is a different story with an API-led connectivity approach. When the IT team is tasked with a new mobile app, they can reuse the building blocks that they had created for the web application, eliminating most of the unnecessary work to build them.

Already we can see the difference in the architecture. The reusable APIs make a big difference and help avoid the spaghetti pattern from point-to-point integration. Creating the mobile app, therefore, is a matter of rewiring instead of recreating. As a result, IT teams have more time and opportunity to innovate and add new features. This is the key to driving agility and guiding businesses toward a more composable process.

Conclusion

After reading today’s blog, we hope that you understand the exceptional architecture of MuleSoft's API-led connectivity model. This architecture comprises of 3 layers of 3 different types of API:

• System API: the base layer that interacts with databases, core systems of records.
• Process API: the middle layer that defines the business logic and processes by shaping the data collected from the base layer.
• Experience API: the top layer that displays information in a suited format that satisfies the requirement of the end-user. This layer aims to deliver a seamless experience.

If point-to-point integration makes IT’s job more complicated by creating a huge pile of spaghetti code, API-led connectivity offers reusable, composable building blocks to facilitate the development process. Moreover, by dividing the architecture into 3 separated layers, developers can easily track the data flow, debug if needed, and have a better understanding of the entire system. The entire integration system becomes well-structured, delivers a clear understanding of the underlying processes and most of all, each building block is reusable with API-led connectivity. In the next and final part of this subject, we will discuss the different ways to use API-led connectivity in different scenarios and some real-life case studies.

Looking for the top Salesforce partner in Vietnam? Contact us here.