[[{“value”:”
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 the previous blog SAP BTP – APIM – Demystified: Designing a Single API Proxy with Dynamic Routing for Multiple Targets where I explained the way where one API Proxy endpoint can routing the messages for mutiple targets endpoins, in this case Iflows in SAP CPI for one specific package.
I could not present a clear view how to monitoring those messages clearly in the dashboard, so the intention of this blog is present how to create the custom dimension, how to setup the statistic collector policies and the result in the custom dashboard SAP APIM.
However, centralizing traffic often creates a visibility vacuum. This point was raised by @MateuszPiotrowski , I didn’t add in previous blog because was too large already.
Important Note (Read First)
This article does NOT propose:
- A generic multi-domain API
- A proxy that aggregates unrelated services
- A replacement for proper API separation
This pattern applies ONLY when ALL conditions below are true:
- All endpoints belong to the same business domain
- All endpoints represent variants of the same business process
- All CPI iFlows belong to the same CPI package
- The API contract, versioning and lifecycle are shared
- A single team owns the full lifecycle
Outside these constraints, this approach becomes an anti-pattern.
The “Invisible Traffic” – Challenge of Management this API-Proxy Pattern
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 and the Statistics Collector policy, we will “unmask” the Domain Routing Proxy traffic, providing full transparency directly within the SAP APIM Analytics Dashboard.
An API Proxy is not a technical router.It is a business contract boundary.
If multiple endpoints:
- Belong to the same domain
- Share the same semantic meaning
- Represent process variants (not different products)
Then splitting them into multiple proxies adds noise, not clarity, this is where the Domain Routing Proxy (DRP) pattern applies.
The Strategy – Mapping the iflows with Javascript
To solve the “visibility vacuum,” we must capture the iFlow’s identity the moment the request hits the Proxy.
API Domain Routing Proxy – ProxyEndpoint routing:
Figure 1 – Routing based on proxy.pathsuffix MatchesPath “/method*”
What means the routing rule ?
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 3 – “Default endpoint” – and properties host and cpi basepath
Architecture Overview API Domain Routing Proxy
The proxy remains contract-centric, while CPI remains integration-centric.
Consumer
↓
SAP API Management
└── Proxy End-point Pre-Flow
├── Security & Traffic Policies
├── Custom property ProxyEndpoint
└── Target Endpoint Pre-Flow
├── Custom Property TargetEndpoint
├── JavaScript Routing Logic
├── Dynamic target.host / target.path / sendid
├── JavaScript collect data into custom dimension variables
├── Statistic Collector
↓
SAP CPI (Same Package)
├── iFlow MethodPost
├── iFlow MethodGet
├── iFlow MethodPut
└── iFlow MethodDelete
Routing Mechanism (Underused but Native Capability)
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
hostandpath 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.
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);
}
The Real Innovation: Business-Oriented Analytics
Routing is not the innovation.Observability is.
By enriching the proxy with business context variables, SAP APIM Analytics can show:
- Calls per sender system
- Calls per CPI iFlow
- Success vs error rates per process variant
- Traffic distribution across the domain
The API Proxy becomes a business observability layer, not just a gateway.
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 3 – Create the dimension custom to be used in the Policy
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 4 – Those policies should be addded in all targetEndpoint PRE-FLOW
The Result:
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
Sender system identifier:
When This Pattern Is Allowed
Use Domain Routing Proxy only if all apply:
- Same business domain
- Same CPI package
- Same contract & version
- Same lifecycle
- Single ownership
- Need for unified analytics
When NOT to Use This Pattern
Do not use DRP when
- Domains differ (Finance + Logistics)
- Versioning differs
- Ownership differs
- SLAs differ
- Backends are heterogeneous
In those cases, separate proxies are mandatory.
Why This Pattern Is Rarely Documented
This pattern is rarely documented because it sits at the intersection of platform engineering and integration architecture — a space few teams truly operate in.
It requires:
- Deep, hands-on mastery of SAP API Management internals, including policy execution order, variable lifecycle, and advanced debugging practices
- Strong SAP CPI package design and naming discipline to ensure long-term semantic consistency across process variants
- An analytics-first mindset that elevates API Management from a routing gateway to a business observability layer
- Mature architectural governance capable of enforcing domain ownership, lifecycle alignment, and controlled deviation from standard patterns
Most implementations stop at proxy-per-backend, never reaching this level of semantic design.
Conclusion:
The Domain Routing Proxy moves beyond URL-based routing and acts as a centralized observability layer.
The single API Proxy endpoint, teams gain consolidated visibility into CPI iFlow executions, traffic patterns, and error behavior, all through one unified SAP API Management dashboard.
Kind regards,
Viana
“}]]
#abap