Recently, we asked you for your ABAP questions so that Paul Hardy, SAP Mentor and author of numerous ABAP books, could answer them. Here’s what he had to say.
Q: What’s the next “hot skill” for the ABAPers who want to stay current and avoid losing their jobs?
I would also note the Cloud Application Programming Model (CAP) as a non-ABAP technology which you really need to learn about. I will expand on this in an answer to a later question.
Q: Most of the function modules are not released by SAP and still we see heavy adoption of it. SAP has not released any changes in them. Why not just release them?
It is no secret every single SAP customer uses tons of “unreleased” standard function modules. However, SAP only provides support for released function modules. So if you have a problem with an unreleased function module you cannot raise an incident. So if SAP released all the standard function modules, they would probably have their help desk overwhelmed, which is not good for anybody. In fact SAP’s position going forward is to stop people using unreleased function modules altogether, which leads on to the next question.
Q: What is new and what kinds of changes are there to ABAP in the SAP Cloud Platform, ABAP Environment?
There are two huge differences in that environment (also known as “Steampunk”). The first is that a new version of ABAP comes out every three months, and the changes are not trivial. ABAP 7.50 is already about eight versions behind for example! This is a very positive thing.
What you won’t like so much is that you can only use “white listed” SAP functions and classes (i.e. you cannot use unreleased function modules) and cannot directly access ERP tables like KNA1 and MARA. You have to go through a released interface. Thus you cannot just cut and paste your existing Z code there.
Q: Which part of ABAP should we focus on and learn more about, keeping SAP S/4HANA in mind?
The biggest change you need to know about is the “ABAP RESTful programming model,” which replaces the “programming model for SAP Fiori.” The two approaches are essentially the same, but the underlying mechanisms are different, e.g. the BOPF and Transaction SEGW are in some sense already obsolete, before some people have even heard of them.
Q: In regards to the ABAP RESTful programming model, what do you think about all "action" happening on local classes?
What this is all about is the fact that in a “behavior definition” class—which handles CRUD operations for business objects like sales orders—the global class is an empty shell, and all your custom code has to be in local classes. To be honest initially I did not think much of this approach at all—it seemed really strange.
I think the idea is to change programmers’ mindsets from calling a CREATE BAPI or a CREATE method of a business object class to using the new “entity manipulation language” to create and modify objects which in theory makes programs read more like English.
Q: Should we use a logical database in programs while using an SAP HANA database?
This answer is easy—absolutely, definitely not. I have always been horrified by logical databases and the fact they still exist at all is only for backward compatibility reasons. They were declared obsolete in the year 2000; I was hoping they would be gone in SAP S/4HANA but sadly I think they are still there. They are not in “ABAP in the Cloud,” thank goodness.
Why don’t I like them? The main reason is the performance is terrible—even nested SELECTS are better, and they are bad enough. Even SAP HANA cannot fix something if it is fundamentally flawed. The other point is that logical databases work by “black magic” generating selections screens and the like, and you cannot really tell what a program using a logical database is doing.
Q: If we have four billion records of reconciliation data from past 20 years, how would SAP HANA help leverage the functionality of ABAP-managed database procedures (AMDP) to complete the task using select queries by joins (or is there any other functionality)?
You do not use an AMDP for all use cases—it comes into its own when you either need multiple results, lots of complex conditional logic to be executed on the database level, or it is possible for different parts of the query to be executed in parallel (i.e. the result of one query does not depend on the result of another).
I have seen some examples on the internet where someone was able to reduce the runtime of a financial report with millions of rows from hours to seconds purely by using aggregation on the database level as opposed to the application server level—and with SAP HANA you can do that just in ABAP SQL.
Q: It is said that BAPI_GOODSMVT_CREATE is the FM to be used to create a goods receipt (GR) for a purchase order (PO), and WS_DELIVERY_UPDATE_2 to do a GR based on inbound delivery (IBD). This notion is from a very long time ago. Do you know of any improvements in BAPI_GOODSMVT_CREATE which now allows us to use it for both PO and IBD?
I do not believe this has changed in regard to receipting inbound deliveries. There are dirty workarounds but sadly it looks like the easiest way to post a goods receipt for an inbound delivery is to do a BDC using Transaction VL32N, as it just involves the BDC populating one field and pressing one button.
Q: Is it better to use SAP Intelligent RPA instead of batch data communication?
When we first saw SAP Intelligent RPA demonstrated at SAP TechEd, a lot of us SAP Mentors made the observation that SAP had rediscovered the BDC concept, along with business workflow.
The big difference, of course, is that RPA can automatically “press buttons” on web applications and even Excel, which a BDC, of course, cannot do. So I would say if you are 100% within the ERP system and a BAPI is available, use that; if there is no BAPI available (and many are still missing even 20 years on) use a BDC, but as soon as more than one system is involved in your process (e.g. SAP Ariba or SAP Concur or a non-SAP system), as well as the ERP, then that is when RPA comes into play.
Q: I personally find it difficult to use regex functionality. How do you simplify it for yourself—do you have a trick or different thought process?
There is a famous IT quote from 1997 by Jamie Zawinski as follows: Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems."
I would tend to agree. Using a regex is incredibly powerful but it is like machine code. You need to be incredibly smart to write it and twice as smart to understand it afterwards. Since making what the code does as obvious as possible is a core aim of programming, I tend to use the standard SAP string manipulation functions instead, so any other programmer (including me) who has to change the code later at least has some chance of knowing what is going on.
Q: In the case of in-app extensibility, why don't we have extension possibilities for all the business objects since there are so many requirements to do screen enhancements (i.e. functional locations, transactions in EAM)?
It could be said this is a case of history repeating itself. In the past SAP tried to put user exits and screen exits and so forth into as many business objects as it could, but there are just so many, with so much functionality, it could never satisfy everybody. It is the same today with SAP S/4HANA, possibly even worse as it is a relatively new product and does not work the same as SAP ECC, so SAP is rushing to keep up but have not yet got anywhere near as many extension possibilities as everyone would like.
Every year SAP does reach out to its customer base and get them to, in effect, “vote” on what improvements are needed, but in the end, I think the solution today is the same as it was yesterday and that is to “wrap” the standard object (i.e. have a custom screen with all the fields you want, and then update the standard object in the background). This leads as on to the next question.
Q: How can we move all classic extensions to cloud and keep the cores as clean as possible?
In SAP S/4HANA Cloud the code base cannot be changed, as it is shared between different customers, so it is by definition “clean.” In the on-premise version you can make modifications in the traditional way but SAP encourages you not to, and rather use the same extension mechanism as is used in the cloud version.
For extensions written in ABAP you use the ABAP in the SAP Cloud Platform, ABAP Environment and communicate with the core ERP with defined interfaces. For extensions written in other languages you use CAPM, which in turn uses the SAP Cloud SDK to interact with standard SAP systems like SAP ERP, SAP SuccessFactors, and so on.