Reality Check: ABAP is not ABAP

As part of an internal innovation project, we wanted to subject the marketing promises to a reality check on the one hand and clarify what it costs to make an on-premise application available on the SCP on the other.

Barcode tool goes cloud

With the Snap barcode tool, a verification service for the widely used barcodes, the barcode data contained in each package marked with it can be processed and reconciled with the SAP ERP system in a fraction of a second.

Our plan: With the help of SCP, we want to offer this service on the Internet as a pay-per-use service with SAP back-end integration. To improve the master data quality of our customers, the application should also be discoverable and integrable via the SAP Business API Hub or the SAP Shop - and easily usable on cell phones via Fiori. So far, so good.

From on-prem to the cloud

At the beginning, our idea was quite simple: The ABAP application that now works on-premise will then run on ABAP on the SAP Cloud Platform (SCP). So we set up an SCP account, activated an ABAP instance on it and imported the barcode tool. That was the plan.

Then maybe a little bit of re-coding, activate an additional service here and there and then generate a simple Fiori demo app from that, publish it in the business hub - that's it! We thought.

Getting a partner license and activating an instance by paying were still simple exercises. The expectation of being able to import our tool into the SCP at best via transport request and at worst via copy and paste was disappointed.

In reality, we had to upload ABAP objects to a Git repository and download others from there. After all, SAP relies on Git, an open source tool that we knew!

But unfortunately, even the proper procedure resulted in error messages. On the one hand, because some objects (such as includes) were not imported, and on the other hand, because classic ERP objects such as MARA and MATNR, which our barcode tool uses, simply do not exist in SCP-ABAP or because access to them is not permitted.

The somewhat bitter realization: The planned "almost one-to-one import" cannot be realized, our experiment is developing in the direction of re-implementing the product!

Workarounds and improvisations

So we built a wrapper to call the functionality from the backend. But the name of the ABAP-RESTful-Programming-Model (RAP) turned out to be a pure euphemism.

Working with it was by no means relaxing, as there is neither the "well-known" SE80 nor an SAP GUI for Windows. What is available is Eclipse and various Fiori Launchpad apps.

Under these conditions, our project to port an on-premise application to the cloud turned into a tour de force of workarounds and improvisations - and a rendezvous with many new components and user interfaces.

ABAP in the cloud ticks differently

Looking back, we learned a few things. First and foremost: ABAP in the cloud is not the same as ABAP on-premise. The cloud offers many new concepts and possibilities.

SAP seems to be developing innovations in the ABAP environment for the cloud first, as the Fiori-everywhere approach to the user interface shows - which eliminates the SAP GUI. The data dictionary does contain some new objects from the on-premise world.

However, what is known is partly no longer available. Our intended migration project has thus rather developed into a veritable new implementation in the course of the project.

Good for new

Even though our approach did not prove to be effective, it gave us a good insight into SAP's cloud platform. It is very well suited for new developments, also in combination with on-premise solutions, but less so for porting existing applications.

The advantages of the cloud, such as scalability, security and global approaches, can be realized, and new technologies and processes are available here in a timely manner. In short: SCP offers a wide range of innovative possibilities that are state of the art. They can be optimally used in the development of new applications.