SAP Cloud Platform ABAP Environment

In this blog I call it ABAP PaaS because that’s what it is: an ABAP Platform as a Service. For the first time in the history of SAP, developers worldwide can build and run ABAP code in the Cloud. On SAP Cloud Platform, where ABAP is the new kid on the block now, next to Java or Node.js.

You think we made a lot of noise last year and have been sort of quiet ever since? (skip these lines if you don’t). This is exactly why I don’t like upfront noise. I remember the good old times in 1998 when we implemented R/3 on Linux. We didn’t tell anyone inside or outside SAP until the port was completely done. Only then convinced Hasso how cool open source and Linux really are. And then spread the message at CeBIT 1999. Best time of my life, by the way. So far.

Things work a bit differently today, I can tell you. Plus, compared to an operating system port, deriving an ABAP PaaS from code that has its roots in a time when clouds were mainly in the sky, is a considerably bigger task. And it’s by far not finished yet. We’ve just started with a minimum viable product. “Release early, release often – and listen to your customers” was one of the open source mantras we put into practice with R/3 on Linux. And we’re doing the same thing now with ABAP PaaS (oh yes, it does include the listening part, too).

The good thing is, in the Cloud we don’t have all these different release versions with a completely fragmented on-prem ABAP community: some of you are still using ABAP 4.6C (with a kernel I contributed to as a developer, happy times), and some of you are already on the latest S/4HANA release. With ABAP PaaS, there is just this one living thing, always up-to-date. For all of us, at the same time. This makes it a lot easier to gather your feedback and let you influence. Not the release you or your company might be installing in years from now, but the ABAP PaaS you are using NOW.

For me, this is a very special moment in my almost 30-year career at SAP. We are now laying the foundation for the next 10+ years. I am really proud to be part of the fantastic team who made this happen. And I’m extremely glad to be surrounded by friends like Boris Gebhardt (chief product owner ABAP Platform), Frank Jentsch (project lead ABAP PaaS) and Karl Kessler (product management), to name just a few of the many who’ve contributed. Thanks a lot to all of you. Without you guys I would be lost, and there would be no ABAP PaaS.

General

The main goal of this FAQ is honest expectation management. In this section we answer fundamental questions you might have if you’re just curious what ABAP PaaS is all about. Scroll down to the development section for more details on differences between the ABAP you know today and the ABAP PaaS.

[Q1] In a nutshell: what’s in it for me?

You are an ABAP developer?

Well, you can now write your code in the Cloud, for the Cloud. And yes, that might feel a bit different compared to your on-prem ABAP experience. From now on you can always use the latest and greatest ABAP and SAP HANA features, or call any microservice offered by SAP Cloud Platform. Plus, there is no more pain with cumbersome tasks following an upgrade because it is SAP who is operating the entire ABAP Platform and HANA layer, without any follow-ups for you.

You are a customer heading to SAP S/4HANA Cloud with your existing business solutions?

Then the ABAP PaaS is a great opportunity for you to transform your on-prem ABAP extensions to the Cloud, to modernize and stabilize your custom code, and to enhance the skills of your ABAP teams.

You plan to stay on-prem with your SAP ERP or SAP S/4HANA system for the next few years?

There’s nothing wrong with continuing classic ABAP custom development for the time being. For you, the ABAP PaaS is a genuine option for creating innovative and decoupled extensions. Think about scenarios that run in the Cloud, exploit SAP HANA and use other SAP Cloud Platform services, irrespective of the implementation language. And all this without disturbing or putting load on your on-prem ERP system, the stable digital core. With a decoupled approach using clean APIs, the times of extensions or modifications that complicate your next ERP upgrade are over.

You’re a bit puzzled because you’ve never heard any of the announcements? Well, no problem.

You would like a simple picture that shows the main building blocks? Here you go:

You create and maintain your ABAP environment using the Cloud Cockpit, you write your ABAP code using the ABAP Development Tools for Eclipse (ADT), and you use Git for code exchange and versioning. The ABAP PaaS itself is an integrated part of SAP Cloud Platform, making use of its services including HANA.

