BTP API Management Part 2: Proxies, Flows and Policies
Build API proxies correctly: proxy and target endpoints, the flow model (PreFlow, conditional flows, PostFlow) for request and response, where policies attach, key value maps for configuration, and deploying/updating proxies safely.
Explanation
📌 KEY POINTS
✅ Proxy endpoint handles incoming requests; target endpoint calls the back end.
✅ Each has PreFlow → conditional flows (per path/verb) → PostFlow, for request and response.
✅ Policies attach to specific flow steps (e.g. VerifyAPIKey in proxy PreFlow request).
✅ Key value maps store configuration and secrets used by policies.
⚠️ Attaching security policies only in a conditional flow leaves other paths unprotected — put them in PreFlow.
━━━━━━━━━━━━━━━━━━━━
▶ WHERE WE ARE
Part 1 introduced APIM. Now proxies and flows.
━━━━━━━━━━━━━━━━━━━━
▶ 1. ENDPOINTS
- Proxy vs target.
━━━━━━━━━━━━━━━━━━━━
▶ 2. FLOWS
- PreFlow, conditional flows, PostFlow.
━━━━━━━━━━━━━━━━━━━━
▶ 3. POLICY PLACEMENT
- Security first; transformations later.
━━━━━━━━━━━━━━━━━━━━
▶ 4. KEY VALUE MAPS
- Encrypted values for secrets.
━━━━━━━━━━━━━━━━━━━━
▶ 5. FAULT HANDLING
- Fault rules; consistent error format.
━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP
- Create a proxy with two resources.
- Add VerifyAPIKey in proxy PreFlow.
- Add a conditional flow policy for one path.
✅ CHECKPOINT: all paths require a key; one path has extra logic.
Code example
===== FLOW MODEL =====Request: ProxyEndpoint PreFlow [VerifyAPIKey, SpikeArrest] → Conditional flow (/orders GET) [Quota] → PostFlow → TargetEndpoint PreFlow [set auth header from KVM] → back endResponse: TargetEndpoint PostFlow → ProxyEndpoint PostFlow [remove internal headers] ===== KVM =====Key value map "backend_creds" (encrypted): user, password → used by BasicAuthentication policyReal project scenario
A project team attached the API key check only to the /orders flow; /customers was open to anyone. Moving security to the proxy PreFlow closed the gap.
Common mistakes
- Security in conditional flows only.
- Secrets in policy XML.
- No fault rules.
- Untested changes.
- Inconsistent templates.
Best practices
- Security in PreFlow.
- Encrypted KVMs.
- Standard fault format.
- Test before deploy.
- Proxy templates.
Interview angle
Questions: "Explain proxy flows", "Where do you attach security policies?", "What is a KVM?"
Strong answer: endpoints, flows, placement, KVMs, fault handling.
Practice this lesson
Quick check
1. When changes are made to an API proxy configuration in SAP API Management, what must occur before those changes take effect for API consumers?
2. In the processing flow of an API proxy, which sequence best reflects the typical order of policy execution for a request?
3. What is a typical use case for a Key Value Map (KVM) in an API proxy configuration?
Interview questions
1. How would you apply API Management in a real SAP project? Walk through the design or implementation approach.
Answer it in your own words first, then compare.
2. Build an API proxy for an S/4 OData service with security and back-end credentials.
Answer it in your own words first, then compare.
Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.
More lessons in this topic
- BTP API Management Part 1: What API Management Does
- BTP API Management Part 3: Designing Policy Chains
- BTP API Management Part 4: Security — API Keys, OAuth 2.0, JWT and mTLS
- BTP API Management Part 5: Rate Limiting, Quotas, Spike Arrest and Threat Protection
- BTP API Management Part 6: Product Lifecycle, Versioning, Analytics and Developer Portal