ABAP Lives: Getting Embedded Steampunk Right in S/4HANA Public Cloud

Few programming languages have been declared dead as often as ABAP, and few keep living on as reliably. In SAP S/4HANA Public Cloud it is back, though not as the ABAP of user exits and Z reports you know from twenty years of ECC. The rulebook is called ABAP Cloud, the nickname is Embedded Steampunk, and used properly it is the most precise extension tool the Public Cloud offers. In our projects, getting started rarely fails on the technology. It fails on the terminology.

TL;DR: S/4HANA Public Cloud has three extensibility levels: key-user extensibility in the Fiori UI, developer extensibility with ABAP Cloud inside the system (Embedded Steampunk), and side-by-side extensions on SAP BTP. ABAP Cloud means released APIs only, RAP as the programming model and the ABAP Development Tools in Eclipse. Start at the lowest level that solves the requirement, and check early whether the object you want to extend is released.

Sort out the terms first

There are three extensibility levels in and around S/4HANA Public Cloud, and they get mixed up in workshops with remarkable reliability:

Key-user extensibility is the lowest rung: custom fields, small logic snippets and adapted screens, directly in the Fiori UI and without a development environment. A capable business power user gets surprisingly far here.

Developer extensibility, also called Embedded Steampunk, is real ABAP inside S/4HANA Public Cloud itself, in the development system of the three-system landscape. Same stack, same database, full editor, but under the ABAP Cloud rulebook. SAP describes it in the help on developer extensibility in S/4HANA Cloud Public Edition.

Side-by-side Steampunk is the SAP BTP ABAP environment: a separate ABAP platform on SAP BTP with its own database, decoupled from the ERP. Communication runs through APIs only.

If you would rather build side-by-side without ABAP, the Cloud Foundry environment on BTP is open to you as well; we have described what that looks like in its own post.

What ABAP Cloud means in practice

ABAP Cloud is not a new ABAP but a governed subset with a hard fence. Four things to internalise before the first line of code:

• Only released objects and APIs are reachable. No direct SELECT on unreleased tables, no user exits, no modification of SAP code. Whatever SAP has not marked as released does not exist for your code.
• RAP is the programming model. The ABAP RESTful Application Programming Model structures everything: CDS views as the data model, behaviour definitions for the logic, service bindings for the outside world. If you know RAP, you know Embedded Steampunk.
• Development happens in Eclipse. The ABAP Development Tools (ADT) are the IDE. There is no SE80 in the Public Cloud, and nobody misses it for long.
• Transports run through software components across the three-system landscape: developers release them from ADT, and they are imported into test and production with the Import Collection app.

The decision ladder from our projects

When deciding which level a requirement lands on, a simple ladder has proven itself. You start at the bottom and only climb when there is no other way:

1. Key user first. A surprising amount fits here: extra fields on documents, field controls, small validations, adapted layouts. Skip this rung and you build developer solutions for configuration problems and pay for them twice.
2. Embedded Steampunk when logic has to run in the stack. Determinations and validations on released business objects, custom Fiori apps on custom RAP objects, logic that sits synchronously in the document flow. That is exactly what it is built for.
3. BTP side-by-side when it is a product of its own. Applications with their own lifecycle and release rhythm, or scenarios that aggregate data from several systems. That belongs next to the ERP, not inside it; see SAP BTP at Spadoom.

The ladder sounds trivial. It still saves weeks in every project, because it turns the discussion from “what would be nice” into “what is necessary”.

Three things we bring to every project

The clean-core decision tree, one page, week one. Together with the customer’s IT, we draw a decision tree in the first project week: which requirement lands on which level, and by which criteria. One A4 page settles most future architecture debates before they start. It costs half a day.

Check the released-API list early. The gaps decide the architecture, not the wishes. Whether the object you want to extend comes with released APIs, BAdIs and CDS views is something you clarify on day two, not in sprint five. We have seen initiatives planned as Embedded Steampunk solutions for three weeks until someone looked it up and found that the target object was not released.

Let release upgrades run through. S/4HANA Public Cloud applies release upgrades on SAP’s schedule. ABAP Cloud code on released APIs survives them without anyone touching it, because released APIs are contracts that SAP keeps stable. After years of upgrade projects with SPAU lists, the fence around ABAP Cloud reads as a feature.

The limits

There are no modifications of SAP objects, and not everything you know from ECC is released: some classic BAPIs and function modules are still missing from the released list.

When you hit a hard gap, there is a proven path: raise an influence request with SAP and build a side-by-side bridge on BTP in the meantime, to be dismantled once SAP releases what you need. Not a pleasant moment, but a plannable one. It only gets ugly when you discover the gap during integration testing.

Getting these decisions right early is part of what the S/4HANA readiness assessment covers. Extensions rarely stay inside the ERP: the same clean-core rules apply to the CRM side of the integrated S/4HANA Public Cloud and Sales Cloud V2 stack, and our clean core with SAP CAP guide shows the BTP counterpart. If you are comparing implementation partners, see the best SAP S/4HANA Public Cloud partners in Switzerland and our guide to the best SAP partner for Cloud ERP and CRM in Switzerland.

Frequently asked questions

Is ABAP dead in S/4HANA Public Cloud?

No. ABAP is part of S/4HANA Public Cloud as ABAP Cloud, with the ABAP RESTful Application Programming Model (RAP) and a clear rulebook: only released APIs, no modifications. What is gone are modifications and unrestricted Z programs, and that is what keeps upgrades uneventful.

Do experienced ABAP developers need complete retraining?

Retraining yes, complete no. The language stays ABAP; the mindset changes: RAP instead of reports, released APIs instead of direct table access, Eclipse-based ABAP Development Tools instead of SE80. In our experience that is a focused ramp-up of weeks, provided someone with RAP practice accompanies the first objects.

Where does the code live?

In the development system of your S/4HANA Public Cloud three-system landscape, organised in software components. Developers release transports from the ABAP Development Tools, and the extensions are imported into the test and then the production system with the Import Collection app. No separate infrastructure is needed.

---

You are planning extensions in S/4HANA Public Cloud and want the architecture question answered before it gets expensive? We will bring the decision tree. Talk to our team.