SAP Business Technology Platform API Management layer.

[Atul_Joshi85]

We are exposing several S/4HANA services to external applications via SAP Business Technology Platform API Management layer.

One open question we have is around governance vs performance. Some teams are suggesting we bypass API Management for internal apps to reduce latency, while others strongly recommend keeping everything routed through API Management for consistency.

What is the recommended real-world approach here? Do companies actually mix both approaches, or is it better to enforce a single standard?

[Atul_Joshi85]

After looking into this further and weighing the pros and cons, I’ve decided on a path that balances governance with performance. I wanted to share it here in case it helps others.

The Conclusion: APIM by Default We’ve decided to stick with SAP BTP API Management as our primary gateway for both internal and external traffic. While bypassing it for internal apps seems tempting for speed, the 'extra hop' latency is actually negligible (usually just a few milliseconds). The risk of losing central visibility and security control is a much bigger concern than the minor speed gain.

A Simple Example of Why:

• The Problem: If we let internal apps call S/4HANA directly, we lose the ability to see who is calling what. If an internal app suddenly starts sending too many requests, it could slow down the entire S/4 system for everyone.

• The Solution: By keeping them in APIM, we can set a 'Quota' policy. This acts like a safety valve—if an app goes over its limit, APIM catches it before it ever hits our core S/4 system.

How we are handling the 'Internet' concern: For our most sensitive internal traffic, we are looking into SAP BTP Private Link. This gives us the best of both worlds: we get the full governance and analytics of API Management, but the data travels over a private connection rather than the public internet.

Final Rule of Thumb: We will use APIM for everything to keep a 'Clean Core.' We will only allow a direct connection as a rare exception for massive data transfers where every millisecond is critical, but those will be documented case-by-case.

[VijayKonam]

APIM puts everything over the internet. If the organization has control over both the consumers and the service providers, APIM may add an unnecessary hop at times. It totally depends on your level of trust risk that you are okay to take. The APIM at the current level provides very minimal ways with organizing the APIs. For internal communications where you do not need to put explicit policies hitting them directly the OData layer on S4 may absolutely be fine. But for external consumption, APIM is a must to protect the organization from threats and attacks. 

Let's see what the other experts have to say.

[Atul_Joshi85]

Thanks for the perspective — that helps. Where I’m still unsure is how to balance governance vs performance when we have mixed traffic patterns (internal apps, partner apps, and external consumers).

From what I’ve seen:

• Direct S/4 OData calls work for low‑latency internal workloads, but we lose central policies, quota control, API versioning, and lifecycle governance.

• API Management gives us consistent security (OAuth2SAMLBearerAssertion, JWT validation, IP filtering), analytics, and traffic management — but adds an extra hop.

• Private Link + APIM seems like a middle ground, but I’m not sure how widely it’s used in real projects.

So I’m still trying to understand the real‑world pattern:

Do most customers enforce APIM for all traffic (internal + external) to maintain a single governance layer, or do they selectively bypass it for high‑throughput internal scenarios?

Would love to hear how others have handled this at scale without creating two parallel integration standards.

[Atul_Joshi85 · Accepted solution]

After looking into this further and weighing the pros and cons, I’ve decided on a path that balances governance with performance. I wanted to share it here in case it helps others.

The Conclusion: APIM by Default We’ve decided to stick with SAP BTP API Management as our primary gateway for both internal and external traffic. While bypassing it for internal apps seems tempting for speed, the 'extra hop' latency is actually negligible (usually just a few milliseconds). The risk of losing central visibility and security control is a much bigger concern than the minor speed gain.

A Simple Example of Why:

• The Problem: If we let internal apps call S/4HANA directly, we lose the ability to see who is calling what. If an internal app suddenly starts sending too many requests, it could slow down the entire S/4 system for everyone.

• The Solution: By keeping them in APIM, we can set a 'Quota' policy. This acts like a safety valve—if an app goes over its limit, APIM catches it before it ever hits our core S/4 system.

How we are handling the 'Internet' concern: For our most sensitive internal traffic, we are looking into SAP BTP Private Link. This gives us the best of both worlds: we get the full governance and analytics of API Management, but the data travels over a private connection rather than the public internet.

Final Rule of Thumb: We will use APIM for everything to keep a 'Clean Core.' We will only allow a direct connection as a rare exception for massive data transfers where every millisecond is critical, but those will be documented case-by-case.

[VijayKonam]

Just make sure you define a good naming criteria for APIM. Because, there are no groupings or folder structure available. Also a strategy to defined versions for APIs and how you transport them. Those have been few pain points that I observed. 

Good luck!

[Atul_Joshi85]

Thanks, @VijayKonam  That is a very fair point. The lack of folders in APIM can definitely lead to a 'wild west' feel if you aren't careful.

To address those pain points, we are looking at:

• Strict Naming Convention: We’re planning a prefix-based system (e.g., "INT_" for internal, "EXT_"  for external, followed by the functional area like "BILL" or  " LOG"  ) to make filtering easier since we can't use folders.

• Version Control: We intend to use the header-based versioning or URL path versioning (like "/V1/") to ensure we don't break existing consumer apps when S/4 services evolve.

• Automated Transport: We are exploring SAP CI/CD service or Project "Piper" to automate the transport of API proxies. Doing this manually through zip files is definitely a recipe for configuration errors.

I really appreciate the 'heads up' on these—it helps us avoid those traps before we go live!. So far 5 days no defects but we went more we will get to know any real life cases. so far so good although.