Introducing API templates with reusable System and Process APIs

In today’s world, APIs are used to abstract the complexity of systems of records, to provide secure connectivity to the end systems, and to accomplish business goals such as creating a unified view of a customer. But APIs alone cannot accomplish all integration use cases. For example, when you want to send data from won opportunities in Salesforce to SAP for invoice creation, on top of using APIs, you will also want to do data migration and/or data synchronization to accomplish this use case.

To help our customers drive consistency and reuse while addressing such use cases, we are introducing API templates. API templates comprise of reusable “system APIs”, “process APIs”, and templatized orchestration to quickly address common use cases.  

Taking an API-led approach

API-led connectivity is an approach that defines methods for connecting your assets using  reusable API building blocks. The approach includes three distinct layers which contain reusable APIs on the system, process and experience-levels. In this article we’re not going to cover examples of experience APIs, but we will showcase how system and process APIs help with data migration and synchronization use cases.


API Led Connectivity

System

Underlying all IT architectures are core systems of records that are often not readily available due to its complexity and connectivity concerns. APIs provide a means of hiding that complexity from the user while exposing data and providing downstream insulation from any interface changes or rationalization of those systems.

API templates provide system APIs for creating building blocks that can be reused by anyone in the organization looking to access the same data. System APIs expose data via a set of RESTful services that are designed in RAML, making it easily consumable by any developer within the enterprise.

Below you can see an example of connecting to SAP via BAPIs versus using the system APIs provided in the SAP System API Template.

Connecting to SAP via BAPIs

connecting sap via bapi

Connecting to SAP via a system API

connecting sap via system api

Process APIs

Process APIs encapsulate the underlying business processes that interact with source and target systems or channels via a set of system APIs. For example, in a purchase order process, there is some logic that is common across products, geographies and retail channels that can and should be distilled into a single service that can then be called.

To templatize common integration needs, base patterns must first be established to make integrations atomic, reusable, and extensible. Patterns will usually include:

  • a source – system API where data resides before execution
  • a destination –  system API where the data will be inserted
  • the criteria – which determines the scope of data to be copied, moved or replicated
  • results capture – to compare the final state with the desired state.

API templates encapsulate the five most common integration patterns into process APIs, such as migration, broadcast, aggregation, correlation, and bi-directional synchronization.

api direction

API Templates in action

Take a look at our first set of API templates which feature system APIs for Salesforce, SAP, and databases, and process API for account migration. Let’s take a look at how we can use these templates to migrate account data from SAP to Salesforce:

1. Abstract the complexity of underlying systems

First, we are going to use RESTful APIs to hide the complexity of the underlying system of records, in our example Salesforce and SAP. Once the system APIs are selected, configure the applications and deploy them to CloudHub.

2. Access data

Once we deploy the system APIs, we can access the account data from Salesforce and/or SAP via RESTful APIs.

api reference

3. Implement a business logic

Now, once the SAP and Salesforce data is easily accessible through the system APIs we’re going to migrate account data. To do this, we will use Migration Process API and once configured; we will only need to make an API call to move accounts from Salesforce to SAP.

Conclusion

With an increasing number of systems in the enterprise, reuse becomes paramount to accelerate delivery and to scale.  Take an API-led approach to connectivity by giving the templates a try. If you have any questions or feedback, send them to info@mulesoft.com


We'd love to hear your opinion on this post


8 Responses to “Introducing API templates with reusable System and Process APIs”

  1. Nice article

  2. Hi,

    Nice article!

    I have some questions regarding the article if I may. On this architecture, how should systems comunicate each other, internally?
    For instance:
    1 – If required, should Salesforce invoke a system API to send an SMS using Twillio?
    2 – If a CRM system has an automatic process to deactivate accounts should it invoke a process API to do this? (assuming that the process API for account deactivation updates multiple systems using the system API)
    3 – Should an experience API comunicate directly with a System API if there is no complex logic nor orquestration in order to update other systems?

    Best regards,

    • Daniel, these are great questions! It always depends on the use-cases and architecture, because each organization is different, but here are my thoughts that might help with the questions you’re facing:
      1. Yes, there is no problem in Salesforce invoking a process or system APIs depending on your use-cases.
      2. It seems that you have a point to point connection between your CRM and other systems, where CRM triggers the deactivation. If that’s the case, another architectural approach would be to build a process API for a user deactivation that will deactivate a user across all systems. This is what we’re suggesting as part of our API led best practices, but once again, it all depends on your system landscape.
      3. There is no problem having an Experience API talking directly to a System one. Three layered API approach is a framework that should guide, not limit.

  3. HI i want to use microservices with sitecore would be really helpful if i can get more insight on using sitecore with microservices. do we need any separate sitecore license to implement this . any lead will be really helpful fo me

    • Toshi, we don’t have any API templates on the top of Sitecore APIs, but you can use one of our API templates for Salesforce as an example and HTTP for REST or Webservice Consumer for SOAP connectors to integrate with Sitecore APIs.

  4. Hi Anton,

    Thanks for the interesting article.

    As I understood from various sources, a system API exposes a concept within a bounded context, e.g. a product within the sales LOB. The underlying system where that concept is stored, is not relevant in the identification of the API.

    From Mike Stowe (https://forums.mulesoft.com/questions/53639/system-apis-scope-of-concern.html):
    But to dig into the terminology, a System API is an API that represents and abstracts a specific system – whether that be a series of databases setup as slaves with a master (in other words all with the same data), or SAP, or a SaaS service.

    So in other words, if a product is stored in both SAP as Salesforce, it still represents the same concept. For me, at that point, it belongs in one system API.

    If I need to replicate the product from SAP to Salesforce, shouldn’t this be written than in the same system API, e.g. Products sAPI?

    Or do you have a flow SAP -> Products sAPI -> Product Replication pAPI -> Products API -> Salesforce? At that point, what is your added value of the process API?

    Another question, if I have my client under control and they can consume a CDM, can they talk directly to the system API or do I need an experience API anyway?

    And a last question, all the diagrams I have found so far show the experience API for incoming messages. However, for me, it sounds logical to also use it for outbound messages. If I have a two-way communication with a partner, all those communications pass through that same API since they might just require the same transformations in different directions (partner specific -> CDM and CDM -> partner specific). Is my understanding correct on this point?

    Regards,

    Jan

    • Jan – glad you enjoyed the article. There is no right a wrong answer here since most of this questions are mainly architectural decisions that are specific to the application landscape. In cases when you need to replicate data from one system to another, I’d suggest to always think what system holds master data. In your case, you might want to build a point to point, either SAP to Salesforce or System API to Salesforce. If Salesforce will contain more information about the product, then you might want to enrich your System API with more data.

      As for sharing your APIs with others, I would not be concerned with the layer you assign it to, but rather if this API contains everything your partner/customer needs e.g. SLAs, authentication methods, policies, documentation, methods, and resources, etc.

      To the last question, this is a slightly different API pattern and you are right, there is not need to limit your APIs to inbound or outbound messages. We’re currently working on a better experience to design and manage evented APIs.