In SAP TechEd in Las Vegas Bernd Leukert announced that the SAP Cloud Platform ABAP Environment (Steampunk) was Generally Available.
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.
Published on tip from Tom Raftery (Our SBN Conference keynote speaker in 2017)