Technical Articles
My open questions from SAP TechEd 2020
In random order,
A: ABAP public APIs
As an ABAP developer, I’d like to start moving my code in a direction where it is more compatible with the public APIs offered in Steampunk. To help the ecosystem move in this direction, I think it’s long overdue for SAP to publicly share the list of objects which are considered part of the public API.
Will SAP publicly share the ABAP public APIs?
Sure, I can sign up for the Steampunk Trial, and log into Eclipse to search, but I’m thinking more in the direction of something similar to https://devdocs.io
And like all other platforms, public APIs is a moving target, they will change over time. And some parts of the public APIs will be available on some BASIS versions and some on others.
The first step will be sharing the list, then tooling can be built to help the developers.
B: ABAP/HANA trial versions
Trials have been an ongoing topic for some time, but only in relation to the cloud. I’m personally more interested in the future of the trials for the core offerings ABAP and HANA,
The latest HANA Express is getting close to a year old
The latest SAP NetWeaver AS ABAP Developer Edition is more than a year old
Where will SAP be moving these in the future?
I do not see the Steampunk trial as a replacement for the ABAP Developer Edition, Steampunk is basically a different platform, with a limited(?) user/customer base compared to the more traditional ABAP AS.
UPDATE SEE: https://blogs.sap.com/2021/02/15/sap-abap-platform-1909-developer-edition-available-soon/
C: AMD/ARM CPU support
During the last year, a lot has happened in the CPU industry, AMD has gained the highest market share since 2007, and both Apple and AWS has introduced new ARM CPUs.
Will SAP support running HANA on AMD/ARM, and ABAP systems?
This could potentially lead to savings for a lot of customers(?), both AMD and ARM does need to put more work into the high-performance area, but I’m sure we will see this move during the next year.
D: Keeping the Core Clean
It is my impression that SAP suggests moving developments into the cloud, which is okay in itself.
But if the on-premise ABAP system is a mess, it doesn’t help to move this mess to the cloud, the result will be a bigger mess with more systems and integrations(which, to me, are more difficult to test/develop and debug).
Will there be any tooling/recommendations/guidelines to facilitate this move?
If the code in the on-prem ABAP system is nicely separated and organized, it feels clean to me, it doesn’t have to be in the cloud to be clean?
Take a clean(?) ABAP program like,
FORM list RAISING cx_salv_msg.
SELECT * FROM vbak INTO TABLE @DATA(lt_data).
cl_salv_table=>factory(
IMPORTING
r_salv_table = DATA(lr_alv)
CHANGING
t_table = lt_data ).
lr_alv->display( ).
ENDFORM.Would it implemented in the cloud, look somewhat like:
Sorry, not a fair comparison, but the on-prem ABAP systems are not all disadvantages, it also has advantages to keep logic and data close.
Let me know if I missed/misunderstood something, comments welcome below 🙂
I have mentioned this before and never tire of mentioning it: technology has to be easily accessible! This includes trial versions and documentation!
This is necessary so that we can inspire younger developers to work with SAP products, especially ABAP. Without new developers there are no fresh ideas and no one who maintains the legacy code.
It also means a more than serious problem for entire branches and industries. If you as a company have developed important processes in ABAP and there are only a few developers left, then you either cannot get them at all or only for an incredible amount of money. About the money that wouldn't be so bad for the developers 😉 But that also immediately reduces the attractiveness of ABAP for a company to use further 🙁
Point D does worry me a bit. The phrase “developer choice” was frequently used without anyone questioning whether it was necessarily a good thing.
If you author a solution using 5 different technologies, you generally need 5 developers to put it together. You then have multiple points of failure and the need to have all 5 skill sets in your organisation while the solution is still valid.
As an ABAPer who spends a lot of his time finding the best way (rather than just a way) to accomplish something, I don’t see choice as unequivocally a good thing even in my own language! I suppose my worry is: if you have an ECC system and some in-house ABAPers who understand your business and your legacy code intimately, why should your journey to S/4HANA risk losing that core competency in the name of choice?
Andrew
That is a very good point. But I look at it with another perspective. These are only my opinions, based on observations during my time in the SAP ecosystem.
There is a shortage of developers in general. Having more options, opens up for onboarding more developers using their existing skillset, rather than trying to produce ABAPers before getting them productive. By placing them in an appropriate part of the stack, we can leverage the positive effects of getting them in the ecosystem. To your last point, you are absolutely correct. There should be no question about the value of the experienced ABAPer, that know the business and legacy code. And if the journey to S/4HANA is risking losing this person, they are doing something fundamentally wrong.
There are definitively some challenges and added risk, by adding more technologies to the stack. But all in all, I see this as a positive move. I have experienced a lot of ABAPers having almost an existential crisis, with an overwhelming amount of change rushing into the SAP space, over relatively few years. I've had conversations, where ABAPers have become almost hostile, as they felt threatened. ABAP will be the heart of SAP ERP for the foreseeable future, and there practically nobody challenging that. The important part of all this is communicating how important the ABAPer still is, and that this isn't question of ABAP OR <insert technology>, but ABAP AND <insert technology>.
best regards
Ronnie
Sometimes cloud is the answer, sometimes not. Sometimes ABAP, sometimes not.
It feels difficult to navigate, and correct answers are also different for different organizations.
Hi Ronnie,
I'm interested that you say there is a shortage of developers in general. I don't see this in the ABAP market. We now appear to be 10-a-penny, especially here in the UK where most ABAP development has been off-shored.
The other problem we have is that the choice of which technology to invest in is often made by people who read Gartner summaries rather than those who will have to work near the coal face. The shiny and new is often held above the established and dependable, because the mantra that change and choice are good (or even essential) goes unquestioned.
I was particularly encouraged by the Lab preview of Embedded Steampunk for S/4HANA Cloud at TechEd. When the customer is given an environment in which to do their side-by-extensions and already has the ABAP skills, I hope the temptation to unnecessarily look elsewhere will be curtailed.
Cheers,
Andrew
I admit that my perspective is coloured by my observations in my own market. And also by my field of work, as primarily Fiori and SAP Cloud Platform developer. Here it is a developers market, also for ABAPers, especially those who master modern ABAP. It is interesting that there are large differences between the different markets, even though they are fairly close.
I totally agree on the challenge with where the decisions are made. It is also connected with the challenge of decisions being made on a per project basis, making the landscape an even large patch work of technologies. Nobody is looking at the bigger picture. ?♂️
br,
Ronnie
I'll add one point :
In case of many alternative technologies/solutions, there is a great risk that SAP will just decide to abandon this technology/solution over time (and w/o any migration plan), so customers may lose all their assets.
That used to happen one or more times in the past..
ABAP is like the sun, it will keep shining for a million years 🙂
I remember some discussion when the Java stack was introduced (dual stack topic). Some people said to me: Everything will be rewritten in Java. Forget ABAP and learn Java. That may have been 16 years ago. Same people have their whole logistics processes still in SAP ERP on prem in ABAP 🙂 I personally don't think someone will invest the money to implement same processes in Java. Maybe if there are additional benefits, but not the same already done stuff.
I can see lots of potential benefits in reorganising code in separate units with good CI support. And since that would require a rewrite, you could as well do it in another language.
But if you do it in one go by the time you have an MVP we are all retired, forget paying back the investment.
Rewriting a bit at a time, moving non essential logic out of the core server looks like a much better strategy, and that works much better if the core stays ABAP for the time being
And I still would like to see that Python stack on SCP just as a play ground?
I think that's fine for a demo, to make the point you have extreme flexibility in choosing technologies. Being able to choose is great, how you use your freedom is up to you.
Under the surface I think there's a serious issue: SAP would like customers to move to the cloud where traditional ABAP is not an option.
Steampunk is, but requires significant developer upskilling, and its main selling point is access to ABAP APIs (see point 1 above for standard ones, custom ones can't migrate to the cloud anyway), which imho makes it a bit of a hard sell
It's a hard choice. Why learn something else when what you are using is working. In the US there are a lot of ABAP Developers. And then a lot of things ae sent off-shore.
My issue is I come from a small shop. Two developers. Me and my boss. So if something goes wrong it would be nice if we could both support it.
Now to move to different technologies. I just love to learn. But I like to be productive after I learn something. What to do... What to do... My first choice was CDS views. They are a lot like ABAP. Then on to AMDP. Then the things I have to learn like BRF+ and flexible workflows. They all sound like regular SAP languages don't they? With CDS views I can easily build a FIORI application. Cool huh?
Steampunk made me cheer. ABAP became more feasible to use in the future. I believe people are listening.
So losing the core? Well right now what I'm doing is mostly using the core ABAP competency - even with all of the above. With Fiori as our base, it won't be long for me to use SAPUI5. So you start to use less ABAP. I am on-prem.
I believe in learning. I really believe in being proactive. We moved to HANA and I had to quickly start using things BRF+ (older but new to me), CDS Views, Flexible workflow... So with that in mind, I still suggest being proactive. If you are moving to HANA pick up some of these "Not really new languages". ABAP based.
Adding more languages? Cool, because my guess is there will be more of an option to buy solutions to our problems. Value of a person who know the business process and ABAP. Invaluable. This is something that I don't think will ever die. SAP just has too many lines of code and investment in it. I think they heard us too. Steampunk now seems like it is viable.
Also cool is knowing what to use and when. So picking things up at a high level until you use them is probably a good idea. At least that's what I do. I doubt I'll ever stop developing in ABAP. I do believe I'll be using a bit more than just ABAP. Why? We are a small shop. We don't have the budget for UI developers and ABAP developers, and... Well you get the picture.
Great comment, Andrew! There was an interesting study that determined when an ice cream shop offered only a few flavors (e.g. chocolate, vanilla, and strawberry), the customers were much happier about their choices than when a shop offered 24 flavors. This seems odd at first but then imagine yourself contemplating 24 choices, then getting one and still wondering of one of the other 23 might have been better. 🙂
It's good to have choices but too many choices create the issues like above. Also, what I find SAP is lacking most of the time is guidance on making the choices. "When to use what" is the most coveted information in SAP world yet it's most difficult to find. (Some product managers do better job with this than others.)
To provide such information, you'd have to acknowledge limitations of certain product or functionality. And I find SAP people are mostly scared for their life to disclose this. Only at TechEd in person, you might get such scoop off the record. And it shouldn't be like that, in my opinion. Because the customers will find anyway when something is not working or working not as advertised. So there is no reason not to provide better guidance, IMHO.
I wonder what is the reasoning behind SAP trying to sideline ABAP every so often?
Are they? I mean they have now got Steampunk. That would work on the cloud. Me - I'm on-premise, so I've always had different options.
I had been thinking they were sidelining it last year. But... Steampunk. I'll admit right now that I've never used it. And I'm not sure how it would work.
And years ago I bought a JAVA book. It's got a lot of dust on it right now.
ABAP got a lot of mentions at TechEd, so I dont think it will be sidelined, its here to stay 🙂
That's right but they attempted to replace it with Java back in the day and now CAP is a bit of a competition to RAP and is more promoted by the SAP 'influencers' on Twitter. Just my feeling.
Steampunk has been around for a couple of years now. SAP had too many external names for it in the initial 6 months, so I think they've given up trying to remember what it's supposed to be called this week and just refer to it by its internal name again.
It's all very well SAP bigging it up at TechEd, but they need their people to sell it and their clients to buy it. It definitely sounds like they're going to give it a bigger push now, unlike last year where they seemed to be deciding if they were going to seriously carry on with it or not.
There are good courses on openSAP which use Steampunk, so it's much easier to learn than Java 🙂
🙂 Isn't that normal. They rename about everything. I agree with you and Lars. They seemed to promote ABAP & Steampunk more this year than in the years past. I like Steampunk as a name. So I doubt they will keep it.
I believe the name de jour is "SAP Cloud Platform ABAP Environment". Even though it's long and confusing, I rather wish SAP would just settle on a single name. Otherwise it's very confusing: all the TechEd sessions are like "Steampunk!" while this name is nowhere to be found in all other places. Just pick a name and stick with it, for cripes sake.
It's funny how goodness forbid a customer puts a space between "S/4" and "HANA" yet at the same time it's OK for SAP to call the same thing by completely different names.
Steampunk forever (as name)!
On item B: ABAP/HANA trial versions - specifically the HANA Express parts. Of course we do have HANA Cloud trial on SCP. It is completely free and a full, private HANA instance. And it gets constantly updated as a managed service. So for cloud-based HANA developer trial access it has become the recommend path and I personally think it provides a great, very low barrier to entry option to get started with HANA.
That said we want to continue to deliver both a cloud and a local installation/on premise option; the local installation option being HANA Express. I spoke with the Product Manager for HANA Express and the hope is still that we can deliver an updated version of HANA Express for SPS 05 sometime in Q1/2021. Mike Paola has given some updates on the future plans for HANA Express here: https://answers.sap.com/questions/13142484/is-it-possible-to-get-an-date-on-the-hana-express.html
Thanks for clarifying the HANA part 🙂
Hi Thomas,
if not Santa then maybe Easter Bunny will bring us the SP5 HXE, and
as always, thx for checking with the product team and sharing it here, with us.
gm
The main branch in which I work is health care, I have two concerns.
With my impression "the solution for everything (and the only path) is the cloud", something very controlled as downtimes (for upgrades, for example) will cause a very big impact.
We are talking about a system with people and integrations working 24/7 in it.
To be more specific (with a huge example), all the public hospitals of a region of Spain are working with SAP, and all the pharmacies of this region are connected to SAP.
With the cloud, you lose control over downtime.
The other thing, I learned working in different health centers, is that all have different processes and, also, regulations. So many enhancements needed to be done in the core. An example will be that you can't (or you should be warned) to schedule surgery (depending on the type) without a previous anesthetic evaluation. You can't check it in the cloud if there isn't a BAdI for that.
This is a very obvious case, but there are more complex cases, as I said, based on the institution or the regulation.
I hope SAP (and Cerner here) thought about those questions.
Amen!
Also my few words about the B part:
In my opinion the whole trial situation is pretty good especially when I remind myself my beginnings in ABAP world in 2016. I started before Julie Plummer blog post about installation 7.50 SP02 - in this time I think that only official available version (of minisap) was 7.0* something, so you was even not able to use may new statements. Since this time everything changed, and we basically get regular updates of trial versions, and newest one are sometimes even more complex one (like in last version i was able to install business content). I see 2 fields of improvement here:
Br,
Pawel.
I think on-prem is cool only if integration capabilities become a bit easier. Nevertheless cloud offers various programming languages.
There are so many different reasons for On-Prem. Integration hasn't been a problem for me. Although to be fair we haven't integrated with very many apps.
I could go on, but you get the point there are advantages and disadvantages to both. I was concerned at Teched when they thought most of us would be moving to on the cloud instead of on-premise. On-premise would be migrated. I don't think that will happen. Again keep in mind I'm talking core SAP here. Now things like analytics do make sense to move to the cloud. We have in fact purchased the cloud version.
About item B, I’m told that there are plans to release a new version of the ABAP trial/dev edition slated for January, 2021.
Cheers,
Rich Heilman
Looking forward to it. Will it be quantum-safe, Rich?
Mr. Rich,
Do you think this is actually going to happen? Some time back it was clearly stated that the last ever ABAP standalone system was going to be 7.52 which was released in Jan 2017 and is in some senses about ten ABAP releases old (if you count the quarterly releases).
All well and good if everyone was going to ABAP in the Cloud tomorrow, as that is always up to date. However I am not sure everyone will be going down that path. Eventually maybe, but bear in mind 20 years after it was available most ABAP programmers still turn their noses up at OO programming.
So leaving the cloud out of it, is the reason for no more standalone ABAP systems a technical one (which I doubt) or a political/marketing one (i.e. if you want to see what an ABAP on-premise 7.53+ system looks like, then move to S/4HANA!)
Cheersy Cheers
Paul
Yes, there has been a slight delay, but I do believe it is on the way.
Cheers,
Rich Heilman
https://blogs.sap.com/2021/02/15/sap-abap-platform-1909-developer-edition-available-soon/
Thanks for sharing, Lars!
On your point A (APIs), I'd expect this to be part of API hub because that's where other API information is. That hub is not bad, actually, as long as you can find what you're looking for. 🙂 The only issue with it, it seems even though API is literally in the name, SAP has been piling up more content there which seems rather unrelated. E.g. in the Content Type we can see "Business Process", "Events", etc. Don't quite understand what it's doing there.
On D, I agree with you and personally, find some statements about moving "to The Cloud" rather confusing. E.g. one session said something like you should already start using Cloud (limited) syntax even in on-premise system and create cloud apps / extensions for on-premise systems using SAP CP to glue it all together. But my immediate reaction is: why would I do that?
S/4HANA on-premise I believe will still be supported until 2040 or so. That's a long time. What business benefit will be gained by not taking advantage of simpler development in on-premise environment? I agree that there are definitely scenarios when a cloud app / extension would be suitable but I wouldn't issue a blanket statement about it because this needs to be evaluated on case-by-case scenario.
And in the heat of a technical discussion it's easy to forget that in SAP world, technology needs to provide a business benefit. It's very difficult to get a sign-off from the stakeholders for any tech initiatives when the benefit is not clear. This is where SAP doesn't always help us with the answers.
P.S. Could you please add "SAP TechEd" tag to your blog? I've almost missed your blog, thank goodness for LinkedIn. 🙂
A: I’m not thinking in the direction of integration between systems APIs, which I guess is the purpose of the API hub(?), but instead the ABAP artifacts that is allowed to be used/called inside the system.
“SAP TechEd” tag added, thanks
Why would a company like to loose it's developer ecosystem and technological asset? Would Apple ever drop Swift because Java is free and Scala just better? NO
ABAP gives tremendous flexibility to SAP and is a proven tool with 5 million developers. ABAP is evolving and should continue the evolutionary path. Well when I was in college doing B.Tech in Computer Engineering even I was crazy for C and Java that's normal because they are free stuff you lay your hands on, ABAP is not free and so is Swift and those who know the value will pick it up and master. So, show the value of SAP and it's software and people will follow don't chase the people and drop ur standards else soon u will have to write the next gen ERP on java script or something crappy!
C: HANA on AMD EPYC announced in https://www.youtube.com/watch?v=ECHhuvuiNzs
C: almost two years later, some updates at https://blogs.sap.com/2022/09/30/sap-hana-cloud-to-support-arm-based-aws-graviton-processors/
Perfect! Thank you.