BTP Integration Suite: Enterprise Integration Architecture

By Sarah Chen, Lead SAP Architect
SAPExpert.AI Weekly Deep Research Series

Executive Summary

The SAP Business Technology Platform (BTP) Integration Suite represents the next generation of enterprise integration, bringing cloud-native capabilities to connect and orchestrate a variety of systems — from on-premise SAP ERP and S/4HANA to third-party cloud applications, SaaS, and IoT devices. This flagship solution replaces traditional middleware with a unified, extensible platform, enabling organizations to build robust, secure, and scalable integrations using modern API and event-driven patterns. With Integration Suite, companies accelerate digital transformation by adopting reusable integration building blocks, continuous delivery pipelines, and intelligent tools, while ensuring elevated traceability and governance.

By leveraging Integration Suite’s API-led connectivity, businesses treat every endpoint as an API, making it easier to consume, monitor, and secure services consistently. The suite’s Event Mesh component further enables decoupled architectures, publishing and subscribing to business events for high-throughput, real-time processing. Advanced features like AI-assisted mapping (via Integration Advisor) and prebuilt Open Connectors to popular SaaS apps reduce time-to-market for new integration projects.

In practice, adopting the Integration Suite can yield significant business benefits. For example:

• A global manufacturing enterprise reported 40% faster integration development cycles after migrating legacy PI/PO interfaces to API-based flows in Integration Suite.
• An e-commerce retailer gained real-time inventory visibility by coupling SAP S/4HANA order events to a third-party logistics system via Event Mesh, eliminating daily batch delays.
• A financial services firm enforced strict security and governance by applying OAuth 2.0 scopes and JSON Web Token (JWT) validation on all exposed APIs, meeting compliance with minimal custom code.

Key recommendations for architects include:

• Modular Design: Build integration flows as reusable microservices or API proxies. This means defining clear service contracts (e.g. OpenAPI specs) and allowing different teams to consume shared integration endpoints.
• API Governance: Use SAP API Management to secure and monitor all interfaces. Employ OAuth 2.0 (client credentials or authorization code flows) for machine-to-machine and user interactions, and validate JWTs issued by trusted identity providers. Leverage rate limiting, quotas, and API analytics to protect backends and measure usage.
• Event-Driven Patterns: Wherever feasible, publish domain events (such as “OrderCreated” or “DeliveryShipped”) rather than polling systems. Configure Event Mesh namespaces and topics for core business domains. This decouples producers and consumers, improving scalability and resilience.
• Continuous Integration/Continuous Delivery (CI/CD): Integrate BTP tools with source control (e.g. GitHub, Azure DevOps) and CI/CD pipelines. Automated builds and tests of integration content (iFlows, API proxies) ensure consistent deployment across development, test, and production landscapes. Use the BTP CLI or APIs for automated transport of integration artifacts.
• Hybrid Connectivity Strategies: For secure on-premise integration, set up the SAP Cloud Connector. Map only the necessary internal hosts/ports, and use subaccount-specific tunnels. Leverage target mappings to restrict access and monitor logs for connectivity tests.

By following these guidelines and leveraging the Integration Suite’s cloud-native capabilities, organizations of all sizes can achieve a more agile, maintainable integration architecture. The sections below provide a deep dive into each component and step-by-step guidance to implement a robust enterprise integration solution using SAP BTP Integration Suite.

Technical Foundation

Core Concepts and Architecture

At its heart, SAP BTP Integration Suite is a unified integration platform that supports a wide spectrum of integration scenarios. It combines multiple capabilities:

• Cloud Integration (iFlows): The central engine for designing and running integration flows. Developers create iFlows using either a visual flow editor or with code (Java/Groovy/XSLT). These flows can perform content-based routing, message enrichment, transformations, and protocol bridging between systems.
• API Management: A comprehensive gateway and portal for creating, securing, publishing, and analyzing APIs. Backend services (e.g. an S/4HANA OData API or a custom microservice) are exposed through API proxies. Policies for authentication (OAuth2, Basic Auth), traffic control (SpikeArrest, Quota), and transformation (JSON-to-XML, sampling) are applied at the gateway transparently.
• Event Mesh (Enterprise Messaging): A fully-managed, cloud-based message broker that implements publish/subscribe patterns using standard protocols (AMQP, MQTT, JMS). Event Mesh supports global namespaces and topics. Producers publish events without knowing who will consume them; consumers subscribe to relevant topics. This supports asynchronous, event-driven integration and decouples producers from consumers for better scalability.
• Open Connectors: A library of pre-built connectors for over 160 popular non-SAP applications (Salesforce, ServiceNow, Workday, etc.). These wrappers simplify authentication (OAuth2 out-of-the-box) and expose normalized REST APIs for common operations, reducing the need to custom-build connectors.
• Integration Advisor: An AI-assisted tool that automates mapping of data formats (e.g., mapping purchase orders between different EDI/IDoc/CSV/XML schemas). It suggests mapping rules based on SAP’s best practices and community content, accelerating development of transformations in iFlows.

Together, these components support an Enterprise Integration Architecture (EIA) that emphasizes:

• Hub-and-Spoke Pattern: The Integration Suite acts as the central hub (or fabric) where all integrations converge. Backend systems (SAP or non-SAP) act as spokes. This centralization allows for consistent monitoring, error handling, and security enforcement.
• API-led Connectivity: Each enterprise system exposes functionality through standardized APIs. For instance, an on-premise SAP S/4HANA might expose OData services for order entry, while a microservice might expose a REST endpoint. All clients (SAP systems, custom apps, external partners) consume these APIs. The API gateway ensures only authenticated clients can invoke them.
• Event-Driven Architecture (EDA): Instead of only request/response, key business events (order created, invoice paid, etc.) are published to the Event Mesh. Other components subscribe to these events to take action. This architecture improves responsiveness and scalability, because producers do not block waiting for consumers. It is ideal for alerts, data replication, and microservice choreography.
• Hybrid Integration: Many enterprises have a mix of cloud and on-premise systems. The SAP Cloud Connector provides a secure tunnel from Integration Suite (in SAP BTP) to on-premise systems. This allows, for example, a cloud iFlow to call an on-premise SOAP endpoint without exposing it publicly. Hybrid integration combines the flexibility of the cloud with the security of on-premise data.

Below is a simplified view of the BTP Integration Suite architecture. An on-premise SAP system connects through the Cloud Connector, Ni ce to include integration flows in the cloud that route messages to and from SaaS applications and publish events to an Event Mesh broker.

Embedding an architectural diagram can help visualize how Integration Suite components interact with existing systems:

!SAP BTP Integration Suite Architecture
Figure: SAP BTP Integration Suite supports cloud and hybrid integration via connectors, API gateways, and event mesh. (Source: SAP Help Portal)

Prerequisites and Technical Specifications

Implementing the Integration Suite solution requires some upfront planning and environment setup:

• BTP Subaccount and Environment: Ensure you have an SAP BTP subaccount with the Integration Suite service enabled. Integration Suite runs on the Cloud Foundry environment (CF) with Kubernetes. Confirm your subaccount has proper entitlements and that you have assigned roles like Admin or Developer for Integration Suite. Check that the Integration Suite package version is current (e.g. 2024.06 or later).
• Regions and Availability Zones: Integration Suite is available in multiple regions (AWS, Azure, Google Cloud, or SAP data centers). Choose regions close to your primary users or SAP instances. Example: us10, eu22, jp10. If you have multi-region requirements, plan for separate subaccounts and data replication.
• Network and Connectivity: For hybrid scenarios, you will use the SAP Cloud Connector (SCC). SCC (v2.14 or higher) should be installed on a host within your on-premise network. SCC will create a secure tunnel to the BTP subaccount. In addition, check firewall rules: allow outbound connections from the SCC host to the BTP destinations (default port 8443 for SCC), and from Integration Suite runtime to your on-prem systems (4030/80/443 depending on backend ports). When planning ports, remember that iFlows can reach external services on standard HTTP/HTTPS, IDoc listener (port 3299 for IDoc adapter), or other ports if needed.
• Supported Protocols and Adapters: Integration Suite supports a wide range of protocols out-of-the-box. Common SAP adapters include IDoc (to connect to SAP ECC/S/4 IDoc interfaces), RFC (via SAP Cloud Platform RFC adapter), SFTP/FTP, JMS (for messaging), SOAP, OData v2/v4, JDBC, REST, SMTP, and more. Non-SAP integration can use generic web service adapters (REST, HTTP, and JMS) or leverage Open Connectors. Ensure that your target systems provide REST or SOAP APIs, or install SAP add-ons (like the SAP S/4HANA Cloud Agent) if needed.
• Security and Certificates: All data in transit must use TLS 1.2+ encryption. For HTTPS calls, upload the root and intermediate certificates in the Integration Suite trust store. Use Client Authentication profiles when calling on-premise endpoints. For example, set up a Client Certificate in BTP and assign it in your iFlow sender/receiver configuration. Mappings between user accounts (SAML 2.0 or OAuth identity provider) should be handled via XSUAA (SAP Identity Authentication Service) or a corporate Identity Provider (IdP).
• Development Tools:
  • Integration Flow Designer: The primary tool for building iFlows. Access it via the BTP Integration Suite tile under the subaccount. Consider using SAP Business Application Studio or Visual Studio Code with the SAP Integration Extension Pack for offline development. These IDEs allow you to export integration flows, version control them, and use local debugging.
  • API Proxy Designer: Found inside SAP API Management. Here you define API proxies, policies, and develop APIs.
  • Postman / curl: For testing APIs and iFlow endpoints.
  • SAP CLI Tools: Use the cf (Cloud Foundry CLI) or btp CLI for deploying MTA (Multi-Target Application) packages or retrieving logs programmatically.
• Account and Role Setup: Ensure the right user roles in SAP BTP: as an architect, you may need Integration Suite Admin/Developer and API Portal Admin roles. Assign roles for CI/CD bots or service users if automating deployments.
• Licensing: Check that your Enterprise Agreement covers Integration Suite capabilities. There are metrics (number of messages, events) that could incur costs. Monitor usage in the BTP Usage Reports.

Having this foundation in place allows for a smoother implementation of integration scenarios. The steps that follow assume these prerequisites have been met.

Implementation Deep Dive

This section walks through the practical steps to build a real-world integration solution using SAP BTP Integration Suite. The example scenario is as follows: An order management system (e.g. SAP S/4HANA) sends order creation events to cloud-based order processing and billing systems. We will set up hybrid connectivity (for on-premise S/4HANA), define integration processes (iFlows), create APIs, publish events, and implement monitoring.

Step 1: Establish Integration Strategy and Landscape Assessment

Before building integrations, take time to plan and document your integration requirements. Key activities include:

• Identify Systems and Interfaces: List all source and target systems (SAP on-premise, S/4HANA Cloud, third-party SaaS, legacy databases, IoT devices). For each, note the available interface type (e.g., OData service, IDoc, REST API). For instance:
  • System A: SAP S/4HANA on-prem, exposes IDocs (ORDERS) and OData (salesorder API).
  • System B: Salesforce CRM (cloud), access via Open Connectors or REST API.
  • System C: Partner logistics platform (cloud SaaS), supports SOAP.
• Define Data Flows and Business Events: Map out the business process being integrated. E.g., when an order is created in System A, we need to update System B (via API) and notify System C (via event). Create simple process diagrams showing triggers and endpoints.
• Select Integration Patterns: Decide which integration pattern fits each use case:
  • Real-time synchronous call: Use this when the calling system (say, an external web app) needs an immediate response. Implement using API proxies or iFlows with backchannel.
  • Fire-and-forget asynchronous message: When System A publishes an event and does not need an immediate reply. Use Event Mesh topics or asynchronous iFlows.
  • Batch processing: For high-volume transfers (e.g., nightly CSV data load), use a scheduled iFlow or data management service.
  • Bi-directional sync: If two systems need to stay in sync (e.g., customer data), consider dual integration flows or a message queue with guaranteed delivery.
• Set SLAs and Performance Targets: Determine throughput and latency requirements. For example, “Order event delivery must occur within 5 seconds 95% of the time.” Use this to size your Cloud Connector (bandwidth) and iFlow timeouts.
• Security Requirements: Classify data sensitivity. If using public APIs, require OAuth2 with JWT validation. For internal flows, you can use X.509 certificates and network whitelisting. Determine if encryption of payloads at rest is needed (e.g., for logging).
• Network Topology and Environment Setup: Document network boundaries. For hybrid flows, identify on-premise hosts, private IPs, and required open ports. Confirm whether the SCC will run on the corporate DMZ or internal network.
• Proof of Concept: It’s wise to start with a POC scenario. For example: “Send an order from S/4HANA to a mock service in Cloud Integration to validate connectivity.” This will uncover issues in trust or mapping early.

Checklist for Step 1:

• Document all endpoints, including URLs, ports, and authentication (for example, sap.example.com:8000/ORDERS, requires SOAP with Basic Auth).
• Gather any existing interface specs (WSDLs, OpenAPI docs, IDoc definitions).
• Decide which data formats need transformation (XML to JSON, custom fields).
• Confirm change management: coordinate with network, security, and SAP BASIS teams to schedule Connector installation and certificate provisioning.

This planning phase might take anywhere from a few days to a couple of weeks, depending on environment complexity. The goal is to minimize surprises once you start building iFlows.

Step 2: Configure Hybrid Connectivity

To connect cloud integration flows with on-premise systems, use the SAP Cloud Connector (SCC). Follow these steps:

1. Install SAP Cloud Connector:

   • Download SCC installer (version 2.14+ recommended) from the SAP support portal.
   • Install on a Windows or Linux server within the corporate network. Ensure the server has a fixed IP or hostname. The machine needs JRE (Java 8+) slots and outbound access to sapcpapimttractor URL and SAP BTP (port 8443).
   • Start the SCC service. By default, the admin UI is at https://<hostname>:8443. Log in with the default credentials (Administrator / manage) and change the password.

2. Connect to BTP Subaccount:

   • In the SCC admin UI, select Cloud to On-Premise section, then click Add Subaccount.
   • Enter your BTP region (e.g., us10), subaccount ID, and the credentials of a BTP user with the Subaccount Administrator role.
   • Choose the appropriate Cloud Foundry environment. The SCC will establish a tunnel to your subaccount. Make sure to watch for a green status indicator.

3. Configure Access Control:

   • Under Cloud To On-Premise -> [Your Subaccount] -> Access Control, click Add.
   • In the “Add System Mapping” dialog:
     • Internal Host: the hostname or IP of your on-premise system (for example, sap.server.local).
     • Internal Port: the port of the service (e.g., 8000 for SAP HTTP, 3300 for IDoc, or 44300 for SOAP TLS).
     • Virtual Host: a URL path or host that the cloud will use to refer to this service (e.g., onprem.sap.local). This will be the hostname used by iFlows or API proxies.
     • Virtual Port: usually match your protocol (e.g. 443 for HTTPS, 8000 for HTTP).
     • Protocol: HTTP or HTTPS.
   • Click OK to create the mapping. Optionally, restrict the source IPS or user principal if needed (for security).

Example internal system mapping in configuration (conceptual):

# Example Cloud Connector access control entry
{
  "internalHost": "sap.example.local",
  "internalPort": 8000,
  "virtualHost": "onprem.sap.local",
  "virtualPort": 443,
  "protocol": "HTTPS"
}

4. Test the Connection:

• From the Integration Suite, create a simple test. For instance, in Cloud Integration, create an HTTP receiver adapter pointing to “. Check if the iFlow can successfully call the endpoint.
• In SCC UI, go to Diagnostics -> Connectivity and run Check TCP Connection. Enter sap.example.local and 8000 (the internal host/port) to ensure SCC can reach it. A successful message should confirm connectivity.
• Use network tools directly as well: on the SCC host, run telnet sap.example.local 8000 or curl to verify you can reach the on-prem service. If these fail, check firewall rules and ensure SAP Gateway (IAG) or SAPRouter are not blocking.

5. Review Certificates:
   • If using HTTPS to on-premise, upload the certificate chain of the internal service to the SCC trust store and to the Integration Suite keystore.
   • If using a client certificate for authentication, create a key pair in the re xppl. trust store of Integration Suite and assign it to the HTTP(S) adapter in the iFlow configuration.

At the end of Step 2, the SCC tunnel should allow Integration Suite iFlows and APIs to call on-premise endpoints securely using the onprem.sap.local virtual host. All internal systems remain protected behind your network.

Step 3: Design Integration Flows (iFlows)

With connectivity ready, the next step is to build the integration logic. An integration flow (iFlow) in Cloud Integration defines how messages move from sender to receiver, including transformations and routing. Here’s a sample process:

1. Create a New Integration Flow:

   • In the BTP cockpit under your Integration Suite subaccount, launch the Cloud Integration design view.
   • Choose Integration Flow and click Create. Give it a name like IF_Orders_RestToSAP and a descriptive description. Assign a meaningful package or iFlow package.
   • Specify if it’s a synchronous (request/reply) or asynchronous flow. For REST to SOAP, choose synchronous.

2. Define the Sender Adapter:

   • Drag a Sender component onto the canvas. Select the adapter type, e.g., Receiver REST (for REST JSON inputs) or SOAP if the sender is SOAP. For a REST sender:
     • Set HTTP Method (POST), a relative path (e.g., /api/orders), and optionally a security interface or application identity.
     • If unsecured during development, leave authentication open; for production, switch to OAuth2 client credentials or basic auth.
     • Example: The sender might listen on https://<integration_runtime>/revOrders/api/orders.

3. Add Processing Steps:

   • Use a Mapping step or Script step to transform the payload. In Cloud Integration, you can choose graphical mapping (click “Map Message” to open the integration advisor or mapping editor) or use a Groovy Script. For example, to map a JSON order from an external app into an SAP SOAP XML, you could insert a Groovy script step.

   • Example Groovy Transformation: Convert an incoming JSON to a SOAP XML structure. Indent the code block for markdown:

     // Example: Groovy script to transform JSON payload to SAP SOAP XML def json = new groovy.json.JsonSlurper().parseText(message.body) def soapXml = """<soapenv:Envelope xmlns:soapenv=""> soapenv:Body <soap:CreateOrderRequest xmlns:soap=""> ${json.orderId} ${json.customer} ${json.totalAmount} </soap:CreateOrderRequest> </soapenv:Body> </soapenv:Envelope>""" message.body = soapXml

   • If working with XML, you can also use an XSLT step. For example, an XSLT transformation might look like this:

     <xsl:stylesheet version=“1.0” xmlns:xsl=""> <xsl:output method=“xml” indent=“yes”/> <xsl:template match=“/Order”> <xsl:value-of select=“OrderID”/> <xsl:value-of select=“Date”/> <xsl:value-of select=“Customer”/> <xsl:value-of select=“Total”/> </xsl:template> </xsl:stylesheet>

   • For robust scenarios, use Integration Advisor: Upload the source and target message structures to generate a mapping template. In Cloud Integration, click on the Integration Advisor icon during mapping design, link your source/target catalogs, and let the AI suggest field mappings. The generated mapping can be imported into your iFlow mapping step to reduce manual work.

4. Add Business Rules or Routing:

   • If the iFlow needs to route messages based on content, add a Content Modifier or Switch condition.
   • Example: Use a Content Modifier to set header values:

     # Example: Content Modifier to add/mutate headers
     Set header 'ProcessType' = '${property.orderType}'
     

     This header can then be used in a Router to send orders of type “EXPEDITED” to a priority queue, and others to a standard flow.

5. Configure Receiver Adapter:

   • Drag a Receiver component out. Configure it to point to the target system. For our example (SAP on-premises):
     • Choose adapter type SOAP.
     • Set the Endpoint URL to the virtual host created in Cloud Connector, for example: “.
     • Specify the SOAP action or WSDL if required.
     • If Basic Authentication is needed, provide a username and password credentials from the credential store. If using client certificates, attach the certificate from the trust store.
   • Ensure you set the document or operation name matching the target service. For instance, SOAPAction might be urn:OrderServiceWS:CreateOrder.

6. Handle Faults and Errors:

   • In the iFlow, add Exception Subprocesses or configure fault messages. For example, connect a separate error handling path to log the error or send an alert email.
   • Use Exception Subprocess in the BPMN flow to catch any runtime errors. Within it, you might add a Mail adapter to notify a support team or a retry mechanism.

7. Deploy and Test the iFlow:

   • Save and deploy the iFlow to the integration runtime.

   • In Cloud Integration, go to Design → Artifacts → Deployed to see its status.

   • Test by sending a sample message. If it’s a REST trigger, use Postman or curl:

     Example REST call to trigger iFlow (replace endpoint and token)

     curl -X POST https:///revOrders/api/orders
     -H “Content-Type: application/json”
     -H “Authorization: Bearer <JWT_or_OAuth2_Token>”
     -d ’{“orderId”:“123”,“customer”:“ABC”,“totalAmount”:456.78}’

   • Check if the message appeared in the SAP on-premise system (monitor the target). Also view the Message Processing Logs in Integration Suite to confirm successful execution (Status = Successful).

By the end of Step 3, you should have a running integration flow that takes incoming data, transforms it, and calls a backend service. You can repeat this step to build other flows (e.g., asynchronous flows for outbound data or event triggers).

Step 4: API Management Setup

Managing and exposing your integrations as APIs is crucial for governance and security. Here’s how to configure the API Management component:

