ABAP to the Cloud
This morning Bjoern Goerke, SAP’s Chief Technology Officer and President SAP Cloud Platform, announced at SAP TechEd in Las Vegas that SAP are going to make the ABAP runtime available on the SAP Cloud Platform (SCP).
ABAP has been a bit maligned over the years for not being ‘cool’. Maybe this is partly because simple consumer style apps for the smartphone are more hip than enterprise applications? Maybe it is because SAP lost a bit of interest in ABAP during some of the noughties? Maybe it is partly because we ABAPers are not always great representatives of the language? Maybe you can think of other reasons?
But those of us who have kept up to date with the latest ABAP features, and the roadmap, will be aware that ABAP continues to be enhanced and improved to support the current and emerging needs of the enterprise.
ABAP might not appear in the RedMonk Programming Language Rankings but it is a great language for building enterprise applications like S/4HANA.
What is often overlooked when discussing ABAP versus other languages is the amazing capabilities built into the ABAP runtime environment – capabilities that ABAP developers can take for granted. Things like security, workflow, content management, etc. provide enterprise grade features that the ABAP developer can simply make use of as needed.
Another amazing technical achievment is that ABAP is “backwards compatible”. This means ABAP code written decades ago, in some cases on an R/2 system, still runs correctly on the latest ABAP stack. An amazing achievment but also an amazing legacy.
A cloud platform needs to support multiple users running multiple applications across shared computing resources. The cloud platform therefore needs to guard against a rogue program adversely impacting the platform as a whole.
Therefore we can’t expect a simple lift and shift of your on-premise ABAP runtime to the SAP Cloud Platform. The ABAP runtime for SCP will need to be locked down to protect the platform itself, to protect other SCP applications and users, and to protect ABAP developers from themselves.
So when building ABAP applications for the SCP ABAP runtime I expect some pretty major changes.
All those old ABAP language features that are really only there to support those legacy applications written last century probably wont be available. Lots of them are already deprecated – expect them to totally disappear on the SCP runtime.
I expect the compiler to have a whitelist of available language elements for the SCP runtime. I also expect that access to the runtime features we have gotten used to will also be whitelisted. SAP will pick and choose which features, API’s if you prefer, will be available and which wont be.
Does all this sound a bit nebulous? Then let me give you a very specific example.
SAP’s roadmap for UI technology is all webservice-based. i.e. oData (or similar) web services being consumed by whatever UI technology the developer chooses – but from SAP’s perspective they would like you to choose SAPUI5.
So I expect the SCP ABAP runtime will probably not contain any user interface technology built in. No SAPGUI, no Web Dynpro, nothing, nada, nilch. The WRITE statement might not be on the language element whitelist.
We will use the SCP ABAP runtime to execute back-end processing functions that we will expose through web services – most obviously for extending existing on-premise Business Suite and S/4HANA implementations.
Like me, you probably have lots of questions. Feel free to share yours here if you like. I wont have the answers but I am pretty confident someone from SAP who does will be tracking the comments. 😉
*Update: Post your questions in the FAQ blog.
I think ABAP on SCP is a big topic. Will those SAP GUI transactions to build/admin/trace SAP Gateway services be ported to a kind of "Admin Console" on SCP?. Only one of many questions I have. I mean, there is no SAP GUI, so, how can I achieve those tasks?
Thanks!
Hi Leonardo!
There should be an Administrator Dashboard available from the SCP cockpit, but this is still in progress. And yeah, there is definitely no SAO GUI anymore.
Cheers, Inna
That's a really good news for we abapers. Congrats SAP for this smart decision. It makes all sense to have the abap runtime on SCP.
It's a BIG DAY for all ABAPer
Hi Graham,
good summary. I also feel the same way, but I'm saying right now it is the right time to bring a new "dynpro"-painter into the game. Everything is prepared and the last piece to make a 360 degree view is the UI.
So let's see what happens and I hope to not put everything into an Odata-Service in the future.
~Florian
Thanks Graham for sharing this. It's really a big change for ABAPer's and SAP Developer community.
Cannot agree more!! Great news for ABAPers.. Thanks Graham for summarizing and sharing!
Great article, well written and interesting news. Good to see that ABAP is moving with the times, and it'll be interesting to see what benefits come.
ABAP isn't cool because it's dealing with business transactions. There's a ceiling value of coolness when dealing with "I want to buy x widgets from vendor y at a rate of z gbp/widget". You can have the sexiest interface going, but ultimately you still need to render that information to the user.
With regards to mobile apps, they are great, offer convenience and speed, however, the sort of detail that most of the ABAP transactions have traditionally had to present are more easily navigated with a desktop, rather than an iPhone.
As for putting it into the cloud... well, I'll wait until I've seen it and the benefits it confers before I get too excited ;D A lot of the success will depend on user adoption, but looks like we've got plenty of enthusiasts here, so I'm optimistic!
I've got mixed feelings on the "no write statement" comment. It's often useful for those quick and dirty test programs, but I guess the next best thing would be that you write and call an API that publishes data to the test harness and no more that.
And as for the RedMonk ratings, that's based on pull requests and StackOverflow, so it's not really representative. Pull requests are a poor indicator because generally ABAP isn't pulled/git'd, and StackOverflow because, well, we've got SDN and that's the go-to place that'll cover the majority of issues, and then maybe SO... Best Regards.
Regarding “quick and dirt test programs”, I also expected to see a ABAP REPL on SCP. If it happens, we will be able to test programs just like we did in JavaScrip on Console.
Thanks for your comments Patrick.
It would be nice if more ABAP projects were published on GitHub - wouldn't it? 😉
abapGit - so easy
When I was developing my first application using SAPUI5 and GW I had a vision that ABAP is PERFECT for backend and “not so perfect” (ok, I’m using an euphemism here) for frontend. Today your blog corroborate my vision.
Very excited to see next steps!
Hi Graham,
Very interesting article.
You ask for more reasons for ABAP not considered to be “cool”. IMHO the most important reasons that ABAP is left behind other languages like Java are less language specific than dev platform and dev process specific and I appreciate your opinions about this topic.
In spite of all the progress and enhancements of ABAP as a language, the concepts of the development platform did not change in the last decades. The most important impediment for ABAP as a development platform is the centralized code base inside the runtime system. This is the root cause why ABAP development lacks many features of modern software development or at least makes it extremely costly and time-consuming to adapt modern methods.
Compare the flexible and powerful features of git to the limited object based change history of ABAP.
The build-deploy-cycle common to almost all languages except ABAP enables developers to do continuous integration and continuous deployment. All this is the fundament both for long-term quality measures like refactoring and TDD on the one side and for agile development on the other.
No feasible way in ABAP to do automated continuous integration e.g. with Jenkins. TDD is much much more costly than in other development platforms. As blogs show, TDD in ABAP does not have any tradition although AUnit exists for ages. The root cause is similar.
No way to branch your code for a time consuming development task, to develop and test this branch isolated from the rest of the work of other developers and to decide to merge it back to the main “master” when you are done.
Of course the ABAP way of development enables a quick start, is good enough and a good fit for smaller, short-termed projects with few developers for one customer.
But coming to cloud development and long-term agile solutions, for me the really interesting question is if ABAP will be file-based and versionable in git (along your SAP UI5 code) and deployable into the runtime - not manually, but by a Jenkins job that runs the AUnit tests afterwards 🙂
Björn Goerke only demonstrated an import from GitHub into the ABAP system. Besides this everything looked like the old concept of code living inside the ABAP system.
Regards
Rolf
Thanks for your comments Rolf. You make some valid points.
Rather than respond directly I will refer you to the post abapGit - so easy and ask you to have a play with abapGit - if you haven't already. It's not perfect - but it is a start.
Cheers
Graham Robbo
Hello Rolf,
Good points.
The development in other languages and platforms always allowed you to work with some best practices or development techniques.
Git repositories when you have changes in parallel for the same objects, with different tracks for development of new features and support of existing ones.
Automated Unit Tests, Build server, Pipelines, just to list a few.
As shown in the Keynote, Git support seems to be on its way to the standard AS ABAP. Let`s see what SAP will do with it, if build it from scratch or use the Open Source abapGit - BTW, thanks Former Member .
On automated testing, we already have AbapUnit for ages but it was hard to tackle the dependency nightmare, or to just skip one part of the code that wasn`t really testable.
This is about to change now, since SAP is delivering a lot of enhancements on this topic, like Test Doubles, eCATT for OData Services, OpenSQL Test Double Framework, CDS Test Double Framework, ABAP Test Seams/Test Injection. For those who attended TechEd, session S4H232 presented all new capabilities.
As this test framework becomes more powerful, the next step is to provide tools to create pipelines, their steps, like: automated unit tests, automated transport to test environment in case of success(deploy), automated integrated test (eCATT) and finally, deploy it into production.
For me, the hardest part is to change the mindset of the ABAP Developers who never heard about those topics, like TDD, CD/CI, Agile, and make them interested in these "new" techniques.
Regards,
JN
Could you please explain why short term. We have complex big projects with teams working on parts.
Hi Prasenjit,
in applications with long-term support over years with change requests and enhancements, regression tests become very costly if these tests cannot be automated, and TDD is widely accepted to reduce these costs. Furthermore, on the long run substantial refactorings become necessary to keep quality high. Refactorings need both a very good (XUnit) test coverage and tool support. Without these preconditions, refactorings will not happen and software quality will decrease.
Regards
Rolf
Hi Rolf,
I agree with your comment and with the technical reasons for ABAP not being popular.
But for me the major reason for ABAP being not popular is that is not (or at least not easily) available for interested developers. Especially for pupils or students! Or do you know anybody who started ABAP development as a teenager on his own? I don't!
Cheers,
Martin
Well said Martin!!!
I work in integration projects using SAP PI/PO. I see many PI/PO consultants who struggle to write proxy coding(methods and classes). This is one of the major reason why they are not able to do so.
if they get anything in java, even they dont know java, somehow by googling and running some samples in eclipse, they managed to learn and achieve it.same goes with xslt, xpath, groovy script and java scripts, these are used mainly to write functions in PI/PO and HCI.
and developer key thing, it really sucks.
So, is it SAP and PI/PO product and ABAP to blame or the quality of these fake PI/PO consultants to blame who rely on copy pasting. Client should then hire a smart intern who can copy paste than paying up these people. Actually they even don't know Java and Groovy because you only said they will copy code in that language too.
Yep. Instead of hiring smart intern they should hire SAP certified intern, SAP certified folks can do much better than others 🙂
SAP certified people wont copy paste, they are original.
Yes I hope so because if you are certified you should have the dignity not to copy paste or completely depend on it. If that was a dig on me well I am a proud developer who may ask for help but my job is not on the mercy of google and coipy paste I have the brain to write my own code 🙂
Agreed. you have the brain to write your own function module to create SO PO...
No wonder why sap support team asked me that if am certified or not when i was raising incident for product bug.
May be let the people to participate in sap community who are certified. Others can stay away from this community/sap/abap.
customers are fooled that certified people can do better than non certified people.
Hi Martin,
Very interesting side effect. Even more for interested Java developers who write an SCP extension and want to know ABAP so they can debug and later fix and finally write the backend code they are calling.
The main point that is commonly missed is that ABAP primarily is not a programming language but a platform. An integrated and closed platform bundling several concepts from the 80’s when 4GL concepts were popular, and a 3GL language (with procedural history and OO attachment) and several 4GL tools+languages (DDIC tools, Open SQL, CDS Views, Gateway, BOPF, lifecycle (activation), transport logic, centralized code base baked within the server, …)
I do not see any evidence that these concepts are needed and useful for cloud development.
But I stay tuned, it is very interesting.
Regards
Rolf
"The main point that is commonly missed is that ABAP primarily is not a programming language but a platform. An integrated and closed platform bundling several concepts from the 80’s when 4GL concepts were popular, and a 3GL language (with procedural history and OO attachment) and several 4GL tools+languages (DDIC tools, Open SQL, CDS Views, Gateway, BOPF, lifecycle (activation), transport logic, centralized code base baked within the server, …) "
In cloud ofcourse form based services are not there. Moreover if 4GL features are there what could be the negative.
Hello Martin,
When we talk about ABAP popular or not isn't it also worth noticing that ABAP unlike JAVA or C++ is not offered in the open market foir free and general useage. It's a proprietary language for SAP products as Swift is to Apple (Ignoring what IBM is doing with enterprise Swift). So, ofcourse when a significant portion of people can not lay their hands on it, you can not use same metrics of measuring popularity. But within the SAP environment it is clearly the language of choice.
Further when merits of a language are discussed, i think it's the right tool for right job right? C/C++ family for operating systems and system level programming, Java mostly application and backened web server, Java Script for web; similiarly ABAP for SAP bbusiness product programming because they have refined and created a language that serves our purpose brilliantly. Also compared to any modern language ABAP is either right there at the top or at the same league. There are far more brilliant features and integration than Java, etc. Isn't the entire Fiori app development with ABAP a magic.
Those who don't like ABAP should go and try new languages in new products and new ecosystems. Who is stopping such developers after all it is a free economy.
Regards,
Prasenjit
But for swift at least i have this
https://repl.it/languages/swift
ABAP is tightly integrated to SAP products and enterprise applications are not flashy like iOS app development that is the first point. Second it is not required that teenagers should baptise with ABAP in their programmer's journey there are tons of languages to start with like say C/C++, etc.
I don't think it is that big a reason. May be wrong analogy but still to be a surgeon you don't need cadavers while growing up to play with.
I think if you compare , ABAP is a better platform withj faster ease of development thean anythging out there compared to Java based products. The only thing is like the version and revision control things which should be a matter of time to arrive on AS ABAP.
Former Member
IMHO you do not have an idea about modern frameworks like spring boot or JHipster. The times of J2EE 2.x are over for many years.
Just reread James Wood’s blog. https://blogs.sap.com/2017/10/04/abap-in-the-cloud-is-this-a-good-thing/
The cloud development everywhere, not only Java, is becoming more and more lightweight and serverless. CI, CD fully automated are a MUST. Containers overtaking other virtualization concepts like virtual machines. The concept of a heavy platform with everything including code coupled indivisible to the platform and server seems anachronistic. But as said before there will be a niche.
Hi Graham,
I was literally thrilled when I saw the video on youtube :). Amazing news and a greate opportunity for ABAPers. SAP has done it's deal for us now it is up to us to max use it.
Thank you.
Prasenjit