SAP BTP extensions and the clean-core approach

How to build side-by-side extensions on SAP Business Technology Platform using CAP, released APIs, destinations and events — without touching the S/4HANA core.

SAP Business Technology Platform (BTP) is where new SAP development happens. The point is not that it is a nicer runtime — it is that code living outside the core has its own release cycle, so your ERP upgrades stay boring.

Anatomy of a side-by-side extension

A typical extension has four moving parts:

1. A CAP service (Node.js or Java) defining entities in CDS and exposing OData v4.
2. A destination in the BTP subaccount pointing at the S/4HANA system, with principal propagation or a technical user.
3. A Fiori elements or UI5 front end deployed to the HTML5 application repository and surfaced through Work Zone or the Launchpad service.
4. XSUAA for authentication and role collections for authorisation.

// srv/service.cds
using { sap.capire.orders as db } from '../db/schema';

service OrderReview @(requires: 'Reviewer') {
  entity Orders as projection on db.Orders;
  action approve(ID: UUID) returns Orders;
}

Only consume released APIs

Check SAP API Business Hub and the release contract (C1) of any object you consume. A released OData service or CDS view is guaranteed stable across upgrades; an unreleased one can change without notice. In ABAP Cloud the compiler enforces this for you — outside it, you have to be disciplined.

Events beat polling

Use SAP Event Mesh / Advanced Event Mesh so the ERP publishes business events (BusinessPartner.Changed, SalesOrder.Created) and your extension reacts. Polling OData on a timer is the most common cause of extension-driven load problems on production ERP systems.

Security checklist

• Prefer principal propagation so the ERP sees the real end user, not a shared technical account.
• Scope XSUAA roles narrowly and map them to role collections, not to individual users.
• Store nothing sensitive in application environment variables — use the credential store or service bindings.
• Turn on audit logging in the subaccount and ship it to your SIEM.

Operating the extension

Treat it like any other cloud service: CI/CD through the Continuous Integration & Delivery service or your own pipeline, transport via MTA archives, alerting through Cloud ALM, and a documented rollback. Give the extension its own on-call runbook — when it breaks, the business will call it "SAP is down".

When not to use BTP

If the requirement is a field on a standard screen, a validation rule, or a simple report, key-user extensibility inside S/4HANA is faster, cheaper and equally upgrade-safe. BTP earns its keep when you need a distinct data model, a different lifecycle, non-SAP integration, or an AI/ML workload.