A Christmas Collection of Useful Classes
CL_RECA_MESSAGE_LIST – The ultimate message handler
This class (interface IF_RECA_MESSAGE_LIST) is the ultimate message handler (collector) in ABAP at least for me.
About two years ago I used this class very successfully in a data migration project (purchase orders including entire history; total volume ca. 800 Mio. CHF; Message Handling – Finding the Needle in the Haystack). I created a custom validation class and used CL_RECA_MESSAGE_LIST to collect and display the error messages in a tree view. Initially we started with about 150 thousands(!) error messages in the tree (no joke. Approx. 30% of the messages were overhead due to the hierarchical structuring of the messages. And we had a multiplication of errors, e.g. 5000 purchase orders had 4 vendors assigned in the history all of which contained some error => 5000 x 4 = 20’000 error messages).
Surprisingly, the tree display had no problems with this huge numbers of nodes. The message handler helped us tremendously to find out the errors in the migration data. Within a single day we were able to reduce the number or error messages from 150’000 (morning) to about 12’000 (lunch time) to about 500 (tea-time).
Do not miss to check out the sample reports in package SZAL, e.g. SBAL_DEMO_04_DETLEVEL.
Still using function module TH_CREATE_MODE to open a transaction within a new GUI mode? If you have this class available on your SAP system then have a look at its static method CALL_TRANSACTION. Using parameter IF_NEW_EXTERNAL_MODE you can decide whether you want to open a new window or not.
I have not yet used any of the other available methods yet they may be useful as well:
|GET_GUI_FUNC_OF_GUI_STATUS||Gets All Functions of a GUI Status|
|GET_ICON_FOR_BUSOBJ||Gets Icon with Quick Info for Business Object|
|GET_QUICKINFO_FOR_ICON||Gets the Quick Info for an Icon|
|MSGLIST_RAISE_AND_FREE||Exception of Message List with FREE|
I believe all of us have already encounter the problem to check whether two periods overlap or not. Two periods are overlapping if the beginning or the end of one period lies with the other period or if one period lies completely within the other period. In case of overlapping periods the static method CHECK_INTERSECTION will raise exception PERIODS_HAVE_INTERSECTION.
CL_RECA_GUID – Making object identifiers unique
If you need to get a unique identifier for your objects then get your GUID using the static method GET_NEW_GUID.
There are many more interesting classes in package RE_CA_BC e.g. like CL_RECA_COMM_SERVICES (Sending E-Mail) or CL_RECA_STRING_SERVICES (String: Utilities) which may be worth being investigated.
CL_REEXC_COMPANY_CODE & CL_REEXC_CONTROLLING_AREA
If you need data related to company codes (BUKRS) and controlling Areas (KOKRS) these two classes provide many useful methods.
CL_PT_EMPLOYEE – The Infotype Broker
You require access to all kinds of PAnnnn infotype data? Use this class (interface IF_PT_EMPLOYEE). It is as simply as that (Unified Access to All HR Infotypes).
CL_ABAP_CONTAINER_UTILITES – Being Unicode-Compatible
If you need to shuffle data between structured and unstructured variables and you do not want to run into any problems on Unicode systems then this is the right class to use.
|FILL_CONTAINER_C||Fill Container of Type C or STRING with Content||structured -> unstructured|
|READ_CONTAINER_C||Read Container of Type C or STRING||unstructured -> structured|
CL_GUI_CFW – Mastering Control Event Handling
Controls (like ALV grid, ALV tree, etc.) are very powerful and user-friendly development tools which should be used whenever appropriate.
However, there are stumbling blocks when working with controls which can be circumvented if you keep a few basic principles in mind:
- Refreshing or Updating the control occurs automatically when passing PBO
- Control events usually do NOT trigger PAI (and therefore there is no succeeding PBO – see (1.)).
- Control events can be handled as system events (done by the control framework) or application events.
- Using controls we have a frontend (= control) and a backend (e.g. the itab used for data display in an ALV grid).
- For editable controls the data displayed at the frontend can differ from the data in the backend. Special control-specific methods are required to ensure synchronization between frontend and backend.
The effect of such a “sychronization” method is demonstrated in put X into checkbox of alv when button select all entries.put X into checkbox of alv when button select all entries. (CHECK_DATA_CHANGED of CL_GUI_ALV_GRID) and ALV Tree not getting refreshed (UPDATE_CALCULATIONS andFRONTEND_UPDATE of CL_GUI_ALV_TREE).
In almost all cases I use the control events as system events. Below you see what the SAP online documentation says:
You construct the tables using a special ABAP Objects Control Framework method (control->set_registered_events). When you register the event, you must specify whether the event is to be processed as a system event or as an application event.
- System events are triggered before any automatic field checks (for example, required fields) have taken place on the screen, and before any field transport. The PAI and PBO events are not triggered. Consequently, you cannot access any values that the user has just changed on the screen. Furthermore, there is no field transport back to the screen after the event, so values that you have changed in the event handling are not updated on the screen.
The handler method that you defined for the event is called automatically by the system. However, you can use the method set_new_ok_code to set a new value for the OK_CODE field. This then triggers the PAI and PBO modules, and you can evaluate the contents of the OK_CODE field as normal in a PAI module.
- Application events are triggered automatically at the end of the PAI event. Consequently, all field checks and field transport has taken place. If you want the event handler method to be called at a particular point during PAI processing, you must trigger the event handler using the static method
Not using application events means no automatic field transport, no triggering of PAI (followed by PBO) and a potential discrepancy between frontend and backend.
So why I am still in favour of system events? Because they give me the freedom of choice.
If the control event is just used to display additional data (e.g. double-click on user name in ALV list -> call transaction SU01 for this user) there is no additonal effort required and I explicitly do not want to trigger PAI.
However, if the control event is used to change data (Hotspot-clicking (Insert function) plus ALV SortingHotspot-clicking (Insert function) plus ALV Sorting) then I call method CL_GUI_CFW=>SET_NEW_OK_CODE to trigger PAI. Thus, the system event has become an application event. All required updating of the ABAP backend (i.e. itab) is done here at PAI (and not within the event handler method). The succeeding PBO takes care of refreshing/updating the control (automatic flushing).
SAP provides many valuable and powerful classes and it is worth spending some time to search and find them. And, of course, adopt them.