One of the most exciting announcements made by SAP at last year’s TechEd was the planned release of ABAP in the SAP Cloud Platform. This move should ease the transition of existing customers into the cloud, and it is good news for ABAP developers as well, as their skillset will remain relevant. There are some open questions however and it remains to be seen where this road will take us.
How is it different?
SAP made it very clear that the version of ABAP made available in the SCP will not be the same as “good old ABAP”, but a subset of it as some problematic language elements (direct file access, SAP GUI screen programming, list programming) are disabled and will now result in a compile-time error. This makes perfect sense as these features are not in line with the cloud experience. It also introduces a “strict” mode where programs containing already deprecated statements cannot be compiled either.
This, of course, has an impact on the development environment too. Since there is no SAP GUI in the cloud, there is no SE80 either, so this move further solidifies Eclipse as the main ABAP IDE going forward. Git integration will also be added to pull in ABAP code from existing private or public repositories.
Extending S/4HANA and a new programming paradigm
Of course, one of the main use cases of developing applications in the SAP Cloud Platform is adding custom functionality to an existing S/4HANA Cloud installation.
Extending the functionality of a SAP ECC system in ABAP was always about tight integration in the past since developers had direct access to every API, DDIC object and database table, along with the file system and low-level tools. This is both a blessing and a curse: almost anything can be implemented but dependencies are hardwired and subsequent changes to standard SAP objects can easily break these custom solutions.
In contrast to this, the cloud is all about loose coupling. At first, SAP will only allow side-by-side extensibility which means that ABAP cloud applications only have access to a well-defined set of APIs to access the data in the core S/4HANA system – APIs that are not explicitly whitelisted cannot be used. All APIs are exposed as OData services in accordance with SAP’s new programming paradigm which is mostly based on RESTful services. The modification techniques known from on-premise environments (like the Enhancement Framework) are simply not feasible in the cloud as multiple tenants share the same core code.
This is, of course, a lot more restrictive than the previous model, but more importantly, it also means that most existing ABAP-based solutions cannot be ported to the cloud without significant refactoring – if at all. This may be disappointing to many customers as this is probably the first thing that comes to mind when reading about the introduction ABAP in the cloud.
The future
All these developments leave ABAP in an interesting place. Instead of being “the” language to develop SAP based custom solutions, it becomes one of the many options alongside other containers in the SAP Cloud Platform (Node.js, Java, Python, etc.) and doesn’t seem to offer any advantages over the alternatives – at least for now.
SAP is planning to add other use cases in addition to just side-by-side extensibility in the future which could still put ABAP above the other options on the platform, but little of these plans are known at this point. (A bit tighter but still strictly controlled integration would make sense however, since S/4HANA itself is also written on the same ABAP cloud platform.)
Nevertheless, introducing ABAP in the SCP is a sensible move from SAP to increase the adoption of their cloud platform as millions of ABAP developers now have a lower barrier of entry into the new world of SAP development.
If you want to find out more about how we are helping some of the largest SAP users in the world transitioning to S/4HANA, then get in touch.
