When I was interviewed for my role at MuleSoft a few months ago, I was asked if it was possible to have more than one System API layer. I froze — and it’s possible this question has crossed your mind as well.
After the interview, I sketched out some use cases to figure out the answer to this question. It did not take long for me to understand that API-led connectivity is not strictly restricted to three layers — System API, Process API, and Experience API — but that this is just a starting point. The key to success is using the layers effectively and flexibly.
The myths about three layers are:
- All three layers are mandatory and fear of any anomaly might lead to failure.
- Building APIs in every layer for security whether or not ideal.
- Building APIs for agility without gauging whether or not applicable.
These myths create challenges of their own:
- Increased cost of implementing the APIs, complexity, operations, and maintenance.
- SLA impact can cause overhead.
- Giving the consumer inaccurate or more elements than what they should consume.
Much like a cake, your application network needs to be layered with appropriate patterns and baked so it tastes well in production. The trick is to figure out how many layers you need!
Choosing your flavor: Picking a use case
Let’s take a look at the ingredients that we need for the use case of a retail industry for supply chain management, and various systems that an organization typically uses to handle their business. We’ll use a retail example here:
The retail business procures goods from various trading partners and communicates via EDI files exchange.
MuleSoft provides Anypoint Partner Manager with advanced features, such as trading partners onboarding, transaction tracking, advanced B2B operational metrics, and more. However, this use case uses a traditional Anypoint EDI connector (EDIFACT, X12) to give you a gist of patterns.
On the other hand — purchase order, shipment, receipt, and invoice status are tracked as purchase order tracking to be consumed by Vendor Web Portal or a mobile app. Further, these transactions will become part of analytics for KPI metrics and the cost from the ERP will be exported to EDW on a daily basis as part of profit and loss plumbing.
The big picture recipe using an API-led approach, looks like this:
Now, it’s time to learn how to make the cake!
Baking the cake: 5 different API-led patterns
While you can name them as you like, I took the liberty of naming my different baking options.
Pattern 1: The three-layered approach
Layers: MuleSoft System API, Process API, and Experience API
Approach: This is the common approach that you’ll encounter for the first time when learning the API-led approach. In this example:
- WMS and the bank systems do not provide their own APIs. Hence, the system of records are unlocked by building MuleSoft System APIs for inventory and payment information.
- Purchase order tracking is orchestrated to get the status of various stages of the purchase order life cycle. For this logic, building a Process API layer is required.
- As there are two different consumers — Mobile API and Web application API — each requires an Experience API.
Inference: The classic benefits of this approach are increased reusability of APIs, clarity of ownership, and easy to manage any changes to source of record systems. It also provides an Experience Layer to drive the consumer first/ product-focused approach.
Pattern 2: The three-layered approach with buddy-buddy system layers
Layers: Non-MuleSoft System API, MuleSoft System API, Process API, and Experience API
Approach: The Non-MuleSoft System API layer has APIs of the downstream ERP system which acts as the provider. These non-MuleSoft System APIs could be SOAP and REST APIs.
- A MuleSoft System API is built as a wrapper or a proxy API. Some of the examples could be Find-Purchase-Order along with UOMConversion (when supplier UOM and the business UOM are different), shipments, receipts, and invoices. These become part of the MuleSoft System API layer.
- A set of Process APIs — such as shipment status, purchase order, invoice status, receipt status, or purchase order tracking is built as part of the Process API layer.
- An Experience API is built around these statuses to be consumed by corresponding consumers, such as mobile and web applications.
Inference: This is a pattern where the downstream source of records system provides its own APIs. To get the complete purchase order (Ex: PO and converted UOM), a MuleSoft System API is needed. This enables loose coupling to achieve agility. Now that we have System API proxies created, we can manage QoS to backend non-MuleSoft system APIs using policies like throttling. The Process APIs can be integrated with reusable System APIs with reduced complexity.
Pattern 3: All System and Process, but no Experience Layer
Layers: Non-MuleSoft System API, MuleSoft System API, and Process API
Approach: In this scenario, the system of records are unlocked using Non-MuleSoft System SOAP/REST APIs of ERP and transportation management system.
- Mulesoft System APIs for purchase orders, shipments, receipts, invoices, inventory, payment, and transportation are built as a proxy.
- Process APIs are built for orchestrating through various flows for purchase order tracking.
- As the definition of Process API and analytics are the same, there is no need to build an additional layer except in case of anticipated changes to Process API definition.
Inference: This Process API is owned by analytics team and fit for use that eliminated the need for an Experience Layer. This pattern demonstrates how internal product-focused Process API was created and owned by LOB which utilizes information from third-party APIs.
Pattern 4: MuleSoft System and Process Layers only
Layers: MuleSoft System API and Process API
Approach: In this scenario, as WMS and the bank do not provide their own APIs.
- The system of records are unlocked by creating a MuleSoft System APIs for inventory and payment from WMS and banks.
- Process APIs are built for orchestrating through various system flows for tracking the statuses of shipment, receipt, and invoice.
- As the definition of Process API and analytics are the same, there is no need to build an additional layer except in case of anticipated changes to Process API definition.
Inference: This is similar to the above use case where the Process API was a fit for use candidate for analytics. This approach is another example in which not every layer is required to promote agility and usability. It is also extensible enough to unlock data for any other consumer channels. On the other hand, this manages fewer APIs. However, if a new channel is added we can always evaluate if this pattern will work as-is or if another pattern is needed.
Pattern 5: Only a MuleSoft System Layer
Layers: MuleSoft System API
Approach: For-profit and loss reconciliation purposes, the cost needs to be extracted to EDW (data warehouse) on daily basis.
- A MuleSoft System API is built to perform the cost file transfer from system (source) folder to the common business folder from where EDW picks up the file.
- This cost export is just a small piece, but there is another area of integration with ETL to explore.
- As this use case does not involve any message processing and no business logic is involved, the need to have a Process API doesn’t arise.
Inference: File transfer process here is a single API that polls from an ERP location and drops into common folder which provides flexibility around consumption by any application or systems with economic maintenance.
The moment of truth: The taste test!
While these patterns are just an idea of design but aren’t the same as production. The factors that impact in building robust architecture such as:
- Performance and SLAs
- Security
- Deployment topology (cloud, on-prem, hybrid)
- Additional lines of business, acquisitions, and re-modelling
- Unexpected pandemics, etc.,
These other factors need to be considered before you go deep in production and any future changes that will help to inform which recipe works best for you.
While I enjoy the layer cake that I help my customers bake, there are even more recipes out there with B2B flavor and a whole cookbook laying patterns that can provide a jump start to your cake layering adventures. Happy baking!
