Simple tip to speed up entering data in (some) fields.

All new developments should be implemented using ABAP Objects unless still impossible (RFC, IN UPDATE TASK, screens, etc). Existing developments, when rewritten, should also be converted to OO, if it proves to be realistic. Official ABAP Programming Guidelines (page 32) rule 3.1: Use ABAP Objects whenever possible for new and further developments. Classical processing blocks may be newly created in exceptional cases only.

• pdf/why-abap-objects.pdf

• https://scn.sap.com/people/thomas.jung/blog/2007/12/19/update-your-abap-development-skills-to-sap-netweaver-70

• https://wiki.sdn.sap.com/wiki/display/ABAP/ABAP+Objects

An easy way of programmatically accessing the texts of any program:

DATA: t_textos TYPE TABLE OF textpool.
READ TEXTPOOL sy-repid INTO t_textos
  LANGUAGE sy-langu STATE 'A’.

Now, you have all of the texts available in the internal table T_TEXTOS.

As if this were not enough, you can also change the texts programmatically with the following commands:

INSERT TEXTPOOL sy-repid FROM t_textos LANGUAGE sy-langu.
DELETE TEXTPOOL PROGRAM LANGUAGE 'E’.

According to SAP, these last two commands are for internal use only. You can use them, but at your own risk. I’ll have nothing to do with it. Unless they force me otherwise, I’ll stick to “READ” only.

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.

Here’s a cool mini-function to obtain some details of a remote system accessible by RFC:

RFC_SYSTEM_INFO

I cannot give any example here because it would reveal very important secret information about my client which would certainly be used by the baddies to perform industrial espionage. But it is easy to test in SE37.

Thanks to kingofthebigmacs for the photo.

Greetings from Abapinho.

If you look up the UNAME system variable in debug within a RFC call you may think it kind of odd to find a username that is not your own. What happens is that the system adopts a specific username for remote calls and a new session is started. A new session implies a new execution context and, hence, all our strategically placed breakpoints will no longer be recognised.

This problem can hinder a simple debug forcing us to run through the code looking for THAT remote call to THAT particular system.

SAP has a solution.

There are countless standard functions to make calculations with dates. There are too many of them, they are redundant and, in many cases, they are obscure or impossible to understand. I’ve been meaning to insert an article here with a list of the most useful ones. But now it’s no longer necessary.

Here’s a simple way to start debugging a job:

1. Go to transaction SM37;

2. Click on the job you want to debug;

3. type JDBG in the command line (without /) and press ENTER;

4. and… bang! you’re now debugging the job.

Thank you Ricardo Monteiro for the tip. And thank you Ingolf for the photo.

Greetings from Abapinho

Some months ago I showed how to transform the debugger into a time machine.

Today’s tip is simple but useful: there is a keyboard shortcut which makes it even simple to travel in time:

shift + F12

Just place the cursor in the line you want to travel to and then… shift+F12.

Thank you Maxsuel Maia for the tip.

Greetings from Abapinho.

And there you go, if you read the title you know the hint.

Now, here are some hints about the hint: