In this wonderful software world in which we live it has been said that the best and worst thing about the current state of affairs is the ever-increasing speed with which updates come out.
It’s good because an update brings lots of new things and hopefully fixes existing bugs. It’s bad because it is perceived to bring instability—e.g. every time you log onto an application it looks different and (for example) the menu options may all be in different places.
For example, SAP used to re-arrange the menu tree in the Implementation Guide (IMG, where you customize the standard software) with every release so you had to go hunting around to find an area you could easily navigate to before. Another example is the SAP GUI versions that tend to change icons with each release from a circle to a square and then to a triangle and then back to a circle again, each time claiming it is more “modern.”
A specific example of the latter was that when the “Blue Crystal” SAP GUI theme came out, the icons looked so different that no one could possibly guess what each one meant, even if they were in the same position as before.
There is only so much change people can stomach at any one time. SAP was so happy that they could provide quarterly releases for SAP S/4HANA in the cloud, and then were most surprised when a large amount of organizations said they don’t want quarterly releases, because that schedule means they spend 100% of the time testing to make sure nothing breaks.
What’s That Got to do with ABAP?
Traditionally in an upgrade project—say SAP 4.7 to SAP ECC 6.0—in the project plan there was a large amount of time allocated to the ABAP developers going through the (often very large) custom code base to make sure it all still worked in the new version. Many companies (e.g. Panaya) sell products which help you identify areas of custom code which may well break.
This is needed because sometimes your custom code does stop working or starts to behave erratically in the new version. This, despite the fact that ABAP has always prided itself on being downward compatible to the extent that something written in 1996 should (in theory) still work correctly to this day. Not all programming languages are like that.
The Bad News
If it were such a huge effort to adapt your custom code when the language was supposed to be downward compatible, how much worse would it be if the language is not downward compatible?
This is what you face when going from SAP ECC 6.0 to SAP S/4HANA, for example. SAP has done its best to prevent syntax errors in existing code, but there are just so many changes to the underlying data model (database tables) and application layer (various modules have been removed) that the custom code remediation is going to be a lot more difficult than anything you may have encountered before.
And that is just if you go to SAP S/4HANA on-premise. If you want to go to SAP S/4HANA Cloud and bring some (or all) of your custom code along, then you will find that virtually all of the existing code most likely will not work at all. There, you are restricted to a “whitelist” of standard SAP objects you can use (function modules, classes, data elements, and so on). Previously you just used anything you found. Worse, you cannot directly access tables like KNA1 or MARA; you have to go via a whitelisted interface e.g. CDS view.
The Good News
At first glance, that all sounds rather depressing. Nonetheless you don’t have to take this lying down—in fact, you can proactively fight back right now, so when the time comes for an upgrade (a move to SAP S/4HANA is a conversion rather than an upgrade, but people still refer to it as an upgrade) you do not have a gigantic one-off exercise to perform.
I would advocate two things to do to help prevent the pain in advance, and neither are new—in fact some organizations may have started to do this in the year 2000, and if they did I bet they wonder why other people make a big fuss about SAP version changes.
Favor Object Orientated Programming
The OO version of ABAP came out in version 4.6C of SAP in the year 2000, and 20 years on hardly anyone uses it. The major benefit when it comes to upgrade time is the separation of concerns that a (well-written) OO program has. If the database access is in its own class, and the UI processing is in its own class, then when going to, say, the SAP Cloud Platform, ABAP environment, the business logic part may very well need very little change, leaving you to concentrate on rewriting the database and UI parts which change totally.
Use the SAP Syntax Check Tools
I am amazed how few people run some automated static code checks once they have finished creating or changing a program. What they should be doing is running:
- The extended syntax check and then
- The extended syntax check in ATC mode and then
- The Code Inspector
Most importantly, every single finding should be investigated and either flagged as a false positive or corrected. Moreover, there are two add-ins to the code inspector you can install from GitHub.
https://github.com/larshp/abapOpenChecks
https://github.com/SAP/code-pal-for-abap
A lot of the checks in the two add-ons are in regard to “clean code” which is not about functionality so much as rather ensuring your programs are understandable. Why is that important? Because if you do have to go looking at some code to make it work in a new SAP version, you need to have some sort of idea what in the world the code is supposed to be doing, and a lot of programs are written so cryptically you have no idea.
I have found that, years ago after the extended check and/or code inspector became available in my SAP system, as long as I used them properly, that future upgrades to new SAP versions were never a problem. As a rule, if you have all green lights after running all those checks, your code is pretty much going to work in your target version. There are even special checks for SAP S/4HANA in general, and also ABAP code that runs in the SAP Cloud Platform, ABAP environment (e.g. ADD 1 TO X will give a syntax error in that environment).
Conclusion
When it comes to custom code conversion during any form of an SAP upgrade, there can be a lot of work involved. However, it does not have to be that way—even if your next upgrade is in 10 years you can start right now, today, to start changing your code during the normal day-to-day development cycle so that when upgrade day dawns it is a non-event.
This is not just an academic theory. I have done this in real life. As a result, I wrote an E-Bite for SAP PRESS describing how I handled a custom code migration to SAP S/4HANA. It serves basically as a check list of the steps that are needed and how to handle the weird things you may find at every step.
So if you have an SAP S/4HANA migration coming up in the near—or even distant—future then you should check out this E-Bite.
Comments