[Q2] If I can use Java or Node.js on SAP Cloud Platform, why consider ABAP?

Good point. ABAP is probably not the first thing that comes to mind when talking about the Cloud. So first of all: this is about free choice, no one is going to force you.

The vast majority of the SAP digital core is based on ABAP. That means there is a lot of ABAP know how out there in the world, as well as heaps of extensions written in ABAP. And this is exactly the sweet spot of ABAP PaaS. In scenarios where the non-functional properties of ABAP PaaS are quite adequate because the target SaaS solution is not Twitter, it can be a huge benefit to reuse the existing ABAP skills and even parts of the code in the Cloud (see developer section below).

Apart from that: From a technical point of view, due to the proximity of data types and structures, we would expect that enhancing a universe of ABAP apps with ABAP extensions is probably not the worst choice (think about data replication or data proxy scenarios).

We strongly believe in starting where customers are today and helping them to move to the Cloud, and here the ABAP PaaS can really help.

[Q3] The ABAP community has a long wish list, just think about version management. Why do you waste your time with an ABAP PaaS?

As mentioned above, the two main uses cases that motivate ABAP PaaS are:

1. Extend S/4HANA Cloud with decoupled ABAP code

2. Transform your on-prem ABAP extensions to the Cloud, using decoupled ABAP code

The third aspect is the unique opportunity to

3. Modernize the ABAP universe

This means we can now use the ABAP PaaS as an innovation frontrunner (see Q12), and as stated above: you are invited to give feedback and influence the future of the ABAP PaaS.

Concerning potential waste: In the Cloud, the ABAP Platform comes with two flavors, or plays two different roles. On the one hand as the internal foundation for SAP’s own larger SaaS solutions like S/4HANA Cloud. In this context the ABAP Platform is just used SAP internally as the enabler for the SaaS solutions. The other role now is the ABAP PaaS, offered to anyone in the world who wants to build and run a SaaS solution on top of ABAP.

Both flavors are based on one common codeline for the ABAP kernel and the ABAP layers. And most of the SAP investments related to ABAP and Cloud (and even S/4HANA on-prem) flow into this common codeline, so there’s no waste anyway.

And regarding version management: don’t worry, we heard you loud and clear (see the Git question below).

[Q4] What exactly can I do with the first version? Just play around with it or do real stuff?

From the very beginning ABAP was intended to efficiently write and run business applications, and this does not change with ABAP PaaS. You can develop standalone business apps or extensions to the digital core, be it Cloud or on-prem, S/4HANA or the classical ERP.

The focus of this first version are extensions to S/4HANA Cloud. Don’t worry, connectivity to on-prem systems (outbound remote function call (RFC)) is planned for this year, 2018. In addition, you can develop services in ABAP and expose them through HTTP(S) or OData.

As an example of what you can build today with ABAP PaaS imagine the following scenario or user story that we have been using in internal demos: A sales rep wants to find potential new customers in the neighborhood using OpenStreetMap. After collecting some candidates she then wants to create and edit the customer data and finally sync them to her S/4HANA Cloud account.

This is the first version of ABAP PaaS with a limited scope. It will grow over time, hopefully with your feedback and contributions, but already today you can write real applications and services.

[Q5] What is the roadmap and vision?

The first version of ABAP PaaS focuses on code written from scratch to extend S/4HANA Cloud. The next items in the backlog involve support for custom code migration, as well as the extension of on-prem solutions.

For 2019, we plan to provide better support for partners who develop and run apps for their customers on top of ABAP PaaS (think about integration with SAP App Center, or optimizing marginal costs with multitenancy).

Developer View

In this section we try to provide answers to questions an experienced ABAP developer might have: What is the difference between the ABAP PaaS and my on-prem ABAP? Is feature x supported? Can I reuse existing code?

[Q6] Why is it so restrictive? I’ve heard there’s no SAP GUI or Web Dynpro, and just limited ABAP language features and APIs. Why can’t I develop as I do on my on-prem systems?

