Introduction
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.
The “Invisible Traffic” – Challenge MegaProxy
When some of distinct business processes (iFlows) share a single API Proxy from the same CPI Package, 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 Granular Observability by extracting technical metadata and transforming it into human-readable business dimensions. Using JavaScript and the Statistics Collector policy, we will “unmask” the Mega-Proxy traffic, providing full transparency directly within the SAP APIM Analytics Dashboard.
The integration prespective below:
Figure 1 – Integration Prespective
The Strategy: Mapping Business Identity
Observability in SAP APIM doesn’t happen by accident; it is engineered. To solve the “visibility vacuum,” we must capture the iFlow’s identity the moment the request hits the Proxy.
API MegaProxy – ProxyEndpoint routing:
Figure 2 – Routing based on proxy.pathsuffix
Target Endpoints:
Figure 3 – One API Proxy and mutiples Targets Endpoint.
The JavaScript Logic: The Metadata Translator
Instead of manual mapping, we utilize a centralized JavaScript policy in the PreFlow. This script acts as our “Metadata Translator”: it inspects the proxy.pathsuffix (the incoming URL) and injects meaningful business context into flow variables.
Than in each of target endpoint you need to add the java script below plus the policy Statistic Collector.
function setCustomHeaders(){
var path = context.getVariable(“proxy.pathsuffix”);
var packageName = “sap.scn.package”;
var iflowName = “Unknown Iflow”;
// Lógica de mapeamento dinâmico
if (path.indexOf(“/http/cpi/methoddelete”) > -1) {
iflowName = “Iflow.Template.MethodDelete”;
}
else if (path.indexOf(“/http/cpi/methodget”) > -1) {
iflowName = “Iflow.Template.MethodGet”;
}
else if (path.indexOf(“/http/cpi/methodpost”) > -1) {
iflowName = “Iflow.Template.MethodPost”;
}
else if (path.indexOf(“/http/cpi/methodput”) > -1) {
iflowName = “Iflow.Template.MethodPut”;
}
// Create variables
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. This is the exact name you will reference in your policy and search for in your reports.
Figure 4 – 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>
<!–Specify Stats collector policy to add custom dimensions and measures –><StatisticsCollector xmlns=”http://www.sap.com/apimgmt” async=”false” continueOnError=”false” enabled=”true”>
<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>
</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 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 – 5 – Custom Dashboard monitoring SAP APIM
Image 6 – CPI Iflows
Conclusion:
Mastering the Mega-Proxy was just the beginning. By implementing Observability, you transform a simple integration into a strategic asset. You now provide total transparency for stakeholders what is running over one API Proxy endpoint and absolute control and visibility of the traffic and operations.
Kind regards,
Viana.
IntroductionIn 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.The “Invisible Traffic” – Challenge MegaProxyWhen some of distinct business processes (iFlows) share a single API Proxy from the same CPI Package, 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 Granular Observability by extracting technical metadata and transforming it into human-readable business dimensions. Using JavaScript and the Statistics Collector policy, we will “unmask” the Mega-Proxy traffic, providing full transparency directly within the SAP APIM Analytics Dashboard.The integration prespective below:Figure 1 – Integration PrespectiveThe Strategy: Mapping Business IdentityObservability in SAP APIM doesn’t happen by accident; it is engineered. To solve the “visibility vacuum,” we must capture the iFlow’s identity the moment the request hits the Proxy.API MegaProxy – ProxyEndpoint routing:Figure 2 – Routing based on proxy.pathsuffixTarget Endpoints:Figure 3 – One API Proxy and mutiples Targets Endpoint.The JavaScript Logic: The Metadata TranslatorInstead of manual mapping, we utilize a centralized JavaScript policy in the PreFlow. This script acts as our “Metadata Translator”: it inspects the proxy.pathsuffix (the incoming URL) and injects meaningful business context into flow variables.Than in each of target endpoint you need to add the java script below plus the policy Statistic Collector.function setCustomHeaders(){
var path = context.getVariable(“proxy.pathsuffix”);
var packageName = “sap.scn.package”;
var iflowName = “Unknown Iflow”;
// Lógica de mapeamento dinâmico
if (path.indexOf(“/http/cpi/methoddelete”) > -1) {
iflowName = “Iflow.Template.MethodDelete”;
}
else if (path.indexOf(“/http/cpi/methodget”) > -1) {
iflowName = “Iflow.Template.MethodGet”;
}
else if (path.indexOf(“/http/cpi/methodpost”) > -1) {
iflowName = “Iflow.Template.MethodPost”;
}
else if (path.indexOf(“/http/cpi/methodput”) > -1) {
iflowName = “Iflow.Template.MethodPut”;
}
// Create variables
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. This is the exact name you will reference in your policy and search for in your reports.Figure 4 – Create the dimension custom to be used in the PolicyPolicy 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><!–Specify Stats collector policy to add custom dimensions and measures –><StatisticsCollector xmlns=”http://www.sap.com/apimgmt” async=”false” continueOnError=”false” enabled=”true”>
<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>
</Statistics>
</StatisticsCollector>Add in seguency:Figure 4 – Those policies should be addded in all targetEndpoint PRE-FLOWThe Result:Once this configuration is live, you move from a generic chart to a Business 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 – 5 – Custom Dashboard monitoring SAP APIMImage 6 – CPI IflowsConclusion:Mastering the Mega-Proxy was just the beginning. By implementing Observability, you transform a simple integration into a strategic asset. You now provide total transparency for stakeholders what is running over one API Proxy endpoint and absolute control and visibility of the traffic and operations.Kind regards,Viana. Read More Technology Blog Posts by Members articles
#SAP
#SAPTechnologyblog
