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 or Multiple backend ODATA API / SOAP API 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 APIA proxy that aggregates unrelated servicesA replacement for proper API separation
This pattern applies ONLY when ALL conditions below are true:
All endpoints belong to the same business domainAll endpoints represent variants of the same business processAll CPI iFlows belong to the same CPI packageThe API contract, versioning and lifecycle are sharedA 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 or Backend API services, splittled by diferent (iFlows) following the same pattern of endpoint or backend Odata or Soap API’s, 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 domainShare the same semantic meaningRepresent 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 2 – “Default endpoint” – and properties host and cpi basepath
Samples of URL calls:
Those URL’s is exposed to the consumer side, as you can see there is no SAP CPI path on it.
https://<apimaddress>/megaproxy/v1/methoddeletehttps://<apimaddress>/megaproxy/v1/methodposthttps://<apimaddress>/megaproxy/v1/methodputhttps://<apimaddress>/megaproxy/v1/methodget
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.pathsuffixcustom properties in ProxyEndpoint and TargetEndpointConditional flowsJavaScript policiesDynamic target resolution
Instead of creating multiple target endpoints, the proxy uses:
A single targetDynamic host and path via propertiesRouting 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);
}
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();
If you analises this somehow procude another security layer, because the APIM contains the whole https path, the consumer only one part.
Urls expose to the consumer:
https://<apimaddress>/megaproxy/v1/methoddeletehttps://<apimaddress>/megaproxy/v1/methodposthttps://<apimaddress>/megaproxy/v1/methodputhttps://<apimaddress>/megaproxy/v1/methodget
Url’s generate inside the API PROXY:
https://<apimaddress>/megaproxy/v1/http/cpi/methoddeletehttps://<apimaddress>/megaproxy/v1/http/cpi/methodposthttps://<apimaddress>/megaproxy/v1/http/cpi/methodputhttps://<apimaddress>/megaproxy/v1/http/cpi/methodget
Test Proposal via postman for methoddelete:
Figure 4 – Postman test of endpoint /methoddelete
Debbug prespective:
Figure 5 – Full debugg process success.
Figure 6 -Debug runtime variables and target.url where the message must be delivered in SAP CPI.
Figure 7 – CPI Monitoring – Iflow.Template.MethodDelete
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 systemCalls per CPI iFlow or another backend system api serviceSuccess vs error rates per process variantTraffic 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);
}
Samples of URL’s
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 8 – Create Custom Dimensions that will be used in Policy Statistic Collector
Figure 9 – 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 10 – Those policies should be added in the last step into the Target Endpoint 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
Image – 11 – Custom Dashboard monitoring SAP APIM
Sender system identifier:
Image 12 – Indentifier of Sender System
Image 13 – Indentifier of Sender System – Coke – and which Iflow endpoint
Image 14 – CPI Iflows
When This Pattern Is Allowed
Use Domain Routing Proxy only if all apply:
Same business domainSame CPI package or Same Odata ou SOAP API from the backendSame contract & versionSame lifecycleSingle ownershipNeed for unified analytics
When NOT to Use This Pattern
Do not use DRP when
Domains differ (Finance + Logistics)Versioning differsOwnership differsSLAs differBackends 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 practicesAn analytics-first mindset that elevates API Management from a routing gateway to a business observability layerMature 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 or Backend API Services ( ODATA, SOAP), traffic patterns, and error behavior, all through one unified SAP API Management dashboard.
Kind regards,
Viana
IntroductionThis 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 or Multiple backend ODATA API / SOAP API 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 APIA proxy that aggregates unrelated servicesA replacement for proper API separationThis pattern applies ONLY when ALL conditions below are true:All endpoints belong to the same business domainAll endpoints represent variants of the same business processAll CPI iFlows belong to the same CPI packageThe API contract, versioning and lifecycle are sharedA single team owns the full lifecycleOutside these constraints, this approach becomes an anti-pattern.The “Invisible Traffic” – Challenge of Management this API-Proxy PatternWhen some business domains over a SAP CPI package or Backend API services, splittled by diferent (iFlows) following the same pattern of endpoint or backend Odata or Soap API’s, 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 domainShare the same semantic meaningRepresent 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 JavascriptTo 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 routingThe 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 endpointsFigure 2 – “Default endpoint” – and properties host and cpi basepathSamples of URL calls:Those URL’s is exposed to the consumer side, as you can see there is no SAP CPI path on it.https://<apimaddress>/megaproxy/v1/methoddeletehttps://<apimaddress>/megaproxy/v1/methodposthttps://<apimaddress>/megaproxy/v1/methodputhttps://<apimaddress>/megaproxy/v1/methodgetArchitecture Overview API Domain Routing ProxyThe 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 MethodDeleteRouting Mechanism (Underused but Native Capability)SAP API Management already provides:proxy.pathsuffixcustom properties in ProxyEndpoint and TargetEndpointConditional flowsJavaScript policiesDynamic target resolutionInstead of creating multiple target endpoints, the proxy uses:A single targetDynamic host and path via propertiesRouting logic based on suffix and contextThis 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);
}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 Endpointvar finalUrl = targetBase.toString() + cpipath.toString() + suffix.toString();If you analises this somehow procude another security layer, because the APIM contains the whole https path, the consumer only one part.Urls expose to the consumer:https://<apimaddress>/megaproxy/v1/methoddeletehttps://<apimaddress>/megaproxy/v1/methodposthttps://<apimaddress>/megaproxy/v1/methodputhttps://<apimaddress>/megaproxy/v1/methodgetUrl’s generate inside the API PROXY:https://<apimaddress>/megaproxy/v1/http/cpi/methoddeletehttps://<apimaddress>/megaproxy/v1/http/cpi/methodposthttps://<apimaddress>/megaproxy/v1/http/cpi/methodputhttps://<apimaddress>/megaproxy/v1/http/cpi/methodgetTest Proposal via postman for methoddelete:Figure 4 – Postman test of endpoint /methoddeleteDebbug prespective:Figure 5 – Full debugg process success.Figure 6 -Debug runtime variables and target.url where the message must be delivered in SAP CPI.Figure 7 – CPI Monitoring – Iflow.Template.MethodDeleteThe Real Innovation: Business-Oriented AnalyticsRouting is not the innovation.Observability is.By enriching the proxy with business context variables, SAP APIM Analytics can show:Calls per sender systemCalls per CPI iFlow or another backend system api serviceSuccess vs error rates per process variantTraffic distribution across the domainThe 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);
}Samples of URL’sCustom 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 8 – Create Custom Dimensions that will be used in Policy Statistic CollectorFigure 9 – 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 10 – Those policies should be added in the last step into the Target Endpoint Pre-FlowThe Result:Once this configuration is live, you move from a generic chart to a Business Iflow Dashboard. You can now generateVolume 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 failingImage – 11 – Custom Dashboard monitoring SAP APIMSender system identifier:Image 12 – Indentifier of Sender SystemImage 13 – Indentifier of Sender System – Coke – and which Iflow endpointImage 14 – CPI IflowsWhen This Pattern Is AllowedUse Domain Routing Proxy only if all apply:Same business domainSame CPI package or Same Odata ou SOAP API from the backendSame contract & versionSame lifecycleSingle ownershipNeed for unified analyticsWhen NOT to Use This PatternDo not use DRP whenDomains differ (Finance + Logistics)Versioning differsOwnership differsSLAs differBackends are heterogeneousIn those cases, separate proxies are mandatory.Why This Pattern Is Rarely DocumentedThis 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 practicesAn analytics-first mindset that elevates API Management from a routing gateway to a business observability layerMature architectural governance capable of enforcing domain ownership, lifecycle alignment, and controlled deviation from standard patternsMost 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 or Backend API Services ( ODATA, SOAP), traffic patterns, and error behavior, all through one unified SAP API Management dashboard.Kind regards,Viana Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
