Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
uwe_schieferstein
Active Contributor

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.

CL_RECA_GUI_SERVICES

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_STATUSGets All Functions of a GUI Status
GET_ICON_FOR_BUSOBJGets Icon with Quick Info for Business Object
GET_QUICKINFO_FOR_ICONGets the Quick Info for an Icon
MSGLIST_RAISE_AND_FREEException of Message List with FREE

CL_RECA_DATE

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_CFill Container of Type C or STRING with Contentstructured -> unstructured
READ_CONTAINER_CRead Container of Type C or STRINGunstructured -> structured

unicode -program giving dumpunicode -program giving dump

Unicode - Transfer structure with packed fields (type p, x) into c-fieldUnicode - Transfer structure with packed fields (type p, x) into c-field

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:

  1. Refreshing or Updating the control occurs automatically when passing PBO
  2. Control events usually do NOT trigger PAI (and therefore there is no succeeding PBO - see (1.)).
  3. Control events can be handled as system events (done by the control framework) or application events.
  4. Using controls we have a frontend (= control) and a backend (e.g. the itab used for data display in an ALV grid).
  5. 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

CL_GUI_CFW=>DISPATCH

    .

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).

Conclusion

SAP provides many valuable and powerful classes and it is worth spending some time to search and find them. And, of course, adopt them.

8 Comments