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, that is what it is 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 does not know. And the question is on the table: do we have to touch the core after all?

You do not. 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.

TL;DR: When key-user extensibility is not enough, build a small CAP application on SAP BTP Cloud Foundry that reads and writes S/4HANA Public Cloud only through released APIs, connected via the Destination service and a dedicated communication arrangement. Keep it boring: read-heavy dashboards and small, clearly scoped write scenarios. Upgrades then pass without anyone noticing, and running costs stay small.

The pattern: a small app next to the system

The blueprint is always the same, and that is its strength. In the backend, a service built with the SAP Cloud Application Programming Model (CAP), in Node.js or Java, that fetches, aggregates or enriches data from S/4HANA. In front of it, a frontend: SAPUI5/Fiori if the app should feel like SAP, a plain web frontend if it does not have to. The connection to the ERP runs through the Destination service and a communication arrangement in S/4HANA, and only released APIs from the SAP Business Accelerator Hub are consumed. SAP documents the approach as side-by-side extensibility with SAP BTP.

That is it. No framework zoo, no platform of your own, no modification. Anyone who has set up a Node.js project finds their way around CAP within days. And since the Cloud Foundry environment bills memory per instance, an app that runs in a few hundred MB costs little 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 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 change 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. It is embedded as a mashup directly in SAP Sales Cloud V2, with single sign-on 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 result: the ERP was never touched. The app runs in a few hundred MB of Cloud Foundry memory, and monthly infrastructure costs sit in the two-digit franc range. Sales got a view of the customer that did not exist before. The same pattern on the CRM side is described in our post on extending Sales Cloud V2 with custom Cloud Foundry apps.

The architecture checklist

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

1. Released APIs only. If it is not documented as released on the SAP Business Accelerator Hub, it is not consumed. 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 person is asking, you need principal propagation. A technical user is 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 authentication method live in the destination, never in the repository.
5. One BTP subaccount per stage. Test and production separated, each with destinations pointing at the matching S/4HANA system. It sounds obvious and is skipped surprisingly often.

The payoff: upgrades nobody has to care about

S/4HANA Public Cloud receives its release upgrades on SAP’s schedule, whether you like it or not. If you had modified the core, you would test your modifications with every upgrade. The side-by-side app does not notice the upgrade, because it only uses released, versioned APIs that SAP keeps stable. Our dashboard from the example has passed several releases without any work on our side.

That is the point of clean core: not dogma, but the freedom to let upgrades happen.

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 is where the pattern shines.

Two warning signs from projects we have taken over. First, if you catch yourself replicating half the ERP into a HANA Cloud database, stop and rethink the target picture. From that point on you are building a second system with all the synchronisation problems that come with it. Second, watch API rate limits. An app that re-queries 75,000 documents on every page load learns the hard way that released APIs are throttled. Aggregate, cache and reload on a schedule.

If the logic has to sit synchronously in the ERP document flow instead, ABAP Cloud is the better tool; we have described it in Embedded Steampunk in S/4HANA Public Cloud. Choosing a partner for this kind of work? Our overview of SAP BTP development partners in Switzerland sets out what to ask, and SAP BTP at Spadoom shows how we work. Side-by-side apps are also a typical building block of the integrated S/4HANA Public Cloud and Sales Cloud V2 stack, which is why we cover both halves with one team, as described in our guide to the best SAP partner for Cloud ERP and CRM in Switzerland.

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 plus small items for services such as destination and authorisation. Our example app with a few hundred MB of memory runs for a two-digit franc amount per month; the relevant cost is the build, not the operation, and even that stays manageable for a focused scenario.

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

Key-user extensibility for fields, validations and UI adjustments inside an existing app. BTP Cloud Foundry when you need your own data aggregation, your own UI or embedding into another system such as a CRM. ABAP Cloud (developer extensibility, also called Embedded Steampunk) when the logic has to run close to the ERP transactions and the team brings ABAP skills.

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

Yes. Sales Cloud V2 embeds the app as a mashup in the account or opportunity view. With single sign-on set up properly, users do not notice they are working in an external app; that is how the revenue dashboard in our example runs.

Does the app break when SAP changes the API?

Released APIs are versioned, and SAP keeps released versions stable; new versions arrive additively. The risk sits almost entirely with unreleased interfaces, which is why the first rule of our checklist is to consume released APIs only.

---

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