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.
You are looking at a class in SE24, a table in SE11 or a program in SE80. Now you want to see the package of this object and its content. Until recently, I would do this: first I would look in the object’s characteristics to see its package, then open a new session, go to SE80 and write the package there.
Now I’ve learned a much easier way.
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)
The other day, a series of things crashed in our test machine. All of a sudden, no one could work on it. We found a series of transport requests improperly transported to STMS. The user who appears to be associated with each of these requests is its owner. But is it the owner’s fault? Didn’t someone else do the transport?
How can we find out?
Hi. How’ve you been? How’s life? All cool? This tip is so simple that if we don’t talk for a while it will all end too quickly. The sun is shinning. It rained in the morning but now it stopped. Moving on. Every time I see someone still using SE16 I wonder why, since SE16N is so much better and already exists for so long. But this is not the tip.
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;
When you try to delete a package where you have created objects that have meanwhile been deleted, and the package looks empty in SE80, when you try to delete it, it won’t work because it says the package still contains objects.
For some silly reason, SE80 does not show every type of object associated with packages. In addition, when an object is deleted, its entry is often times not deleted correctly. SAP is full of shortcomings. But it’s what we have, and it’s what brings us the bacon, so let’s not say too many bad things about it.
Abapinho has the solution for you.
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).
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.
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.
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.
