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.
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..
Note: Steampunk is the secret internal code name for SAP Cloud Platform ABAP Environment. Don’t tell anyone. 😉
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.
You can see more detail about this example in this SCP ABAP Environment tutorial on Adding Transactional Behavior to Your CDS View.
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.
I went to a couple of sessions on the RAP (Restful ABAP Programming Model) at Tech Ed and I came away impressed. One thing it does is answer the 'Why?' question with regard to the SAP Cloud Platform ABAP environment. One use case is clearly for ABAP developers to rapidly develop OData services.
It's interesting to note the conceptual similarities with the Cloud Platform Application Programming Model (or CAP). It too uses the behaviour extension of CDS (Core Data Services) but the services are implemented in Java or Node.js. Will ABAP developers familiar with the RAP go on to use the CAP?
Where I struggle to share the vision is with the tooling. Of course every speaker at Tech Ed used only Eclipse (a.k.a. AiE or ADT) in their demos. Yet when they asked how many attendees were using Eclipse only a few hands went up. I've started using it myself, but I'm yet to really feel at home. In my head I 'know' it's the future but my heart disagrees.
We're told that the RAP has been build to stay relevant for the coming decade(s) but I'm not sure we can say the same about ADT. I'd be interested to know your thoughts, Graham Robinson
I've been using ADT for a little over a year now. It takes a couple weeks to get used to the differences from SE80, but once you adjust, I think it's clearly a superior IDE. The Quick Assist tool (Ctrl+1) alone is worth the switch, plus there are a number of other significant improvements over SE80. If you still do much development in classic dynpros then you'll still need to jump back to SE80 (or open SE80 in an embedded GUI window within ADT) to access the screen painter, but for most development, ADT is definitely the way to go.
There are also some things that can only be coded in ADT (e.g. CDS views); that, combined with the fact that no new features or bug fixes are being developed for SE80, makes me think that ADT really does have some staying power.
This looks great: RAP and CAP but I fear it will be many years before I see customers using sap cloud and abap in the cloud. By which time we’ll have different programming models.... 😉
Did you hear of any timelines for the RAP and onpremise systems??
According to my knowledge it is planned for 2019 but not confirmed. As a transition for currently built business objects (FIORI programming model) to RAP seems to be planned for 2020, it should not be too far in the future. Hopefully!
Thank you for this great blog and for sharing your experience at SAP TechED LV.
I think that ABAP in the cloud will ease the way for companies who want to accelerate their way to the cloud while also leveraging its ABAP developers' experience. It will surely enable them to be more agile if they want.
I know big companies sometimes are slow movers as the above comment states but in our increasingly digital world, they are being forced to think again about being faster. It is good to see SAP supporting that.
Cannot stop from being a bit sarcastic ...
ABAP Restful model ... Save investments, integration planned for 2020 ... mmmm ... from wikipedia about REST - "...The term representational state transfer was introduced and defined in 2000..." ... Yeah ! Nice !
No, I do agree that the platform is evolving, there are many cool recent improvement indeed, it is getting better, I just don't understand so much celebration about catching up some of 10-20 year old technologies. This sarcasm is not towards this post or author but rather to general presentation approach of sap.
And, yeah, just not to forget. If I remember well trial of SCP ABAP costs 6400 EUR per month if I understood well. Very affordable for any community member of course 🙂
Sorry, maybe I'm just in a bad mood today ... just ignore if something wrong.
I hope they have a lot more ABAP badges for Teched Barcelona!
yeah well, it's a bit different with business software - you'll see once you get a bit more experienced with business software. This is not a company that just started. How old is now, 50 years? A lot of that old software has to continue working.
REST is already supported since 2010-ish as an ODATA service with ABAP and SAP Gateway, so it's not that late (not to mention that 2000 was the research paper followed by a standard in probably 2004 by W3). And it's not like there weren't alternative technologies for HTML applications in SAP. REST is not necessary to SAP, because you have everything you need there. REST is necessary to other data consumers than SAP.
Just for the sake of discussion ...
Had seen a few 😉 But I believe that SAP cannot be regarded as an "ordinary" business software. It is a platform for good half of large enterprises in the world and stated to be #1 EU IT company. So there are more strict demand to them. Google, Amazon, Oracle and MS are constantly presenting something new but not so "celebrative", they just deliver innovations and quite frequently in a more affordable manner (well, imho, at least from what I can see, not pretending to have the best view point to judge).
And talking about REST specifically ... it is a mainstream at the time being, but there are some recent tendencies to criticism and decline, whereas new approaches like graphql gain appreciation. So ... I suspect that by 2020 REST might (might!) face it's starting sunset ... looks very like fiory and jQuery story. Although, frankly, I think it is most pessimistic scenario ... on the other hand how quick the real business will adopt the new releases that have new REST features ? "REST is necessary to other data consumers than SAP": I mostly agree. However clouds are a lot about interoperability, so good tools for this would be nice.
It says "Recording from TechEd 2017" but I can't find any useful materials on the topic.
Excellent post and thanks for sharing!
all is good but please for god's sake allow development of ABAP in SAPGui... all these crutches are solutions to a non existing problem with SAP - it was always a "cloud" platform with a dedicated client.
ABAP for the next 10 years and it will be a fantastic adventure and journey