Side-by-Side: Extending S/4HANA Public Cloud with Small Cloud Foundry Apps, Without Sacrificing the Clean Core

Every S/4HANA Public Cloud project reaches the moment when key-user extensibility hits its ceiling. An extra field, a validation, an adjusted app layout: no problem at all, that’s what it’s built for. But then sales wants a dashboard that aggregates revenue across years and tens of thousands of documents. Or a department needs a small process the standard simply doesn’t know. And suddenly the question is on the table: do we have to touch the core after all?

You don’t. The answer is side-by-side: a small application on SAP BTP Cloud Foundry that lives next to the system and talks to it exclusively through released APIs. The ERP stays untouched, the extension runs alongside. And small is meant literally.

The Pattern: A Small App Next to the System

The blueprint is always the same, and that’s exactly its strength. In the backend, a CAP service (Cloud Application Programming Model, Node.js or Java) that fetches, aggregates or enriches data from S/4HANA. In front of it, a frontend: Fiori/UI5 if the app should feel like SAP, or a plain web frontend if it doesn’t have to. The connection into the ERP runs through the Destination service and communication arrangements in S/4HANA, and only released APIs from the SAP Business Accelerator Hub get consumed.

That’s it. No framework zoo, no platform of your own, no modification. Anyone who has set up a Node.js project before finds their way around CAP within days. And since Cloud Foundry bills memory per instance, an app that runs in a few hundred MB costs next to nothing to operate.

An Example From One of Our Projects

At a Swiss trading company, sales wanted to see in the CRM what a customer had actually bought over the years: revenue per year, per product group, trend. The raw data lives in the ERP, spread across roughly 75,000 sales orders. No standard CRM report covers that, and nobody wanted to tinker with the ERP for it.

So we built a small side-by-side app: a CAP service that reads the orders through the released sales order API, aggregates them per customer, and serves a lean dashboard. The whole thing is embedded as a mashup directly in SAP Sales Cloud V2, with iframe SSO so nobody logs in twice. The sales rep opens the customer in the CRM and sees the dashboard as if it were part of the product.

The bottom line: the ERP was never touched. The app runs in a few hundred MB of Cloud Foundry memory. Monthly infrastructure costs sit in the two-digit franc range. And sales got a view of the customer that simply didn’t exist before.

The Architecture Checklist

To keep the pattern clean, we stick to five points in every project:

1. Released APIs only. If it isn’t documented as released in the SAP Business Accelerator Hub, it doesn’t get consumed. Full stop. This one rule decides whether the app survives upgrades.
2. One communication arrangement per scenario. Not one catch-all arrangement with every scope, but a dedicated arrangement per business use case. That keeps permissions traceable and decommissioning painless.
3. Principal propagation or technical user: decide consciously. If the ERP needs to know which human is asking, you need principal propagation. If a technical user is enough, it’s simpler, but then the app itself checks who may see what. Both are legitimate; undecided is neither.
4. Destination service instead of URLs in code. Endpoints, credentials and auth method live in the destination, never in the repository.
5. One BTP subaccount per stage. Test and production separated, each stage with its own destinations pointing at the matching S/4HANA tenant. Sounds obvious, gets skipped de facto surprisingly often.

The Payoff: Upgrades Nobody Cares About

This is where the discipline pays off. S/4HANA Public Cloud gets its release upgrades on a quarterly cadence, whether you like it or not. If you had modified the core, you’d now be testing your modifications every quarter. The side-by-side app, on the other hand, doesn’t notice the upgrade at all, because it only uses released, versioned APIs whose compatibility SAP guarantees. Our dashboard from the example has lived through several release changes. Effort on our side: zero.

That’s the actual point of clean core. Not dogma, but the freedom to let upgrades simply happen.

Project Know-How: Build It Boring

The most important rule for side-by-side apps is unspectacular: build them boring. Read-heavy dashboards, small write scenarios through released APIs, clearly scoped jobs. That’s exactly where the pattern shines.

Two warning signs from projects we’ve taken over. First: if you catch yourself replicating half the ERP into a HANA Cloud, stop and rethink the target picture. From that point on you’re no longer building an extension scenario, you’re building a second system with all the synchronisation problems that come with it. Second: watch API rate limits. Released APIs are throttled, and an app that re-queries 75,000 documents on every page load learns that the hard way. Aggregate, cache, reload on a schedule: unglamorous, but exactly right.

Frequently Asked Questions

What does a small Cloud Foundry app cost to run?

Less than most people expect. You essentially pay for Cloud Foundry memory (GB hours) plus small line items for the destination and authorization services. An app with a few hundred MB of memory ends up at two-digit francs per month. The relevant cost block isn’t operations, it’s the build, and even that stays manageable for a focused scenario.

When key-user extensibility, when BTP Cloud Foundry, when Steampunk?

Our rule of thumb: key-user extensibility for fields, validations and UI adjustments inside an existing app. BTP Cloud Foundry as soon as you need your own data aggregation, your own UI, or embedding into another system (a CRM, say). Steampunk, meaning ABAP Cloud embedded or on BTP, when the logic has to live close to the ERP transactions and the team brings ABAP skills. ABAP Cloud gets its own post here soon, by the way.

Can such an app be embedded in SAP Sales Cloud V2?

Yes, and it’s one of the nicest use cases. Sales Cloud V2 embeds the app as a mashup, via iframe right in the account or opportunity view. With SSO set up properly, users don’t notice they’re working in an external app. That’s exactly how our revenue dashboard from the example runs.

Does the app break when SAP changes the API?

Released APIs are versioned, and SAP keeps existing versions stable. New versions arrive additively. The risk sits almost entirely with unreleased interfaces, which is precisely why rule one of the checklist sits where it sits.

Your key-user extensibility is maxed out and the next proposal on the table says core modification? We’ll happily show you what the side-by-side pattern looks like in your case. Talk to us.