The Cloud comes with a new distribution of responsibilities. In this case, the provider (SAP), takes care of the ABAP Platform and the SAP HANA layer, operating the entire landscape and continuously providing new features and fixes. All the code on top is managed by you, the tenant. This only works if there is a strict separation between provider and tenant on the one hand, and between tenants on the other. We, as the provider, must be able to exchange the platform without affecting your code.

This is exactly why we need a clear and well-defined interface between you and us: the whitelist of supported ABAP artefacts, from the ABAP language to CDS views. This whitelist will grow over time, and you are invited to help shaping it. But the whitelist can only support artefacts that don’t break any of the isolation types mentioned above, and it must not introduce incompatible changes. Last but not least, the whitelist can only offer those artefacts that can be supported with reasonable effort in terms of product standards, be it security or performance.

This is the reason why we start small, why we only expose RESTful services instead of supporting SAP Gui, or why direct access to the file system won’t work.

[Q7] Ok, understood. So what does that mean for the ABAP PaaS?

We defined the following basic principles regarding the nature and scope of the ABAP PaaS:

◈ It’s still ABAP – we are not creating a new language, but an appropriate subset.

◈ It’s the Cloud – whatever breaks or endangers Cloud operation is not permitted.

◈ The principle of one – keep it simple and reduce the operational risk. For components like UI or output management we support one strategic Cloud variant, not all of its historic predecessors.

◈ Start small – since we must keep the whitelist stable we start with a small whitelist and enhance it step-by-step.

◈ Listen to your customers – we collaborate with early adopters and the ABAP community to rank our backlog.

◈ Pragmatic approach – we try to find a balance between the beauty of a modern ABAP platform, and reusing existing ABAP code. And while being open for your wish list, we truly hope you don’t insist on MOVE source TO destination PERCENTAGE perc

To enforce these principles, the ABAP PaaS checks the application code during design time. Development objects violating these rules lead to syntax errors. Code that cannot be checked statically is not supported. We are currently evaluating additional runtime checks to support dynamic ABAP programming features.

[Q8] And what is the impact of these principles for the UI, the language or SAP HANA access?

Here you go:

UI

ABAP PaaS exposes its services via OData or plain HTTP only. Classic ABAP UI technologies like SAP GUI, Web GUI, Web Dynpro or BSP are not available. The exposed services can then be consumed by a Fiori UI or any other Web-based UI framework.

SAP HANA

To enforce a secure ABAP operation, only ABAP-managed access to ABAP-managed HANA objects is supported. This includes ABAP SQL, core data services (CDS) and ABAP-managed database procedures (AMDP). We cannot support native HANA artefacts or native HANA access.

ABAP Language

ABAP PaaS uses a special Cloud version of the ABAP language. Statements that may harm Cloud operation or cannot be controlled (like local file access, kernel calls, EXEC SQL, GENERATE REPORT etc.) are excluded. Additionally, statements marked as obsolete have been removed, and statements like CALL SCREEN are not supported, since the dynpro technology is no longer part of the ABAP PaaS offering.

ABAP reuse services and reuse elements

ABAP PaaS offers a whitelisted subset of the well-known objects in the reuse layers BASIS and ABA (e.g. CDS views or ABAP classes).

In addition, ABAP PaaS replaces or adapts some technical ABAP services concerning destinations, UI repository, printing or identity management. In ABAP PaaS these services are implemented by calling SAP Cloud Platform services.

ABAP programming model

For Fiori and OData services, the new RESTful ABAP Programming model (RAP) is enforced. Older versions of the Fiori programming model using Gateway services (SAP Gateway service builder SEGW) or BOPF are not supported.

To build standard REST/HTTP services, ABAP PaaS provides new whitelisted ABAP interfaces.

[Q9] Which ABAP objects and APIs does the whitelist contain in the first version?

The whitelist of the first ABAP PaaS version contains more than 400 ABAP development objects (classes, interfaces, CDS views, data elements etc.), focusing on core ABAP services like date and time conversion, XML handling or application logs. There is no doubt the whitelist will grow significantly with the next versions.

After the more technical services we plan to whitelist business reuse services like number range, factory calendar or change documents.

