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

Few languages have been buried as often as ABAP. And few keep living on as reliably. In SAP S/4HANA Public Cloud it’s 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’s the most precise extension tool the Public Cloud has to offer. In our projects, getting started rarely fails on the technology. It fails on the terminology.

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, adapted screens, all directly in the Fiori UI and without a development environment. A capable business power user gets surprisingly far here, no developer required.

Developer extensibility, aka Embedded Steampunk, is real ABAP inside the development tenant of the S/4HANA Public Cloud system itself. Same stack, same database, full editor. But under the ABAP Cloud rulebook, more on that in a moment.

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

If you’d rather build side-by-side without ABAP, Cloud Foundry on the BTP is open to you as well; we’ve covered what that looks like in its own post.

What ABAP Cloud Means in Practice

ABAP Cloud isn’t a new ABAP, it’s a 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 hasn’t marked as released simply doesn’t exist for your code.
• RAP is the programming model. The ABAP RESTful Application Programming Model structures everything: CDS views as the data model, behavior 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 only IDE. There’s no SE80 in the Public Cloud, and nobody misses it for long.
• Transport runs through gCTS-based software components, across the three systems DEV → TEST → PROD. Git-based versioning included, a genuine step up from any classic transport regime.

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’s 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’ll build developer solutions for configuration problems, and pay for them twice.
2. Embedded Steampunk when logic has to run in-stack. Determinations and validations on released business objects, custom Fiori apps on custom RAP objects, logic that sits synchronously in the document flow. That’s exactly what it’s built for.
3. BTP side-by-side when it’s a product of its own. Applications with their own lifecycle, their own release rhythm, or scenarios that aggregate data from several systems. That belongs next to the ERP, not inside it.

The ladder sounds trivial. It still saves weeks in every project, because it turns the discussion from “what would be cool” 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, laminate-ready. That single page settles every future architecture debate before it starts. The effort is half a day; the return is every escalation round that never happens.

Check the released-API list early. It’s not the wishes that decide the architecture, it’s the gaps. 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’ve seen initiatives planned as Embedded Steampunk solutions for three weeks, until someone looked it up and found the target object isn’t released. Back to square one.

Quarterly upgrades just run through. S/4HANA Public Cloud applies release upgrades automatically. ABAP Cloud code on released APIs survives them without anyone touching it; released APIs are contracts, and SAP keeps them stable. That’s the whole point of the exercise. Once you’ve experienced it, after years of upgrade projects with SPAU lists, the fence around ABAP Cloud suddenly reads as a feature.

The Honest Limits

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

When you hit a hard gap, there’s a proven path: raise an influence request with SAP (the release cycles are short, the odds are real, we’ve seen releases land within two cycles) and build a side-by-side bridge on the BTP in the meantime, to be dismantled later. Not a pleasant moment, but a plannable one. It only gets ugly when you discover the gap during integration testing, see above.

Frequently Asked Questions

Is ABAP dead in the Public Cloud?

No, quite the opposite. ABAP is back in S/4HANA Public Cloud as ABAP Cloud: modern, with RAP as the programming model and a clear rulebook. What’s gone are modifications and wild Z programs. You can call that a loss. We call it discipline, and the upgrade track record backs that view.

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 access, Eclipse instead of SE80. In our experience that’s a focused ramp-up of weeks, not months, provided someone with RAP practice accompanies the first objects.

Where does the code actually live?

In the development tenant of your own S/4HANA Public Cloud instance, organised in software components. From there it travels gCTS-based and versioned through DEV → TEST → PROD. No separate system, no infrastructure of your own, but cleanly separated from the SAP standard.

You’re planning extensions in S/4HANA Public Cloud and want the architecture question answered before it gets expensive? We’ll bring the decision tree. Talk to us.