Steampunk is going all-in
In Poker, going all-in can mean you’re really desperate. Or pretty confident that it’s the right thing to do. Judging by the spirit of optimism in our ABAP Platform dev teams, I don’t think we’re desperate, and here are some of the reasons why:
- The ABAP Platform unit has sort of rejuvenated. More than half of our employees have joined us during the past 4 years. ABAP is ready for the years to come.
- We feel we’re relevant. Our biggest issue now is to handle the growing demand of customers, partners, and internal stakeholders. Could be worse.
- We’ve invented Embedded Steampunk. In addition to running side-by-side on the SAP Business Technology Platform (BTP), the Steampunk dev model will now be offered for extensions directly within SAP S/4HANA as well, both in the Cloud and on-prem. Hence the pun: all-in. See below to learn more.
It’s been two years after our last blog post in August 2019. About time again to anticipate the questions you might have and, as always, honestly answer them (resisting the urge to get carried away, which is not easy this time, as you will see ;-).
I’m lost already. Could you give us a quick recap what this Steampunk thing is all about?
I’ve learned that roughly three quarters of the world’s business transactions touch an SAP System. Most of them are probably running on ABAP, and probably on-prem. You can argue about the length of the transition period, but there is little doubt that someday the software replacing today’s business transactions will run in the Cloud.
From my point of view, there are two risks for SAP. Number one, we can be too conservative and stick for too long with outdated concepts that are no longer required. And number two, we can be too radical and leave our current customers behind, or even worse, introduce technologies with a short half-life.
This is exactly why we have invented Steampunk (aka SAP BTP ABAP Environment) with a sharp focus: provide an ABAP Platform that is not only the benchmark for enterprise-readiness, as today, but is Cloud-ready as well (I prefer this term over Cloud-native). The main Steampunk properties are:
- a dedicated stable public interface between platform and solutions on top, ensuring upgrades without hiccups,
- an enterprise-ready environment for Cloud development, including a new ABAP language version and the ABAP RESTful Application Programming Model (RAP),
- a Cloud-ready runtime environment with BTP integration, standardized system updates and configuration, and automated operation,
- a Cloud transition path for our current customer base, carefully balancing between the two risks mentioned above.
Today, Steampunk is offered on BTP only, running side-by-side to the core ERP systems. With Embedded Steampunk, this will radically change. And this change will make the so-called clean core a lot cleaner. But let’s start with Steampunk on BTP first.
Steampunk reality check – what happened since your last blog post in Aug 2019, and what’s next?
There is still a lot to be done. We know. But it feels as if we’re on the right track, and what the teams have delivered during the past two years is simply amazing.
The prio 1 feature that was postponed in our last blog post has been delivered in 2020: support for multitenancy. This means a significant cost reduction for our partners who can now provide a SaaS solution to multiple customers within the same Steampunk system. For ABAP insiders: the Steampunk multitenancy architecture is based on the Client field and thus provides full isolation between consumers (tenants) with minimal costs per additional consumer. For real ABAP insiders: I think with this we have now implemented all theoretically possible multitenancy variants ;-).
Apart from that, Steampunk came with so many enhancements that I want to refer to Florian Wahl‘s release blog posts for all the details. An improved ABAP language optimized for the Cloud, more efficient support for developers, better tools for administrators, migration tools for ERP custom code, reuse services, or extensibility for partners are just a few of many.
And what are we currently working on? Well, this list is long, too. Cost savings by elastic scaling of application servers with Kubernetes, zero-downtime updates, a reduction of the minimum HANA memory size (30GB instead of 64GB), high availability and disaster recovery, more data centers and hyperscalers, to just name a few items. So, enough topics for future blog posts.
To me, the important message for now is that we have a powerful Cloud offering for all ABAP minded customers and partners, no matter the use case. Today, Steampunk on BTP is live in the following usage scenarios:
- customers extending their ERP applications side-by-side (clean core initiative)
- partners offering SaaS applications to their customers
- partners developing SAP Solutions Extensions for the SAP price list (e.g. Vistex)
- SAP products (e.g. Market Communications for Utilities, or SAP Master Data Governance, Cloud Edition)
- SAP’s own internal ERP extensions
Not enough? Well, we’re working on another one: Embedded Steampunk!
What is Embedded Steampunk? Embedded where? And why?
Steampunk is a great option for loosely coupled side-by-side extensions or for partners offering SaaS solutions written in ABAP. This is somewhat comparable to the solutions that were running side-by-side on NetWeaver. Let’s take a short trip back in time.
In the on-prem world, customers could adapt SAP software by modifying it, or by writing custom code that could make use of any SAP object (red in the drawing). There was no dedicated stable and public interface, and that was exactly the reason for annoying upgrade hiccups. With NetWeaver Standalone, it was at least possible to write loosely coupled extensions with a lifecycle separated from the ERP core.
The situation today looks like this (at least from the ABAP perspective, I’ll leave out our BTP Java and Node.js universes for simplicity).
Regarding the extension mechanism, nothing much changed on the on-prem side (bottom left). But in the Cloud, it is a must to only offer Cloud-ready extension mechanisms that survive upgrades without hiccups. For all loosely coupled ABAP scenarios, the solution is Steampunk on BTP (top right), with a stable public interface (green) between platform and layers above.
Extending the ERP core side-by-side is great for many use cases. But not for all of them. Think about custom code that needs to run close to the app that is being extended. Within the same context, calling local APIs, e.g., to avoid huge data replication, or to run within the same logical unit of work (database LUW). For these cases, S/4HANA Cloud so far only offers key-user extensibility (top left). A powerful mechanism that allows for field extensions or custom business logic but cannot be compared to the classic extension possibilities on developer level. And offering the on-prem extension style is of course not an option (not Cloud-ready, not upgrade-stable).
So here we finally go: Embedded Steampunk!
Internally, S/4HANA Cloud and Steampunk share the same ABAP Platform code line anyway (marked blue), with Steampunk being a kind of frontrunner for innovations. So, it is just a logical next step to embed the Steampunk development model directly into the S/4HANA Cloud stack. Custom extensions developed with Embedded Steampunk now have the same properties that made Steampunk Cloud-ready and upgrade-stable:
- Usage of stable public interfaces only
- No modifications of SAP code
- Restricted usage of the ABAP language and other technologies
- Restricted usage of system functionality
- Efficient development with RAP
Developing extensions with Embedded Steampunk using ADT (ABAP Development Tools) feels exactly like developing with Steampunk on BTP. With one important additional benefit: Embedded Steampunk extensions can not only call the more technical ABAP Platform interface (green), but also a local(!) public S/4 interface (orange) containing the business functionality (e.g., CDS views like I_Product, replacing direct access to table MARA, or RAP facades for the creation of purchase orders). In S/4HANA Cloud, the custom code itself is either an own app or service, or implemented via public extension points, using the well-known BADI technology.
If you are an ABAP developer and willing to familiarize yourself with RAP, with ADT instead of SE80, or with clean APIs instead of freestyle modifications, you will feel directly at home with Embedded Steampunk. You can use all the tools and processes you already know. And these are the same tools and processes thousands of developers are using each day at SAP.
Sounds good. Anything else planned?
Yes. Embedded Steampunk for S/4HANA on-prem!
S/4HANA on-prem still allows for classic extensions, shortening the migration path from the classic ERP world, but leaving the upgrade issues. With Embedded Steampunk in S/4HANA on-prem (bottom left below), we want to support the transformation of these systems to a cleaner core, with a stable public interface between SAP and extensions. Of course, we cannot enforce such a move overnight, due to the vast amount of classic custom code and missing public SAP APIs or extension points. That is why on-prem ABAP custom code can now set a flag telling the ABAP compiler whether to allow classic code or enforce strict Steampunk checks. On-prem S/4 customers thus have a free choice on ABAP class level: stay with the classic extension method or refactor it. Needless to say, refactoring makes the core cleaner step-by-step, reducing upgrade issues and preparing for a future move to the Cloud.
The Steampunk development environment is exactly the same in BTP, S/4HANA Cloud and S/4HANA on-prem. The local public S/4 business interface (orange) is currently created using the Cloud-first approach but will grow over time in S/4 on-prem as well.
From our point of view, Steampunk and Embedded Steampunk make the long transition period from on-prem to hybrid to Cloud a lot easier. And both fully support the clean core strategy.
Great! But when is all this available?
Embedded Steampunk has already been briefly announced as a lab preview at Sapphire 2021. We start with S/4HANA Cloud and are currently collecting first customer feedback via an Early Adopter Program (by invitation only), before rolling this out to all customers. Stay tuned for more infos at SAP TechED 2021!
Last question: How did you draw these pictures?
With GoodNotes on my daughter’s iPad. A great tool if you want to sketch something quickly … or spend hours and hours optimizing your drawings afterwards ;-).
September 30, 2021
Update Oct 12: Why read a 7-minute blog post if you can have it all in a 1-hour video interview ;-).
Much needed move. Thanks For sharing . Looking forward to try it out .
thank you for the great blog. I have absolutely no doubt: Embedded Steampunk is a gamechanger. A really strong investment into the future!
And let me add some comments.
1) What is about key user extensibility - in your pictures 3 and 4 it is gone. Is key user extensibility going away, will it be replaced by Embedded Steampunk? No! Key user extensibility will not go away and it will be still a very powerful, convenient, and elegant way to solve extensibility problems. A recent example is described in the very nice blog post Key User Extensibility in SAP S/4HANA Cloud Sales. So may be you want to add a small Gaulish village to your target pictures.
2) Embedded Steampunk on-premise: On central concept of Embedded Steampunk is the ABAP language version (sometimes called "restricted ABAP"). This is mandatory in the Cloud environments (SAP BTP ABAP and new the ABAP Environment on S/HANA Cloud). But it is also already available on on-premise. For those of you who are interested in detail, I recommend my blog posts: Restricted ABAP for SAP Cloud Platform ABAP Environment and Restricted ABAP and SAP S/4HANA On-Premise.
PS: Let me add the link to the documentation for those guys that want to read more.
Just talked to Thomas who wants his "Asterix village" back (key-user ext. from drawing 2, now gone in drawing 3 & 4). And he has a point: we are now offering extensibility options for both the key-user (as before) and the developer (comes with Embedded Steampunk).
But for the sake of simplicity I tried to keep the drawings as easy as possible, so both key-user and developer extensibility are part of this thing labeled "extension". We are not taking anything away!
In the end, Thomas was fine with that ... phew ;-))
Great blog post!
Great blog and excellent overview! The feedback of our early adopter partners is very very positive. Now with the plan to bring Embedded Steampunk also to S/4 onPremise, partners will be able to realize their extensions with one codeline only. 🙂
Great blog and great news about Embedded Steampunk !
Regarding Embedded Steampunk, could you spend some words about its real use cases?
For example, I am curios to know if, in add to customers and partners, SAP is also going to deliver "functions" (whatever they are) within the S/4 on-prem Embedded Steampunk.
Can't wait to hear more
In addition to Sergios question if SAP will use Embedded Steampunk to deliver functions my question would be if partners can create extensions for Embedded Steampunk that can be installed as Add Ons. And would it then be possible to use the same codeline for this Extension if it uses onyl released interfaces that are supported in S/4HANA Cloud and S/4HANA on prem.
Very nice and useful Information !!
What happened to the SAP Web IDE? A few years ago, the browser was king. Now it seems everything revolves around the fat & ugly client, Eclipse. Again. What happened?
we never had the ambition to integrate ABAP development into SAP Web IDE. In the meanwhile SAP Web IDE is going to be replaced by VS Code and Business Application Studio.
For ABAP we decided to stick to Eclipse as the IDE of choice.
are there any plans or thoughts integrating ABAP into VS Code IDE as well, replacing Eclipse?
No, there are no such plans.
Here is a couple of fresh tutorials which we have published as part of our early adopter initiative that gives you a feeling how Embedded Steampunk will look like in practice. The four tutorials cover the implementation of BADIs and the use of RAP facades in the area of SAP S/4HANA Cloud Procurement, see https://developers.sap.com/tutorial-navigator.html?search=purchase&tag=programming-tool%3Aabap-development
We now have our own dedicated tag for these tutorials:https://developers.sap.com/tutorial-navigator.html?tag=software-product-function%3As-4hana-cloud-abap-environment&tag=programming-tool%3Aabap-development
Not all of them have a title / keyword that includes "purchase" and we are adding to them all the time, so use this new search URL for best results.
Great Blog and a very Good News.
Asking clients to use a separate instance of ABAP on Cloud for simple side by side extensions on S/4HANA Cloud was a very big ask as it involved additional cost and licenses. Embedded ABAP platform (Steampunk) within S/4HANA Cloud will boost the adoptability of S/4HANA Cloud as more requests from end-users can be realized through side by side extension and it also opens the platform to write real code using Restful Programming Model (RAP).
Having an option to use embedded Steampunk for on-premise is really a very good move this helps to keep the core really "clean".
Hopefully this Embedded Steampunk will stay free with standard subscription :).
Lets wait for Teched in Nov for more information.
I hope that the reduced footprint that you've mentions will bing at the end Steampunk also in the Free Tier Model of BTP.
that's exactly the idea. We plan to offer Steampunk as part of the BTP Free Tier model in the next couple of months.
that's great news. Thank you for the fast reply.
Great blog to tell the future and direction of ABAP - the Steampunk way.
My struggle with the "clean APIs", "clean core" and so on is how fast these APIs will be developed to suit customer needs. Seventeen years working with SAP and ABAP and we had so many important BAPIs missing that sometimes we need to resort to non-released function modules or old, ugly and risky batch inputs. Recent example: developing a custom UI5 app to create and confirm production orders. There was a BAPI for everything EXCEPT for adding a component, which was crucial. So, when SAP doesn't deliver an API, neither a renewed user-friendly interface, we still run out of options, unless you still do classic extensions and take you chances when upgrading.
Same thoughts here with an example: needed to mass-change the purchase info records. We could not find a suitable BAPI. Either do an ugly batch input with ME12 or use awkward function modules from inside of ME12.
My/our daily struggle on customer systems (even on cutting edge S/4HANA 2020 on-prem) is navigating between super fancy bling-bling stuff and ancient/awkward business function modules.
And then the CIO asks me "what do you think about clean core?". My answer begins with: "Well, in theory..."
"elastic scaling of application servers" sounds really good!
What time intervals do you aim for? ie would it be feasible to have eg each workday from 6am to 10am an additional application server?
Would there also be an elastic scaling for the HANA part?
the design for elasticity is in the works. We evaluate several options.
Of course, we want to be able to manage workloads more dynamically so that you do not have
to size your system based on the peak load. This also fits better to the commercial models (pay per use, pay as you go). We will focus on the ABAP stack, but also leverage the HANA Cloud capabilities and optimizations for sure.
nice to hear!
I am asking about HANA part because in our case the most of the performance requirements are massivly parallel OData read requests where most of the heavy work is done on the HANA level.
Hi Karl Kessler ,
any update here?
Thanks Harald, This is great news !
Quick question on SAP S/4HANA Public Cloud Embedded Steampunk -
Are there any additional restrictions programmatically ( other that usage of Released API / Whitelisted CDS ) for building Complex custom CDS view thereby consuming it in RAP model for reporting purpose?
Hi Harald Kuck,
How to connect to the embedded steampunk in S/4HANA cloud?
Thank you for this great explanation!! I benefited a lot from it (not being the developer:)).
Very interesting. Couple of questions if I may:
from what I understood so far:
After all the effects of this war, I no longer think the CLOUD is the future . you can't argue it.
You find some comments about on-premise in the blog above. That means, if you don't believe in cloud then this new extension concept is still valuable for on-premise customers.
It is very promising. I have the following doubts:
If this new in-app development extension capability only allows the data consumption/modification from/to the S/4 HANA Cloud data sources, then the gaps are might still be there compare to the classic extension.
thanks for your questions. Here are some thoughts and suggestions:
Thanks a lot for your answer. It is very promising and I would like to see our traditional ABAP add-on SolEx partners all use this option to rollout their solutions for SAP S/4HANA Cloud.
When and under which release will embedded steampunk be offered on-prem?
as already mentioned by Harald above, we currently collect feedback from customers and partners who participate in our early adopter program. We will incorporate this valuable feedback into SAP S/4HANA Cloud ABAP Environment before we will make it generally available.
We also look into private Cloud and on-premise in parallel.
Since SAP S/4HANA, SAP S/4HANA Cloud and SAP BTP ABAP Environment are all based on the same ABAP Platform innovation codeline the enablement of Embedded Steampunk for private Cloud and on-premise is a similar effort.
Please stay tuned for our announcements at the various SAP conferences this year (SAP TechEd in particular).
I am looking for an answer to an important question:
As mentioned in the help documentation that there is a restriction that 99 software components can be created per customer at following link: How to Create Software Components - SAP Help Portal
And also there can be only one Business Configuration Software component in one tenant as mentioned here Software Components - SAP Help Portal
How do you manage transports or for that matter you want to use CI/Cf/gCTS for your custom developments. If you create multiple development packages inside a software component but want to transport a single development package, I don't think it will be possible because your transport is linked to your software component and not your development package. And also if that is the case you will have to create a software component per package and transport it independently. But down side would be that you can only create 99 development packages and cant' do any more developments?
Similarly you will have to send all of your config in a single transport because you can create only one business configuration software component in one tenant?
Is this correct or have I got it totally wrong?
Correct, as of today, there is a restriction that only 99 software components can be created per customer. In the future, we plan to mitigate this aspect by allowing customers to use their own Git repository instead of an SAP-managed repository. This is what we call the "bring-your-own-Git" approach. In this case, there will not be a limit on the number of repositories. Unfortunately, I cannot give any information about feature availability or timelines at this point.
Regarding the current restriction, an important aspect of such a large number of software components is that we do not provide automatic dependency management. The resolution of dependencies is therefore the responsibility of the customer. In the standard case, we recommend a so-called layered approach to avoid cyclic dependencies between the repositories.
Your understanding of the transport granularity is correct. With gCTS on Steampunk ("Manage Software Components" app) we only transport complete software components, respectively ABAP structure packages. A transport of single development packages is not possible.
Dear harald kuck,
Thanks for the information.
Can you please provide below inputs.
Is there any estimated date for GA of Embedded Steampunk in S/4HANA OnPrem?
Sorry for the late answer. Meanwhile Embedded Steampunk is available in SAP S/4HANA private Cloud and on-premise (SAP S/4HANA release 2022).
Details can be found in this blog post:
How to use Embedded Steampunk in SAP S/4HANA Cloud, private edition and in on-premise – The new ABAP extensibility guide | SAP Blogs
Thank you so much for this post.
It is really easy to understand.
Questions considering the context of S/4HANA Cloud 2022, Private Edition on AWS or Azure (and so on)
Please refer to the following blog post to get the details about Embedded Steampunk:
Embedded Steampunk – Some more details for ABAP developers | SAP Blogs
How to use Embedded Steampunk in SAP S/4HANA Cloud, private edition and in on-premise – The new ABAP extensibility guide | SAP Blogs
To your questions:
In SAP S/4HANA Cloud, private edition (release 2022) you can directly use Embedded Steampunk. No need to activate anything.
To "demystify" this:
Using Embedded Steampunk in the private edition (2022 release) means that you go to your ABAP IDE and switch the attribute "ABAP Language version" to "ABAP for Cloud Development" for your custom ABAP development objects (e.g. one of your ABAP classes).
After this change the strict ABAP Cloud syntax check is active for this object (the ABAP class) and you get syntax errors if you e.g. try to use not released SAP objects like a legacy SAP function module in your custom ABAP code.'
So, Embedded Steampunk enforces the ABAP Cloud rules via ABAP syntax check and provides stable released SAP APIs (CDS views, classes, RAP facades for CUD operations) and SAP extension points, which you can use in your ABAP Cloud code.
That's it - no further magic.
Please check the ABAP Cloud blog post to get details about the new cloud-ready and upgrade-stable ABAP Cloud development model: ABAP Cloud | SAP Blogs
You are right the new ABAP Cloud development model can be used to build "on-stack" extensions directly on the SAP S/4HANA stack (Embedded Steampunk) or to build side-by-side extensions on SAP BTP (Steampunk). We see this as a big advantage, because this allows to use ONE common ABAP Cloud development model for on-stack and side-by-side extension use cases.
To your question: "Why should someone use the BTP_Steampunk instead of the embedded Steampunk?"
I have the following analogy in my mind: Think of tools like a hammer and a screwdriver. Both tools are necessary, and neither is superior to the other. These are different tools for different use cases.
The same is true for Embedded Steampunk versus Steampunk.
You use Embedded Steampunk if your extension needs tight coupling to the ERP - This means your extension needs tight coupling to
You use SAP BTP (Steampunk or other SAP BTP environments like Java/Node.js) if your extension is loosely coupled to the ERP and you want to benefit from this decoupling. (Deploy it separately on SAP BTP - not on the ERP)
Some examples for extension use cases which shall/must run SAP BTP:
learning, AI etc.
Please refer to chapter 3 of our ABAP extensibility guide to get all the details for the question "When to use which cloud extensibility option"