[Q10] Can I really reuse my ABAP know-how?

You’re already familiar with ABAP code on SAP HANA, Fiori apps, ABAP in Eclipse or unit tests?

Then you’re only a small step away from developing and running your first apps or services on the ABAP PaaS. All you need is a little jump start learning the RESTful ABAP Programming model (RAP).

You ask yourself why SE80 and SAP GUI won’t do?

Maybe it’s time to just give all the new features a chance that were invented for the ABAP community over the past years. And please don’t panic. We provide a rich set of training courses and tutorials to ramp you up. If you’ve liked ABAP so far, you won’t be disappointed. That’s a promise.

[Q11] Can I copy & paste my z-Code to ABAP PaaS?

The downside: you will see a lot of syntax errors if you just copy your on-prem code to the ABAP PaaS. More seriously, the question is how much of your existing on-prem ABAP code can really be reused in the ABAP PaaS. And this is hard to predict since it depends a lot on your code, but we’ll try to make a forecast.

It’s the following ABAP PaaS characteristics that reduce the reuse of existing on-prem ABAP code, ranked by their impact on reuse:

1. ABAP PaaS running side-by-side with the core business systems

2. Whitelisted technologies (e.g. no SAP GUI)

3. Whitelisted SAP objects (e.g. no direct access to SAP tables)

4. Whitelisted ABAP statements (e.g. no OPEN DATASET)

Most challenging for existing custom code is the side-by-side approach and the missing support for GUI/dynpro technology. Let’s start with side-by-side.

Already with the on-prem NetWeaver, we’ve seen many hub scenarios or decoupled side-by-side extensions. Just like the solutions in these scenarios, ABAP PaaS apps communicate via remote APIs with the core business systems. Consequently, custom code that is loosely coupled to the business logic of the core business system is a good candidate for a move to ABAP PaaS.

On the other hand, on-prem custom code that is deeply integrated with the business process should better stay in the core system. This is comparable to the so-called in-app extensions in S/4HANA Cloud: for tightly coupled scenarios this is the right mechanism to use. Even for decoupled scenarios a combination of in-app extensions / custom code and ABAP PaaS application is often the best fit.

To sum this up, if you have custom NetWeaver add-ons or loosely-coupled custom extensions that already use Fiori UIs, then your code reuse on the ABAP PaaS will be quite high. In all other scenarios the reuse is reduced mainly to the business logic. How much business logic you can reuse in the ABAP PaaS depends on the architecture of your custom code. Most beneficial for reuse is a clear separation between UI code, custom business code and SAP code.

[Q12] ABAP PaaS as innovation frontrunner? What does that mean?

The ABAP PaaS is updated automatically by SAP on a quarterly basis at defined dates. Innovations will reach the ABAP PaaS first, before they might later be implemented in other ABAP based solutions.

Here we start to renovate the entire ABAP development process (see below). Here you’re the first to get an impression of the new and very effective Fiori programming model based on RAP. Here you can see how we provide step by step SAP HANA features like graph, hierarchy or geo spatial directly in ABAP. Or enrich your ABAP PaaS app with SAP Cloud Platform services like identity authentication, portal, mobile, IoT or machine learning.

[Q13] What about Git?

We’ve saved the best bit till last. ABAP PaaS uses Git for code exchange and code deployment.

The code exchange use case covers the possibility to share ABAP code or other ABAP artefacts in community projects or to exchange ABAP code between ABAP systems via Git (e.g. when transferring custom code from an on premise system to the ABAP PaaS). For code exchange, ABAP PaaS uses the well-known open source solution abapGit.

The code deployment use case is about transferring ABAP code and other ABAP artefacts between ABAP PaaS systems (e.g. from a development system to a test system). The first version of ABAP PaaS uses Git for code deployment under the hood of the standard ABAP transport management system.

We know that up to now, version control in ABAP is rather limited, and there is little support for branching, merging or CI/CD (continuous integration/delivery) tool chains. The goal is to renovate the ABAP step by step using a version control system like Git without sacrificing the benefits of the ABAP change and transport system.