SAP Community - API Management

Introducing AI-Powered Anomaly Insights & Recommendations in SAP Integration Suite

2025-12-08T13:14:27.158000+01:00

Introduction

SAP Integration Suite offers API Anomaly Detection that involves monitoring and identifying abnormalities in time series data related to APIs, enabling API Owners detect unexpected patterns or deviations from the norm, ensuring optimal performance and business continuity. Traditionally, resolving these anomalies has been time-consuming involving manual activities around impact assessment, root cause analysis & identification of mitigation plans.

That’s about to change!

What’s New

SAP Integration Suite now brings AI-powered anomaly insights and intelligent recommendations to help you move from detection to resolution faster than ever. It improves troubleshooting efficiency and reduces manual investigation time. This feature leverages advanced machine learning models to identify anomalies and AI models to suggest actionable steps to fix them—empowering API Owners & developers to stay ahead of issues.

Note : The feature is in the process of getting updated in our global Data centres. Check this Note for information about regional availability.

Note : The availability of the Anomaly Detection & Intelligent Recommendations feature is dependent on your SAP Integration Suite service plan. Check this note for information about the various plans and supported features.

Key Benefits

Detailed Insights & Causes: Ready to use analysis of the Anomaly, its impact and the probable root cause(s)
Intelligent Recommendations: Get context-aware suggestions for quick resolution
Reduced Downtime: Minimize business impact with faster troubleshooting
Continuous Learning: Recommendations improve over time as the system learns from user feedback

Feature Overview

To assist API Owners who have enabled Anomaly Detection in their tenants with faster resolution of Anomalies, we introduce AI-driven analysis of the Anomalies.

When an Anomaly is detected, an advanced AI-model generates comprehensive insights on the event around the system state, clients involved, the intensity of the Anomaly etc. It also then highlights the potential root causes for the Anomaly, which gives clarity on where the corrections/resolutions must be applied. Finally, it also provides a set of recommendations that the API Owners & developers can apply – both within & outside APIM systems - to resolve the issue at hand & also prevent future events.

Enablement

As an API Administrator of an SAP Integration Suite – API Management tenant, one could enable this new extension by just selecting an additional check box under Anomaly Detection settings. If you are switching on Anomaly Detection for the first time, then the check box is selected by default. You need to accept the Generative AI usage terms before starting to use the feature.

Anomaly Analysis

In the event of an Anomaly, if the Intelligent Recommendations has been enabled on the tenant, you will see three new tabs under the Anomaly details – Insights, Causes & Recommendations.

Insights: Delivers an in-depth analysis of unusual API traffic patterns, the system state during the anomaly, and its potential impact on API performance and stability.

Causes: Highlights the likely factors behind the anomaly by examining API usage trends, traffic variations, and underlying system conditions.

Recommendations: Offers practical steps and configuration adjustments to resolve the issue, enhance API performance, and implement preventive measures to avoid similar anomalies in the future.

In the example below, an API Traffic surge Anomaly has been detected. Observe how each of the tabs helps in getting clarity on the event itself & also quickly identify what could be done next.

For each of the generated content, feedback could be provided that helps the AI model learn over time & improve accuracy.

Summary

Instead of spending hours diagnosing issues, API owners can now rely on AI-driven guidance to resolve problems efficiently. This means less manual effort, fewer disruptions, and more time for innovation. More information could be found in our help documentation here.

Enable anomaly detection and intelligent recommendations in your SAP Integration Suite – API Management tenant and experience smarter, faster ways to work with your APIs. Do give this a try & let us know what you think.

Part 1: Governance in Developer Hub: Empowering Administrators with Control and Flexibility

2025-12-17T06:08:15.318000+01:00

Overview

Governance lies at the heart of every well-managed Developer Hub. It ensures that access, visibility, and subscription processes remain secure, compliant, and aligned with organizational policies.

Developer Hub offers integrated governance features that enable administrators to oversee and manage essential developer activities, such as user registration and product subscriptions.

As a Developer Hub administrator (assigned the AuthGroup.API.Admin role collection), you can configure governance levels that best fit your organization’s needs—striking the right balance between openness and control.

Note: This three-part series will guide you through the full spectrum of governance in Developer Hub. In Part 2, we will extend these foundational concepts by setting up an external governance workflow for more advanced approval scenarios. In Part 3, we will take this a step further and demonstrate how to implement external governance using SAP Integration Suite and SAP Build Process Automation, enabling a fully integrated and automated approval experience.

Understanding Governance Levels in Developer Hub

Developer Hub’s governance framework is divided into two main areas: Access Governance and Subscription Governance.

Access Governance: Access governance determines who can see, register for, and access APIs within your Developer Hub.
- Site Visibility Governance: Control how visible your Developer Hub catalog is to users. For detailed steps, see Manage Access.
- User Registration Governance: Require administrator approval for new user registrations to ensure only authorized developers gain access. See Managing the Access Request of the Users.
- Product Visibility Governance: Define which users can access specific API products using custom role collections. See Restricting Access to API Products Using Custom Role Attribute.
Subscription Governance: Subscription governance defines how API product subscriptions are managed. Administrators can choose to let external systems handle approval workflows by enabling external governance, ensuring that subscription decisions align with enterprise workflows and approval processes. See Manage Product Subscriptions.

Manage Product Subscriptions

Subscriptions are how developers gain access to API products in Developer Hub. Administrators can configure how these subscriptions are approved—either automatically within the Developer Hub or through an external approval process—to ensure proper governance, control, and secure API access.

Managing Governance for Internal and External API Products

Governance works differently depending on whether your APIs are managed inside or outside the SAP ecosystem.

SAP Managed Products are products that contain APIs managed within SAP Integration Suite. All APIs inside these products are created, published, and governed using SAP’s native capabilities—including automated or manual subscription approvals, user registration controls, and end-to-end lifecycle management.

Externally Managed Products are products that contain APIs managed outside SAP Integration Suite, even though the product itself is published through the platform. These APIs originate from external systems or services, and therefore require external governance mechanisms, to handle subscription requests and validations that cannot be governed directly within the platform.

Governance for SAP-Managed Products

For APIs managed within SAP API Management, subscription approvals occur through Developer Hub based on the configured settings. The credentials to access these APIs are generated by SAP API Management.

Governance for Externally Managed Products

For APIs managed outside SAP:

The content administrator (AuthGroup.Content.Admin) can import external APIs, package them into products, and publish them in Developer Hub.
The product must be marked as subscribable by selecting the Allow Subscription checkbox.

Depending on your setup, you can choose between:

Governance Only: To track developer-product relationships.
Governance + Credential Distribution: To also share API credentials automatically upon approval.

Note: Developers cannot subscribe directly to these products within SAP.
External administrators can manually share API keys from their external gateways after approval.

Configuration Requirements Summary

To ensure smooth external governance:

Governance option set to Manage Approval Outside Developer Hub
Product marked as Allow Subscription (applicable only for externally managed products.)
All SPI and destination configurations completed
External system properly integrated with Developer Hub API

Note: You cannot remove or modify products with pending or approved subscriptions.
To apply configuration updates, bring the product into draft mode, make changes, and republish it.

Conclusion

Developer Hub’s governance capabilities provide the flexibility and control modern enterprises need to manage their API ecosystems effectively.

Whether your organization prefers internal governance through SAP systems or external workflows via custom integrations, Developer Hub empowers administrators to tailor governance processes that align with their business policies—ensuring secure, compliant, and well-managed API access across your developer community.

Part 3 Configuring External Governance

Part 2: Setting Up an External Governance Workflow

2025-12-17T06:08:29.647000+01:00

Organizations that require more sophisticated approval flows can configure external governance.
This setup allows subscription requests raised within Developer Hub to be reviewed, approved, or rejected through an external system (such as SAP Build Process Automation, any other custom workflow, or an custom application).

Before we dive into the implementation details, it is helpful to revisit the foundations covered in the earlier parts of this series.
In Part 1, we explored the importance of governance within Developer Hub and how administrators can configure built-in governance levels to balance openness with control.

Step 1: Enable External Governance in Developer Hub

Logon to Developer Hub.
Navigate to Admin Center > Manage Governance Settings, click on the Subscriptions tab, and choose Edit.
Now, select the option Manage Approval Outside Developer Hub and choose Save.

This redirects all future subscription requests to your external governance system for approval.

Note: Enabling this setting alone isn’t enough—several prerequisites must be completed for the setup to function correctly. Make sure you first complete all prerequisite steps and only then update the governance settings.

Step 2: Implement the Service Provider Interface (SPI)

The customer subaccount administrator must implement the Service Provider Interface (SPI), which handles the redirection of subscription requests to your external system.
This could be a workflow, backend service, or UI application that processes approvals.

SPI specifications, including interface details and parameters, are available on the SAP Business Accelerator Hub.

Recommendation

Use SAP Integration Suite API Management for implementing the Service Provider Interface (SPI), and SAP Build Process Automation for designing your external approval workflow. For step-by- step instruction, see Part 3: Implementing External Governance Using SAP Integration Suite and SAP Build Process Automation (add blog link).

Step 3: Create a Destination in SAP BTP Cockpit

Once the SPI is in place, create a destination in your SAP BTP subaccount that points to the SPI endpoint.
This destination should include:

The SPI service URL
Authentication credentials (e.g., OAuth2, Basic Auth)

This setup ensures Developer Hub can securely send subscription requests to your external system.

In your web browser, log on to SAP BTP Cockpit and navigate to your source subaccount.
Choose the Connectivity > Destinations tab in the left-hand pane.
Choose Create and in the Create New Destination popup, select From Scratch to create a new destination manually.
In Destination Details section, fill in all the required details according to the descriptions provided in the table and choose Create.

Note: Use the credentials provided by the customer sub-account administrator. Supported authentication methods include OAuth 2.0, Client Certificate, and Basic authentication.

Fields	Details
Name	Enter DeveloperHub_Governance_SPI as the destination name.
Type	Enter HTTP as the supported type.
Description	Enter a brief description stating the purpose of creating a new destination in the Description field.
URL	Enter the external governance application URL. Since, in this use case, you are using the API proxy as the SPI implementation in SAP Build, enter the API proxy connectivity link in the Destination URL field and provide the corresponding authentication details.
Proxy Type	Internet
Authentication	Select the authentication type depending on your requirement. Basic: User provides a simple username and password based authentication. Client Certificate: The user provides the Key Store Source, Key Store Location, and Key Store Password. The server verifies the certificate to grant access. OAuth2ClientCredentials: Used when third-party services need to access resources without sharing the user’s password. A backend service authenticating with a resource server to access an API using Client ID, Client Secret, and Token Service URL. The token URL should correspond to the customer governance application when OAuth2 is being used.

You can also do a Check Connection to verify whether you've added the destination correctly.

Step 5: Update Developer Hub with Governance Decisions

After the external administrator approves or rejects a subscription request, that decision must be communicated back to Developer Hub.

The external governance system does this by calling the API Developer Hub - External Governance (CF) published on SAP Business Accelerator Hub, using credentials tied to the AuthGroup.External.Reviewer role collection.

Once the decision is received, Developer Hub updates the subscription status accordingly.

When Governance Takes Effect

Once all prerequisites are fulfilled and Manage Approval Outside Developer Hub is enabled:

New subscription requests are automatically routed to the external approval system.
Approvals and rejections are reflected in Developer Hub based on feedback from the external workflow.

⚠️Caution:
If prerequisites aren’t configured correctly, subscription requests will fail. Always verify your setup before enabling external governance.

How the External Subscription Process Works

Developer Submits a Subscription Request

The developer subscribes to an API product from the Developer Hub catalog.
The request is automatically sent to the external approval system.

External Administrator Reviews the Request

The external admin (using a workflow, e.g., SAP Build Process Automation) reviews and approves or rejects the request.
They can view API details in Developer Hub or via APIs on SAP Business Accelerator Hub.

Developer Receives the Decision

If approved, the developer receives a confirmation email containing a link to the application with the subscribed product.

If rejected, they receive a rejection email, and the pending subscription is deleted.
Developers can monitor request status under My Workspace → Subscriptions → Pending Approval.

Configuration Requirements Summary

To ensure smooth external governance:

Set the governance option to Manage Approval Outside Developer Hub
Select the Allow Subscription option for the product.
Complete all the Service Provider Interface (SPI) and destination configurations
Integrate the external system properly using the Developer Hub API

Note: ️ You cannot remove or modify products with pending or approved subscriptions.
To apply configuration updates, bring the product into draft mode, make changes, and republish it.

Conclusion

Developer Hub’s governance capabilities provide the flexibility and control modern enterprises need to manage their API ecosystems effectively.

Whether your organization prefers internal governance through SAP systems or external workflows via custom integrations, Developer Hub empowers administrators to tailor governance processes that align with their business policies—ensuring secure, compliant, and well-managed API access across your developer community.

Part 3: Implementing External Governance in Developer Hub Using SAP Integration Suite and SAP Build

2025-12-17T06:08:57.959000+01:00

In Part 1, we explored the importance of governance within Developer Hub and how administrators can configure built-in governance levels to balance openness with control.
In Part 2, we walked through how to set up an external governance workflow, enabling subscription requests to be processed through systems such as SAP Build Process Automation.

Building on these foundations, Part 3 focuses on how to implement the Service Provider Interface (SPI) using SAP Integration Suite – API Management and how to design and manage your approval workflow with SAP Build Process Automation. This combined approach ensures a streamlined, standardized, and well-governed integration between Developer Hub subscription flows and your organization’s external approval mechanisms.

Before we dive into the implementation details, it is helpful to revisit the foundations covered in the earlier parts of this series.

Recommended Workflow:

Set up the External Workflow in SAP Build

Leverage SAP Build Process Automation to design the external governance workflow. For more information on SAP Build Process Automation, see SAP Process Automation | SAP Learning.

Sample workflow to review the applications

On click of approve/reject call the Developer Hub API to inform about the decision. You can find the API details here: Developer Hub - External Governance (CF) -Governance Decision

Sample workflow to invalidate the credentials when they were shared with Developer Hub

On click of Submit the credentials can be deleted in Developer Hub by calling the API: Developer Hub - External Governance (CF) - Deletion Confirmation

Note: If you don’t have any externally managed API products, you can skip this step.

Obtain Credentials from Workflow

Create a service instance and a service key of SAP Build Process Automation Service in SAP BTP Cockpit to obtain the credentials. For more information, see Create a Service Instance and Create a Service Key for the SAP Build Process Automation Instance | SAP Help Portal.

1. Create the API proxy that acts as your SPI implementation for SAP Build

Prerequisite:

Create an API provider

a). Log on to the SAP Integration Suite.
b). Navigate to the API Configuration Page.
From the side navigation pane, choose Configure → APIs.

c). Create a New API Proxy.
Click Create to start defining your API proxy.

Discover the policy template

Navigate to the Discover tab and search for the SAP API Management Governance <Link> package. Open the package and go to Artifacts. Select the template Developer Hub Governance with SAP Build Process Automation and, under Actions, choose Copy.

Steps to create an API

Log on to the SAP Integration Suite.
Access your Integration Suite environment with administrator privileges.
Navigate to the API Configuration Page.
From the side navigation pane, choose Configure → APIs.
Click Create to start defining your API proxy.

4. Select the Provider method and fill in the required details.

From the dropdown, choose the API Provider you created for SAP Build Process Automation in the prerequisite steps. Then enter the API Name, Title, and API Base Path.

Note: In the URL field, enter: /workflow/rest/v1/workflow-instances.

Fields such as API State and Host Alias will populate automatically. Set the Service Type to REST.

5. Review your configurations and choose Create.

. Now, go to the Policies tab, click on Policy Template and choose Import.

To call the SAP Build workflow, import this policy template and update the following script:

Script Name: setVariables

jsgovernanceWorkflowDefinitionId: The workflow ID for the governance approval/rejection process.

keyInvalidationWorkflowDefinitionId: The workflow ID for the key invalidation request.

keyInvalidationResponse:

Set to 200 if you want Developer Hub to immediately proceed with application deletion once the workflow request is created.

Set to 202 if you want Developer Hub to wait for confirmation before deleting the application.

In the top-right corner of the API details page, click the ⋯ (More options) button. From the dropdown menu, select Deploy.

2. Add the API Proxy URL to the Destination in SAP BTP Cockpit

After implementing the Service Provider Interface (SPI), the customer subaccount administrator creates a destination in their SAP BTP subaccount pointing to the SPI endpoint.

In your web browser, log on to SAP BTP Cockpit and navigate to your source subaccount.
Choose the Connectivity > Destinations tab in the left-hand pane.
Choose Create and in the Create New Destination popup, select From Scratch to create a new destination manually.
In Destination Details section, fill in all the required details according to the descriptions provided in the table and choose Create.

Note: Use the credentials provided by the customer sub-account administrator. Supported authentication methods include OAuth 2.0, Client Certificate, and Basic authentication.

Fields	Details
Name	Enter DeveloperHub_Governance_SPI as the destination name.
Type	Enter HTTP as the supported type.
Description	Enter a brief description stating the purpose of creating a new destination in the Description field.
URL	Enter the external governance application URL. Since, in this use case, you are using the API proxy as the SPI implementation in SAP Build, enter the API proxy connectivity link in the Destination URL field and provide the corresponding authentication details.
Proxy Type	Internet
Authentication	Choose OAuth2ClientCredentials. Fetch the Client ID, Client Secret, and Token Service URL from the workflow credentials. Refer to the “Obtain Credentials from Workflow” section for details. The token URL should correspond to the customer governance application when OAuth2 is being used.

You can also do a Check Connection to verify whether you've added the destination correctly.

3. Enable External Governance in Developer Hub

Logon to Developer Hub.
Navigate to Admin Center > Manage Governance Settings, click on the Subscriptions tab, and choose Edit.
Now, select the option Manage Approval Outside Developer Hub and choose Save.

This redirects all future subscription requests to your external governance system for approval.

Streaming in SAP API Management: Extended Guide

2025-12-21T13:24:57.654000+01:00

Why Streaming Matters

By default, APIM buffers request/response payloads so policies can operate on the full message. Non-streamed payloads are limited to ~10 MB. When payloads exceed the buffer, APIM returns a fault. Streaming lifts this buffer by passing data through without payload modifications, allowing up to ~500 MB per direction (subject to connection stability).

Key Limits

Non-streamed request/response: up to 10 MB
Streamed request/response: up to ~500 MB
Header limits: Request headers ~18 KB; Response headers ~25 KB
Resource files (XSL/JS/Python) ~15 MB (design-time)

Note: When streaming is enabled, policies that read or transform the payload are bypassed and may fail on large payloads.

Properties Explained

request.streaming.enabled (ProxyEndpoint & TargetEndpoint):
false: buffer requests; payload policies operate.
true: stream request payload to target; payload-reading policies in ProxyEndpoint request flow are bypassed.

response.streaming.enabled (ProxyEndpoint & TargetEndpoint):
false: buffer responses; payload policies operate.
true: stream response payload back to client; payload-reading policies in ProxyEndpoint response flow are bypassed.

Configure via UI (APIM Portal)

Steps:
1. Go to Develop → APIs → select your proxy.
2. Open Proxy Endpoint tab → Properties → Add:
• Name: request.streaming.enabled, Value: true
• Name: response.streaming.enabled, Value: true
3. Open Target Endpoint tab → Properties → Add same properties.
4. Save and redeploy the proxy.

Configure via XML (Proxy & Target Definitions)

Proxy Endpoint sample:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<ProxyEndPoint default='true'>
<name>default</name>
<base_path>/my/api</base_path>
<properties>
<property><name>request.streaming.enabled</name><value>true</value></property>
<property><name>response.streaming.enabled</name><value>true</value></property>
</properties>
</ProxyEndPoint>

Target Endpoint sample:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<TargetEndPoint>
<name>default</name>
<url>https://backend.example.com/v1</url>
<properties>
<property><name>request.streaming.enabled</name><value>true</value></property>
<property><name>response.streaming.enabled</name><value>true</value></property>
</properties>
</TargetEndPoint>

Error 'Screenshots' (Fault Payloads)

Non-streamed payload exceeds 10 MB:

Streaming enabled but payload-transform policy attached:

Policies: What Works / What to Avoid

Works with streaming: Verify API Key, OAuth verification, Access Control, basic header logging (no body read).
Avoid with streaming: JSON↔XML transforms, schema validations, masking/redaction, payload enrichment — these force buffering or fail.

Patterns with SAP Cloud Integration (CPI)

Use APIM for pass-through streaming of large payloads. Perform transformations/validations in CPI or backend. For very large datasets, consider paging, split-and-collect, or batch processing.

Optional: Streaming + gzip + chunked

Compress the entire payload first, then stream using chunked transfer (Content-Encoding: gzip; Transfer-Encoding: chunked; no Content-Length).

Troubleshooting

TooBigBody: Enable streaming for the affected direction; remove payload-transform policies.
Policies inconsistent >10 MB: Redesign to avoid body access in streamed flows.
Timeouts: Adjust TargetEndpoint transport properties (connect.timeout.millis, io.timeout.millis) per backend latency.

FAQs

Q: Can I enable streaming on all proxies?
A: Technically yes, but only enable when required; payload policies will be bypassed.
Q: Maximum streamed size?
A: ~500 MB per request/response direction; ensure stable connections.
Q: Can I transform payload while streaming?
A: Not recommended in APIM; move transforms to CPI/backend.

Pre-deployment Checklist

☐ Identify direction (request/response) needing streaming.
☐ Remove payload-inspecting policies from streamed flows.
☐ Tune timeouts for long streams.
☐ Communicate design impacts to teams (no in-proxy transforms).
☐ Validate with large test payloads.

Disclaimer

This content reflects implementation experience and references official SAP Help pages. Always consult SAP Help for the latest guidance and product limits.

References

SAP Help: Enable Streaming of Requests and Responses in an API Proxy – https://help.sap.com/docs/integration-suite/sap-integration-suite/enable-streaming-of-requests-and-responses-in-api-proxy

SAP Help: Proxy Endpoint Properties – https://help.sap.com/docs/sap-api-management/sap-api-management/proxy-endpoint-properties

SAP Help: Limits in API Management – https://help.sap.com/docs/sap-api-management/sap-api-management/limits

SAP Help (Neo) – Sample streaming configuration – https://help.sap.com/docs/sap-api-management/sap-api-management-for-neo-environment/enable-streaming-of-requests-and-responses-in-api-proxy

Turning SAP BTP Integration Suite as a core ERP module for Business APIs & Business AI

2026-01-07T12:19:25.663000+01:00

ERP modernization is not enough

Over recent years, SAP clients have concentrated transformation efforts on S/4HANA to standardize processes, adopt cloud operating models (public, private, hybrid, sovereign), and enable continuous evolution. In parallel, the integration backbone must evolve from SAP PI-PO to SAP Integration Suite, ensuring your enterprise can operate API‑first and Event‑first, at the speed and scale modern business demands.

Context: SAP PI/PO maintenance aligns with NetWeaver 7.5 lifecycles. But this decision point is not just about end‑of‑maintenance.
Imperative: Integration modernization is foundational to agility, AI‑enabled processes, and resilient cloud operations across heterogeneous landscapes.

Beyond “middleware”: What SAP Integration Suite really is

SAP Integration Suite is not a one‑to‑one PI-PO replacement. It’s an enterprise iPaaS on SAP BTP that unifies:

Cloud Integration for process and data integration
API Management to design, secure, publish, and govern Business APIs
Event Mesh for event‑driven architectures (EDA)
Integration Advisor and content packages for accelerated build
Monitoring and observability for end‑to‑end visibility across hybrid landscapes

This shift, from “interfaces” to "Business APIs", enables secure, discoverable, measurable, and even monetizable capabilities. It opens a path to Composable Architecture, where SAP and non‑SAP modules can be assembled, re‑assembled, and composed to meet changing business needs.

Key benefits:

Speed: Faster delivery via reusable APIs, events, and prebuilt content
Quality: Strong governance, testing patterns, and observability
Resilience: Decoupling through asynchronous events and queues
Scale & Security: Unified policy enforcement, rate limiting, and consistent identity/access models

From Monolith to Modular: Real‑Time, Composable Integration

For Supply Chain, Manufacturing, and other data‑intensive domains, real‑time integration is essential. By slicing the SAP monolith into modular building blocks, organizations can distribute, elevate, and govern data across the enterprise and partners ecosystem.

Decoupled communication allows plug‑and‑play assembly of new components and systems.
Event‑driven patterns (domain events, queues, fan‑out) reduce coupling and improve reliability.
Business APIs + events become the operating surface for cross‑system processes and innovation.

Preparing for Enterprise AI Agents: Event‑First, API‑First

AI is rapidly moving beyond chat into agents that act, use tools, and orchestrate work across systems. SAP is rolling out agentic capabilities on SAP BTP, including Joule Studio for Enterprise Agents, and secure access to foundation models via SAP AI Core and Generative AI Hub. Capabilities and patterns emerging in the ecosystem include:

Model Context Protocol (MCP) to simplify agent connections to tools and data
Agent‑to‑Agent (A2A) patterns/protocols for secure, autonomous collaboration
AI Adapter patterns to link Integration Suite flows with GenAI tasks

In this operating model, Business APIs and events let agents subscribe to near real‑time signals, trigger actions/approvals, and enrich processes, reusing the IT estate and preserving existing investments while modernizing how work gets done.

A Practical PI-PO to Integration Suite Path

Treat the transformation as a program, not a lift‑and‑shift. A pragmatic path often includes:

Assessment & Prioritization
- Inventory interfaces (by business process, domain, criticality, volume, latency).
- Identify patterns: synchronous APIs, asynchronous events, B2B/EDI, file, IDoc, RFC, REST/SOAP.
Target Architecture & Design Principles
- Define API‑first and event‑first standards (naming, versioning, domain event taxonomy).
- Establish security models (identity, scopes, policies), observability, and SLAs.
Co‑Existence & Strangler Pattern
- Run PI-PO and Integration Suite side by side.
- Gradually redirect traffic to new APIs/events, decommission legacy interfaces incrementally.
Enablement & Guardrails
Cutover & Stabilization
Decommissioning & Continuous Evolution
- Retire redundant PI-PO objects; codify lessons learned.
- Expand event domains; evolve API products; onboard partners faster.

Anti‑Patterns to avoid

Lift‑and‑shift without rethinking business APIs and event domains
Point‑to‑point proliferation that undermines modularity and reuse
No product ownership, leaving integrations to drift without roadmaps or SLAs
Limited observability, making troubleshooting slow and costly

The takeaway

The ECC to S/4HANA journey modernizes the core.
The PI-PO to Integration Suite journey operationalizes Business APIs and events, enabling composable architectures, resilient integrations, and AI‑ready operating models.

Organizations that treat integration as a business platform - rather than a technical migration - will gain a durable advantage in agility, innovation, and speed to value.

Call to Action

Are you aligning the PI-PO to Integration Suite transformation with your Cloud ERP journey? Start with a portfolio assessment, define API‑first and event‑first standards, and establish a co‑existence plan that drives measurable business outcomes. The sooner you begin, the faster your enterprise will be ready for event‑driven processes and AI agents.

Asynchronous Logging in SAP API Management

2026-01-08T13:58:24.166000+01:00

Introduction

When configuring APIs in SAP API Management, it is as important aspect to configure info logging or error logging and then send it across to the downstream systems like Loggly, ServiceNow etc. which is Synchronous mode by default. Since the default logging in API Proxies takes place in Synchronous mode, the consumer of the API Proxy must wait for all backend calls to finish, which increases the total response time which is a big concern in the Request-Reply pattern.

This blog explains how to implement true asynchronous logging in SAP API Management. The main objective of this blog is to showcase the approach of implementing Asynchronous logging in APIM and improve the response time which is so critical for Request-Reply Pattern.

Synchronous vs Asynchronous Logging

Before building the necessary Artifacts for enabling Asynchronous logging, let’s understand the behavioral difference:

Synchronous Logging

When a request arrives, the API proxy processes it to the target backend and then directly calls logging systems like Loggly where in the result could be success or failure. If it is success ,the flow moves into the PostFlow of the proxy endpoint. Here, the proxy makes a synchronous call to the logging system. The response is sent to the consumer only after this logging call finishes, which increases the overall response time. If there is a failure, the flow triggers FaultRules where error logging happens synchronously, and the error response is sent only after the logging call completes.

Asynchronous Logging

When a request arrives, the API proxy processes it and immediately sends the response back to the api proxy consumer due to async mode of logging. Logging operations happen separately in the background by queuing messages to JMS for later processing. Background processes handle the actual delivery to Loggly or other logging platforms. If logging fails, it gets retried without impacting the response time.

Compared to synchronous logging, this approach helps APIs respond faster, keeps logging problems away and perform well even during high traffic.

Architecture Overview

Implementation Steps:

Step 1:Create a proxy endpoint:

After creating the proxy endpoint, include the following policies:

Step 2: Extract the Control Header

First, we add a header to control when asynchronous logging should be used.

Policy: ExtractVariables-Flag.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ExtractVariables async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
<! -- Extract AsyncFlag from incoming HTTP header -->
    <Header name="AsyncFlag">
        <Pattern>{AsyncFlag}</Pattern>
    </Header>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    <Source>request</Source>
</ExtractVariables>

This extracts the AsyncFlag header from the request. When the value is "true", asynchronous logging will be triggered.

Step 3: Prepare the Log Payload

Build the log message containing all the request details you want to capture. This structured JSON format makes it easy to search and analyze logs in Loggly.
Policy: AssignMessage-LogPayload.xml

<!-- This policy assigns a log payload JSON to a variable -->
<AssignMessage async="false" continueOnError="false" enabled="true" xmlns='http://www.sap.com/apimgmt'>
  <AssignVariable>
    <Name>LogPayload</Name>
    <Value>
      {
        "timestamp":”system.timestamp}",
        "messageId":"{messageid}",
        "apiProxy":"{apiproxy.name}",
        "environment":"{environment.name}",
        "logLevel":"INFO",
        "description":"Request received for processing",
        "syncFlag":"{req.AsyncFlag}",
        "targetURL":"{target.url}"
      }
    </Value>
  </AssignVariable>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <AssignTo createNew="false" type="request">request</AssignTo>
</AssignMessage>

This creates a variable called LogPayload containing a JSON object.

Step 4: Configure the Async Log Request

Prepare the request object that will be used to send logs asynchronously. This step structures how the log data will be transmitted to the logging system.

Policy: AssignMessage-AsyncLogRequest.xml

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
<!-- Assign payload and headers for async log request -->
  <AssignVariable>
    <Name>AsyncLogRequest.payload</Name>
    <Value>{logPayload}</Value>
  </AssignVariable>
<AssignVariable>
    <Name>AsyncLogRequest.header.Content-Type</Name>
    <Value>application/json</Value>
  </AssignVariable>
<AssignVariable>
    <Name>AsyncLogRequest.verb</Name>
    <Value>POST</Value>
  </AssignVariable>
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
  <AssignTo createNew="true" type="request">AsyncLogRequest</AssignTo>

Step 5: Configure Authentication Credentials

Configure the authentication needed to securely call your SAP Cloud Integration endpoint. Store your cloud integration client credentials and encode them into the proper authorization header format that will be used when sending logs.

Step 6: Trigger Asynchronous Logging via Integration Flow and JMS

In this step, the API proxy hands over the prepared log payload to an integration endpoint asynchronously, and from there the message is written into a JMS queue. This asynchronous approach ensures that it does not wait for the logging response and no delay to the consumer.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout async="true" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
    <Request clearPayload="true">
        <Set>
            <Headers>
                <Header name="Content-Type">application/json</Header>
                <Header name="Authorization">{sapapim.Authorization}</Header>
            </Headers>
            <Payload contentType="application/json">{logPayload}</Payload>
            <Verb>POST</Verb>
        </Set>
        <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
    </Request>
    <Response>cpi.logresponse</Response>

    <Timeout>30000</Timeout>

    <HTTPTargetConnection>
        <URL>https://{cpi-tenant-url}/http/Async_toJMS</URL>
    </HTTPTargetConnection>
</ServiceCallout>

Important: This policy is configured to be executed only when the condition request.header.AsyncFlag = "true" is met. This means asynchronous logging is triggered based on the header value sent in the request.

Once the integration endpoint receives the log payload, it stores the message in a JMS queue instead of sending it directly to Loggly or another logging system. This is where real asynchronous behavior comes from.

Why JMS helps with asynchronous logging?

JMS queues let the integration flow accept a log message, drop it into a queue, and return immediately. The queue takes responsibility for the message from that point on. A separate consumer reads from the queue later and sends the log to Loggly or any other target system such as service now etc.

This means the logging process is completely decoupled from the original request. The API response is not tied to how fast Loggly responds or whether it is even available at that moment. The request finishes as soon as the business logic is done, while JMS guarantees that the log will be processed in the background, which is exactly the asynchronous behavior we want.

Conclusion

Asynchronous logging keeps logging out of the API’s critical execution path. The API finishes its business processing and sends the response back to the client right away, while logs are passed in the background to the integration layer and JMS for delivery to Loggly.

This way, response times stay fast, logging delays or outages don’t affect the API, and you still get all the visibility needed for monitoring and troubleshooting. It’s a practical approach that balances performance, reliability, and observability, making it a good fit for high-volume, enterprise APIs.

Creating a REST API (web service) in SAP for Web App Consumption.

2026-01-08T18:27:24.050000+01:00

Step by step process for creating a rest API (Web Service) in sap, which will be consume by
web based application:

1. Create Table- ZDT_WEB_COMPLAIN

2. Create SNRO Number range object: ZSNRO_WEB

Transaction code: SNRO

Give SNRO name and click on create

enter short text, long text, number length domain, % warning and save.

click on Ranges--> click on change intervals--> click on new entries.

insert the number range and save.

3. Create request handler class : ZCL_WEBCOMPLAINT_REQHANDLR

Go to Transaction Code - SE24 and create request handler class.

enter the superclass as cl_rest_http_handler and click on save.

Go to method section to see super class methods.

select the get_root_handler and click on redefine. Add the below code in between method and endmethod.

DATA(lo_router) = NEW cl_rest_router( ).  
  
    lo_router->attach( EXPORTING  
                       iv_template =  '/webcomplaint' " Unified Name for Reso  
                       iv_handler_class =  'ZCL_WEBCOMPLAINT_REQHANDLR'   " Object Type Name  
                      "  it_parameter  = " Resource contructor parameters

save and activate the class .

4. Create resource provider class: ZCL_WEBCOMPLAINT_REQPROVIDER.

Go to Transaction Code - SE24 and create request provider class.

enter the superclass as cl_rest_resource and click on save.

Go to method section to see super class methods.

select the method 'GET' and click on redefine . Add the below code.

DATA : lv_string1   TYPE vbeln,         "string, 
           lv_string2   TYPE string, 
           gs_complaint TYPE zdt_web_complain. 
 
    lv_string1 = mo_request->get_uri_query_parameter( iv_name = 'DOC_ID' ). 
 
    CALL FUNCTION 'CONVERSION_EXIT_ALPHA_INPUT' 
      EXPORTING 
        input  = lv_string1 
      IMPORTING 
        output = lv_string1. 
 
 
    SELECT SINGLE * FROM zdt_web_complain INTO CORRESPONDING FIELDS OF gs_complaint 
    WHERE doc_id = lv_string1. 
 
 
    /ui2/cl_json=>serialize( 
      EXPORTING 
        data        =  gs_complaint    " Data to serialize 
*       COMPRESS    = ABAP_FALSE    " Skip empty elements 
*       NAME        =     " Object name 
*       PRETTY_NAME =     " Pretty Print property names 
*       TYPE_DESCR  =     " Data descriptor 
      RECEIVING 
        r_json      =   lv_string2  " JSON string 
    ). 
 
    mo_response->create_entity( )->set_string_data( iv_data = lv_string2 ). 
 
 
    mo_response->set_header_field( 
 
      EXPORTING 
        iv_name  =  'Content-Type'   " Header Name 
        iv_value =  'application/json'   " Header Value 
    ). 



save and activate .  

similarly redefine the post method and add the below code. 

  METHOD if_rest_resource~post.
*CALL METHOD SUPER->IF_REST_RESOURCE~POST
*  EXPORTING
*    IO_ENTITY =
*    .

    DATA : lv_string1   TYPE vbeln,         "string,
           lv_string2   TYPE string,
           lv_response  TYPE string,
           gs_complaint TYPE zdt_web_complain.

    DATA(lo_entity)    = mo_request->get_entity( ).
    DATA(lo_response)  = mo_response->create_entity( ).

    "read string data i.e json
    DATA(lv_data) = lo_entity->get_string_data( ).

    /ui2/cl_json=>deserialize(
      EXPORTING
        json                  =  lv_data   " JSON string
*     PRETTY_NAME           =     " Pretty Print property names
      CHANGING
        data                  =  gs_complaint   " Data to serialize
    ).
*   CATCH CX_SY_MOVE_CAST_ERROR.    "

    CALL FUNCTION 'NUMBER_GET_NEXT'
      EXPORTING
        nr_range_nr             = '01'
        object                  = 'ZSNRO_WEB'
        quantity                = '1'
*       SUBOBJECT               = ' '
*       TOYEAR                  = '0000'
*       IGNORE_BUFFER           = ' '
      IMPORTING
        number                  = gs_complaint-doc_id
*       QUANTITY                =
*       RETURNCODE              =
      EXCEPTIONS
        interval_not_found      = 1
        number_range_not_intern = 2
        object_not_found        = 3
        quantity_is_0           = 4
        quantity_is_not_1       = 5
        interval_overflow       = 6
        buffer_overflow         = 7
        OTHERS                  = 8.
    IF sy-subrc <> 0.
* Implement suitable error handling here
    ENDIF.

    gs_complaint-createdby    = sy-uname.
    gs_complaint-createdon    = sy-datum.
    gs_complaint-time         = sy-uzeit.

    INSERT INTO zdt_web_complain VALUES gs_complaint.


    /ui2/cl_json=>serialize(
      EXPORTING
        data        =   gs_complaint    " Data to serialize
*        COMPRESS    = ABAP_FALSE    " Skip empty elements
*        NAME        =     " Object name
*        PRETTY_NAME =     " Pretty Print property names
*        TYPE_DESCR  =     " Data descriptor

      RECEIVING
          r_json   = lv_response
          ).

    " JSON string
    lo_response->set_string_data( iv_data = lv_response ).

ENDMETHOD.

save and activate.

similarly redefine the post method and add the below code.

METHOD if_rest_resource~post.
*CALL METHOD SUPER->IF_REST_RESOURCE~POST
*  EXPORTING
*    IO_ENTITY =
*    .

    DATA : lv_string1   TYPE vbeln,         "string,
           lv_string2   TYPE string,
           lv_response  TYPE string,
           gs_complaint TYPE zdt_web_complain.

    DATA(lo_entity)    = mo_request->get_entity( ).
    DATA(lo_response)  = mo_response->create_entity( ).

    "read string data i.e json
    DATA(lv_data) = lo_entity->get_string_data( ).

    /ui2/cl_json=>deserialize(
      EXPORTING
        json                  =  lv_data   " JSON string
*     PRETTY_NAME           =     " Pretty Print property names
      CHANGING
        data                  =  gs_complaint   " Data to serialize
    ).
*   CATCH CX_SY_MOVE_CAST_ERROR.    "

    CALL FUNCTION 'NUMBER_GET_NEXT'
      EXPORTING
        nr_range_nr             = '01'
        object                  = 'ZSNRO_WEB'
        quantity                = '1'
*       SUBOBJECT               = ' '
*       TOYEAR                  = '0000'
*       IGNORE_BUFFER           = ' '
      IMPORTING
        number                  = gs_complaint-doc_id
*       QUANTITY                =
*       RETURNCODE              =
      EXCEPTIONS
        interval_not_found      = 1
        number_range_not_intern = 2
        object_not_found        = 3
        quantity_is_0           = 4
        quantity_is_not_1       = 5
        interval_overflow       = 6
        buffer_overflow         = 7
        OTHERS                  = 8.
    IF sy-subrc <> 0.
* Implement suitable error handling here
    ENDIF.

    gs_complaint-createdby    = sy-uname.
    gs_complaint-createdon    = sy-datum.
    gs_complaint-time         = sy-uzeit.

    INSERT INTO zdt_web_complain VALUES gs_complaint.


    /ui2/cl_json=>serialize(
      EXPORTING
        data        =   gs_complaint    " Data to serialize
*        COMPRESS    = ABAP_FALSE    " Skip empty elements
*        NAME        =     " Object name
*        PRETTY_NAME =     " Pretty Print property names
*        TYPE_DESCR  =     " Data descriptor

      RECEIVING
          r_json   = lv_response
          ).

    " JSON string
    lo_response->set_string_data( iv_data = lv_response ).

ENDMETHOD.

save and activate.

5. Create SICF service:

Execute Transaction code SICF.

click on execute.

give the service element name and press enter.

enter description and request handler class name [ zcl_webcomplaint_reqhandlr ]and save.

on SICF main screen activate the service.

now before testing add some record in table, then test the service.

SAP BTP - IS - How to become a SAP Integration Suite Consultant beyond SAP CPI - SAP APIM Part I

2026-01-09T11:49:25.429000+01:00

Spoiler

Disclaimer: This isn’t a tutorial about how button click works. No, the audience of this post are engineers with all levels of experience, from Junior up to Senior, which might have fallen into that "I'm SAP CPI". My goal has been to help you move from just obvious to"Architectural Thinking - SAP BTP Integration Suite Consultant". You got the basics, now let's move on.

Introduction

In my last entry, I talked about the "Frankenstein Landscape" - SAP BTP - Integration Suite: Clean Architecture vs The Frankenstein Landscape.

Today, I’d like to put the spotlight on you and your career and if you are a SAP CPI developer, you might have noticed the hard times of just being good at building Iflows that seems to end.

This is the first of four posts (the last one a summary because I will not explain SAP CPI, I'm expect that you know already), and we will navigate you through how to stop being “SAP CPI Developer” and become an SAP Integration Suite Consultant - "Generals".

First we will start with SAP API Management ( APIM ).

Why bother leaving your comfort zone?

I see this all the time: developers treating APIM and CPI like neighbors who don't talk to each other. But here’s the reality.

if they don’t work together, your architecture is going to break sooner or later.

Growth is uncomfortable, moving away from just "configure adapters, fixing errors and create mappings" to actually thinking about strategy is tough, but you have to do it if you don't want to get stuck in the "trap" mindset.

Carl Jung once said: “Who looks outside, dreams; who looks inside, awakens.”

In the world of SAP BTP Integration Suite, if you only look at the "outside" - All they perceive is an illusion of integration you are merely dreaming of a perfect integration, but that dream won't survive longer with the digital integration transformation to truly "awaken" as an SAP BTP Integration Suite Consultants, you must look inside at integrations and the components they join in a more profound level. This in-depth knowledge results in more consistent and less brittle integrations.

The "General" vs. The "Soldier" (A quick story)

Let me show you a imaginare conversation conversation

The following dialogue illustrates a common situation in integration projects when API Management is treated as an afterthought instead of an architectural capability.

Enterprise Architect / Solution Architect

We need to migrate 40 APIs from an old platform to SAP BTP APIM, after deep analyses of polices and others comparing with other vendors. we are good to go.

How should we handle this ?

SAP CPI Developer

Easy. I’ll just build the iFlows in CPI, set up the HTTPS endpoints, and maybe throw in some Basic Auth or OAuth inside the flow. If something fails, I’ll set up an email alert.

Enterprise Architect / Solution Architect

Okay... but what if a partner starts spamming our endpoint with 10x more traffic by mistake?

Is CPI going to tank that hit directly?

Who’s controlling the gate?

Response - (Awkward silence)

SAP BTP - Integration Suite Consultant

Hold on. We are not trading URLs here; we need to position SAP APIM as the defense in depth. It is our immune defense.

We will control the rate limiting and security policy within APIM so no request will get into CPI if not satisfy our requirements. If a call is below age, APIM will cancel it before it hits the system.

This reduces CPI to only its strengths: being an orchestrator and a logic, not a firewall.

This is also important to clarify: my assets as a member in SAP APIM include the technical API proxy, provider, policy and configuration definition but EAM org-level governance decisions belongs within the overall architectural mandate and organisational governance model.

Real Talk - "General": My Just Goto Checklist for Migrations

The following are several significant factors to keep in mind while moving APIs:

Separate Responsibility:Security and traffic management will be taken on by the API Management (APIM) layer while the Cloud Platform Integration (CPI) takes care of actual processing logic.
Gate Block the Trash: When garbage reached your integration flow (iFlow), then it is the last line of defense that am asking you to re-develope.
Cleaner Contracts: Make use of the OpenAPI specs in APIM. Incoming data should not be left to guesswork in terms of CPI.
Observability: Also very important to keep an observability from A-Z of the integration path, I mean from devportal until S/4HANA logs. Make sure there is not a blind spot in your monitoring.
CPI is NOT a Firewall Stop trying to make CPI be a securtiy wall

Image 1 - SAP Integration Suite Consultant

Charting New Responsibilities on the possible migration from external vendors: Who Does What?

To witness the transformation from Soldier - SAP CPI to General - SAP BTP Integration Suite Developer, one must reconfigure their mindset, gain governance experience, and, most importantly, understand the clear boundaries of authority for each role.

Integration Architect

The Integration Architect projects the technical-specific horizon. They look beyond simple system connectivity to understand how interdependencies affect the global SAP BTP infrastructure.

Migration Analysis: When migrating from external gateways (API Management external vendor) to SAP BTP - APIM he is responsible for the gap analysis of policies, ensuring that security and traffic rules are successfully mapped and supported by the BTP infrastructure.
Traffic & Performance Benchmarking: He compares the processing power and latency overhead of the old platform against SAP BTP APIM to prevent bottlenecks after the "Go-Live".

Solution Architect

Focuses on the business solution design. They ensure the integration makes sense for the end-to-end process, such as Order-to-Cash or Hire-to-Retire.

Information Security: Works alongside the CISO to ensure data privacy (GDPR/LGPD) and sensitivity are respected.
Systemic Design: Decides whether a flow should be synchronous or asynchronous, ensuring the backbone (like S/4HANA) is protected from unnecessary overhead.

SAP BTP Integration Suite Consultant

This is the most critical role for the project's success—the Elite Executor. It is vital to understand: you are not the platform owner, nor the one who decides on corporate governance or global licensing. Your mission is high-level execution.

Technical Security: You implement the orders. You configure OAuth2, X.509 certificates, and message encryption. You don't invent the security rule; you enforce it through technical excellence.
Technical Execution: You are the one building the API Providers, creating Proxies, applying policies in APIM, and developing complex iFlows.
The "Technical Beacon": You are the eyes on the ground. You signal back to the Architects when a policy is technically unfeasible or when estimated traffic might threaten performance. You provide the reality check from the front lines.

Responsibility	Integration Architect	Solution Architect	BTP Integration Consultant
Main Focus	Governance & Platform	Business Process	Project Execution
Security Role	Defines Global Policies	Defines Data Sensitivity	Implements (Certs, Policies)
APIM Scope	Traffic & Capacity Analysis	Endpoint Requirements	Configures Proxies & Resources
Deliverable	Strategic Roadmap	Solution Blueprint	Working Integrations

Conclusion — Part I

In this first part, we explored SAP API Management as more than just a proxy. In a clean integration setup, APIM helps control who can access APIs, how traffic is handled, and how contracts are defined, when the decision is use SAP APIM to protecting SAP CPI or expose OADATA services from backend systems.

Going beyond a CPI-only mindset does not mean changing your role overnight. It means understanding where each tool fits and using the right capability for the right responsibility.

SAP API Management is not about copying URLs from one platform to another in case of migration from External APIM. It is about setting clear boundaries, when SAP APIM should be in front of SAP CPI ( This definitions not comes from SAP BTP Integration Suite Consultant, comes from high level people and when it comes, if you don't know or have any ideia how to create api proxy, api provider, key value mapping, setup policies ProxyEndpoint Pre - Post Flow or Targetentpoint Pre-Postflow and others, you can not be helpfull because your skill set is tied as SAP CPI.

In Part II, we will move to event-driven integration

Kind regards,

Viana.

References to study

References links compilation:

After the learn path, check those blogs and try to replicate just to learn.

SAP SCN - APIM - Blogs:

Integration Suite API Management CF custom domain activation via self-service

2026-01-12T12:04:47.814000+01:00

Introduction

In this blog post you will learn how to setup and activate custom domains (standard setup not mTLS) for SAP Integration Suite API management runtime based on Cloud Foundry via de self-service procedure. If you already have a custom domain activate and in the past this was performed by SAP, this is the blog for you.

To keep this blog to the point the focus is to provide detailed steps and information for this case. Information about obtaining a certificate, create a virtual host for API Management or updating DNS records are only briefly touched.

Prerequisites

To follow the steps explained please make sure you have or gathered:

Administrator access to the subaccount in which Integration Suite is running. To be able to:
- Provide required authorizations
- Create/Update service keys
SAP Integration Suite, API management is setup and running. Launchpad is accessible.
SAP API management a test API is published and working with the standard SAP domain.
DNS administrator authorization or a contact within the organization authorized to perform the required activity.
Certificate administrator authorization or a contact within the organization authorized to perform the required activity.
A HTTP Client like Postman for executing API calls.
- Access to api.sap.com for details on the required API actions

API Management Service key

Before we are able to call any APIs for information and activities with API management it is important a service key is created with specific authorizations: APIManagement.SelfService.Administrator using the plan apiportal-apiaccess. To create an instance you need to navigate towards: Home page Global account->subaccount for integration suite->left hand menu Services->Instances and subscriptions->create instance with the following details, using the correct Space:

As a result the output should look like below:

This service key is required for all upcoming activities to validate existing virtual hosts and create/update a virtual host for custom domain usage.

APIM virtual host overview

Assumption is the service key is created and active. As a first step try to retrieve a token for the service key, my examples are from Postman:

As noticed you can here also validate when the response is positive the authorization is properly linked.

After this step is completed you can call the endpoint:

{hostname from servicekey URL}/apiportal/operations/1.0/Configuration.svc/VirtualHostRequests

with the hostname from the service key, with the HTTP GET method this should result in the overview of virtual hosts for the API Management instance. If you currently only have the SAP standard domain this is the only record to be returned.

APIM create virtual host (optional)

This step is optional and only required if not additional virtual host is already created

A virtual host for APIM can easily be created calling the endpoint:

{hostname from servicekey URL}/apiportal/operations/1.0/Configuration.svc/VirtualHostRequests including the body as:

{

"accountId": "{accountId}",

"virtualHostUrl": "{desired virtual host prefix}",

"isDefaultVirtualHostRequest": false,

"operation": "CREATE"

}

To be sure the virtual host is created it should result in a positive response and it should become visible in APIM within the API proxy section, as example below:

APIM read virtual hosts - available

Retrieving all virtual hosts for an APIM instance is handled via the same URL mentioned a couple of times in this blog:

{hostname from servicekey URL}/apiportal/operations/1.0/Configuration.svc/VirtualHostRequests

a response looks like:

Important fields are highlighted which are required to create/update a custom domain for the created virtual host.

APIM create keystore for custom domain

Compared to SAP Cloud Integration custom domain which is handled via de Custom Domain Manager UI for APIM this is not working in the same concept. This also means the required certificate needs to be created differently and more information is required. For APIM a certificate needs to be bought/requested from the used CA within the company without using an CSR from SAP. In this blog we are using a wildcard certificate which is used for all APIM environments.

The certificate details you need to create a keystore are:

private key
public key
certificate chain including root and intermediate certificates

Important is that the certificate needs to be in a .pem format. In our case we already get the certificates delivered in .pem format. It is important the the public key part including the certificate chain is created in the following order in which the first entry is at the top:

public key client certificate
intermediate certificates (if any is available)
root CA

And saved as a .pem file. The exact steps to create the keystore including the required content is described in SAP documentation: https://help.sap.com/docs/integration-suite/sap-integration-suite/manage-certificates . To create a JAR file we used the JAVA JDK as a download (not required to install) in combination with PowerShell:

In PowerShell the following commmands are used:

Create JAR keystore: {location java JDK}\bin\jar -cf customdomain.jar main.pem privateKey.pem
Update JAR keystore with META-INF information: {location java JDK}\bin\jar -uf customdomain.jar META-INF/descriptor.properties

When the creation is successful this keystore needs to be uploaded.

APIM upload keystore for custom domain

The upload step is very simple. Navigate within SAP Integration Suite overview page towards: Left hand menu Configure->APIs->Tab: Certificates :

and click the create button with the following setup:

Important is to select Key Store and New Store. The Store Name and Name value can be anything you like within the boundaries of what SAP allows and in the upload field you need to select the created JAR file. If you select update it will give a warning the create is the approach. In case you select update and you upload a new certificate the already existing one is overwritten with the same name.

If the upload is going as expected it will be listed in the tab Certificates.

APIM activate custom domain

If all previous steps are completed successfully, activation can start. Be aware of the following:

The used root CA for custom domain needs to be trusted by applications/systems to be able to make a working connection.
Make a decision if the custom domain needs to be the default domain when creating or importing an API proxy. We decided not to use the custom domain as default virtual host.
After custom domain activation you need to
- update any existing DNS CNAME records. The target URL will change. However this URL will only be available after the activation is executed via an API call. This target value can be located in field lbHost in the response from the activation when this is positive.
- redeploy all API proxies using the custom domain and as a second step all API products. This to make sure the correct certificate is used. This is especially important when the custom domain is already used and the certificate chain is changed.

Activation for custom domain is handled via an API call:

{hostname from servicekey URL}/apiportal/operations/1.0/Configuration.svc/VirtualHostRequests

With the following content:

{

"accountId" : "{accountId from read operation}",

"virtualHostUrl": "{full custom domain with virtual host prefix}",

"isDefaultVirtualHostRequest" : false,

"isForCustomDomain": true,

"keyStoreName": "{created during keystore upload}",

"keyStoreAlias": "{created during keystore upload}",

"operation" : "UPDATE",

"virtualHostId":"{virtualHostId from read operation}"

}

A positive response should look like:

The values in fields virtualHostUrl and lbHost are important for updating the CNAME record in DNS.

APIM create/update custom domain DNS CNAME

To make sure the custom domain can be reached and is forwarded to the correct endpoint a DNS CNAME record is required for every APIM virtual host activated for custom domain. In our case we already had a CNAME record for our custom domain pointing to the standard SAP domain [

test.apimanagement.eu20.hana.ondemand.com] as provided by SAP when they initially handled the custom domain activities for APIM. As mentioned in the previous paragraph the CNAME now needs to be:

virtualHostUrl value -> lbHost value

Be aware in case you use multiple virtual host in an APIM environment the lbHost value might be the same but this is not causing any issues related to call the correct endpoints.

After it is validated via DNS checkers the CNAME record is updated the first step is to activate 1 API proxy and the linked API product and validate the correct routing and certificates are handled. We decided to edit the API proxy and perform a dummy change and updated the revision with details about the redeployment. Other options are also available.

In our case we used temporary a testing endpoint specific for the custom domain validation. We also provided this endpoint to application, system and partner contacts for validation purposes and to request them to validate if the root CA is available in the trust store.

Conclusion

The switch from SAP managed custom domains for our organization towards self-service is a logical one. We got confronted with the self-service approach 5 working days prior to the current certificate expiring which gave us clear time contraints. Luckily the creation of the virtual host and retrieval of the overview of virtual hosts was already known for us and the service key already existed.

Looking at the SAP documentation most steps are stated (high-level) in multiple pages however from our perspective some pieces of documentation raised questions from our end. With a ticket towards SAP we received definitive clarification to get this change done correctly without any disruptions. This is the reason the blog was written.

Hopefully this blog is giving others the insights and information required to make this working properly within the own organization.

Documentation & Links

If you like to read more information about custom domains and the setup it requires for other cases I can recommend reading the below helpful information:

Request or update an APIM custom domain: https://help.sap.com/docs/sap-api-management/sap-api-management/requesting-for-custom-domain-for-virtual-host
Create a JAR keystore: https://help.sap.com/docs/integration-suite/sap-integration-suite/manage-certificates
Configure DNS for a custom domain: https://help.sap.com/docs/custom-domain/custom-domain-service/configure-dns-for-custom-domain

SAP Integration Suite: Q4/2025 Feature Highlights

2026-01-12T18:00:38.146000+01:00

The fresh batch of features delivered in Q4 2025 brings powerful new tools designed to make your integrations smarter, faster, and more resilient. From AI-powered recommendations that simplify troubleshooting, to streamlined connectivity with top platforms like Amazon Kinesis and Box, these updates are crafted to boost your operational efficiency and keep you ahead of the curve. Read on to explore how these innovations can transform your integration experience.

Artificial Intelligence

AI-based intelligent recommendations for detected API anomalies

This AI enhancement builds on anomaly detection to explain what changed, why it likely happened, and what to do next, cutting triage and speeding recovery. Embedded in API Management, it surfaces guidance alongside alerts with one-click actions and optional “intelligent healing.”

The included capabilities - Insights, Causes, and Recommendations - enable faster response to error spikes, latency surges, and abnormal traffic patterns, improving reliability and operational efficiency for API owners and teams. See how to get started in this blog post and review the Documentation.

Connectivity and Adapters

Amazon Kinesis receiver adapter: facilitates and accelerates connectivity to Amazon Kinesis Data Streams, streamlining data communication and enhancing real-time data processing.
Box receiver adapter: connects SAP Integration Suite to Box and enables you to access components on Box.
Microsoft OneNote receiver adapter: automates common business operations by integrating MS OneNote with other business applications. It connects an SAP Integration Suite tenant to a remote system using HTTP protocol.
Azure Service Bus adapter: connects SAP Integration Suite to Azure Service Bus.
MongoDB receiver adapter: connects SAP Integration Suite to MongoDB.
Poll Enrich Step in FTP sender adapter: reads (poll) messages from FTP server and adds the content to the original message in the middle of the message processing sequence.

New data space integration package

The data space integration package helps supply chain partners exchange data securely and self-sovereignly within data spaces. It includes two components: a data space connector for secure, sovereign data exchange, and a decentralized identity wallet for sharing trustworthy, verifiable data. Read all details in the blog post.

Data Center Availability 🇩🇪 🇮🇹 🇦🇪

Customers can now run SAP Integration Suite in four new data centers: on SAP infrastructure in Frankfurt, Sankt Leon-Rot (both in Germany) and in the United Arab Emirates; and additionally, one in Italy on Amazon Web Services.

Event-driven Integration

Micro-Integrations

Micro-Integrations are small, event-driven connectors that link applications to an Advanced Event Mesh as on-ramps (event sources) or off-ramps (event targets), avoiding brittle point-to-point ties so changes stay localized and low-risk. By focusing on narrowly defined tasks, they are easier to design, adapt, and scale, delivering high-throughput, real-time streams via pub/sub and letting you add more Micro-Integrations per task as demand grows. Available in the Cloud Console, they provide management and observability for integrations between external systems and event brokers or meshes, resulting in greater agility, faster data distribution, and flexibility to use the best-fit technologies at the source and target. Find more details and the currently available micro-integrations in the blog post.

Event Mesh integration with SAP Cloud ALM for health monitoring

SAP Integration Suite’s Event Mesh now integrates with SAP Cloud ALM Health Monitoring to regularly collect and display broker vitals, such as active connections, message consumers, message queues, spool usage, and broker state, on the CALM dashboard. Customers can customize thresholds for each metric (except broker state), view 14 days of history, and receive warning notifications when values reach 80% (orange) and 90% (red) of the defined thresholds, enabling proactive monitoring and alerts for Event Mesh health. Set up and further details can be found here.

Migration support from Event Mesh capability to SAP Integration Suite, advanced event mesh

Great news to facilitate your system modernization: SAP provides technical- and process-oriented migration support to help customers move from the Event Mesh capability in SAP Integration Suite to SAP Integration Suite, advanced event mesh, scaling smoothly from basic scenarios to a richer, more powerful event-driven foundation. This includes support for migrating events so applications can communicate asynchronously in real time across distributed landscapes with support for various protocols, enabling teams to start simple, grow confidently, and modernize without disruption.

B2B Integration

Support for the SFTP adapter and Alerting of failed B2B interchanges in Trading Partner Management

SAP Integration Suite’s Trading Partner Management now supports SFTP (Secure File Transfer Protocol), available in both standard and premium editions and via the SAP BTP Enterprise Agreement. Users can read and write files to their own or trading partners’ SFTP servers and, when defining systems, can choose SFTP sender and receiver adapters.

Additionally, SAP Integration Suite extends Trading Partner Management by publishing B2B interchange data to SAP Cloud ALM for centralized monitoring and rapid detection of failed transactions. Using SAP Cloud ALM, you can configure granular scenario specific alerts that filter by details such as trading partners or message types to receive targeted notifications and act quickly on issues.

Process Integration

Basic authentication on Edge Integration Cell

SAP Integration Suite’s Edge Integration Cell now supports basic HTTP authentication using a client ID and client secret during temporary connectivity loss to SAP BTP. This enables simple sender authentication for testing with minimal configuration and allows integration flow processing and API artifact invocations using clientId and clientsecret while SAP BTP is unreachable.

Advanced checks in Groovy scripts

SAP Integration Suite’s Cloud Integration designer now offers advanced checks for Groovy scripts, helping developers analyze and prepare custom integration flows for future runtime version upgrades. A new “ensure upgrade readiness” guideline recommends supported libraries and classes and can automatically update scripts to align with upgrade requirements. See all information in the respective documentation.

Service interface artifact creation In Cloud Integration

SAP Integration Suite Cloud Integration now supports creating and editing service interface artifacts directly in the workspace, aligning with an API first outside in development approach and supporting existing Enterprise Services Repository use cases. These artifacts enable proxy generation in ABAP backends for smooth integration into ABAP based systems. The capability is available in the multi cloud environment and allows native creation of service interface artifacts in your Cloud Integration tenant.

Local OData API Access & SAP HANA Support

See details and demo in the video:

----

For a sneak peek into what’s in store for 2026, check out the road map explorer and the SAP TechEd 2025 News Guide
Join the integration community and connect with other integration developers!

Use SAP Integration Suite to connect SAP and AWS services

2026-01-20T11:36:09.592000+01:00

Bridging the gap between SAP and 3rd party systems

Everyone already knows that SAP Integration Suite is the election tool to connect your SAP services. But did you know that it is also your tool to integrate Everything, Everywhere, All in One Place? (yes, almost like the Oscar award winning movie 🏆)

Use SAP Integration Suite to connect SAP and AWS services is a new official SAP Discovery Center Mission that focus on showcasing how easy it is to integrate not only SAP systems but also non-SAP systems using SAP Integration Suite.

For this mission, we decided to use the AWS platform as the example of third-party cloud services provider, but the same rational with this set of best practices and capabilities can be used to integrate with other cloud providers. By following the cards provided in the mission, you will see step-by-step how you can start to integrate an application developed with SAP BTP development tools with AWS services, such as S3 for image storage and Rekognition for image identification.
You can even use a SAP BTP Trial account to perform the SAP BTP parts of the mission, even though you will always still require also an AWS account to connect with the S3 and Rekognition services (and IAM for user and roles management on the AWS side). Either if you are a technical user or more of a business user interested in rapid application development, cloud integration strategies and/or AI-powered business solution, this mission is for you!

The following architecture shows the big picture of what the final result of the mission should look like, seamlessly combining the best of both SAP BTP and AWS platforms:

Use Case Description

The use case followed trough out the mission focuses in enabling a Supplier to donate surplus food ingredients through an AI-powered mobile and web application built using SAP Build Apps, a low-code/no-code solution within SAP Business Technology Platform (SAP BTP), seamlessly integrated with AWS capabilities for storage and artificial intelligence–based image recognition. For the integration part, you will leverage and combine different integration capabilities that are part of the SAP Integration Suite. The intended outcome of the use case is to minimize food waste while simplifying the donation process and facilitating redistribution to organizations in need.

Solution Components:

SAP Build Apps: The low-code/no-code application development service used to create the application (frontend and logic) where the Supplier can donate the surplus ingredients by taking or uploading photos
SAP Integration Suite: The secure and centralized integration management service for all your integrations, making them easier to manage, monitor and troubleshoot
Amazon S3: The Amazon service for simplified and cost-effective image storage capabilities
Amazon Rekognition: The Amazon service for AI-powered identification and categorization, in this case used to identify the ingredients in the images taken or uploaded from the application to a S3 bucket

The Use Case Flow:

A Supplier captures or uploads an image of surplus ingredients through the mobile/web app (developed with SAP Build Apps)
The image is securely stored in Amazon S3 via SAP Integration Suite (using Cloud Integration, Pre-built Open Connector and API Management capabilities)
Also via SAP Integration Suite, the app then calls Amazon Rekognition to automatically identify and categorize the ingredient present in the image (using Cloud Integration, Custom Open Connector and API Management capabilities)
The results are sent back to the app and ready for further processing

Learning Outcomes

By completing this Discovery Center Mission, you'll gain practical experience in:

Building low-code applications with SAP Build Apps
Configuring SAP Integration Suite for AWS connectivity
Implementing secure cloud-to-cloud integrations
Leveraging AI services for business process automation
Managing integration flows and monitoring capabilities

Getting Started

Once you open and start the Mission, you will see in the Project Board the different cards that will guide you step-by-step, divided in 7 columns.

Make sure you fullfill all the requirements indicated in the SET UP and PREPARE columns. After that, you can start with the EXECUTE columns. You will first explore the Open Connectors capability of SAP Integration Suite (in the Execute - OpenConnectors), followed by the Cloud Integration and API Management capabilities of SAP Integration Suite (in the Execute - Security Material and Integration Flow) and lastly you will get to visually create a simple app screen with SAP Build Apps (in Execute - Build app) .
After finishing the mission, don't forget to mark all the cards as completed and we encourage you to leave your feedback and share your experiences with the rest of the SAP Community.

And now, for those who saw the movie Everything Everywhere All at Once, DON'T "Just be a rock" and start the mission here! -> SAP Discovery Center Missions - Use SAP Integration Suite to connect SAP and AWS services

SAP BTP - APIM - Advanced Domain Routing API-Proxy Pattern for Governing Similar Backend Endpoints

2026-01-20T15:57:09.545000+01:00

Author Note (2026)
This article represents an intermediate architectural exploration that preceded the formal definition of the Domain-Centric Routing Pattern (DCRP).

While the techniques described here remain valid in constrained scenarios, they have since been consolidated and governed under the DCRP framework to address scalability, governance, and observability at enterprise scale.

This article is preserved for educational and historical context.

PEER-REVIEWED ACADEMIC PAPER PUBLISHED

Official DOI: 10.5281/zenodo.18582469 Published: February 10, 2026 | Repository: Zenodo (CERN) Status: Open Access, Peer-Reviewed

This Medium article is the foundational disclosure (Feb 7, 2026). The complete academic paper with validation data, vendor implementations, and 40 references is now available:

Download Full Paper (PDF): https://zenodo.org/records/18582469

Validation Results:

90% reduction in API proxies (40 → 4)
90% reduction in CPI packages (40 → 4)
95% faster deployment (273 min → 14.5 min)
33,000+ messages tested, 68ms latency, 100% success

Citation: Viana, R. L. H. (2026). Gateway Domain-Centric Routing: A Vendor-Agnostic Metadata-Driven Architecture for Enterprise API Governance. Zenodo. https://doi.org/10.5281/zenodo.18582469

Introduction

This article presents an advanced API Management pattern for SAP landscapes, where a single API Proxy represents one business contract and dynamically routes requests to multiple SAP CPI iFlows belonging to the same business process and domain.

The goal is not to reduce the number of APIs, but to increase governance, observability, and semantic clarity, while keeping analytics consolidated at the business-domain level.

In a previous exploratory article—removed as part of an architectural consolidation and deprecation process—I described how a single API Proxy endpoint can route requests to multiple SAP CPI iFlows within a single package.

In that initial exploration, it was not possible to present a clear and structured view of message monitoring within the analytics dashboard. The purpose of this article is therefore to demonstrate how to define custom dimensions, configure Statistics Collector policies, and visualize the results within the SAP API Management analytics dashboard.

However, centralizing traffic often creates a visibility vacuum. This point was raised by @MateuszPiotrowski ,it was not included in the previous article due to its scope.

Important Note (Read First)

Figure 1 - Outside these constraints, this approach becomes an anti-pattern.

The "Invisible Traffic"

When some business domains over a SAP CPI package, splittled by diferent (iFlows) following the same pattern of endpoint , share a single API Proxy, standard analytics become a "black box." In the default dashboard, all traffic appears under the same Proxy name.

In this post, we will bridge this gap. I will demonstrate how to implement using JavaScript Policy and the Statistics Collector policy, we will "unmask" the Domain Routing Proxy traffic, providing full transparency directly within the SAP APIM Analytics Dashboard.

The Strategy - Mapping the iflows with Javascript Policy

To solve the "visibility vacuum," we must capture the iFlow’s identity the moment the request hits the Proxy, the sender, the iflow, the package if needed and others details.

API Domain Routing Proxy - ProxyEndpoint routing:

Figure 1 - Routing based on proxy.pathsuffix MatchesPath "/method*"

What does this routing rule mean?

So the basic path address of the API Proxy is - https://<apimanagementaddress>/megaproxy/v1

Any extra call that comes with path /method will generate the routing

The endpoint https://<apimanagementaddress>/megaproxy/v1/method*

The target Endpoint properties:

In this case different that was presente in the previous blog, I decide to higher the level of cracking, only using the default as a targetEndpoint but in the end is routing for 4 different endpoints

Figure 2 - "Default endpoint" - and properties host and cpi basepath

Routing Mechanism

The only references that I could find was the SAP but confused to understand -

SAP Enable-Dynamic-Routing

Enable Dynamic Routing Manually

SAP API Management already provides:

proxy.pathsuffix
custom properties in ProxyEndpoint and TargetEndpoint
Conditional flows
JavaScript policies
Dynamic target resolution

Instead of creating multiple target endpoints, the proxy uses:

A single target
Dynamic host and path via properties
Routing logic based on suffix and context

This is not a hack — it is native SAP API Management functionality that is widely available but rarely explored in depth within the SAP Community. This article formalizes its application as an architectural pattern rather than an implementation trick.

Figure 2 - API Management - API Proxy Design Pattern

Example: Dynamic Routing Logic (Conceptual)

//Routing mechanism
function RoutingCpiEndpoint() {
    
var suffix = context.getVariable("proxy.pathsuffix");
if (suffix == null) {
    suffix = "";
}
var targetBase = context.getVariable("target.cpi.host");
var cpipath = context.getVariable("target.cpi.basepath")

// Use the + operator for compatibility
var finalUrl = targetBase.toString() + cpipath.toString() + suffix.toString();

// Set it back to a context variable so the target can use it
context.setVariable("target.url", finalUrl);

}

Samples of URL's after the groovy:

This line is responsable to extract the cpi.path and cpi.host from the Properties Configured in the Target Endpoint:

Figure 3 - Custom properties in the Target Endpoint

var finalUrl = targetBase.toString() + cpipath.toString() + suffix.toString();

This approach also introduces an additional abstraction layer, as the full backend URL structure remains hidden from the consumer.

Urls expose to the consumer:

https://<apimaddress>/megaproxy/v1/methoddelete
https://<apimaddress>/megaproxy/v1/methodpost
https://<apimaddress>/megaproxy/v1/methodput
https://<apimaddress>/megaproxy/v1/methodget

Url's generate inside the API PROXY:

https://<backendfinal endpoint>/http/cpi/methoddelete
https://<backendfinal endpoint>/http/cpi/methodpost
https://<backendfinal endpoint>/http/cpi/methodput
https://<backendfinal endpoint>/http/cpi/methodget

Test Proposal via postman for methoddelete:

Figure 3 - Postman test of endpoint /methoddelete

Figure 4 - CPI Monitoring - Iflow.Template.MethodDelete

The Real Innovation: Business-Oriented Analytics

Routing itself is not the primary innovation; the real value lies in achieving clear visibility into API usage and sender-consumer behavior.

Enriching the api-proxy , SAP APIM Analytics can show:

Calls per sender system
Calls per CPI iFlow or another backend system api service
Success vs error rates per process variant
Traffic distribution across the domain

The JavaScript policy enriches SAP API Management analytics by providing clear visibility into endpoint usage, sender system identification, and process execution outcomes (success and failure).

//Set custom headers with name of Iflow
function setCustomHeaders() {

    var path = context.getVariable("proxy.pathsuffix");
    var sourceSystem = context.getVariable("request.header.X-Sender-ID");
    var packageName = "sap.scn.package";
    var iflowName = "UnknownIflow";
    var senderid = sourceSystem ? sourceSystem : "UnknownSender";

    if (path === "/methoddelete") {
        iflowName = "Iflow.Template.MethodDelete";
        context.setVariable("custom.senderid", senderid);
    }
    else if (path === "/methodget") {
        iflowName = "Iflow.Template.MethodGet";
        context.setVariable("custom.senderid", senderid);
    }
    else if (path === "/methodpost") {
        iflowName = "Iflow.Template.MethodPost";
        context.setVariable("custom.senderid", senderid);
    }
    else if (path === "/methodput") {
        iflowName = "Iflow.Template.MethodPut";
        context.setVariable("custom.senderid", senderid);
    }

    context.setVariable("custom.package_name", packageName);
    context.setVariable("custom.iflow_name", iflowName);
}

Custom Metrics Setup:

Recorded data is only useful if it can be visualized. You must prepare the ground in the Analytics portal before the policy can successfully register data:

Navigate to Analyze > Settings > Custom Metrics/Dimensions.
Add a new dimension named sapcpiIflow.
Expert Insight: SAP will prefix these fields as custom_sapcpiIflow and custom_senderid. This is the exact name you will reference in your policy and search for in your reports.

Figure 5 - Create Custom Dimensions that will be used in Policy Statistic Collector

Figure 6 - Create two dimensions, iflowname and senderid.

Policy Statistic Collector:

As you can see in the tag Statistic reffering to custom_sapcpiIflow with the reference of custom.iflow_name created by the javascript above as sample.

<Statistic name='custom_sapcpiIflow' ref='custom.iflow_name' type='string'>0</Statistic>
<Statistic name='custom_senderid' ref='custom.senderid' type='string'>0</Statistic>

<!--Specify Stats collector policy to add custom dimensions and measures -->
 <StatisticsCollector async='false' continueOnError='false' enabled='true' xmlns='http://www.sap.com/apimgmt'>
 <Statistics>

<!-- prepopulated template -->
<!-- Uncomment Statistic which needs to be collected and define reference variable-->
<Statistic name='custom_sapcpiIflow' ref='custom.iflow_name' type='string'>0</Statistic>
<Statistic name='custom_senderid' ref='custom.senderid' type='string'>0</Statistic>

</Statistics>
</StatisticsCollector>

Add in seguency:

Figure 7 - Those policies should be added in the last step into the Target Endpoint Pre-Flow

The Result as SAP CPI as backend:

Figure 8 - APIM - Business-Oriented Analytics Dashboard

Once this configuration is live, you move from a generic chart to a Business Iflow Dashboard. You can now generate

Volume Tracking: Exactly how many calls are being processed by iFlow A vs. iFlow B or C?
Targeted Performance: Which specific iFlow endpoint is experiencing high latency?
Error Granularity: Which iFlow is generating the most errors? Instead of seeing "Proxy Errors," you can pinpoint which specific backend integration is failing

Image - 8 - Custom Dashboard monitoring SAP APIM

Sender system identifier:

Image 9 - Indentifier of Sender System

Image 10 - Indentifier of Sender System - Coke - and which Iflow endpoint

Image 11 - CPI Iflows

11 - When This Pattern Is Allowed

📌How to Reference This Work

When referencing or building upon the architectural concepts discussed in this article, please use the following formal citations:

🧩 DCRP (Domain-Centric Routing Pattern) — introduced by Ricardo Luz Holanda Viana, 2026
🧩 PDCP (Package Domain-Centric Pattern) — introduced by Ricardo Luz Holanda Viana, 2026

These references apply to the formal architectural patterns, not to individual implementation techniques described for educational purposes.

© Intellectual Property & Copyright Notice

⚖️Legal Notice
The public disclosure of the architectural patterns described herein constitutes documented prior art for purposes of authorship recognition and architectural attribution as of the stated publication date.

✅Usage Terms

These usage terms are intended to protect authorship and naming, not to restrict technical adoption.

Free to use for educational, research, and non-commercial purposes
Attribution required when referencing or building upon these architectural patterns
Commercial implementations are permitted, provided proper attribution is given

🚫Use of the names “DCRP™” or “PDCP™” in commercial branding, offerings, or marketing materials requires prior written licensing from the author.

This restriction applies solely to the use of the names and trademarks, not to independent implementations of similar architectural concepts.

🔐No Implied License
Nothing in this publication shall be construed as granting any license, implied or otherwise, to use the described methodologies as branded commercial products or services without explicit authorization.

⚠️Disclaimer

This article reflects the author’s personal architectural perspective and does not represent an official SAP position, product, or recommendation.

Conclusion:

The Dynamic Routing Proxy extends traditional URL-based routing by introducing a centralized API layer focused on governance and observability.

The single API Proxy endpoint, teams gain consolidated visibility into CPI iFlow API's, traffic patterns, and error behavior, all through one unified SAP API Management dashboard.

Kind regards,

Viana – SAP BTP Integration Suite Architect & Author - (The Commander)

Use REST services in Graph

2026-01-20T16:41:34.615000+01:00

Hello!

In this part of the tutorial on Graph we will focus on the support of REST services in Graph. For an overview of other parts of this series, check out the Information Map.

REST support in Graph

Graph enables the use of REST services as data sources for business data graphs (BDGs). Compared to OData data sources, there are some key differences:

The metadata that describes the service must be provided separately along with the service endpoint in the OpenAPI format.
OpenAPI does not have the concept of entities like OData does. Instead, it focuses on operations, which are represented as actions and functions in a BDG.

We will now explain how these differences are being handled by Graph in more detail:

Metadata for a REST service

REST services are commonly described using the OpenAPI format, which outlines the operations and resources available in the service. Unlike OData, which provides a $metadata endpoint for accessing service metadata, plain REST services do not have a standard way to access this information. Since Graph requires metadata to work with REST services, users must provide this metadata when setting up a business data graph.

Graph uses BTP destinations to define access to data sources. To use a REST service as data source, users need to create 2 destinations:

a data destination: that points to the actual REST service
a metadata destination: where the OpenAPI metadata document for the REST service can be retrieved

Both destinations also need annotations that connect them together, so that Graph can understand which metadata destination belongs to which REST service destination.

Data Model

Graph exposes a unified API endpoint for the OData and GraphQL protocols. Both offer an entity (or type/object) model in which data can be represented. Plain REST as described by OpenAPI does not have a strict entity model, and services are defined as different operations. For example, an operation might be to 'find a pet by name' or 'retrieve pets of a store' in a pet-store service. However, to expose these REST-operations as valid OData in the unified API, Graph transforms them into unbound OData operations (actions & functions) in the BDG. We refer to these also as mirrored operations, similar to mirrored entities. As part of that transformation, some changes are made to the signature of the operations to align with the OData standard. These include:

all paths are flattened: for example a GET /users/pets is transformed to a GET users_pets in the BDG
all methods are standardized to GET and POST, with the underlying method being appended to the operation name: for example a DELETE /users/pets becomes a POST /users_pets__delete

Example

Having explained the main concepts of REST support in Graph, let's now look at a practical example. We will take the try-out sandbox of this SAP Ariba Network Catalog Management REST service and use it in a BDG. You can also download the OpenAPI metadata document for the service there under API Resources / API specification.

Tutorial Setup

Before we can use the SAP Ariba service in a BDG, we need to setup the two destinations in SAP BTP.

Prerequisites:

SAP Integration Suite with API Management and Graph enabled
Access to destinations and service instances in SAP BTP cockpit

Data Destination

Open the SAP BTP Cockpit and create a new destination from scratch in the BTP subaccount where you have Graph and SAP Integration Suite. Enter the following details

Name: ariba-network-catalog-mgmt
URL: https://sandbox.api.sap.com/ariba/api/network-catalog-mgmt/v1/sandbox

Also add these two additional properties to the destination:

Key: Graph.destinationType with the value: REST. This declares this destination as a REST data destination to Graph.
Key: URL.headers.apiKey with the value: <your sandbox API key> to add your sandbox API key for authentication purposes (this only applies to this sandbox-example). You can retrieve your API key here: https://api.sap.com/settings.

data destination in BTP cockpit

Metadata Destination

Next, we need to define the metadata destination that points to a location where Graph can access the OpenAPI metadata document. This could be done in a number of ways by hosting this file in a file-server/document storage or at a custom service endpoint for example. For sake of keeping this tutorial simple we will only use SAP Integration Suite to make this file available to Graph: we will create an API artifact which returns the content of the OpenAPI metadata file and then create the metadata destination that points towards the endpoint of that API artifact. Note that this is only for the purposes of this tutorial, and not a requirement.

Hosting the OpenAPI file with an API artifact (optional, only for the tutorial)

First we create the API artifact in SAP Integration Suite. Open Integration Suite and go to Design > Integrations and APIs. Choose an existing package or create a new one. In the package click Edit and open the Artifacts tab. Now you can select Add > API in the table menu. Follow the API creation dialog and select REST API as API Type, Create as Method and then give it the following name: Ariba-Network-Catalog-OpenAPI. Open the created API and in the 'Handle Request' lane select the 'Content Modifier' step. In the bottom UI panel you will then see the Message Body tab where we can paste a constant body this API should return. Here, we will paste the JSON content of the OpenAPI specification of the service (available here). If you have other APIs in the tenant you might also want to assign a unique path for this API. To do that select the HTTPS arrow outgoing from the Start participant, and then in the bottom UI panel you can edit the 'Connection' and change the path in the 'Address' field. Here, we are using /ariba-network-catalog-openapi. Then save the API artifact and deploy it. You can check the deployment status under Monitor > Integrations and APIs > Manage Integration Content: All. When it is deployed, the OpenAPI document will be available at that endpoint. Copy the endpoint URL for later.

constant message body returns the OPenAPI spec JSON

unique path for this API artifact

monitoring view of the deployed API artifact, with the endpoint URL

To access that endpoint in a destination, we also need the authentication details. Here, we want to authenticate using OAuth client credentials that we obtain from a SAP Process Integration Runtime. For that, go to BTP Cockpit and under Services > Instances and Subscriptions you can find it or create a new one. Then create a Service Key for that instance. We now have a set of client credentials we need for authentication: namely the clientid, clientsecret and tokenurl.

process integration runtime with a service key in BTP cockpit

Creating the Destination

Now we can create the Metadata destination. Enter the following details:

Name: ariba-network-catalog-mgmt-openapi
URL: the API artifact endpoint URL from above
Authentication: OAuth2ClientCredentials
Client ID: clientid from above
Client Secret: clientsecret from above
Token Service URL: tokenurl from above

We will also annotate this destination with additional properties, to tell Graph that this is the metadata destination for the previously created ariba-network-catalog-mgmt destination:

Key: Graph.destinationType, with a value of OpenAPI
Key: Graph.metadataFor, with a value of ariba-network-catalog-mgmt

metadata destination

Now the destination setup is complete and we can create a BDG.

Creating the BDG with REST data sources

With the data destination and the metadata destination created, we can now continue to create a BDG with the REST service. The process does not differ much in this case. In Integration Suite under Design > Graph, create a new Business Data Graph with the ID rest-bdg. In the list of destinations, you can now see an ariba-network-catalog-mgmt entry with the type REST. The info icon shows you more details, for example that Graph has identified which metadata destination belongs to this entry. Just select the entry and continue. When the dialog is finished and we see a preview of the BDG details, we can also change the namespace of the data source from my.custom to my.ariba (this is optional). Continue by activating the BDG.

data source selection when creating a new BDG

editing the namespace of a data source

overview of the activated BDG

Making Queries against the BDG

With the BDG activated, we can now inspect the mirrored operations. Open the BDG in Developer Hub (there is a link on the overview tab of the BDG). You will see the following operations:

GET products (mirrored from GET /products)
GET products_ (mirrored from GET /products/{productid})
POST products__delete (mirrored from DELETE /products/{productid})
POST products__patch (mirrored from PATCH /products/{productid})
POST products_post (mirrored from POST /products)

The productid path parameter here is either transformed into an unbound function path parameter, or an unbound action body parameter in this example. This illustrates the transformation that Graph makes of the mirrored operations into valid OData operations as mentioned earlier. In the try out tab we can see all the parameters of the operation and also give it a go.

Note: Graph treats all parameters of mirrored operations as required at this time. However, you can set the value to null.

This SAP Ariba sandbox API requires an X_ARIBA_NETWORK_ID parameter. You can use the value AN02005777309 for this sandbox. When running the my.ariba/products operation, we can see that we get the response from the REST service in a valid OData format.

trying out the mirrored functions in Developer Hub (Graph Navigator)

Summary

In this tutorial we had a look at how REST services can be used as data sources in a business data graph. With this feature, you can integrate data from REST services alongside data from OData services into a single unified Graph API.

You can learn more about REST-support in Graph in the documentation:

Florian Moritz

Discover and Publish Advanced Event Mesh Events and APIs in SAP Developer Hub

2026-01-27T15:16:07.100000+01:00

In today’s digital economy, event-driven architectures (EDA) enable real-time insights and seamless integration across diverse system landscapes—whether connecting SAP applications or extending integration to third-party solutions. Organizations can now more efficiently discover, publish, and consume events and APIs, empowering both developers and integration architects.

In this blog, we’ll explore what these capabilities mean in practice, how to connect Advanced Event Mesh with Developer Hub, and how to publish events from business systems into a centralized discovery catalog—bringing event-driven integration patterns into the mainstream of enterprise integration design.

Create a Destination to Connect Advanced Event Mesh with SAP Developer Hub

To enable the discovery and publication of events from Advanced Event Mesh in Developer Hub, the first step is to establish a secure connection between the two services. This connection is configured using a destination in SAP Business Technology Platform (BTP).

In the following sections, we’ll explain the purpose of this destination and walk through the key configuration details required to set it up successfully.

Why is a Destination Required?

A destination serves as the secure connectivity bridge between Developer Hub and your Advanced Event Mesh (AEM) instance. This connection is essential for Developer Hub to discover EventAPIs within AEM and display them as Events in the central catalog.

Note: In the current release, the destination is used exclusively for the discovery phase of the event lifecycle.

Create the Destination in SAP BTP

1. To create the destination, log in to SAP BTP Cockpit and navigate to the source subaccount where Developer Hub is enabled.

2. From the left navigation pane, go to Connectivity → Destinations and choose Create. Select From Scratch to manually define a new destination.

3. In the Destination Details section, enter all required information:

Name: Provide a unique and meaningful name for the destination.
Type: Choose HTTP as the destination type.
Description: Provide a brief description of the Advanced Event Mesh (AEM) system. This description appears for the AEM business system in Developer Hub.
URL: Enter the base URL of your Advanced Event Mesh portal.
For authentication, choose BasicAuthentication.
Username: Enter the username of the technical user. This can be an email address.
Password: Use an API token generated from the Advanced Event Mesh portal as the password.
When creating the API token, ensure that the following permissions are assigned: a. Read any Application Domain (application_domain:get:*) b. Do anything to any Event API (event_api:*:*) c. Access to Event Portal Designer (event_designer:access). These permissions allow Developer Hub to read event definitions and interact with the Event portal.

Enter the Additional Settings: Choose Internet as the Proxy Type.
Add the following custom property to enable Advanced Event Mesh support in Developer Hub: Key: sap.isuite.dh.aem.enabled Value: true

4. Validate the destination.

After entering all details, choose Create.
You can optionally use Check Connection to verify that the destination has been configured correctly, and that Developer Hub can successfully connect to Advanced Event Mesh.

What’s Next?

Once the destination is set up, Developer Hub can start discovering events from Advanced Event Mesh. These events can then be reviewed, published, and made available to developers through the central catalog.

This simple setup step lays the foundation for enabling event-driven integration using SAP Integration Suite.

Discover and Publish Events from Advanced Event Mesh on Developer Hub

Once the destination between Advanced Event Mesh and SAP Developer Hub is in place, you can start making events available to developers by discovering and publishing them in Developer Hub.

This step is typically performed by a content administrator, who curates events and organizes them into products for easy discovery and reuse.

Before You Begin

To discover and publish events, make sure the following prerequisites are met:

You are assigned the AuthGroup.Content.Admin role collection.
EventAPIs are marked as shared in the Advanced Event Mesh portal.

Only shared events can be added to products and published in Developer Hub. If an event is not shared, update its settings in the Advanced Event Mesh portal before proceeding.

Discover Events in Developer Hub

Log on to Developer Hub and navigate to Admin Center → Manage → Content. Here, you’ll see a list of available business systems. Select the Advanced Event Mesh business system to discover events exposed from it.
Events in Advanced Event Mesh are organized under application domains. When you select an application domain, all events associated with that domain are displayed.
If required, you can enable the option to Show shared events from other domains. This allows you to view and reuse events that have been shared across application domains.

Understand Event Visibility

Each application domain contains its own set of events:

Shared events are visible across all application domains.
Non-shared events are visible only within their own domain.

Only shared events can be added to a product in Developer Hub. This ensures that events intended for broader consumption are clearly identified and reusable.

After selecting the relevant events, you can group them into a product. Products help organize events logically and make them easier for developers to discover.
When creating a product, you can include:

Shared events from the current application domain
Shared events from other application domains

This flexibility allows you to design products that align with business capabilities rather than technical boundaries.

3. Publish the product

Once the product details are reviewed, you can choose how to proceed:

Save as Draft
Keeps the product in a draft state. Draft products are not visible in the catalog and can be published later.
Publish
Makes the product visible in the Developer Hub catalog so developers can discover it.
Published products are discoverable but not yet available for subscription.

What Happens Next?

After publishing, your events are visible in Developer Hub and ready to be explored by developers. This enables teams to quickly understand available event streams and build event-driven applications or integrations using Advanced Event Mesh.

Together with the destination setup, this completes the core flow for exposing Advanced Event Mesh events through Developer Hub.

This approach helps organizations promote event reuse, improve discoverability, and simplify adoption of event-driven integration patterns across the landscape.

Final Thoughts

SAP Integration Suite’s Advanced Event Mesh paired with Developer Hub empowers organizations to treat events as first-class citizens in integration landscapes.

By connecting Advanced Event Mesh to Developer Hub and publishing your event sources and APIs, you:

Promote transparency of event streams
Enable faster development cycles
Support modern application patterns that rely on real-time business context

Whether you’re driving integrations for ERP, CRM, third-party SaaS systems, or custom applications, this capability helps you move from point-to-point communication to a flexible, scalable event-driven architecture.

TMS on SAP Integration Suite for API proxy transports in SAP API Management

2026-01-28T07:19:29.602000+01:00

Purpose

Moving API proxies between different tenants can be a critical step in your development lifecycle. This article provides a clear, step-by-step guide on how to successfully set up the Transport Management System (TMS) to handle API proxy transports, building on the assumption that you already have TMS configured for your Integrations.

Prerequisites
Before beginning the setup, ensure the following entitlement is available in both your source (e.g., Development) and destination (e.g., Production) subaccounts:

API Management, API portal

Process
Step:1: Create a service instance for the API Management, API portal entitlement using the apiportal-apiaccess plan. This needs to be done in both your source and destination subaccounts

Step:2: For the instances created in Step 1, generate a service key in both the source and destination subaccounts. Crucially, ensure you copy and securely store both service keys, as they contain the credentials and URLs required for the following steps.

Step:3: In the Connectivity section of the Cockpit for your source subaccount, create a new Destination (From Scratch). This destination will allow your source environment to connect and push transports to the destination environment. The details that is used in configuring this destination is from the service key details of destination environment (Production in my case)

Parameters	Values
Name	APIManagement
Authentication	OAuth2ClientCredentials
Type	HTTP
Client ID	From Destination JSON Key File
Client Secret	From Destination JSON Key File
Token Service URL	From Destination JSON key file
URL	{{ URL from Destination JSON key File}}/api/1.0/transportmodule/Transport
Token Service URL Type	Dedicated

Step:4: Once the destination configuration is complete, you should be able to initiate the transport of API proxies (and API Providers) from your source tenant. A new Transport Request (TR) will be generated and visible in your Cloud Transport Management System.

You should be finding this TR in your Transport Request of Transport Management System.

Problems faced

Configuration Issues
If any of the below errors are encountered when initiating the transport, check the destination configuration in source subaccount / tenant (Step:3). All the above errors are due to incorrect destination configuration. Check if you have the correct destination name, correct URL in destination configured (destination service key URL with path /api/1.0/transportmodule/Transport), correct credentials (destination service key credential)

Transport request has failed as the destination APIManagement is not correctly configured. Details: Destination configuration error in APIManagement . Bad credentials sap apim
Transport request has failed as the destination APIManagement is not correctly configured. Details: Validation failed as destination APIManagement not configured with correct URL

Dependency Issues
If the below error is encountered, then the integration artifact that this API represents / linked is not actually present in destination tenant or subaccount. First transport the corresponding integration artifacts first then transport the API artifact.

The artifact you're attempting to transport could not be found or has encountered an error. Please verify that the artifact exists and try again. If the problem continues, contact SAP Support for assistance

Configuration Issues
Following error might occur during transport immediately after adding Transport description and clicking Yes. This might be due the special characters in the description provided. Please avoid giving special characters in transport description.

Similar to adding special characters in integration artifact transport and you encounter the following error.

This is due to the presence of special characters in Transport description as mentioned in this KBA. The characters specified in this KBA are too not accepted in API transports. Better to avoid any special characters in transport description.

Result

If you have all the pre-requisite complete along with the above steps, we should readily be able to do the API Proxy transports, API Provider transports from source subaccounts to destination subaccounts. Once you click transport from the source, it should create a transport ID and a transport request that can be seen in Cloud TMS with the API details.

SAP BTP - APIM - Domain-Centric Routing Pattern (DCRP): Governing APIs via CPI Provider - Part I

2026-01-30T17:58:18.353000+01:00

DCRP: Taming Enterprise-Scale SAP Integration API Proxies

Authorship & Origin - 2026

DCRP (Domain-Centric Routing Pattern) and PDCP (Package Domain-Centric Pattern) are original architectural patterns developed by Ricardo Luz Holanda Viana, derived from real-world enterprise integration scenarios and governance challenges in SAP BTP Integration Suite landscapes - API Management & Cloud Platform Integration.

PEER-REVIEWED ACADEMIC PAPER PUBLISHED

Official DOI: 10.5281/zenodo.18582469 Published: February 10, 2026 | Repository: Zenodo (CERN) Status: Open Access, Peer-Reviewed

This Medium article is the foundational disclosure (Feb 7, 2026). The complete academic paper with validation data, vendor implementations, and 40 references is now available:

Download Full Paper (PDF): https://zenodo.org/records/18582469

Validation Results:

90% reduction in API proxies (40 → 4)
90% reduction in CPI packages (40 → 4)
95% faster deployment (273 min → 14.5 min)
33,000+ messages tested, 68ms latency, 100% success

Citation: Viana, R. L. H. (2026). Gateway Domain-Centric Routing: A Vendor-Agnostic Metadata-Driven Architecture for Enterprise API Governance. Zenodo. https://doi.org/10.5281/zenodo.18582469

Executive Summary

The Problem: Enterprise that contains SAP APIM suffers from "Proxy Sprawl"—where each integration requires a dedicated API proxy, creating a 1:1 relationship that leads to:

Deployment bottlenecks (15 min per proxy)
Inconsistent security architecture
Unacceptable technical debt growth

The Solution: The Domain-Centric Routing Pattern (DCRP) consolidates multiple backend services into a single, domain-based API Proxy using a metadata-driven routing engine (JavaScript + KVM).

Impact:

Reduces proxies by up to 96% (100 integrations → 4 proxies)
Deployment time: 15 min → 30 seconds -
Centralized security, analytics, and traceability -
Validated: 4 domains deployed in 8 minutes

My Contribution - Ricardo Viana

Dynamic routing is a native feature in SAP APIM, AWS, and Kong. However, technology alone isn't enough. DCRP provides the governance framework necessary to scale this technology in enterprise environments, including standardized naming conventions, KVM structures +JavaScripts (Brain Logic of the solution), organization, orientation and deployment templates.

Time Investment:

Executive summary: 90 seconds
Full technical guide: 30~40 minutes

🎯Target Audience & Prerequisites

Intended for: Integration Architects, Enterprise Architects, Solution Architects, Platform Owners, Governance Teams, and SAP BTP Integration Suite experts with hands-on API Management experience and for anyone passionate about integration — junior, senior, or student level.

Technical Prerequisites:

✅SAP API Management: Proxy design (ProxyEndpoint/TargetEndpoint), Policy execution flow, KeyValueMap configuration
✅JavaScript in APIM: Context variable manipulation, error handling
✅API Proxy Flow Architecture: PreFlow/PostFlow execution order, when target.url can be modified
✅Enterprise Governance: Naming conventions, change management, security policies

Complexity Level: Advanced.

Not Covered: Basic SAP APIM tutorials, JavaScript fundamentals, beginner proxy creation.

Estimated PoC Time: 2 hours (APIM experts) | 1–2 days (Integration Architects new to APIM)

Introduction

SAP’s official documentation explains how to enable dynamic routing, but it often leaves a gap regarding when, why, and how to govern it at scale. This article aims to bridge that gap by providing a complete framework—from architectural design to hands-on implementation.

Building on my previous post about Advanced Domain Routing, we will now deep-dive into applying the Domain-Centric Routing Pattern (DCRP) to a real-world scenario: Sales & Distribution (O2C).

The DCRP Value Proposition:

Consolidation: A single API Proxy manages multiple sources (Salesforce, Microsoft D365, Vendor CRM).
Governance: Full request traceability and standardized security without infrastructure sprawl.
Scalability: High-performance routing without the overhead of proxy-level versioning.

What to Expect

This is Part I of a four-part series on eliminating integration chaos:

Part I (This Post): DCRP Gateway | Solves Proxy Sprawl | Metadata-driven routing (KVM + JavaScript)
Part II: PDCP Backend | Solves Package Sprawl | Domain consolidation + iFlow DNA naming
Part III: Implementation & Testing | Hands-on guide | JavaScript v8.0 | Postman | GitHub repo
Part IV: Monitoring with SAP Cloud ALM | End-to-end observability | MPL filtering | Dashboards & alerts

Let’s explore the architectural rationale and the step-by-step implementation to apply DCRP in your landscape.

Figure 1 - DCRP - API Proxy Model detailed exploration

1 - The "Sprawl" Problem

In many enterprise landscapes, it is common to find a 1:1 relationship between services and API Proxies. This leads to what we identify as "Proxy Sprawl": an environment where proxies are created for every individual technical service, regardless of their business domain.

Without a central governance authority or standardized naming conventions, these environments quickly become un-governed and unsustainable. As the integration volume grows, the complexity of managing, securing, and monitoring hundreds of individual proxies creates a significant operational bottleneck.

This pattern is not theoretical; DCRP was developed as a direct response to these real-world governance gaps. Following extensive architectural validation, this methodology was formalized to provide a repeatable solution for the SAP Integration Community.

Figure 2 - The Sprawl Problem

2 - What is DCRP (Domain Centric Routing Pattern) ?

The Domain-Centric Routing Pattern (DCRP) is an architectural design pattern that consolidates multiple backend services into a single, business-domain-oriented API Proxy. Residing at the Gateway Layer, DCRP governs how backend services are exposed and routed without necessitating changes to their underlying protocols (REST or SOAP).

Instead of organizing APIs into technical silos, DCRP aligns them with the organization's business domains. This approach significantly reduces API fragmentation and maintenance overhead while remaining fully compatible with SAP’s API Product offerings.

Domain-Centric Organization: - APIs grouped by business domain (Sales, Finance, Logistics) - NOT by technical system (Salesforce, SAP, D365)
Metadata-Driven Routing: - KeyValueMap (KVM) stores path → backend mappings - Changes in 30 seconds without redeployment
Protocol-Agnostic Gateway: - Supports REST and SOAP backends - No protocol lock-in

Figure 3 - The three pillars of DCRP

2.2 - DCRP Decision Framework

✅Use DCRP When:

Domain Density: 10+ APIs in same business domain
High Volatility: Integration changes monthly
Centralized Governance: Critical security requirements
Velocity: Rapid deployment is business-critical

❌DO NOT Use When:

Unrelated services with no business logic connection
Only 1-2 services per domain
Fewer than 10 total APIs
Teams lack governance maturity

Figure 4 - CRP Decision Framework: When to Use vs. When NOT to Use

2.3 - DCRP Architecture Overview: The Power of Dynamic Routing

The diagram below illustrates how the Domain-Centric Routing Pattern (DCRP) transforms the integration flow. Instead of a fragmented landscape of individual proxies, we consolidate connectivity through a unified, intelligent gateway layer.

The Technical Workflow:

Unified Entry Point: Multiple consumer systems—such as Salesforce, Dynamics 365, and Vendor CRMs—connect through a single Sales Domain APIM Proxy.
The DCRP Engine: Within the SAP API Management Gateway, the request is processed by the "Brain" of the pattern, which performs a KVM Lookup and executes JavaScript logic to resolve the target backend dynamically.
Secure Orchestration: The request is routed via a secure tunnel to the appropriate Cloud Platform Integration (CPI) iFlow.
Backend Flexibility: CPI handles the final orchestration with target systems (e.g., S/4HANA, Legacy Systems, or SAP ECC) using protocols like ODATA, SOAP, or HTTPS.
Governance at Scale: This model eliminates the need for separate proxies per integration, allowing for centralized monitoring, auditing, and security enforcement through the Analytics Collector and a global Governance Layer.

Figure 5 - DCRP Architecture Overview end-to-end: Three-CRM Integration Scenario

2.4 - The Technical Foundation: KVM + JavaScript

KeyValueMap (KVM) | The "Memory"

The KVM is a simple lookup table that stores your routing rules.

Decoupled Logic: Maps cpi-packagename, iflowname --> super important for the logic ( the combination of httppath<from cpi>:<iflowname> and sapprocess.
Instant Updates: Change a backend URL in the KVM, and the proxy updates immediately—no deployment needed.
Data-Driven: Business rules are stored as configuration, keeping the codebase clean.

JavaScript Policy | The "Brain":

The JS policy executes the logic based on what it finds in the "Memory."

Dynamic Routing: It fetches the destination from the KVM and constructs the final URL.
Governance: Automatically injects tracking headers like X-SenderId and X-CorrelationId for auditing.
Fail-Safe: Implements Structured Error Handling, ensuring that if a route is missing, the user gets a clear error message instead of a "silent failure."

Figure 6 - Enginne KVM + JavaScript

2.5 - Proxy Sprawl vs DCRP: The Comparison

The shift from a traditional 1:1 model to a Domain-Centric approach fundamentally changes how an integration landscape scales. The following comparison highlights the efficiency gains of the DCRP methodology:

Real Numbers:

100 integrations across 4 domains - Traditional: 100 proxies × 15 min = 25 hours
DCRP: 4 proxies × 2 min = 8 minutes (96% reduction)

Figure 7 - Proxy Sprawl vs DCRP Model

3 - Implementation: Configuring the DCRP API Proxy

This section defines the configuration for the ProxyEndpoint, Routing Rules, and Target Endpoint properties required to deploy a domain-centric architecture.

3.1 - The Entry Contract: One API Proxy per Business Domain

DCRP eliminates proxy sprawl by consolidating multiple technical applications into a single entry contract based on the business domain. This ensures each business area, such as Sales or Finance, has exactly one governed API Proxy.

3.2 - Naming Convention Strategy

A standardized naming convention provides immediate architectural context. DCRP uses the following structure:

[Provider]-[Pattern]-proxy-domain-[BusinessProcess]-[subprocess]

Example: cpi-dcrp-proxy-domain-sales-o2c

cpi: Identifies the provider (SAP Cloud Integration)
dcrp: Defines the routing methodology.
sales: Identifies the business domain/process (O2C).
o2c: sap-subprocess

3.3 Strategic Benefit: Subprocess Segregation

Breaking the naming down to the subprocess level (e.g., o2c for Order-to-Cash) is a deliberate segregation strategy rather than a simple labeling exercise.

By isolating by subprocess, you limit the scope of each API Proxy. This prevents the "Monolithic Proxy" trap, ensuring that updates to one specific flow—such as Warehouse Management—do not risk the stability of the entire Logistics domain.

DCRP Proxy Naming Convention

Pattern: cpi-dcrp-proxy-domain-[Domain]-[Subprocess] - check in the spoiler below:

Spoiler

Domain	Subprocess	Technical Proxy Name	Scope Description
Sales	`o2c`	`cpi-dcrp-proxy-domain-sales-o2c`	Order-to-Cash full lifecycle.
Sales	`crm`	`cpi-dcrp-proxy-domain-sales-crm`	Customer relationship and leads.
Sales	`pri`	`cpi-dcrp-proxy-domain-sales-pri`	Quotes and price conditions.
Sales	`reb`	`cpi-dcrp-proxy-domain-sales-reb`	Bonus and discount agreements.
Sales	`sd`	`cpi-dcrp-proxy-domain-sales-sd`	General sales and distribution.
Finance	`r2r`	`cpi-dcrp-proxy-domain-finance-r2r`	Financial closing and reporting.
Finance	`trs`	`cpi-dcrp-proxy-domain-finance-trs`	Treasury and cash management.
Finance	`ap`	`cpi-dcrp-proxy-domain-finance-ap`	Accounts Payable processes.
Finance	`ar`	`cpi-dcrp-proxy-domain-finance-ar`	Accounts Receivable processes.
Finance	`tax`	`cpi-dcrp-proxy-domain-finance-tax`	Tax compliance and reporting.
Logistics	`le`	`cpi-dcrp-proxy-domain-logistics-le`	Logistics execution and flows.
Logistics	`tm`	`cpi-dcrp-proxy-domain-logistics-tm`	Transportation and freight.
Logistics	`wm`	`cpi-dcrp-proxy-domain-logistics-wm`	Warehouse and bin management.
Logistics	`inv`	`cpi-dcrp-proxy-domain-logistics-inv`	Physical stock and inventory.
Logistics	`mm`	`cpi-dcrp-proxy-domain-logistics-mm`	Material master and movements.
Logistics	`shp`	`cpi-dcrp-proxy-domain-logistics-shp`	Shipping and delivery notes.
Procure	`p2p`	`cpi-dcrp-proxy-domain-procurement-p2p`	Procure-to-Pay lifecycle.
Procure	`srm`	`cpi-dcrp-proxy-domain-procurement-srm`	Supplier portal and relations.
Procure	`crt`	`cpi-dcrp-proxy-domain-procurement-crt`	Legal and operational contracts.
Procure	`clg`	`cpi-dcrp-proxy-domain-procurement-clg`	Catalog and item management.

DomainSubprocessTechnical Proxy NameScope DescriptionSaleso2ccpi-dcrp-proxy-domain-sales-o2cOrder-to-Cash full lifecycle.Salescrmcpi-dcrp-proxy-domain-sales-crmCustomer relationship and leads.Salespricpi-dcrp-proxy-domain-sales-priQuotes and price conditions.Salesrebcpi-dcrp-proxy-domain-sales-rebBonus and discount agreements.Salessdcpi-dcrp-proxy-domain-sales-sdGeneral sales and distribution.Financer2rcpi-dcrp-proxy-domain-finance-r2rFinancial closing and reporting.Financetrscpi-dcrp-proxy-domain-finance-trsTreasury and cash management.Financeapcpi-dcrp-proxy-domain-finance-apAccounts Payable processes.Financearcpi-dcrp-proxy-domain-finance-arAccounts Receivable processes.Financetaxcpi-dcrp-proxy-domain-finance-taxTax compliance and reporting.Logisticslecpi-dcrp-proxy-domain-logistics-leLogistics execution and flows.Logisticstmcpi-dcrp-proxy-domain-logistics-tmTransportation and freight.Logisticswmcpi-dcrp-proxy-domain-logistics-wmWarehouse and bin management.Logisticsinvcpi-dcrp-proxy-domain-logistics-invPhysical stock and inventory.Logisticsmmcpi-dcrp-proxy-domain-logistics-mmMaterial master and movements.Logisticsshpcpi-dcrp-proxy-domain-logistics-shpShipping and delivery notes.Procurep2pcpi-dcrp-proxy-domain-procurement-p2pProcure-to-Pay lifecycle.Procuresrmcpi-dcrp-proxy-domain-procurement-srmSupplier portal and relations.Procurecrtcpi-dcrp-proxy-domain-procurement-crtLegal and operational contracts.Procureclgcpi-dcrp-proxy-domain-procurement-clgCatalog and item management.

3.3 - API Proxy Details

The proxy serves as the unified entry point for the domain:

Name: cpi-dcrp-proxy-domain-sales-o2c
Type: REST
Base URL: https://[tenant].apimanagement.eu20.hana.ondemand.com/sales

3.4 - Endpoint,Routing Configuration, Value Mapping and explanation

The Routing Rules act as a gatekeeper, ensuring only authorized paths reach the dynamic engine in this sample we are working only with orders process.

Proxy Endpoint (Proxy Endpoint):

Route Rule Name: orders
Condition: proxy.pathsuffix MatchesPath "/orders/**"

Imagine your API is a big office building. This "Condition" is the security guard at the front desk checking the labels on incoming mail.

proxy.pathsuffix: This is the "address" written on the envelope after the main building name.
MatchesPath: This is the guard asking: "Does this address look like the one I’m looking for?"
"/orders/**": This is the specific "Department" name. The double stars (**) mean "I don't care what else is written after 'orders', just as long as it starts with that."

Examples

Incoming Path	Does it match?	Why?
`/orders/123`	✅Yes	Starts with `/orders/`.
`/orders/list/today`	✅Yes	Starts with `/orders/` (the `**` covers the rest).
`/customers/456`	❌No	It’s looking for "orders," not "customers."
`/orders`	✅Yes	It is the exact folder.

The configuration below:

Figure 8 - Configuring the Route Rule Condition

Target Endpoint Properties:

These properties provide the base connectivity for the routing engine:

Property Value
- cpi.host https://[tenant].cfapps.eu20.hana.ondemand.com
- cpi.basepath /http/orders

Figure 9 - The main properties for the Java Script create the SAP CPI endpoint

Configuration of Key Value Mapping (KVM)

Following the suggested naming convention, you must create one Key-Value Mapping for each SAP CPI package:

Example Maps: cpipackage-nx.procurement.domain.process, cpipackage-nx.sales.domain.process, etc.

Figure 10 - API-Proxy vs Key Value Mapping

KVM Structure: Each map contains three primary entries:

packagename: The technical CPI package name (e.g., nx.sales.domain.process).
sapprocess: The business domain description (e.g., SAP SD & O2C - Sales Process).
iflowname: The routing metadata string.

Figure 11 - Key Value Mapping Configuration

Understanding the `iflowname` String

The iflowname entry is the "routing table" for the DCRP. It contains pairs consisting of the Semantic Path Suffix (used by the consumer) and the Technical iFlow Name (the target in CPI). This string is parsed by the JavaScript "Brain," so maintaining the pattern is critical.

Example Configuration: httppath: inbound:SO.01.Iflow.Sales.Order.Inbound,tracking:SO.02.Iflow.Sales.Order.Tracking.

The java script support almost all types of demiliters , but you can't use two dots (:) because this is the separation of http path url from SAP CPI and the Iflow name, between the records you can use any my suggestion is ( , )

// Auto-detect delimiter used in KVM string
var supportedDelimiters = [',', ';', '|', '/', '\\', '[', ']', '(', ')', '-', '_'];

It maps the public HTTP URL suffix to the specific CPI technical endpoint:

inbound $\rightarrow$ Routes to /inbound.
tracking $\rightarrow$ Routes to /tracking.

inbound

cpi endpoint: /orders/inbound

tracking

cpi endpoint: /orders/tracking

The SAP CPI Packages:

Following the DCRP methodology, SAP CPI packages are organized as domain-specific containers that house multiple related integration flows.

The Full Configuration of API Proxy

Condition: The Proxy Endpoint validates the path (e.g., proxy.pathsuffix MatchesPath "/orders/**").
Lookup: The "Brain" extracts the iflowname string from the KVM.
Parsing: The JavaScript splits the string using the , delimiter to extract individual pairs.
Generation: The engine matches the incoming suffix (e.g., /inbound) and generates the final CPI Target URL.
End url: https://<cpi>/orders/inbound and any others values from the kvm records.

ARCHITECT'S DEEP DIVE: WHY SUBDOMAIN SEGREGATION?

Context: The KVM Scaling Challenge

You might be wondering:

"If I store all my iFlows in a single KVM as a concatenated string like cpihttpPath:iflowName,, won't this become a gigantic string?"

Answer: Yes, exactly. And this is the core problem that led to the architectural pivot.

The Discovery: Storage ≠ Performance

Initial Assumption

Original design: 1 API Proxy per business domain (Sales, Finance, Logistics, Procurement)
KVM strategy: Concatenated string with all iFlow routes in a single KVM entry
Expected limit: SAP API Management documentation states 10 KB KVM value limit

KVM Size Analysis (Theoretical, Not Production-Tested)

Scenario Size Entries Storage Runtime Concern

Small Domain	~5 KB	40 entries	✅Within limits	Parsing overhead manageable
Medium Domain	~10 KB	53 entries	✅At documented limit	JavaScript performance degrades
Large Domain	~15-30 KB	100+ entries	⚠️Exceeds guideline	Bottleneck: O(n) parsing, not storage

Key Finding:
Storage capacity is not the constraint—JavaScript parsing performance at scale is.

3.5 - The Semantic Facade: One Proxy, Multiple Intentions

Instead of deploying separate proxies, all consumers use the SAME API Proxy. Differentiation handled via path suffixes.

Consumer View (Public API):

POST https://apim/sales/orders/inbound
POST https://apim/sales/orders/tracking

Backend Reality (CPI):

https://cpi/http/orders/inbound
https://cpi/http/orders/tracking

Key Benefits:

Total Abstraction: Consumer contract unchanged if backend migrates
End-to-End Monitoring: Unified analytics for entire Sales domain
Centralized Security: One OAuth2 policy for all
Unified Traffic Control: Spike Arrest and Quotas by domain

Figure 12 - Public API paths mapped to technical CPI endpoints

3.6 - The Routing Engine: Execution Flow

Every request passes through three stages:

Stage 1: Proxy Endpoint Pre-Flow

Security policies (OAuth2, API Key)
Hacking Thread java script
Request validation (payload size, content type)
Traffic control (Spike Arrest, Quotas)
❌Immediate rejection if policies fail

Stage 2: Routing Rules

Evaluate: proxy.pathsuffix MatchesPath "/orders/**"
✅Match → forward to Target Endpoint
❌No match → 404 error

Stage 3: Target Endpoint Pre-Flow

DCRP Brain executes here (last point to modify target.url)

Figure 13 - Three-stage request processing with DCRP logic in Target Pre-Flow

3.7 - The DCRP Brain: Policy Stages

The routing engine executes through four policy stages Target Endpoint - PRE-Flow:

Key Value Mapping: Retrieves httppath, iflowname, and sapprocess.
JavaScript Routing: Performs variable verification, validation, and injection of headers.
RaiseFaultException: Blocks the process in case of exceptions, missing variables, or KVM misconfigurations.
Statistics Collection: Captures custom dimension variables for the SAP APIM Dashboard.

The DCRP pattern transforms the gateway into a high-scale, programmable router by decoupling configuration from execution and moving routing logic into metadata.

Figure 14 - KVM + Java Script

3.8 Scaling Model: Vertical vs. Horizontal

Vertical Scaling (30 Seconds): Add new iFlows to an existing domain by updating the KVM string. No infrastructure changes are required.

Horizontal Scaling (2 Minutes): Onboard an entirely new business domain (e.g., Finance) by cloning the domain template and updating only the mapIdentifier.

Figure 15 - Two-Level scaling strategy

Real-World Validation: 4 Business Domains Deployed

The methodology was validated by deploying four business domains—Sales, Logistics, Finance, and Procurement—managing 8 total iFlows.

Validation Metrics:

API Proxies Deployed: 4.

JavaScript Policies Reused: 1 universal routing engine.
Total Deployment Time: Approximately 8 minutes (~2 minutes per domain).
Resilience: While DCRP returns an HTTP 404 if a specific iFlow endpoint is missing, the routing logic itself remains correct and operational.

Business Domain API Proxy CPI Package iFlows Time

Business Domain API Proxy CPI Package iFlows Time

Sales & O2C	cpi-dcrp-proxy-domain-sales-o2c	cpipackage-nx.sales.domain.process	2	2 min
Logistics & Shipping	cpi-dcrp-proxy-domain-logistics-scm	cpipackage-nx.logistics.domain.process	2	2 min
Finance & Billing	cpi-dcrp-proxy-domain-finance-r2r	cpipackage-nx.finance.domain.process	2	2 min
Procurement	cpi-dcrp-proxy-domain-procurement-s2p	cpipackage-nx.procurement.domain.process	2	2 min

Results:
4 API Proxies managing 8 iFlows
JavaScript policies reused: 1 (universal routing engine)
Total deployment time: ~8 minutes

Total Time = (N domains × 2 min) + (M iFlows × 30 sec)

3.9 - The JavaScript "Brain" (Complete Code)

Figure 16 - Java Script coding

The code of java script is into spoiler below -

TL;DR for Non-Developers: This JavaScript performs 4 tasks:

Extracts path segments (e.g., `/inbound` → httppath cpi `inbound`)
Looks up routing metadata from KVM
Constructs final CPI URL dynamically
Injects governance headers (X-SenderId, X-CorrelationId)

For Architects: Review sections 1-4 for logic flow

For Developers: Full code below with inline comments

⚠️ IMPLEMENTATION NOTICE

⚠️IMPORTANT: This code is a simplified reference implementation designed for Proof-of-Concept (PoC) scenarios and educational purposes. While fully functional for demonstrating the core DCRP pattern, this routing engine assumes a basic KVM structure with simple, human-readable path identifiers like inbound, outbound, tracking, status, etc., as shown in the blog examples.

KVM Format Used in This Blog:

Format: <httppath>:<iflowname>

Examples:
inbound:iflow-salesforce-order-create
outbound:iflow-sap-invoice-send
tracking:iflow-fedex-shipment-track
status:iflow-order-status-query

This approach works well for PoC scenarios with single iFlow per action and straightforward naming conventions.

Before Production Deployment:

This code must be adapted based on your specific requirements:

KVM Structure Design - The iflowname string format you choose will dictate the parsing logic
Naming Conventions - Adapt routing logic to match your organization's naming patterns
Adapter Requirements - HTTP-only vs. mixed HTTP/SOAP landscapes require different endpoint construction
Multi-Vendor Scenarios - Single-vendor vs. multi-vendor per process may need disambiguation logic

Production-Ready Code: DCRP Routing Engine (Part II & III)

A comprehensive, production-grade routing engine covering all enterprise scenarios—multi-vendor disambiguation, PDCP naming compliance, HTTP/SOAP adapter support, conflict resolution (id09/id10), and global-scale architecture—is available in Part II: Package Domain-Centric Pattern (PDCP) and fully implemented in Part III: Implementation & Testing. The latest v8.0 engine is specifically designed for the combined DCRP + PDCP framework, generating CPI endpoints with the /dcrp/ prefix and automatic adapter detection: /http/dcrp/ (HTTP) or /cxf/dcrp/ (SOAP). This evolution handles complex KVM structures, scales to 100+ integrations with zero-code deployment for new vendors, and includes smart vendor-aware routing with fallback logic for seamless multi-instance disambiguation.

Spoiler

/**
 * ═══════════════════════════════════════════════════════════════════════════
 * 
 *   THE DCRP ROUTING ENGINE
 * 
 *   MISSION: Transform static gateway infrastructure into intelligent,
 *            metadata-driven routing orchestration at enterprise scale.
 * 
 *   CAPABILITIES:
 *   ✓ Dynamic iFlow resolution via Key-Value Map metadata
 *   ✓ Path parameter preservation (single or multi-level IDs)
 *   ✓ Query string integrity across gateway boundaries
 *   ✓ Governance header injection (X-SenderId, X-CorrelationId)
 *   ✓ Analytics variable collection for observability
 *   ✓ Zero code deployment for new integrations (metadata-only scaling)
 * 
 *   AUTHOR: Viana - SAP BTP Integration Suite Expert
 *   PATTERN: Domain-Centric Routing Pattern (DCRP)
 *   VERSION: 1.0 - Production Ready
 * 
 * ═══════════════════════════════════════════════════════════════════════════
 */
function resolveDcrpRouting() {
    try {
        var cpiHost = context.getVariable("target.cpi.host");
        var cpiBasepathRaw = context.getVariable("target.cpi.basepath");
        var iflowname = context.getVariable("iflowname");
        var pathSuffix = context.getVariable("proxy.pathsuffix");
        var senderId = context.getVariable("request.header.X-SenderId");
        var correlationId = context.getVariable("request.header.X-CorrelationId");
        var queryParams = context.getVariable("request.querystring") || "";

        if (!cpiHost || !cpiBasepathRaw || !iflowname || !pathSuffix) {
            context.setVariable("routing.failed", true);
            context.setVariable("routing.error", "MISSING_REQUIRED_VARIABLES");
            throw new Error("DCRP: Missing required variables for routing");
        }

        // ========================================
        // SECTION 1.5: EXTRACT PATH SEGMENTS
        // ========================================

        var cleanPathSuffix = pathSuffix.replace(/^\/+/, '');
        var segments = cleanPathSuffix.split('/');
        var firstSegment = segments[0]; // "orders" ou "fodase"
        var remainingPath = segments.slice(1).join('/'); // "inbound"

        // Build dynamic basepath: /http/{firstSegment}
        var cpiBasepath = "/http/" + firstSegment;

        // ========================================
        // SECTION 2: FLEXIBLE DELIMITER DETECTION
        // ========================================

        var supportedDelimiters = [',', ';', '|', '/', '\\', '[', ']', '(', ')', '-', '_'];
        var delimiter = null;

        for (var i = 0; i < supportedDelimiters.length; i++) {
            if (iflowname.indexOf(supportedDelimiters[i]) !== -1) {
                delimiter = supportedDelimiters[i];
                break;
            }
        }

        if (!delimiter) {
            context.setVariable("routing.failed", true);
            context.setVariable("routing.error", "NO_DELIMITER_FOUND");
            throw new Error("DCRP: No valid delimiter found in KVM value");
        }

        // ========================================
        // SECTION 3: KVM PARSING & PATH MATCHING
        // ========================================

        var entries = iflowname.split(delimiter);
        var routes = [];

        for (var j = 0; j < entries.length; j++) {
            var entry = entries[j].trim();
            if (entry.length === 0) continue;

            var parts = entry.split(':');
            if (parts.length !== 2) {
                context.setVariable("routing.failed", true);
                context.setVariable("routing.error", "INVALID_KVM_FORMAT");
                throw new Error("DCRP: Invalid KVM format - expected 'path:iflowname', got: " + entry);
            }

            routes.push({
                path: parts[0].trim(),
                iflow: parts[1].trim()
            });
        }

        routes.sort(function(a, b) {
            return b.path.length - a.path.length;
        });

        var matchedRoute = null;

        for (var k = 0; k < routes.length; k++) {
            var routePath = routes[k].path.replace(/^\/+/, '');

            if (remainingPath === routePath || remainingPath.indexOf(routePath + '/') === 0) {
                matchedRoute = routes[k];
                break;
            }
        }

        if (!matchedRoute) {
            context.setVariable("routing.failed", true);
            context.setVariable("routing.error", "ROUTE_NOT_FOUND");
            context.setVariable("routing.pathsuffix", pathSuffix);
            throw new Error("DCRP: No matching route found for path: " + pathSuffix);
        }

        // ========================================
        // SECTION 4: GOVERNANCE HEADER INJECTION
        // ========================================

        if (senderId) {
            context.setVariable("request.header.X-SenderId", senderId);
        }

        if (correlationId) {
            context.setVariable("request.header.X-CorrelationId", correlationId);
        }

        // ========================================
        // SECTION 5: DYNAMIC URL CONSTRUCTION
        // ========================================

        var targetUrl = cpiHost + cpiBasepath + "/" + matchedRoute.path;

        if (queryParams && queryParams.length > 0) {
            targetUrl += "?" + queryParams;
        }

        context.setVariable("target.url", targetUrl);
        context.setVariable("target.copy.pathsuffix", false);
        context.setVariable("target.copy.queryparams", false);

        // ========================================
        // SUCCESS: SET ROUTING METADATA
        // ========================================

        context.setVariable("routing.success", true);
        context.setVariable("routing.matched.path", matchedRoute.path);
        context.setVariable("routing.matched.iflow", matchedRoute.iflow);
        context.setVariable("routing.target.url", targetUrl);
        context.setVariable("routing.selected.basepath", cpiBasepath);

        context.setVariable("idiflow", matchedRoute.iflow);
        context.setVariable("idcorrelation", context.getVariable("request.header.X-CorrelationId"));
        context.setVariable("idsender", senderId || "UNKNOWN");

    } catch (error) {
        context.setVariable("routing.failed", true);
        context.setVariable("routing.exception", error.message || error.toString());

        print("DCRP Routing Error: " + error.message);
        print("PathSuffix: " + pathSuffix);
        print("KVM Value: " + iflowname);
    }
}

/** * ═══════════════════════════════════════════════════════════════════════════ * * THE DCRP ROUTING ENGINE * * MISSION: Transform static gateway infrastructure into intelligent, * metadata-driven routing orchestration at enterprise scale. * * CAPABILITIES: * ✓ Dynamic iFlow resolution via Key-Value Map metadata * ✓ Path parameter preservation (single or multi-level IDs) * ✓ Query string integrity across gateway boundaries * ✓ Governance header injection (X-SenderId, X-CorrelationId) * ✓ Analytics variable collection for observability * ✓ Zero code deployment for new integrations (metadata-only scaling) * * AUTHOR: Viana - SAP BTP Integration Suite Expert * PATTERN: Domain-Centric Routing Pattern (DCRP) * VERSION: 1.0 - Production Ready * * ═══════════════════════════════════════════════════════════════════════════ */ function resolveDcrpRouting() { try { var cpiHost = context.getVariable("target.cpi.host"); var cpiBasepathRaw = context.getVariable("target.cpi.basepath"); var iflowname = context.getVariable("iflowname"); var pathSuffix = context.getVariable("proxy.pathsuffix"); var senderId = context.getVariable("request.header.X-SenderId"); var correlationId = context.getVariable("request.header.X-CorrelationId"); var queryParams = context.getVariable("request.querystring") || ""; if (!cpiHost || !cpiBasepathRaw || !iflowname || !pathSuffix) { context.setVariable("routing.failed", true); context.setVariable("routing.error", "MISSING_REQUIRED_VARIABLES"); throw new Error("DCRP: Missing required variables for routing"); } // ======================================== // SECTION 1.5: EXTRACT PATH SEGMENTS // ======================================== var cleanPathSuffix = pathSuffix.replace(/^\/+/, ''); var segments = cleanPathSuffix.split('/'); var firstSegment = segments[0]; // "orders" ou "fodase" var remainingPath = segments.slice(1).join('/'); // "inbound" // Build dynamic basepath: /http/{firstSegment} var cpiBasepath = "/http/" + firstSegment; // ======================================== // SECTION 2: FLEXIBLE DELIMITER DETECTION // ======================================== var supportedDelimiters = [',', ';', '|', '/', '\\', '[', ']', '(', ')', '-', '_']; var delimiter = null; for (var i = 0; i < supportedDelimiters.length; i++) { if (iflowname.indexOf(supportedDelimiters[i]) !== -1) { delimiter = supportedDelimiters[i]; break; } } if (!delimiter) { context.setVariable("routing.failed", true); context.setVariable("routing.error", "NO_DELIMITER_FOUND"); throw new Error("DCRP: No valid delimiter found in KVM value"); } // ======================================== // SECTION 3: KVM PARSING & PATH MATCHING // ======================================== var entries = iflowname.split(delimiter); var routes = []; for (var j = 0; j < entries.length; j++) { var entry = entries[j].trim(); if (entry.length === 0) continue; var parts = entry.split(':'); if (parts.length !== 2) { context.setVariable("routing.failed", true); context.setVariable("routing.error", "INVALID_KVM_FORMAT"); throw new Error("DCRP: Invalid KVM format - expected 'path:iflowname', got: " + entry); } routes.push({ path: parts[0].trim(), iflow: parts[1].trim() }); } routes.sort(function(a, b) { return b.path.length - a.path.length; }); var matchedRoute = null; for (var k = 0; k < routes.length; k++) { var routePath = routes[k].path.replace(/^\/+/, ''); if (remainingPath === routePath || remainingPath.indexOf(routePath + '/') === 0) { matchedRoute = routes[k]; break; } } if (!matchedRoute) { context.setVariable("routing.failed", true); context.setVariable("routing.error", "ROUTE_NOT_FOUND"); context.setVariable("routing.pathsuffix", pathSuffix); throw new Error("DCRP: No matching route found for path: " + pathSuffix); } // ======================================== // SECTION 4: GOVERNANCE HEADER INJECTION // ======================================== if (senderId) { context.setVariable("request.header.X-SenderId", senderId); } if (correlationId) { context.setVariable("request.header.X-CorrelationId", correlationId); } // ======================================== // SECTION 5: DYNAMIC URL CONSTRUCTION // ======================================== var targetUrl = cpiHost + cpiBasepath + "/" + matchedRoute.path; if (queryParams && queryParams.length > 0) { targetUrl += "?" + queryParams; } context.setVariable("target.url", targetUrl); context.setVariable("target.copy.pathsuffix", false); context.setVariable("target.copy.queryparams", false); // ======================================== // SUCCESS: SET ROUTING METADATA // ======================================== context.setVariable("routing.success", true); context.setVariable("routing.matched.path", matchedRoute.path); context.setVariable("routing.matched.iflow", matchedRoute.iflow); context.setVariable("routing.target.url", targetUrl); context.setVariable("routing.selected.basepath", cpiBasepath); context.setVariable("idiflow", matchedRoute.iflow); context.setVariable("idcorrelation", context.getVariable("request.header.X-CorrelationId")); context.setVariable("idsender", senderId || "UNKNOWN"); } catch (error) { context.setVariable("routing.failed", true); context.setVariable("routing.exception", error.message || error.toString()); print("DCRP Routing Error: " + error.message); print("PathSuffix: " + pathSuffix); print("KVM Value: " + iflowname); } }

Add in seguency in the Pre-Flow TargetEndpoint - Raise Fault Routing:

condition: routing.failed = "true"

Figure 17 - Raise Fault in case of failure in the "Brain Java Script Routing"

Spoiler

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
    <FaultResponse>
        <Set>
            <StatusCode>404</StatusCode>
            <ReasonPhrase>Route Not Found</ReasonPhrase>
        </Set>
        <Set>
            <Payload contentType="application/json">{
  "error": "ROUTE_NOT_FOUND",
  "message": "{routing.error.message}",
  "details": {
    "error_code": "{routing.error}",
    "blocked_segment": "{routing.blocked.segment}",
    "blocked_path": "{routing.blocked.path}",
    "available_paths": "{routing.available.paths}",
    "timestamp": "{system.timestamp}",
    "correlation_id": "{request.header.X-CorrelationId}"
  }
}</Payload>
        </Set>
        <Add>
            <Headers>
                <Header name="Content-Type">application/json</Header>
                <Header name="X-Routing-Error">{routing.error}</Header>
                <Header name="X-Correlation-Id">{request.header.X-CorrelationId}</Header>
            </Headers>
        </Add>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <RaiseFault async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt"> <FaultResponse> <Set> <StatusCode>404</StatusCode> <ReasonPhrase>Route Not Found</ReasonPhrase> </Set> <Set> <Payload contentType="application/json">{ "error": "ROUTE_NOT_FOUND", "message": "{routing.error.message}", "details": { "error_code": "{routing.error}", "blocked_segment": "{routing.blocked.segment}", "blocked_path": "{routing.blocked.path}", "available_paths": "{routing.available.paths}", "timestamp": "{system.timestamp}", "correlation_id": "{request.header.X-CorrelationId}" } }</Payload> </Set> <Add> <Headers> <Header name="Content-Type">application/json</Header> <Header name="X-Routing-Error">{routing.error}</Header> <Header name="X-Correlation-Id">{request.header.X-CorrelationId}</Header> </Headers> </Add> </FaultResponse> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault>

4 - Operational Simulation and Architectural Flow

This section demonstrates the practical execution of the DCRP (Domain-Centric Routing Pattern) framework by simulating how the routing engine processes a request through the landscape.

Architectural Flow Simulation

Based on the provided technical diagram, the process follows a structured path from the initiating system to the final integration endpoint:

Request Initiation: External systems such as
- Salesforce - http://<apim>/sales/orders/inbound
- Dynamics 365 - http://<apim>/sales/orders/status
- Vendor CRMs - http://<apim>/sales/orders/tracking
The DCRP Engine: Upon reaching the SAP API Management Gateway, the DCRP Enginne is triggered to manage the transaction logic.
- Metadata Retrieval (KVM Lookup):
  - Inbound:iflowname | sapprocess | cpipackage
  - Tracking:iflowname | sapprocess | cpipackage
  - Status: iflowname | sapprocess | cpipackage
- Logical Resolution (JavaScript): The JavaScript component processes the proxy.pathsuffix against the metadata retrieved from the KVM to determine the correct technical path.
  - http;//<cpi>/orders/inbound
  - http;//<cpi>/orders/tracking
  - http://<cpi>/orders/status
  - Header details
- Dynamic Routing: The engine resolves the target and dynamically routes the traffic to the corresponding SAP BTP Integration Suite iFlow.

Architect's Note: This simulation highlights the decoupling of the consumer from the technical backend. The source systems interact only with a standardized semantic layer, while the routing engine manages all technical complexities internally.

Figure 18 - Clear orientation how works the solution from the sender to SAP APIM.

5 - Scaling Strategies: Manual vs Dynamic Routing

Scaling DCRP effectively requires choosing between two distinct deployment approaches, depending on the complexity and regional requirements of the enterprise.

Two Strategic Approaches:

5.1 - Approach 1: Single Global Template:

How it works: Create 1 Routing Rule per path (`/orders/**`, `/customers/**`)
Configuration: - 1 proxy per domain - N routing rules (1 per path) -
Fixed:`cpi.basepath` per rule
Time per new path: ~2 minutes (add routing rule + KVM entry)
Best for: Small domains (<5 paths), stable environments

Figure 19 - Template part 1

Figure 20 - Template part 2

Most importantly, you must ensure the Target Endpoint PRE-Flow is ready with the DCRP logic. While this approach provides explicit routing visibility, any additional requirements—such as specific security methods, quotas, or spike control—must be adjusted accordingly.

Required Policies (Target Endpoint PreFlow):

Key Value Mapping
JavaScript Routing
Raise Fault
Statistics Collector

Once this setup is finalized, it takes approximately 2 to 3 minutes to have a fully functional API Proxy ready for operation, and less than 30 seconds to update metadata in the Key Value Mapping.

Figure 21 - Pre-Flow setup - DCRP brain

5.2 - Approach 2: Dynamic Multi-Path Routing

How it works:

Single catch-all route (/**)
JavaScript extracts first segment dynamically
cpi.basepath is comma-delimited string of all paths

Configuration:

1 proxy per domain
1 catch-all routing rule
Security Shield validates domain whitelist

Time per new path: ~30 seconds (update cpi.basepath string + KVM + Security whitelist)

Best for: Enterprise scale, frequent changes

Example Configuration

Target Endpoint Property: cpi.basepath

Initial Value:

/http/orders,/http/customers,/http/invoices,/http/prices

Adding new path (payments):

/http/orders,/http/customers,/http/invoices,/http/prices,/http/payments

Request Flow

Request Path First Segment Dynamic Basepath KVM Match Final CPI URL

`/sales/customers`	`customers`	`/http/customers`	`SO.01.Customer.MasterData`	`https://cpi/http/customers`
`/sales/orders`	`orders`	`/http/orders`	`SO.02.Order.Process`	`https://cpi/http/orders`
`/sales/invoices`	`invoices`	`/http/invoices`	`SO.03.Invoice.Billing`	`https://cpi/http/invoices`

Mechanism: JavaScript extracts first segment → builds /http/{firstSegment} → KVM lookup → routes to CPI.

Figure 22 - Scalation mode hard

Architect's Note Dynamic Multi-Path Routing: This simulation highlights the decoupling of the consumer from the technical backend. The source systems interact only with a standardized semantic layer, while the routing engine manages all technical complexities internally.

Figure 23 - Clear orientation how works the solution with Dynamic Multi-Path Routing from the sender to SAP APIM.

Figure 24 - Setup of cpi.basepath variable in the target endpoint with full string or new incomming process.

To do this setup this takes me 1 minute.

5.3 — Security Shield: Critical for Dynamic Routing

Why It's Required

Catch-all route (/)** = every request reaches routing engine.

Without Shield With Shield

❌Path traversal reaches KVM/JS	✅Blocked at PreFlow (403)
❌SQL injection processed	✅Saves ~100ms per blocked request
❌Resource waste	✅Audit compliance (SOC 2/ISO 27001)

Attack Scenarios

Attack Type Example Without Shield With Shield

Path Traversal	`/sales/../admin/delete`	❌Reaches KVM/JS	✅Blocked (403)
SQL Injection	`/orders?id=1 OR 1=1`	❌Reaches KVM/JS	✅Blocked (403)
Domain Hijacking	`/hacker-domain/exploit`	❌Reaches KVM/JS	✅Blocked (403)
Command Injection	`/orders?cmd=;cat /etc/passwd`	❌Reaches KVM/JS	✅Blocked (403)

Configuration (30 seconds per path)

Add new path (e.g., /payments) in 3 locations:

1. Target Endpoint (cpi.basepath)

/http/orders,/http/customers,/http/payments

2. Security Whitelist (JS-Security-Shield.js) - Inside javascript code

var allowedDomains = ["sales", 
"orders", "customers", "invoices", "payments"]; <-- add here new path

3. KVM Entry (iflowname)

orders:SO.01...,customers:SO.02...,payments:SO.03...

Execution Api-proxy flow steps:

ProxyEndpoint PreFlow:
  1. JS-Security-Shield    → Validates whitelist, blocks attacks
  2. RF-SecurityThreat     → Returns 403 if threat
  3. Quota + Spike Arrest  → Rate limiting
     ↓
TargetEndpoint PreFlow:
  4. KVM Lookup + Routing  → Only if security passed

Performance (Telemetry)

Scenario Time Impact

Valid request	+10ms	✅Acceptable (8% total)
Blocked attack	10ms (no KVM/JS)	✅ Saves 100ms

Key Insight: Security Shield prevents resource waste on malicious requests.

Why Not Rely on KVM for 404?

Defense-in-depth principle:

Resource Efficiency: Blocks at PreFlow (saves KVM + JS overhead)
Attack Intelligence: Logs threats for SIEM
Blast Radius: KVM misconfiguration doesn't expose all paths
Compliance: SOC 2/ISO 27001 require gateway validation

Java Script Thread Hacking protection - ( Complete Code )

Figure 25 - Java Script Policy - Hacking thread protection Domain-Specific Templates

In this case you need to add this java script in the Proxy End-point - Pre-Flow to stop imidiatly any hacking or sql injection, because now the routing mechanism is not based on path, is start - proxy.pathsuffix MatchesPath "/**"

Figure 23 - Java Script Thread Protection - ProxyEndpoint - Preflow

Add in seguency - RaiseFault Hacking thead:

condition: security.raise.fault = "true"

Figure 24 - Raise Fault Thread of Hacking, sql injection and others.

Spoiler

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt">
    <FaultResponse>
        <Set>
            <StatusCode>403</StatusCode>
            <ReasonPhrase>Forbidden - Security Threat Detected</ReasonPhrase>
        </Set>
        <Set>
            <Payload contentType="application/json">{
                  "error": "SECURITY_THREAT_DETECTED",
                  "message": "Request blocked by security policies",
                  "details": {
                    "threat_type": "{security.threat.type}",
                    "blocked_path": "{security.blocked.path}",
                    "client_ip": "{client.ip}",
                    "user_agent": "{request.header.User-Agent}",
                    "timestamp": "{system.timestamp}",
                    "correlation_id": "{request.header.X-CorrelationId}",
                    "request_id": "{messageid}"
                  }
                }
            </Payload>
        </Set>
        <Add>
            <Headers>
                <Header name="Content-Type">application/json</Header>
                <Header name="X-Security-Status">BLOCKED</Header>
                <Header name="X-Threat-Type">{security.threat.type}</Header>
                <Header name="X-Correlation-Id">{request.header.X-CorrelationId}</Header>
            </Headers>
        </Add>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <RaiseFault async="false" continueOnError="false" enabled="true" xmlns="http://www.sap.com/apimgmt"> <FaultResponse> <Set> <StatusCode>403</StatusCode> <ReasonPhrase>Forbidden - Security Threat Detected</ReasonPhrase> </Set> <Set> <Payload contentType="application/json">{ "error": "SECURITY_THREAT_DETECTED", "message": "Request blocked by security policies", "details": { "threat_type": "{security.threat.type}", "blocked_path": "{security.blocked.path}", "client_ip": "{client.ip}", "user_agent": "{request.header.User-Agent}", "timestamp": "{system.timestamp}", "correlation_id": "{request.header.X-CorrelationId}", "request_id": "{messageid}" } } </Payload> </Set> <Add> <Headers> <Header name="Content-Type">application/json</Header> <Header name="X-Security-Status">BLOCKED</Header> <Header name="X-Threat-Type">{security.threat.type}</Header> <Header name="X-Correlation-Id">{request.header.X-CorrelationId}</Header> </Headers> </Add> </FaultResponse> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </RaiseFault>

DCRP Security Shield v1.0

Purpose

Protects catch-all route (/**) from malicious requests before JS-Routing executes - code in the spoiler below

Spoiler

/**
 * ============================================
 * DCRP SECURITY SHIELD v1.0
 * ============================================
 * PURPOSE: Protect /** catch-all route from malicious requests
 * AUTHOR: Ricardo Viana
 * RUNS: BEFORE JS-Routing in Proxy PreFlow
 * 
 * FEATURES:
 * - Path Traversal Protection
 * - SQL Injection Detection
 * - XSS Protection
 * - Domain Whitelist Enforcement
 * - Header Validation
 * - Bot Protection
 * ============================================
 */

try {
    // ============================================
    // CONTEXT EXTRACTION
    // ============================================
    var pathSuffix = context.getVariable("proxy.pathsuffix") || "";
    var queryString = context.getVariable("request.querystring") || "";
    var userAgent = context.getVariable("request.header.User-Agent") || "";
    var contentType = context.getVariable("request.header.Content-Type") || "";
    var method = context.getVariable("request.verb") || "";
    var clientIp = context.getVariable("client.ip") || "";

    // ============================================
    // SECTION 1: PATH TRAVERSAL PROTECTION
    // ============================================
    var pathTraversalPatterns = [
        /\.\./,                 // ../
        /%2e%2e/i,              // URL-encoded ..
        /%252e/i,               // Double URL-encoded .
        /\.\\/,                 // .\ (Windows path)
        /%5c/i,                 // URL-encoded backslash
        /\/\//,                 // Double slashes
        /etc\/passwd/i,         // Linux system files
        /windows\/system/i,     // Windows system paths
        /proc\/self/i,          // Linux proc filesystem
        /\.\.%2f/i,             // Mixed encoding
        /\.\.;/i                // Semicolon bypass attempt
    ];

    for (var i = 0; i < pathTraversalPatterns.length; i++) {
        if (pathTraversalPatterns[i].test(pathSuffix)) {
            context.setVariable("security.threat.detected", "PATH_TRAVERSAL");
            context.setVariable("security.threat.pattern", pathTraversalPatterns[i].toString());
            context.setVariable("security.threat.path", pathSuffix);
            context.setVariable("security.threat.ip", clientIp);
            throw new Error("SECURITY: Path Traversal attempt detected");
        }
    }

    // ============================================
    // SECTION 2: DOMAIN WHITELIST VALIDATION
    // ============================================
    var allowedDomains = [
        "sales", "orders", "customers", "invoices", "prices", "quotations",
        "finance", "accounts", "journals", "payments", "reconciliations",
        "reports", "closings", "taxes", "budgets",
        "logistics", "shipments", "inventory", "deliveries", "warehouses",
        "tracking", "carriers", "returns", "pickpack",
        "procurement", "requisitions", "suppliers", "contracts",
        "buyers", "approvals", "receipts", "catalogs"
    ];

    var segments = pathSuffix.split("/").filter(function(s) {
        return s.length > 0;
    });
    var firstSegment = segments.length > 0 ? segments[0].toLowerCase() : "";

    var isDomainAllowed = false;
    for (var j = 0; j < allowedDomains.length; j++) {
        if (firstSegment === allowedDomains[j]) {
            isDomainAllowed = true;
            break;
        }
    }

    if (!isDomainAllowed && firstSegment !== "") {
        context.setVariable("security.threat.detected", "INVALID_DOMAIN");
        context.setVariable("security.threat.path", pathSuffix);
        context.setVariable("security.threat.segment", firstSegment);
        context.setVariable("security.threat.ip", clientIp);
        throw new Error("SECURITY: Invalid domain '" + firstSegment + "' not in whitelist");
    }

    // ============================================
    // SECTION 3: SQL INJECTION DETECTION
    // ============================================
    var sqlPatterns = [
        /(\bOR\b|\bAND\b)\s+[\w\d]+\s*=\s*[\w\d]+/i,
        /UNION\s+(ALL\s+)?SELECT/i,
        /DROP\s+(TABLE|DATABASE)/i,
        /INSERT\s+INTO/i,
        /DELETE\s+FROM/i,
        /UPDATE\s+\w+\s+SET/i,
        /--/,
        /\/\*/,
        /;\s*DROP/i,
        /xp_cmdshell/i,
        /exec(\s|\+)+(s|x)p\w+/i
    ];

    var fullUrl = pathSuffix + (queryString ? "?" + queryString : "");

    for (var k = 0; k < sqlPatterns.length; k++) {
        if (sqlPatterns[k].test(fullUrl)) {
            context.setVariable("security.threat.detected", "SQL_INJECTION");
            context.setVariable("security.threat.pattern", sqlPatterns[k].toString());
            context.setVariable("security.threat.url", fullUrl);
            context.setVariable("security.threat.ip", clientIp);
            throw new Error("SECURITY: SQL Injection attempt detected");
        }
    }

    // ============================================
    // SECTION 4: XSS PROTECTION
    // ============================================
    var xssPatterns = [
        /<script[\s\S]*?>/i,
        /javascript&colon;/i,
        /onerror\s*=/i,
        /onload\s*=/i,
        /onclick\s*=/i,
        /<iframe[\s\S]*?>/i,
        /<embed[\s\S]*?>/i,
        /<object[\s\S]*?>/i,
        /eval\s*\(/i,
        /expression\s*\(/i,
        /vbscript&colon;/i,
        /<img[\s\S]*?onerror/i
    ];

    for (var m = 0; m < xssPatterns.length; m++) {
        if (xssPatterns[m].test(fullUrl)) {
            context.setVariable("security.threat.detected", "XSS_ATTEMPT");
            context.setVariable("security.threat.pattern", xssPatterns[m].toString());
            context.setVariable("security.threat.url", fullUrl);
            context.setVariable("security.threat.ip", clientIp);
            throw new Error("SECURITY: XSS attempt detected");
        }
    }

    // ============================================
    // SECTION 5: COMMAND INJECTION PROTECTION
    // ============================================
    var commandInjectionPatterns = [
        /;\s*cat\s+/i,
        /\|\s*ls\s+/i,
        /`.*`/,
        /\$\(.*\)/,
        /&&/,
        /\|\|/,
        />\s*\/dev\/null/i,
        /curl\s+/i,
        /wget\s+/i,
        /nc\s+/i
    ];

    for (var n = 0; n < commandInjectionPatterns.length; n++) {
        if (commandInjectionPatterns[n].test(fullUrl)) {
            context.setVariable("security.threat.detected", "COMMAND_INJECTION");
            context.setVariable("security.threat.pattern", commandInjectionPatterns[n].toString());
            context.setVariable("security.threat.url", fullUrl);
            context.setVariable("security.threat.ip", clientIp);
            throw new Error("SECURITY: Command Injection attempt detected");
        }
    }

    // ============================================
    // SECTION 6: HEADER VALIDATION
    // ============================================
    if (!userAgent || userAgent.length < 5) {
        context.setVariable("security.threat.detected", "MISSING_USER_AGENT");
        context.setVariable("security.threat.ip", clientIp);
        throw new Error("SECURITY: Invalid or missing User-Agent header");
    }

    if ((method === "POST" || method === "PUT")) {
        if (!contentType || contentType.length === 0) {
            context.setVariable("security.threat.detected", "MISSING_CONTENT_TYPE");
            context.setVariable("security.threat.method", method);
            context.setVariable("security.threat.ip", clientIp);
            throw new Error("SECURITY: Missing Content-Type header for " + method + " request");
        }
    }

    var suspiciousUAPatterns = [
        /sqlmap/i, /nikto/i, /nmap/i, /masscan/i, /acunetix/i,
        /nessus/i, /burpsuite/i, /metasploit/i, /havij/i
    ];

    for (var p = 0; p < suspiciousUAPatterns.length; p++) {
        if (suspiciousUAPatterns[p].test(userAgent)) {
            context.setVariable("security.threat.detected", "SUSPICIOUS_USER_AGENT");
            context.setVariable("security.threat.user_agent", userAgent);
            context.setVariable("security.threat.ip", clientIp);
            throw new Error("SECURITY: Suspicious User-Agent detected");
        }
    }

    // ============================================
    // SECTION 7: PATH LENGTH VALIDATION
    // ============================================
    var maxPathLength = 2048;

    if (pathSuffix.length > maxPathLength) {
        context.setVariable("security.threat.detected", "PATH_TOO_LONG");
        context.setVariable("security.threat.path_length", pathSuffix.length.toString());
        context.setVariable("security.threat.ip", clientIp);
        throw new Error("SECURITY: Path length exceeds maximum allowed (" + maxPathLength + " chars)");
    }

    // ============================================
    // SECTION 8: SUSPICIOUS PATTERNS
    // ============================================
    var suspiciousPatterns = [
        /admin/i, /config/i, /\.xml$/i, /\.json$/i, /\.env$/i,
        /\.git/i, /\.svn/i, /backup/i, /phpinfo/i, /test/i, /debug/i
    ];

    for (var q = 0; q < suspiciousPatterns.length; q++) {
        if (suspiciousPatterns[q].test(pathSuffix)) {
            context.setVariable("security.threat.detected", "SUSPICIOUS_PATH");
            context.setVariable("security.threat.pattern", suspiciousPatterns[q].toString());
            context.setVariable("security.threat.path", pathSuffix);
            context.setVariable("security.threat.ip", clientIp);
            throw new Error("SECURITY: Suspicious path pattern detected");
        }
    }

    // ============================================
    // SECTION 9: SUCCESS
    // ============================================
    context.setVariable("security.validated", "true");
    context.setVariable("security.validated.timestamp", Date.now().toString());
    context.setVariable("security.status", "PASSED");
    context.setVariable("security.domain", firstSegment);
    context.setVariable("custom.security.status", "PASSED");
    context.setVariable("custom.security.domain", firstSegment);

} catch (error) {
    // ============================================
    // SECURITY THREAT DETECTED
    // ============================================
    context.setVariable("security.failed", "true");
    context.setVariable("security.error", error.message);
    context.setVariable("security.raise.fault", "true");
    context.setVariable("custom.security.status", "BLOCKED");
    context.setVariable("custom.security.threat",
        context.getVariable("security.threat.detected") || "UNKNOWN");
    context.setVariable("custom.security.path", pathSuffix);
    context.setVariable("custom.security.ip", clientIp);
    context.setVariable("custom.security.method", method);
    context.setVariable("custom.security.user_agent", userAgent);
}

/** * ============================================ * DCRP SECURITY SHIELD v1.0 * ============================================ * PURPOSE: Protect /** catch-all route from malicious requests * AUTHOR: Ricardo Viana * RUNS: BEFORE JS-Routing in Proxy PreFlow * * FEATURES: * - Path Traversal Protection * - SQL Injection Detection * - XSS Protection * - Domain Whitelist Enforcement * - Header Validation * - Bot Protection * ============================================ */ try { // ============================================ // CONTEXT EXTRACTION // ============================================ var pathSuffix = context.getVariable("proxy.pathsuffix") || ""; var queryString = context.getVariable("request.querystring") || ""; var userAgent = context.getVariable("request.header.User-Agent") || ""; var contentType = context.getVariable("request.header.Content-Type") || ""; var method = context.getVariable("request.verb") || ""; var clientIp = context.getVariable("client.ip") || ""; // ============================================ // SECTION 1: PATH TRAVERSAL PROTECTION // ============================================ var pathTraversalPatterns = [ /\.\./, // ../ /%2e%2e/i, // URL-encoded .. /%252e/i, // Double URL-encoded . /\.\\/, // .\ (Windows path) /%5c/i, // URL-encoded backslash /\/\//, // Double slashes /etc\/passwd/i, // Linux system files /windows\/system/i, // Windows system paths /proc\/self/i, // Linux proc filesystem /\.\.%2f/i, // Mixed encoding /\.\.;/i // Semicolon bypass attempt ]; for (var i = 0; i < pathTraversalPatterns.length; i++) { if (pathTraversalPatterns[i].test(pathSuffix)) { context.setVariable("security.threat.detected", "PATH_TRAVERSAL"); context.setVariable("security.threat.pattern", pathTraversalPatterns[i].toString()); context.setVariable("security.threat.path", pathSuffix); context.setVariable("security.threat.ip", clientIp); throw new Error("SECURITY: Path Traversal attempt detected"); } } // ============================================ // SECTION 2: DOMAIN WHITELIST VALIDATION // ============================================ var allowedDomains = [ "sales", "orders", "customers", "invoices", "prices", "quotations", "finance", "accounts", "journals", "payments", "reconciliations", "reports", "closings", "taxes", "budgets", "logistics", "shipments", "inventory", "deliveries", "warehouses", "tracking", "carriers", "returns", "pickpack", "procurement", "requisitions", "suppliers", "contracts", "buyers", "approvals", "receipts", "catalogs" ]; var segments = pathSuffix.split("/").filter(function(s) { return s.length > 0; }); var firstSegment = segments.length > 0 ? segments[0].toLowerCase() : ""; var isDomainAllowed = false; for (var j = 0; j < allowedDomains.length; j++) { if (firstSegment === allowedDomains[j]) { isDomainAllowed = true; break; } } if (!isDomainAllowed && firstSegment !== "") { context.setVariable("security.threat.detected", "INVALID_DOMAIN"); context.setVariable("security.threat.path", pathSuffix); context.setVariable("security.threat.segment", firstSegment); context.setVariable("security.threat.ip", clientIp); throw new Error("SECURITY: Invalid domain '" + firstSegment + "' not in whitelist"); } // ============================================ // SECTION 3: SQL INJECTION DETECTION // ============================================ var sqlPatterns = [ /(\bOR\b|\bAND\b)\s+[\w\d]+\s*=\s*[\w\d]+/i, /UNION\s+(ALL\s+)?SELECT/i, /DROP\s+(TABLE|DATABASE)/i, /INSERT\s+INTO/i, /DELETE\s+FROM/i, /UPDATE\s+\w+\s+SET/i, /--/, /\/\*/, /;\s*DROP/i, /xp_cmdshell/i, /exec(\s|\+)+(s|x)p\w+/i ]; var fullUrl = pathSuffix + (queryString ? "?" + queryString : ""); for (var k = 0; k < sqlPatterns.length; k++) { if (sqlPatterns[k].test(fullUrl)) { context.setVariable("security.threat.detected", "SQL_INJECTION"); context.setVariable("security.threat.pattern", sqlPatterns[k].toString()); context.setVariable("security.threat.url", fullUrl); context.setVariable("security.threat.ip", clientIp); throw new Error("SECURITY: SQL Injection attempt detected"); } } // ============================================ // SECTION 4: XSS PROTECTION // ============================================ var xssPatterns = [ /<script[\s\S]*?>/i, /javascript&colon;/i, /onerror\s*=/i, /onload\s*=/i, /onclick\s*=/i, /<iframe[\s\S]*?>/i, /<embed[\s\S]*?>/i, /<object[\s\S]*?>/i, /eval\s*$/i, /expression\s*\(/i, /vbscript&colon;/i, /<img[\s\S]*?onerror/i ]; for (var m = 0; m < xssPatterns.length; m++) { if (xssPatterns[m].test(fullUrl)) { context.setVariable("security.threat.detected", "XSS_ATTEMPT"); context.setVariable("security.threat.pattern", xssPatterns[m].toString()); context.setVariable("security.threat.url", fullUrl); context.setVariable("security.threat.ip", clientIp); throw new Error("SECURITY: XSS attempt detected"); } } // ============================================ // SECTION 5: COMMAND INJECTION PROTECTION // ============================================ var commandInjectionPatterns = [ /;\s*cat\s+/i, /\|\s*ls\s+/i, /`.*`/, /\$\(.*$/, /&&/, /\|\|/, />\s*\/dev\/null/i, /curl\s+/i, /wget\s+/i, /nc\s+/i ]; for (var n = 0; n < commandInjectionPatterns.length; n++) { if (commandInjectionPatterns[n].test(fullUrl)) { context.setVariable("security.threat.detected", "COMMAND_INJECTION"); context.setVariable("security.threat.pattern", commandInjectionPatterns[n].toString()); context.setVariable("security.threat.url", fullUrl); context.setVariable("security.threat.ip", clientIp); throw new Error("SECURITY: Command Injection attempt detected"); } } // ============================================ // SECTION 6: HEADER VALIDATION // ============================================ if (!userAgent || userAgent.length < 5) { context.setVariable("security.threat.detected", "MISSING_USER_AGENT"); context.setVariable("security.threat.ip", clientIp); throw new Error("SECURITY: Invalid or missing User-Agent header"); } if ((method === "POST" || method === "PUT")) { if (!contentType || contentType.length === 0) { context.setVariable("security.threat.detected", "MISSING_CONTENT_TYPE"); context.setVariable("security.threat.method", method); context.setVariable("security.threat.ip", clientIp); throw new Error("SECURITY: Missing Content-Type header for " + method + " request"); } } var suspiciousUAPatterns = [ /sqlmap/i, /nikto/i, /nmap/i, /masscan/i, /acunetix/i, /nessus/i, /burpsuite/i, /metasploit/i, /havij/i ]; for (var p = 0; p < suspiciousUAPatterns.length; p++) { if (suspiciousUAPatterns[p].test(userAgent)) { context.setVariable("security.threat.detected", "SUSPICIOUS_USER_AGENT"); context.setVariable("security.threat.user_agent", userAgent); context.setVariable("security.threat.ip", clientIp); throw new Error("SECURITY: Suspicious User-Agent detected"); } } // ============================================ // SECTION 7: PATH LENGTH VALIDATION // ============================================ var maxPathLength = 2048; if (pathSuffix.length > maxPathLength) { context.setVariable("security.threat.detected", "PATH_TOO_LONG"); context.setVariable("security.threat.path_length", pathSuffix.length.toString()); context.setVariable("security.threat.ip", clientIp); throw new Error("SECURITY: Path length exceeds maximum allowed (" + maxPathLength + " chars)"); } // ============================================ // SECTION 8: SUSPICIOUS PATTERNS // ============================================ var suspiciousPatterns = [ /admin/i, /config/i, /\.xml$/i, /\.json$/i, /\.env$/i, /\.git/i, /\.svn/i, /backup/i, /phpinfo/i, /test/i, /debug/i ]; for (var q = 0; q < suspiciousPatterns.length; q++) { if (suspiciousPatterns[q].test(pathSuffix)) { context.setVariable("security.threat.detected", "SUSPICIOUS_PATH"); context.setVariable("security.threat.pattern", suspiciousPatterns[q].toString()); context.setVariable("security.threat.path", pathSuffix); context.setVariable("security.threat.ip", clientIp); throw new Error("SECURITY: Suspicious path pattern detected"); } } // ============================================ // SECTION 9: SUCCESS // ============================================ context.setVariable("security.validated", "true"); context.setVariable("security.validated.timestamp", Date.now().toString()); context.setVariable("security.status", "PASSED"); context.setVariable("security.domain", firstSegment); context.setVariable("custom.security.status", "PASSED"); context.setVariable("custom.security.domain", firstSegment); } catch (error) { // ============================================ // SECURITY THREAT DETECTED // ============================================ context.setVariable("security.failed", "true"); context.setVariable("security.error", error.message); context.setVariable("security.raise.fault", "true"); context.setVariable("custom.security.status", "BLOCKED"); context.setVariable("custom.security.threat", context.getVariable("security.threat.detected") || "UNKNOWN"); context.setVariable("custom.security.path", pathSuffix); context.setVariable("custom.security.ip", clientIp); context.setVariable("custom.security.method", method); context.setVariable("custom.security.user_agent", userAgent); }

When to Use Each Approach

Use Approach 1 (Manual) when:

Domain has <5 paths and rarely changes
Team prefers explicit routing rules for visibility
Legacy environment with existing path-based architecture

Use Approach 2 (Dynamic) when:

Domain has >5 paths OR frequent changes expected
Enterprise scale with multiple regional deployments
Need maximum deployment velocity (30s per new path)

Comparison Table

Feature Approach 1 (Manual) Approach 2 (Dynamic)

Routing Rule	N rules (1 per path)	1 catch-all (`/**`)
cpi.basepath	Fixed per rule	Comma-delimited string
JavaScript	Matches KVM only	Extracts segment + matches KVM
Security	Rule-based	Whitelist validation required
Time per new path	~2 min (add rule)	~30 sec (update string)
Best for	<5 paths, stable	Enterprise, high-change

ROI Calculation (Approach 2)

Scaling 4 domains with 8 paths each:

Approach 1 (Manual):
4 domains × 8 paths × 2 min = 64 minutes

Approach 2 (Dynamic):
4 domains × 1 setup (2 min) + 32 paths × 30 sec = 8 min + 16 min = 24 minutes

Savings: 40 minutes (62% faster)

Figure 26 - Scaling Strategies: Manual vs Dynamic Multi-Path Routing

6 - API Contracts, Versioning & Openapi Management

Why DCRP Proxies Don't Need Versioning

In traditional API management, versioning is a primary driver of Infrastructure Sprawl. Every new version typically spawns a new proxy (e.g., v1-api, v2-api), forcing architects to manage multiple redundant infrastructures.

DCRP eliminates this proliferation by recognizing that the proxy is a stateless router with an immutable base path, not the owner of the API contract.

Fixed Entry Point:

The proxy base path remains constant (e.g., /sales/orders/**).
Versioned Routing: API versions live in the path suffix (e.g., /v1/, /v2/).
Decoupled Logic: These versions are mapped to specific iFlows via KVM metadata, keeping the proxy itself singular and unchanged.

Figure 27 - Contracts & Governance

Step Traditional 1:1 Proxy Model DCRP Model

Action Create new proxy, configure security, routing, and targets, then redeploy.
Deploy new iFlow and update a single KVM metadata entry.
Time Effort ~15 minutes ~30 seconds
Outcome Managing 4 separate proxy infrastructures. Still managing 1 proxy infrastructure.

Client Interaction Examples:

Legacy: POST /sales/orders/v1/inbound → Routes to v1 iFlow.
Current: POST /sales/orders/v2/inbound → Routes to v2 iFlow.
New: POST /sales/orders/v4/inbound → Routes to v4 iFlow.
Latest (Default): POST /sales/orders/inbound → Dynamically routes to v4 via KVM.

The proxy base path /sales/orders/** never changed., providing a stable, governed interface for consumers regardless of backend evolution.

6.1 - OpenAPI Management: The Hybrid Approach

In the DCRP model, API contracts (OpenAPI specifications) are decoupled from both the proxy and the iFlow, residing in a central API Portal or repository. This hybrid model ensures a clean separation of concerns:

KVM: Stores runtime routing metadata (path → endpoint).

OpenAPI: Stores design-time contract metadata (request/response schemas).

API Portal: Provides discovery, documentation, and governance.

The Execution Flow:
When a developer needs to integrate, they download the spec (e.g., sales-orders-v2.yaml) from the Portal and generate their client code. When they call the DCRP proxy at /sales/orders/v2, the proxy consults the KVM and routes the request to the corresponding v2 iFlow.

Figure 28 - Template prespective

6.2 - KVM vs OpenAPI: Complementary, Not Redundant

At first glance, KVM and OpenAPI might seem to overlap. Both describe APIs. But they serve distinct purposes:

KVM answers: "Where should I route this request?"

Input: /sales/orders/v2
Output:
OpenAPI answers: "What schema should this request/response have?"

Input: POST /sales/orders/v2
Output: Request body must include {orderId, customerId, items[]}, returns {status, orderNumber}

Both are necessary for complete governance:

Without KVM: No dynamic routing (back to static proxy-per-integration)
Without OpenAPI: No contract validation (clients and servers drift out of sync)

DCRP uses KVM for runtime routing decisions and OpenAPI for design-time contract definition and optional runtime validation.

Figure 29 - Complementary - DCRP and OpenAPI

7 - Statistics Collector – Capturing Business Intelligence

While the JavaScript "Brain" handles routing, the Statistics Collector provides the visibility necessary for production management. This policy captures technical metadata and transforms it into actionable business intelligence within the SAP API Management analytics database.

Purpose: Records routing metadata such as iFlow name, package name, domain process, and tracking IDs.

Utility: Enables real-time monitoring, trend analysis, and data-driven capacity planning.

Policy Configuration Snippet:

<StatisticsCollector async='false' continueOnError='false' enabled='true'>
	<Statistics>
		<Statistic name='custom_idcorrelation' ref='idcorrelation' type='string'>0</Statistic>
		<Statistic name='custom_idflow' ref='idiflow' type='string'>0</Statistic>
		<Statistic name='custom_idpackage' ref='idpackage' type='string'>0</Statistic>
		<Statistic name='custom_idsapprocess' ref='idsapprocess' type='string'>0</Statistic>
		<Statistic name='custom_idsender' ref='idsender' type='string'>0</Statistic>
	</Statistics>
</StatisticsCollector>

8 - Troubleshooting: Common Issues & Solutions

8.1 - Runtime Errors

404 Not Found

Cause: KVM iflowname delimiter mismatch
Fix: Verify iflowname uses : separator (e.g., inbound:SO.01...)

500 Internal Server Error

Cause: Missing KVM entry or wrong mapIdentifier
Fix: Check KVM map exists: cpipackage-nx.[domain].[subprocess]

403 Forbidden (Valid Request)

Cause: Domain not in Security Shield whitelist
Fix: Add domain to allowedDomains[] in JS-Security-Shield.js

Gateway Timeout

Cause: Wrong cpi.host or cpi.basepath
Fix: Verify Target Endpoint properties, test CPI endpoint directly

8.2 - Configuration Issues

KVM Lookup Returns Null

Fix: Deploy KVM to same environment as API Proxy (both dev or both prod)

JavaScript Execution Error

Fix: Add error handling: var x = context.getVariable("y") || "default";

Routing Rule Doesn't Match

Fix: Change to MatchesPath "/**" for dynamic routing (Approach 2)

Statistics Collector Not Logging

Fix: Match variable names exactly in <Statistic ref='idiflow' />

8.3 - Security Shield Issues

All Requests Blocked (403)

Fix: Verify allowedDomains = ["sales", "finance"] (lowercase)

SQL Injection False Positive

Fix: Refine regex to exclude valid patterns (e.g., hyphens in IDs)

8.4 - Performance Issues

High Latency (>80ms)

Cause: JavaScript overhead or network latency to CPI
Fix: Profile with APIM trace logs, check network latency

Note: Detailed performance benchmarking with 30,000+ messages will be covered in Part III : Monitoring & Governance.

Gateway Timeout (504)

Cause: Slow CPI iFlow
Fix: Increase timeout in Target Endpoint, optimize iFlow

8.6 - When to Escalate

Escalate to SAP Support if:

Issue reproducible in isolated test proxy
KVM API returns 500 errors despite correct configuration

Collect before opening ticket: Proxy bundle, KVM config, trace logs, network capture.

Conclusion: Discipline Over Chaos

The Domain-Centric Routing Pattern provides the governance layerSAP API Management needs but doesn't offer out-of-the-box.

Benefits Recap:

Infrastructure:
- 96% reduction in proxies (20 → 4)
- Deployment: 15 min → 30 seconds - KVM
- Template-driven: 4× faster at scale

Governance:
- Centralized security policies
- Unified analytics per domain
- End-to-end traceability (SAP ALM ready)

Business Impact:
- Faster time-to-market for new integrations
- Reduced operational overhead
- Future-proof: Consumer contracts unchanged during backend migrations

The Roadmap Ahead

This is only the first step in mastering enterprise-scale integration:

Part I: DCRP – Domain-Centric Routing Pattern (Gateway Layer)
✅ YOU ARE HERE
Part II: PDCP – Package-Domain-Centric Pattern (Orchestration Layer)
Solving CPI Package and User Sprawl | Domain consolidation + iFlow DNA naming + tiered technical users
🔗 [ Part II]
Part III: DCRP + PDCP Implementation & Testing
Hands-on guide | JavaScript v8.0 routing engine | Multi-vendor disambiguation | Conflict resolution (id09/id10) | Postman collections | Production deployment | GitHub repository with full source code - ⏳ COMING SOON
Part IV: End-to-End Monitoring with SAP Cloud ALM
DCRP + PDCP integration with SAP Cloud ALM | MPL filtering via X-IFlow-Id headers | Automated dashboards | Real-time alerting & SLA tracking | Performance analytics - ⏳ COMING SOON

Figure 30 - Implementing DCRP transforms your gateway into ascalable, semantic, governed ecosystem

Before You Scale: Pre-Flight Checklist

✅Team Alignment: Ensure developers understand 1:1 → domain-centric shift
✅Stakeholder Education: Business sponsors grasp consolidation benefits
✅Establish Governance: Define KVM update approval workflows
✅Enforce Standards: Naming convention
✅Sandbox PoC: Validate with 2-3 iFlows before production rollout

This is only the first step in mastering enterprise-scale integration.

📚How to Reference This Work

When referencing or building upon these architectural patterns, please use the following formal citations:

DCRP (Domain-Centric Routing Pattern), introduced by Ricardo Luz Holanda Viana, 2026.
PDCP (Package Domain-Centric Pattern), introduced by Ricardo Luz Holanda Viana, 2026.

🛡️ Intellectual Property & Copyright Notice

Legal Notice:
The public disclosure of the architectural patterns described herein constitutes prior art (state of the art) within the global intellectual property framework. This publication establishes documented evidence of authorship and original contribution as of the stated publication date.

📜Usage Terms

✅Free to use for educational, research, and non-commercial purposes
✅Attribution required when referencing or building upon these architectural patterns
✅Commercial implementations are permitted, provided proper attribution is given
⚠️Use of the names “DCRP™” or “PDCP™” in commercial branding, offerings, or marketing materials requires prior written licensing from the author

This restriction applies solely to the use of the names and trademarks, not to independent implementations of similar architectural concepts.

No Implied License:
Nothing in this publication shall be construed as granting any license, implied or otherwise, to use the described methodologies as branded commercial products or services without explicit authorization.

Disclaimer: This article reflects the author’s personal architectural perspective and does not represent an official SAP position or recommendation.

Kind Regards,

Viana | SAP BTP Integration Suite Expert

Integration Suite in 2025 & 2026

2026-02-03T18:16:06.981000+01:00

Watched this beautiful session by @UdoPaltzer: https://www.youtube.com/watch?v=kFynsigf99o

In case you wanted a quick summary, here you go:

Modernize Integrations:

Use standard content as much as you can
Try to replace your RFCs and IDOCs with OData, Rest, and SOAP.
Leverage Event-driven Integration pattern (for real-time scenarios)
Use Side-by-side extensions to leverage API-centric integrations (with Build)
Leverage monitoring and error resolution capabilities by using SAP AIF (for Business Users), and Cloud ALM (for technical users)

End of maintenance. Time is ticking!

2027 - SAP PO | Standard Maintenance sunset
2030 - SAP PO | Extended maintenance sunset
2028 - Cloud Platform Integration Neo | Services sunset

As far as your migration support is concerned, SAP provides Migration guides, documentation, and community content, which you are already aware of. What is additionally provided is:

SAP Migration Factory | a free 2-3 weeks program to help you assess and plan your migration from PI/PO to Integration Suite
Evolve Neo Program | free access to SAP experts who will help you plan and prepare your migration to Cloud Foundry
SAP Service and Support | quick migration assistance with short duration, low cost engagements

Edge Integration Cell

The latest kid in the block is now flexible to run hybrid integration runtime, which is offered as an optional extension to Integration Suite, which will help customer-managed private landscape to leverage the capabilities of Integration Suite.
The landscapes it supports are: Microsoft AKS, Amazon EKS, Red Hat OpenShift, SUSE Rancher, Google GKE.

Cloud ALM

Your one stop for end-to-end technical health monitoring for: SAP BTP, S/4HANA, S/4HANA Cloud, SuccessFactors, Integration Suite, Customer Experience, Business Network, Concur, Fieldglass.
You can configure the Oubound Channels like: email alerts, on chat-based apps like MS Teams/ Slack, Ticketing System like Service Now, Tasks like JIRA, APIs like SAP Analytics Cloud/ Grafana, and Operation Automations like Build Process Automation, and SAP iRPA, etc.
For us Integration Suite guys, you can use it for Cloud Integratio, API Management and Event Mesh as well.
Specifically for Integration Suite, you can now monitor Tenant Availability, Certificate Validity, Database and Resource consumption, Content, Exhaustion status of JMS queue. So, no more building custom iflows to trigger alerts. Please know that CALM pulls data every 5 mins, and persists data for 30 days. I wonder if they have a feature to display the trace only for failed messages. SAP, are you listening?

Innovations in 2025

Artificial Intelligence
- Joule copilot-based discovery and reuse of artifacts were made available in Business Accelerator Hub
- Generation of Integration flow steps
- Groovy script optimization
- API anomaly detection
- API traffic prediction for usage and trend
- AI adapter
Business Accelerators
- Additional non-SAP adaptors like, AI, Google, BigQuery, IBM MQ (JMS), BigQuery, Microsoft Azure Service Bus, Microsoft OneNote, Mongo DB, Salesforce Pub/ Sub, Shopify, etc
- New design guidelines to ensure upgrade readiness of Groovy Scripts (Camel 3 to Camel 4)
Migration & Modernization
- Generate ABAP proxy in the backend without any dependency on PI
- Edge Integration Cell: Local OData API access, HANA DB, Shared Kubernetes, Basis Authentication during offline mode
- Alerting of failed B2B messages in CALM
- Automatic B2B interface creation based on Payload
API-centric & Event-driven integration
- Lightweight adapter in the context of Advanced Event Mesh for small, light-weight, event-driven integration with non-SAP applications
- Migration support from EM to AEM

Agent-ready Application: IPaaS & AI Market Evolution & Trends

Agent iPaaS
Agent Integrations
Agent Orchestration
AI TRiSm (trusted relationship governance of the AI agents

SAP Integration Suite to become the trusted AI Integration Fabric: IS is evolving to become a trusted AI Integration fabric

Some of the use cases are:

Integration for AI (to make agentic interactions & orchestration to make applications agent-ready)

MCP Gateway
Agent Orchestration
AI Gateway
Agent Identity Verification
LLM connector

AI for Integration (features in IS)

Joule
Anomaly detection
API traffic predictions
Script Optimization
Configuration Agent

2026 SAP Integration Suite Strategic Outlook:

Leveraging Joule for building Integration flows
MCP enablement for APIs
Migration Agents for Java Mappings & adapter modules
AEM events in developer hub
15+ new third-party adapters including Adobe Sign, Google Suite, Oracle, OFTP2, Salesforce Service & Marketing, Cloud, Oracle Eloqua
Joule Skills & AI Agents in SAP Business Accelerator Hub
B2B capabilities in Edge Integration Cell

Roadmap for SAP Integration Suite:

Artificial Intelligence
- Integration flow design validation
- Joule based generation of iflows
- MCP for agentic AI
- Migration agent for adapter modules, Java mapping
- Configuration Agent
- Payload-size anomaly detection
Business Accelerators
- More connectivity options, meaning, more adapters like Google Drive & Sheets Microsoft Excel & Outlook, OFTP2, RosettaNet, Salesforce Service Cloud, etc
- Support for publications of Joule Skills & Agents in Business Accelerator Hub
- Commercial module for Partner Content. Consumers/Customers with a licence to Partner Content can now use it. Currently, customers can copy and use it for free, but from now on, the IP rights are protected, so you can use it only if you have a licence.
Migration & Modernization
- Mass migration from PO to IS
- Edge Integration Cell: customer-managed cloud connectors, offline mode support for 48 hours, B2B capabilities, multiple instances of EIC per Kubernetes Cluster
- SAP IS data centers in Australia, Germany, India, Japan, US.
API-Centric & Event-driven integrations
- AEM health monitoring in SAP Cloud ALM
- Auto discovery and publications of events from AEM to Developer Hub as single catalog for APIs and Events
- Consumption of events through Developer Hub

When Synchronous OData Failed for bulk data processing: How I Solved Problem Using OData V4 Async :

2026-02-09T07:33:18.454000+01:00

The Business Context:

BlueYonder sends planning and operational data
The data volume is large
Data needs to be posted into SAP S/4HANA Public Cloud
SAP exposes this functionality via OData V2 and V4 APIs

The expectation was simple: “Send data from BlueYonder and create/update records in S/4HANA.” But in reality, it was not that easy.

Introduction:

In real projects, integrations look simple on paper but behave very differently in production.

This blog is about a real-time problem I faced while integrating BlueYonder planning data into SAP S/4HANA Public Cloud using OData V2 Inbound.

The solution was understanding how OData V4 async processing works and using one small but powerful HTTP header.

In this blog, I will explain:

What problem I faced
Why synchronous processing failed
How I implemented async OData V4 processing with API proxy(through URL).
What changed after enabling async

The Actual Problem

Initially, I implemented the integration in a synchronous way.

What Happened

CPI sent data to S/4HANA public cloud using standard OData V2 synchronous Api
The backend took time to process the payload
CPI waited for the response
Requests started failing due to:

Timeouts
Long-running backend processing
Unstable behaviour during peak loads

The Key Issue

OData V2 APIs are synchronous by default. This means:

CPI waits until S/4HANA public cloud finishes posting
Large payloads increase risk
One slow request can block the entire flow This was not acceptable for a production-grade integration.
Chunking the payload using General splitter and streaming could increase the number of API Calls and may increase the load on Public cloud.

Design:

While analysing SAP documentation, I came across the asynchronous processing capability of OData V4. SAP provides a standard way to tell the backend: “Accept the request, process it in the background, and do not keep the connection open.”
This is done using the HTTP header: Prefer = respond-async

Step-by-Step Implementation :

Step 1: Receiving HighRadiusData in CPI

BlueYonder sends data in Flatten File.
CPI receives the data and prepares it for S/4HANA public cloud.

Data structure is aligned to OData V4 expectations At this point, the flow is still normal.

*Here I had implemented the Retry mechanism using JMS Queues which is the best practice for the SAP integrations ,If you like you implement it do check out my previous Blog that I had posted in the SAP Community.
Blog URL – {https://community.sap.com/t5/technology-blog-posts-by-members/handling-connectivity-and-recoverable-errors-in-sap-cpi-with-jms-queues/ba-p/14137974}

Step 2: Setting the Async Header (Most Important Step)

In CPI, I used a Content Modifier to add HTTP headers.

Header : Prefer Header Prefer = respond-async This header completely changes how the request is handled.

What Happens After Adding respond-async

Once this header is added:

CPI sends the request
S/4HANA immediately responds with HTTP 202 – Accepted
Backend processing continues asynchronously
CPI does not wait for the final processing result This single header removed timeout risks completely.

Step 3: Posting Data via API Proxy

* Here, I had used OAuth 2.0 Authentication between Integration suite to API Proxy and between API Proxy and S/4 Hana public cloud I had used Certificate Based Authentication.

CPI sends the request to an API Proxy
The proxy forwards the call to the OData V4 API from SAP Business Accelerator Hub
The proxy is created using the URL-based option

Note : OData V4 services do not appear in the API Provider’s service catalog in SAP API Management, so discovery isn’t possible — and that’s why I go with the URL method, so if you want to create proxy for OData V4 public cloud the correct approach is just go with the URL Option don’t fall for this pitfall.

If you want to leverage more on how to create API Proxy with URL option follow SAP Official Documentation.
Official documentation: {https://help.sap.com/docs/sap-api-management/sap-api-management/create-api-proxy-by-providing-direct-target-endpoint-url}

From CPI’s perspective:

The request is completed successfully

No long-running connection is maintained

What Changed After This Implementation
Before Async
- Timeouts during high data volume
- Unstable integration behaviour
- Risk of message failures
After Async
- Immediate response to CPI
- Backend processing happens safely
- No timeout issues
- Integration became stable and predictable
This was a real production-grade improvement, not just a theoretical change, I hope this helps you folks that don’t fall for this pitfall in your production.

Announcement: Register to the new CEI project for SAP Integration Suite in 2026

2026-02-09T08:33:34.010000+01:00

Like in the previous years, we will run a Global Customer Engagement Initiative (CEI) for SAP Integration Suite also in 2026.

Last year, we had 180+ registered customers and partners from over 20 countries worldwide. We ran multiple feedback sessions covering various capabilities and strategic investment topics of SAP Integration Suite such as "SAP Process Orchestration move" (ABAP proxy generation, mass migration, migration assessment, migration agent, etc.), AI & gen AI in the context of SAP Integration Suite in general and for B2B in particular, monitoring and operations, new adapters and adapter enhancements, reusable APIs and governance of API key access, event driven architecture, etc.

In 2026, we will continue collaborating with our customers and partners to gather feedback on product improvements, enhancements and new developments to validate the planned enhancements at an early stage, and ensuring that what we build will meet your business needs.

This will include open discussion about our current product backlog from the roadmap explorer as well as addressing pain points and topics that we collected in last year's CEI project such as more on Edge Integration Cell, AI, SAP PI/PO to SAP Integration Suite migration, Event Driven Architecture, ISA-M, best practices and guidelines, developer experience, etc.

If you like to join the upcoming SAP Integration Suite influence project for providing feedback and shaping the SAP Integration Suite product, please register here (link leads to the customer influence page).

Registration is open from 9th of February 2026 until 13th of March 2026.

Once, the registration closes, we will invite you for an initial call where we go through the scope and the prerequisites of the feedback project. This will be around end of March/ begin of April so that we are able to start the project latest in April this year.

We will run monthly feedback sessions through the end of the year and hold a closing call to summarize our learnings, review the feedback collected, and discuss next steps.

Register today to ensure you do not miss this opportunity to influence and contribute to shaping SAP Integration Suite to meet your business needs.

We look forward to your active participation and valuable feedback.

SAP Community - API Management

Introducing AI-Powered Anomaly Insights & Recommendations in SAP Integration Suite

Part 1: Governance in Developer Hub: Empowering Administrators with Control and Flexibility

Part 2: Setting Up an External Governance Workflow

Part 3: Implementing External Governance in Developer Hub Using SAP Integration Suite and SAP Build

Obtain Credentials from Workflow

Streaming in SAP API Management: Extended Guide

Why Streaming Matters

Key Limits

Properties Explained

Configure via UI (APIM Portal)

Configure via XML (Proxy & Target Definitions)

Proxy Endpoint sample:

Target Endpoint sample:

Error 'Screenshots' (Fault Payloads)

Non-streamed payload exceeds 10 MB:

Streaming enabled but payload-transform policy attached:

Policies: What Works / What to Avoid

Patterns with SAP Cloud Integration (CPI)

Optional: Streaming + gzip + chunked

Troubleshooting

FAQs

Pre-deployment Checklist

Disclaimer

References

Turning SAP BTP Integration Suite as a core ERP module for Business APIs & Business AI

ERP modernization is not enough

Beyond “middleware”: What SAP Integration Suite really is

From Monolith to Modular: Real‑Time, Composable Integration

Preparing for Enterprise AI Agents: Event‑First, API‑First

A Practical PI-PO to Integration Suite Path

Anti‑Patterns to avoid

The takeaway

Call to Action

Asynchronous Logging in SAP API Management

Creating a REST API (web service) in SAP for Web App Consumption.

SAP BTP - IS - How to become a SAP Integration Suite Consultant beyond SAP CPI - SAP APIM Part I

Introduction

Why bother leaving your comfort zone?

The "General" vs. The "Soldier" (A quick story)

Real Talk - "General": My Just Goto Checklist for Migrations

Charting New Responsibilities on the possible migration from external vendors: Who Does What?

Integration Architect

Solution Architect

SAP BTP Integration Suite Consultant

Conclusion — Part I

References to study

References links compilation:

Integration Suite API Management CF custom domain activation via self-service

Introduction

Prerequisites

API Management Service key

APIM virtual host overview

APIM create virtual host (optional)

APIM read virtual hosts - available

APIM create keystore for custom domain

APIM upload keystore for custom domain

APIM activate custom domain

APIM create/update custom domain DNS CNAME

Conclusion

Documentation & Links

SAP Integration Suite: Q4/2025 Feature Highlights

Artificial Intelligence

Connectivity and Adapters

Data Center Availability 🇩🇪 🇮🇹 🇦🇪

Event-driven Integration

B2B Integration

Process Integration

Use SAP Integration Suite to connect SAP and AWS services

Bridging the gap between SAP and 3rd party systems

Use Case Description

Solution Components:

The Use Case Flow:

Learning Outcomes

Getting Started

SAP BTP - APIM - Advanced Domain Routing API-Proxy Pattern for Governing Similar Backend Endpoints

Introduction

Important Note (Read First)

The "Invisible Traffic"

The Strategy - Mapping the iflows with Javascript Policy

Understanding the `iflowname` String