ABAP is Evolving

I had the privilege of attending SAP TechEd in Las Vegas last week as part of the SAP Bloggers Program.

In the keynote Bernd Leukert announced that the SAP Cloud Platform ABAP Environment was Generally Available. When you say it like that it seems like an impenetrable wall of SAPanese – but the announcement was still greeted with spontaneous applause from the audience.

In the Developers Playground area, where attendees could do a series of tutorials on the latest SAP developer tools with expert help readily at hand, the SCP ABAP tutorials were the most popular and also achieved top spot of the scoreboard of completed tutorials.

Attendees were also invited to wear a badge that represented their programing language of choice. The ABAP badges disappeared at a significantly greater rate than other little know languages like JavaScript, Java and C.

There is considerable excitement and interest in the ABAP move to the cloud – but I want to focus here on some other things that interested me regarding the Steampunk project..

SAP’s custodianship of ABAP has ebbed and flowed over the years.

In the 1990’s SAP were all-in on ABAP and we saw the language grow and evolve with each succeeding release. But in the early-2000’s, as SAP started to broaden their portfolio, other languages grabbed their attention and – in my opinion – SAP left ABAP a little unloved. Maybe they thought it was “done”.

The move to S4/HANA and the cloud would have seen SAP reevaluate everything they do – and how they do it – so I imagine there would have been intense discussions about whether to build a completely new ERP for the cloud or to take their existing ERP solution and make it cloud-ready. I can see arguments for suggesting they did both – but once they chose to build S4/HANA in ABAP  they simultaneously committed to ABAP for the long-term.

In recent times SAP have started to pay more attention to ABAP and we have seen the language start to evolve. Up until now I have only really seen enhancements that help me streamline syntax. Things like inline declarations, chained method calls, string templates and functions, constructor expressions, etc. are all well and good but in the main they have not enhanced what we can do with ABAP – only how we do it.

But with the SCP ABAP Environment we get to see where ABAP and ABAP tooling is going – and we get to see it much earlier than we are used to because in the cloud SAP can deliver innovations quicker and more regularly. Because the SCP ABAP Environment is a subset of the ABAP platform – i.e. all ABAP platforms use the same code line – we can look forward to seeing these innovations in our familiar on-premise ABAP as well. They will just take a little longer to get there.

For example, an enhancement to the ABAP in Eclipse tooling is that you can now open a service in a Fiori Elements App directly from the development tools to test it. Previously every SAP tutorial on building an oData service ended with a multi-step process of firing up WebIDE, creating a Fiori App from a given template, using a wizard to link said template into the oData service, nominate the entity of interest, select what properties you are interested in and where to display them, blah blah blah, deploy app and finally run app to see your data. Whew!

Now it is right-click “Open Preview for Fiori Elements App”.

In the same way the SCP ABAP Environment shows us how the ABAP language is evolving too – and it is something of a departure from what we have seen previously.

Think about how you currently do BOPF, persistent objects, even NetWeaver Gateway services? You essentially fire up a wizard, fill in some forms, hit “Go” and it generates a whole lot of framework code that you then are able to call in a prescribed way. In some cases you can enhance the code but if you want to change things a bit too much you need to go back and regenerate everything using the wizard again. We can argue the toss over how good it is to have all this code generated for us – I don’t like it – but a fundamental issue here is that the code generated is the same old ABAP we could have hand coded ourselves if we had the time and inclination.

These wizards are more a developer productivity aid rather than any enhancement of the ABAP language itself.

The recently announced ABAP RESTful Programming Model (RAP) is a departure from this concept. Rather than have a wizard generate ABAP code the features that RAP uses are built into the language itself.

Specifically RAP introduces a new Behaviour concept that is implemented directly in the ABAP language with corresponding new syntax.

*Source SAP TechEd 2018 CNA216 – A Technical Deep Dive into the ABAP RESTful Programming Model

In the ABAP Developer Tools you can attach behaviours to a CDS view.

You can then code those behaviours using new ABAP syntax such as ..

    METHODS modify FOR BEHAVIOR IMPORTING

      roots_to_create    FOR CREATE booking

      roots_to_update    FOR UPDATE booking

      roots_to_delete    FOR DELETE booking.

For me this is best thing about SAP’s recommitment to the ABAP language and its’ subsequent movement into the cloud. SAP now have the motivation to invest in the language and make it a better toolset for all ABAP developers – not just those in the cloud environment.

And the SCP ABAP Environment gives us the earliest possible look at these innovations as they are released without having to wait for them to filter down to our on-premise ERP system.