ABAP to the Cloud

This morning Bjoern Goerke, SAP’s Chief Technology Officer and President SAP Cloud Platform, announced at SAP TechEd in Las Vegas that SAP are going to make the ABAP runtime available on the SAP Cloud Platform (SCP).

ABAP has been a bit maligned over the years for not being ‘cool’. Maybe this is partly because simple consumer style apps for the smartphone are more hip than enterprise applications? Maybe it is because SAP lost a bit of interest in ABAP during some of the noughties? Maybe it is partly because we ABAPers are not always great representatives of the language? Maybe you can think of other reasons?

But those of us who have kept up to date with the latest ABAP features, and the roadmap, will be aware that ABAP continues to be enhanced and improved to support the current and emerging needs of the enterprise.

ABAP might not appear in the RedMonk Programming Language Rankings but it is a great language for building enterprise applications like S/4HANA.

What is often overlooked when discussing ABAP versus other languages is the amazing capabilities built into the ABAP runtime environment – capabilities that ABAP developers can take for granted. Things like security, workflow, content management, etc. provide enterprise grade features that the ABAP developer can simply make use of as needed.

Another amazing technical achievment is that ABAP is “backwards compatible”. This means ABAP code written decades ago, in some cases on an R/2 system, still runs correctly on the latest ABAP stack. An amazing achievment but also an amazing legacy.

A cloud platform needs to support multiple users running multiple applications across shared computing resources. The cloud platform therefore needs to guard against a rogue program adversely impacting the platform as a whole.

Therefore we can’t expect a simple lift and shift of your on-premise ABAP runtime to the SAP Cloud Platform. The ABAP runtime for SCP will need to be locked down to protect the platform itself, to protect other SCP applications and users, and to protect ABAP developers from themselves.

So when building ABAP applications for the SCP ABAP runtime I expect some pretty major changes.

All those old ABAP language features that are really only there to support those legacy applications written last century probably wont be available. Lots of them are already deprecated – expect them to totally disappear on the SCP runtime.

I expect the compiler to have a whitelist of available language elements for the SCP runtime. I also expect that access to the runtime features we have gotten used to will also be whitelisted. SAP will pick and choose which features, API’s if you prefer, will be available and which wont be.

Does all this sound a bit nebulous? Then let me give you a very specific example.

SAP’s roadmap for UI technology is all webservice-based. i.e. oData (or similar) web services being consumed by whatever UI technology the developer chooses – but from SAP’s perspective they would like you to choose SAPUI5.

So I expect the SCP ABAP runtime will probably not contain any user interface technology built in. No SAPGUI, no Web Dynpro, nothing, nada, nilch. The WRITE statement might not be on the language element whitelist.

We will use the SCP ABAP runtime to execute back-end processing functions that we will expose through web services – most obviously for extending existing on-premise Business Suite and S/4HANA implementations.