SAP R/3 repository is a wonderful thing. A vast warehouse of data elements, structures, tables and much more, readily available to one and all. As developers, it is extremely convenient to quickly pick these elements and pull them into our programs as necessity conveys, while our string of thought remains virtually uninterrupted. Well, not all is sunshine and roses. If you are not careful with the mushrooms you pick you might get a poisoned one.
Sometimes you find an IMPORT in the code but you have no idea where the corresponding EXPORT is. When communication is needed between programs, it should be done using a pair of methods belonging to the same class. This way, when we run into one, we’ll always know where the other one is. Anyway, try to use EXPORT/IMPORT only when unavoidable. If possible, use static class variables instead.
When you need to send a dynamic message by parameter, make sure you still use the MESSAGE command, so that the “where-used” doesn’t loose track of it. When you do MESSAGE E001 INTO V_DUMMY, the message details become available in the system variables: SY-MSGNO, SY-MSGTY, etc. Also, message texts should never be hardcoded, they should always be defined in SE91. https://abapinho.com/en/2009/09/evitar-mensagens-dinamicas/ (portuguese)
All code to be put in user-exits (BADIs, enhancements, SMOD, etc.) should be encapsulated. It’s common for an user-exit to include multiple independent parts. Each of these parts should be encapsulated in its own method. Even if it is only one line; This should apply to both new implementations and changes to existing code; A change to existing code should always be seen as an opportunity to organize existing code into methods, since it will have to be tested again anyway;
Official ABAP Programming Guidelines (page 34): [When a classical processing block is required], you should immediately delegate the execution to a suitable method (see Rule 6.37, No Implementations in Function Modules and Subroutines, and Rule 6.44, No Implementations in Dialog Modules and Event Blocks).
ABAP programmers don’t explore the possibilities of SQL, probably for historical reasons. There are many who instead of using INNER JOINs still think it’s faster to do several SELECTs for internal tables and then process the data in ABAP. But the truth is that even if there are exceptions, the rule is: the lower the number of accesses to the database, the better the performance. And it makes sense because, after all, they were written explicitly for this; relational databases are much more adept at processing relational data than an ABAP program.
There are of course things that, due to their complexity, cannot be done with a simple INNER JOIN. Nevertheless, some of these things can be done in a single SELECT.
Recently, I have compiled a set of personal best practices. I decided to share them here by creating a new category (which will soon appear on the menu to the left) into which they will be grouped. The original idea was to make a PDF file but, since they are constantly being reviewed and expanded, this was largely impractical. As such, they will be published one by one. The goal is for these practices to be visible in their entirety as a user-friendly, accessible reference.
When a development is completed in SAP, the time to send it to other systems where it can be duly tested and then executed by users has finally arrived. Before that occurs, however, it has to be checked for lapses, errors and other problems that could lead to our programmes behaving in an unpredictable manner. There is a very useful tool that allows some of these errors and gaps to be filtered out. It is called ABAP Code Inspector.
ABAP is getting smarter all the time. Back in my day, no one did anything with it. And now, slowly, more than a fifth of a century late, it’s trying to imitate C and Java, and becoming more flexible.
I was going to do something like this:
Exception classes let you state multiple texts describing the different possible errors that they can represent.
However, there exists an option to associate it with a message class (SE91). This allows texts to be defined as classic SE91 messages instead of being defined directly in the exception class. And it has advantages.
Today’s hint is not a hint - it’s an advice.
After creating a table, you create its maintenance views. The maintenance views dwell within a group of functions. This group of functions is requested from you at the time of their creation. Since, after all, that’s no more than a set of generated code, and most of it is, nonetheless, standard includes. Loads.
I give you the problem: there are those who create their own Z functions and put them in groups of functions with maintenance views. It’s true. Some do this.
In the ‘bad old days’ when the ABAP was even more old-fashioned than today, variable statements were all made through LIKE and were referenced to table fields:
DATA: V_KUNNR LIKE KNA1-KUNNR.
Some people read the TCURX to find out the number of decimal places of a CURRENCY when they need to write a money field to an alphanumeric variable.
Are you one of those people? Don’t be.
Finally, the SAP NetWeaver 7.0 Enhancement Package 2 makes ABAP start to seem like a normal programming language.
It even allows expressions to be concatenated, no less!
When reading a file with numeric values to an internal table or vice versa, the success of the conversion depends on whether the user has defined the dot or comma as the decimal separator. It is customary to then go and read the user setting and then adjust the values from the file with a dot or a comma as required.
But this is unfortunate and rather inelegant. There should be a way of not making this depend on the user.
And there is.