Unwired API-Led Connectivity

API-Led Connectivity

MuleSoft’s API-led Connectivity is a methodical way to connect and unlock data from systems and devices, composing data into processes, or delivering an experience through reusable and purposeful APIs that become primary building blocks for addressing enterprise grade integration needs and digital transformation. Based on Gartner’s Pace-Layered Application Strategy, it is intended to categorize, select, manage and govern applications APIs (microservices), divided into 3 categories: Experience APIs, Process APIs and System APIs, where in this context, terms such as “API” and “microservice” are often used to refer to Mule applications exposing RESTful web services and in this post I will use the same terminology.

Unwired

The picture above implies that API-Led Connectivity has to be done in a way that the communication between the APIs has to be done synchronously, where Experience APIs are bound to make HTTP call Process APIs and these last ones call System APIs also through HTTP protocol. Nothing wrong with that approach, however it is not fully decoupled as one API depends on the other within the 3 layers and also restricts the solution to only work with HTTP protocol and connector rather than possibly one or more of the other hundreds available in Mule.

This POST aims to present a different way of thinking and designing the collaboration between APIs in a truly decoupled and asynchronous way, still maintaining the layering and collaboration between them, purely using Anypoint Platform tools at the integration layer. That can be achieved by implementing publisher/subscriber model and leveraging Anypoint MQ, where not only Mule applications, but virtually any rest client can collaborate by publishing and consuming messages from queues.

In order to better explain this model, I have created a fictitious scenario where a company stores Product Offerings in Salesforce and wants to integrate that data with underlying 3rd party FTP, a Retail POST system that exposes an API and a Showroom Application Cache DB, according to the family of product. The diagram below illustrates how it would look like:

On top of implementing a de-facto unwired (truly decoupled) API-Led Connectivity, we are also saving on computer processing power, since rather than MuleSoft polling Salesforce for new or modified products, Salesforce is responsible for calling an API exposed by MuleSoft to notify new or modified products, working in a reactive, event-driven way.

Practice

For the developers reading this, as usual, now things becomes really interesting as we are about to prove that the theory is right by implementing the Mule applications that comprise this solution, except for the fact that we are going to implement only one of the experience APIs, the Construction Products Experience API.

Queues

Let’s start with the beating heart of that solution, Anypoint MQ where 3 queues will be created:

The next thing is to create client applications for the 3 APIs that comprise the solution:

System API

After creating the queues and the client applications, we can switch to Design Centre and create the RAML for Product Offerings System API, which will be called by Salesforce to notify new or modified products:

When finished and ready to be implemented, we can switch to Anypoint Studio and implement the API, where the implementation flow publishes product notification to Anypoint MQ:

Process API

The next thing will be the creation and implementation of the process API from where we subscribe to Product Offering Events and this demo only routes the event to the appropriate destination, according to product industry. If there isn’t a queue correspondent to the product industry (construction), the message gets published to an "unidentified industry" queue:

Experience API

At that stage, both system and experience APIs have been implemented, so we just have to implement the Construction Product Offerings Experience API, which for this demo only logs the payload received from Construction Product Offerings queue:

Solution Execution

Once all the 3 APIs are ready and deployed to Cloudhub, requests can be sent to the System API and the final result can be seen as log entries in Construction Products Experience API log if the product industry is “construction”.

Otherwise the message will land in the “unidentified” queue:

Conclusion

MuleSoft’s Anypoint Platform is a full-blown enterprise integration platform, which caters for all sorts of integration patterns and styles. It leverages an enormous number of out-of-the-box, enterprise grade connectors for a number of platforms that run in the cloud or on-premises, via several application-level protocols - Synchronous, asynchronous, mix-and-match and beyond… You name it!

Happy integrations!

Author

Eduardo Ponzoni works for Datacom New Zealand as an Enterprise Integration Development Manager and is the MuleSoft Practice Lead. He hails from Sao Paulo, Brazil and has over 18 years’ experience in the IT industry, having been in a technical leadership and managerial role with Datacom for about 3 years. He is well versed in integration practices and has a number of certifications in numerous technologies including MuleSoft and Microsoft.

To get in contact, feel free to reach out via LinkedIn or email