Presenting the EGSAP_TECH app
Do you know about the EGSAP_TECH app? It’s a SAP knowledge bank.
Here is a description in the words of its own creators:
Do you know about the EGSAP_TECH app? It’s a SAP knowledge bank.
Here is a description in the words of its own creators:
Abapinho received a letter.
Mr. Abapinho,
Everybody knows how to set default values in select options using the DEFAULT keyword. What some people may not know is that one can also set the default option, sign and even if allows for intervals or just fixed values.
Today I will teach you how to chain exceptions. It’s a very practical solution to a complicated, not so obvious problem. Let’s start by describing the problem. Imagine you are in the application BANANA. The application is quite complex. It has three modules: BANANA1, BANANA2 and BANANA3. Each one has its exception class ZCX_BANANA1, ZCX_BANANA2 and ZCX_BANANA3. Since the application is in fact well designed, all the exception classes inherit from the same ZCX_BANANA.
When calling a function module which returns exceptions you normally give them sequential numbers like this:
CALL FUNCTION 'GO_BUT_PLEASE_COME_BACK'
EXPORTING
ali = 'To the moon'
EXCEPTIONS
NOT_FOUND = 1
GOT_LOST = 2
OTHERS = 3.
But Code Inspector may be configured to report a warning if afterwards you are not careful to add an IF or a CASE to look at SY-SUBRC,
In classes, consider using exceptions classes over the old ones. These have great advantages and, once understood, are simple and allow for simpler code. https://zevolving.com/2011/12/class-based-exception/
In reports, instead of WRITE TEXT-001, use WRITE ‘bla bla bla’(001). This way a default text will always be there and besides the readability of the program is improved. https://abapinho.com/en/2011/11/programas-poliglotas/
SALV classes are more versatile and more recent than the old function modules. So, for new ALVs always use SALV. The only exception is editable ALVs which SALV classes are still very incapable of doing. https://scn.sap.com/docs/DOC-10365 https://scn.sap.com/docs/DOC-10366
We start with two variables:
DATA word1 TYPE string.
DATA word2 TYPE string.
DATA: phrase TYPE string.
word1 = ‘this’.
word2 = ‘that’.
And we want to concatenate them adding the word “plus” between them and, of course, separate them by space.
In Greek mythology, the gods’ most commonly used means of communication with mortals was rape. They would rape for no reason whatsoever.
The closest thing we have to rape in ABAP is the command “SUBMIT”, which is also the most common way of communicating between two programmes.
The ABAP editor has many curious functionalities. You can even write in multiple lines at the same time.
It’s not.
But they - the people who make and remake the ABAP itself - are trying to mend this unfortunate situation.
Look at this new functionality:
Did you know that you can do a LOOP on an internal table of one type into a structure of a different type?
Since data operations are much more optimized in the database server than in ABAP, it is always better to use the first as much as possible. FOR ALL ENTRIES should only be used when INNER JOIN doesn’t give us what we need or is not possible (like with BSEG for example). Artificial ranges are also a possible alternative to FOR ALL ENTRIES but be careful not to reach the SQL parser limit.
User-exits (and enhancements) are usually crowded with CHECKs. The tragic consequence is that, if the check fails, nothing else after it will run. Not even the standard code. Always try to correct these. Encapsulating the code inside a routine (ideally a method) is enough to render it harmless.
To indent a block of lines do the following: