Regardless of how customized your SAP instance(s) may be, or how mismatched the object models may be between SAP and third-party solutions, Anypoint Platform is purpose-built to abstract the complexity of any system and its proprietary language. This results in obviating the need to build with custom code by leveraging an API-led approach.
How API-led connectivity accelerates SAP integrations
API-led connectivity provides a means of connecting and exposing SAP and other systems with APIs. With this approach, every asset, application, or system becomes a managed, modern, developer-friendly API that is discoverable through self-service while maintaining the security policies you’ve designed.
APIs allow you to mediate SAP customizations and logic while orchestrating across multiple systems, simplifying your integrations between connected applications while creating a scalable, plug-and-play infrastructure. Once these APIs have been built, multiple business lines and stakeholders can use Anypoint Exchange to discover, collaborate, and reuse these integration assets, reducing the burden on central IT while standardizing integration best practices.
These APIs play specific roles – unlocking data from systems, composing data into processes, or delivering particular experiences to end users – and these roles can be illustrated through MuleSoft’s API-led connectivity three-layered architecture:
- Systems APIs: This layer unlocks data from SAP, Salesforce, and other systems, providing consistent, managed, and secure access to each system. The SAP connector can use either RFC calls of BAPI functions and/or IDoc messages for data exchange. Thus, the first step is to create an SAP system API, which hides the complexity of SAP from a user (leverage our SAP system API template to get started). This API abstracts account data from SAP into canonical objects that we define within the Salesforce system API, using JSON as an exchange format to translates calls into the semantic data structure required by SAP. In this case, we have two different SAP instances with their own customizations, but those complexities are abstracted through the canonical data model. Similar processes would be followed for each additional system.
- Process APIs: Build upon system APIs by leveraging core data from each system, combining them with the necessary business logic to achieve a business goal. For example, you may want to combine customer data from SAP and Salesforce into process APIs called “Customer API” and “Order status API.” These APIs are loosely coupled and can be reused for future integration projects.
- Experience APIs: This layer is designed to enable the consumption of underlying APIs for specific end-users within an application or particular device. By decoupling the user interface from the underlying data, front-end developers can innovate quickly without having to understand the underlying back-end systems.
The principle of API reusability is a significant benefit of MuleSoft’s API-led connectivity approach, allowing new integrations to leverage previous work, thereby accelerating development. By using an API-led approach, you can liberate SAP and other systems with APIs, avoiding the configuration complexity that plagues many organizations, and drive agility and speed while reducing costs.
Practical application: issue to resolution
Service agents have difficult jobs, working diligently to resolve the problems of unhappy customers. What’s more, the role of service agents is transforming. Customers increasingly expect agents to possess expertise across multiple domains, including the ability to provide recommendations about products and services. These evolving requirements necessitate providing agents with more capabilities than ever before, enabled by access to products, pricing, inventory, order status, and more. To achieve these capabilities, organizations need to integrate SAP with customer service applications, providing agents with a single view of their customers and the ability to transact.
A single view of customers allows agents to see order status, delivery status, and other data without having to swivel chair into SAP and other systems of record. Additionally, the ability to transact enables agents to serve their customers better (example: reordering a package that was lost-in-transit) and allows service agents to sell additional products and services. Best of all, these capabilities result in better customer experiences while increasing agent productivity.
To provide agents with a single view of customers and the ability to transact, all within a unified experience (say, in Salesforce Service Cloud), we use an API-led connectivity approach. To synchronize data between SAP, Salesforce, and other systems, we use a publish-subscribe integration pattern, a modularized approach to integration allowing us to decouple source and destination systems. Publisher clients address messages to a topic that serves as a bulletin board, while subscriber clients dynamically consume these messages by subscribing to that topic. The system takes care of distributing the messages to all present subscribers at the time the message arrives, and it ensures that the messages are reliably delivered just once to each subscriber.
With SAP providing order management and inventory management while using Service Cloud for customer support, pub-sub enables your company to maintain a consistent, real-time view of the data in every system. If a customer needs a replacement product, your agent will 1) know what they previously ordered, 2) have access to the latest product catalogs, 3) have visibility into inventory and shipping lead times, and 4) be able to reorder the product, all accomplished within Service Cloud. This drives significant time and costs savings across your entire call center.
Practical application: S/4Hana migration
With 2025 rapidly approaching, now is the time to prepare for SAP’s ECC end-of-life. Whether you’re planning on migrating to S/4Hana or another solution, MuleSoft’s API-led approach allows you to connect multiple ERPs while abstracting the idiosyncrasies of each endpoint, decoupling them from front-end systems. This approach allows for a phased rollout, running both ECC and S/4Hana in parallel. When you’re ready, you can begin migrating data to S/4Hana without any loss of data or system downtime. If you decide to move to a non-SAP ERP, these same techniques enable migrating to a new vendor with the same results.
To learn more about S/4Hana migration, read our Integrating SAP S/4HANA or our SAP integration best practices whitepaper.