1. Create a Service Instance:

   • In the BTP cockpit, ensure the API Management service (part of Integration Suite) is enabled.
   • Launch the API Portal or API Manager application. This may open a separate portal URL (e.g., https://<domain>.apimanager.cloud.sap/sitest). Log in with your BTP credentials.

2. Design an API Proxy:

   • In API Manager, create a new API Proxy. Give it a name, like OrdersAPI.
   • Under Backend Target, specify the endpoint of your integration or backend system. For example: “.
   • For the Base Path, set something like /orders-api/1.0. This will form the path on the API gateway (e.g., https://<api-host>/orders-api/1.0/CreateOrder).
   • Set the API protocol (REST or SOAP). If SOAP, you can import the WSDL directly. For a REST proxy, you may define it manually or import an OpenAPI spec.

3. Apply Security Policies:

   • In the proxy editor, add an OAuth 2.0 policy to validate incoming tokens. For instance, want to use VerifyAccessToken:

     VerifyAccessToken request.header.Authorization orders.read orders.write

     This XML (indent with 4 spaces) configures the proxy to only accept calls with a valid OAuth token that has the scopes orders.read and orders.write.

   • Also add a Check JWT or Extract Variables if you need to inspect token claims. For example, to ensure the iss claim matches your Identity Provider:

     RS256 MIIBIjANBgkq...

     Place this VerifyJWT policy before the routing step, so invalid requests are rejected early.

4. Add Traffic Controls:

   • To protect your backend, incorporate rate limiting. For example, a Spike Arrest policy sets a maximum call rate:

     20ps

     This limits the proxy to 20 requests per second, buffering bursts.

   • Alternatively, use Quota to limit per time period:

     1 hour 1000

     This enforces a maximum of 1,000 requests per hour per consumer.

5. Set Up CORS and Headers (if exposing to web clients):

   • If the API will be called from browsers, configure a CORS policy to allow cross-origin calls:

     * GET, POST, OPTIONS Content-Type, Authorization

   • Add any transformation policies if you need to convert formats (e.g., inline JSON-to-XML for older SOAP backends).

6. Publish APIs to Developer Portal:

   • Once the API is configured, publish it to your organizational developer portal (if using one). Document the API: supply descriptions, example payloads, and specify required OAuth scopes.
   • Define Products and Roles: In the API management portal, group APIs into products and assign roles to allow specific BTP users or groups to request access.
   • Create Application Keys for internal or partner apps. For OAuth2 client credentials, generate a client ID/secret pair that a calling service will use. Add this consumer (application) to the API product.

7. Test the API Layer:

   • Use Postman or curl to invoke the secured endpoint. Example using OAuth2 client credentials (replace placeholders):

     Get OAuth2 token from SAP IAS or Ida (authorization server)

     curl -X POST
     -d “grant_type=client_credentials&client_id=<client_id>&client_secret=<client_secret>“

     Use the token to call the API proxy

     curl -X POST https:///orders-api/1.0/CreateOrder
     -H “Authorization: Bearer <access_token>”
     -H “Content-Type: application/json”
     -d ’{“orderId”:“ABC123”,“customer”:“XYZ”}’

   • The API gateway should validate the token, apply policies, and then route the call to the backend (which may in turn invoke an iFlow). Check the Execution trace to see each policy in action. The backend service should receive the transformed request.

By the end of Step 4, your services are exposed as managed APIs. Consumers cannot bypass the gateway without proper authentication, and you have metrics and governance on usage.

Step 5: Implement Event-Driven Integration with Event Mesh

To decouple systems and scale asynchronously, leverage SAP BTP’s Event Mesh. Here’s how to produce and consume events:

1. Set Up an Event Mesh Namespace:

   • In the BTP cockpit, navigate to your subaccount -> Instances and Subscriptions, and create a new Messaging instance of type Enterprise Messaging (Event Mesh).
   • Open the Event Mesh console. Create or navigate to your namespace (e.g., RetailEvents). Note the Namespace ID. Create a virtual host (vHost) if needed.
   • Within the namespace, create topics for your business events. For example, orders.created, orders.updated, customers.registered. These act as channels.

2. Configure Access:

   • Use Access Control to create a client credentials pair (client ID and secret) for publishing/subscribing. This will be used by applications or integration flows to authenticate to the Event Mesh broker.
   • Ensure the relay host and port (displayed in the Event Mesh UI) are noted, e.g., `psaenerator.“.onsiteRealms etc.

3. Develop an Event Producer:

   • This could be an Integration Flow or an application that publishes events. For example, in the integration flow we built, after the SOAP call to on-prem is successful, we might want to publish an “OrderCreated” event.

   • Example with Node.js SDK: Use the SAP Event Mesh SDK to publish. Indent the code block as shown:

     const { EventMeshClient } = require(‘@sap/event-mesh-client’);

     async function publishOrderCreatedEvent(order) { const client = new EventMeshClient({ namespace: ‘RetailEvents’, clientId: ‘EM_CLIENT_ID’, clientSecret: ‘EM_CLIENT_SECRET’ }); await client.connect();

      const event = {
        id: order.id,
        type: 'OrderCreated',
        source: '/sap/s4/order',
        subject: 'SalesOrderAPI',
        data: order,  // the entire order payload
        time: new Date().toISOString()
      };
     
      await client.publish('orders.created', event);
      await client.disconnect();
     

     }

     In this snippet, replace 'EM_CLIENT_ID' and 'EM_CLIENT_SECRET' with the credentials created earlier. This will send the event to the orders.created topic. The data field can be any JSON serializable object representing the event payload.

   • Alternatively, you can publish events directly from an iFlow using the AJAX adapter or a custom connector. But using the SDK or REST API is more common for push events.

4. Develop an Event Consumer:

   • A consumer listens for events on a topic and processes them. This could be a microservice, a Lambda function, or even another iFlow.

   • Example with Node.js SDK: Subscribe to orders.created:

     async function listenToOrderEvents() { const client = new EventMeshClient({ namespace: ‘RetailEvents’, clientId: ‘EM_CLIENT_ID’, clientSecret: ‘EM_CLIENT_SECRET’ }); await client.connect();

      await client.subscribe('orders.created', (event) => {
        console.log('Received order event:', event.data);
        // Process order event, e.g., notify downstream systems
      });
     

     }

     listenToOrderEvents();

     Whenever an order is created, this code prints the event and could trigger further actions (like calling a billing API).

   • In Integration Suite, you can also create an iFlow with an Event Mesh (Messaging) adapter. For example, add a Messaging Consumer step in your iFlow designer, configure it for JMS or AMQP, and point it to the orders.created topic. This iFlow would automatically be triggered when a new message arrives.

5. Define AsyncAPI Specifications:

   • Document your events using the AsyncAPI standard, which is to events what OpenAPI is to REST. This improves clarity and allows code generation.

   • Sample AsyncAPI fragment (show without code fencing):

     asyncapi: ‘2.0.0’ info: title: Orders Event API version: ‘1.0.0’ channels: orders.created: subscribe: summary: Event when a new order is created. message: payload: type: object properties: id: type: string description: Order ID customer: type: string description: Customer ID totalAmount: type: number items: type: array items: type: object properties: productId: type: string quantity: type: integer

   • This spec indicates that services can subscribe to orders.created to receive an object with id, customer, totalAmount, etc. Hosting an AsyncAPI definition in your documentation portal or Git repository aids developers in integrating with the event.

6. Test and Validate:

   • Publish a test event either manually using the SDK or via the iFlow logic.
   • Verify that your consumer receives it (check logs or output). Use the Event Mesh monitoring UI to see that messages were published and consumed (look at message backlog, consumer group status).
   • Check for message durability: Event Mesh ensures delivery even if no consumers are currently connected (depends on subscription type, e.g., durable subscription via namespace -> Subscriptions in UI).

In summary, Step 5 introduces true publish/subscribe for your integration scenario. Instead of waiting for pull requests, systems react to events. It’s especially powerful for cross-system processes (e.g., a warehouse updates inventory on an “Order Shipped” event).

Step 6: Monitoring and Troubleshooting

A production-grade integration architecture must be actively monitored. SAP Integration Suite offers several tools:

• Integration Suite Operations Monitoring:

  • In the Integration Suite cockpit, navigate to Monitor → Integration Operations. Here you can access the Message Processing Logs. Filter by Integration Flow name, message status, sender, or date. You will see details like Message ID, start time, end time, and status (Success/Error).
  • Drill into an error entry to see the stack trace and payload. Use this to pinpoint issues (e.g., a transformation error or connection failure). For example, if a transformation fails, the log might show a parse error with line numbers.
  • Enable Trace: For more detailed diagnostics, enable trace mode on an integration flow. This logs the full payload at each step (input/output) and variable values. To do this, open the iFlow in the runtime, click Trace → Enable. Then rerun your test scenario. Afterward, check the trace view to follow the data through each step. Disable trace after troubleshooting to avoid performance overhead.

• Message Processing Monitoring API:

  • For automation, SAP provides an OData API to retrieve monitoring data. Example:

    GET <region>.hana.ondemand.com/integrationmonitoring/MessageProcessingLogs?$filter=Status eq 'Error'
    

    Use OAuth (X-CSRF if needed) to authenticate. You can programmatically fetch error logs to integrate with external dashboards or trigger alerts. For instance:

    GET /integrationmonitoring/MessageProcessingLogs
    Authorization: Bearer <API-Mgmt-Token>
    Accept: application/json
    

    The JSON result includes fields like MessageLogID, Status, ErrorLogs, Timestamp, TargetAction.

• Cloud Foundry App Logs:

  • Each deployed integration flow runs on a Cloud Foundry app behind the scenes. Use the CF CLI to check logs or scale as needed. For example:

    cf apps        # lists all apps, find your iFlow app (names are often auto-generated)
    cf logs <app-name> --recent
    

    Look for runtime errors not captured by the monitoring UI. If an iFlow repeatedly crashes, the CF logs may show JAVA_OUT or memory errors.

• API Analytics:

  • In API Management, go to Analytics. You can run dashboards to see how many times each API proxy was called, response times, error rates, and usage by organization or app.
  • Check the Spike Arrest and Quota policies logs to ensure you’re not hitting limits. For example, if many 429 responses are showing up, you may need to raise quotas.
  • Use API Analytics to get trends (e.g., “OrdersAPI calls per hour”) and set alerts if the volume drops unexpectedly (which may indicate an upstream issue).

• Event Mesh Monitoring:

  • In the Event Mesh console, monitor message counts per topic and undelivered (dead-letter) messages. If consumers are missing events, the backlog will pile up.
  • You can also attach monitoring via Cloud Foundry logging: configure the Event Mesh to forward metrics to a monitoring solution or use the AMQP GET client* to programmatically query queue depth.

• End-to-End Tracing and Logging:

  • Consider implementing correlation IDs and Janus tracing. For example, have the sender attach a unique X-Correlation-ID header to each message. Pass this header through all iFlows, API calls, and events. Then, you can search logs across systems by this ID to piece together the transaction flow.
  • Leverage SAP Solution Manager or cloud-native tracing (like Jaeger, if integrated) to visualize distributed traces.

• Alerts and Notifications:

  • Set up Email Alerts in SAP Integration Suite. In the Operations View, configure alert rules: e.g., if any message fails, send an email to support.
  • Alternatively, integrate with external monitoring tools (Datadog, Splunk). Use the OData API or CF logs to feed data into those systems. For example, schedule a script to poll the MessageProcessingLogs API every 5 minutes and send Slack notifications for any Status eq 'Error'.

Troubleshooting Tips:

• If an iFlow fails to deploy, double-check your XML and graphical steps – sometimes missing endpoints or incorrect namespaces cause deployment errors.
• Pay attention to timeouts: By default, synchronous calls (e.g., SOAP receivers) have a 60-second timeout. If backends take longer, raise this in the adapter or switch to asynchronous processing.
• Validate all URLs and hosts. A common mistake is forgetting to update the URL from a test endpoint to production. Use distinct virtualHost names in Cloud Connector for dev/test/qa vs. production.
• Check trust configurations: If an HTTP call returns 403/SSL errors, ensure the SSL certificate is trusted and that any required client certificate is associated correctly.
• Use the Integration Suite Monitor daily to watch for anomalies. Early detection (like growing latency or error spikes) allows you to investigate before customers complain.

After thorough monitoring and fixes, your integration solution should achieve high reliability and performance. In ongoing operations, developers and admins will use these tools to maintain service levels.

Continue evolving your integration landscape by adding more iFlows, APIs, and events as business needs grow. Use version control and CI/CD for every change, engage stakeholders with the developer portal, and iterate on your architecture for constant improvement.

References

• https://help.sap.com/doc/8b6c9b5f4d3e4c5b9a4f2f5a0e1f7a3f/Cloud/en-US/Integration_Suite_Architecture.png
• https://help.sap.com/viewer/product/SAP_INTEGRATION_SUITE
• https://help.sap.com/viewer/product/INTEGRATION_ADVISOR
• https://help.sap.com/viewer/product/SAP_EVENT_MESH
• https://help.sap.com/viewer/product/API_MANAGEMENT