ABAP evolves (even though it stood mostly still for too many years). And as it evolves, it leaves behind some commands and syntax constructions which are replaced by better ones.
Besides learning what’s new it is also important to learn what becomes obsolete.
Legibility is very important in all written text. Except, maybe, in concrete poetry.
As a follow up to the previous post, here are a couple of rules to help you deal with the negative in boolean expressions.
Because…why should they be complex to read? It would only make it harder to maintain in the future.
Just because an IF condition is complex doesn’t mean it has to be complicated.
ABAP SQL is becoming more and more interesting and powerful. My latest discovery is the ability to use CASE in SELECT.
How many times in your ABAP consultant life did you have to deal with dumps happening as a consequence of a program trying to insert duplicate lines into an internal table defined with a UNIQUE KEY?
Enough.
In 2012 I wondered why LISTBOX is so rarely used. I taught how to use it with standard data elements, which automatically populate it. Today I’ll teach you how you can populate it yourself.
There’s so many things you can do on the selection screen. Here’s another one: five buttons in the toolbar.
When you need to send an email to multiple email addresses, the usual approach is to store that list of email addresses in a custom table and then add each one as recipient to the BCS request.
But I recently learned a much nicer way to achieve the same result.
Even though many ABAP programmers tend to forget this, the less texts you hard code in your program the simpler it will be to translate it.
Here’s a simple but rather obscure way to manipulate selection screen texts while still being able to translate then. This way you can, for example, prefix them with icons.
Imagine that you are calling an RFC function module several times in a row. Maybe you think that each call is completely independent from the others. It is not. The remote function group remains in memory and so does its global data. That global data will be reused on every call. This is probably irrelevant in most cases. But there will be scenarios in which, for some reason, the function module being called is storing data in global variables which will negatively affect the outcome of the subsequent calls.
I recently started working in a new customer and noticed something they do here which I really liked. Whenever they need to call a remote function module by RFC in another SAP system, they create a local function module with the same name and leave it empty, except for a comment explaining that it is a dummy function for that remote function call. Thanks to this simple trick, one can use the where-used tool to find out where it is being called.
I remember when SAP notes had to be inserted by hand. Copy paste and pray that no mistake was made. Wild.
I actually remember a project which, for some strange obscure reason, instead of upgrading, decided to implement hundreds and hundreds of notes by hand. They printed them all and made a huge pile of paper and about 10 ABAP consultants spent the whole weekend trying to process the whole pile. We did it. But I have no idea what were the consequences and how many bugs were introduced. Many for sure.
Before the modernization of ABAP in 7.40, a table lookup required an auxiliary variable and at least 4 lines of code.
As is well known, SAP stores amounts internally in variables with 2 decimal places. When we want to convert it to its external format, we use WRITE with the CURRENCY option. But WRITE writes to an alphanumeric variable. What if we need to write it to a numeric variable?
