Continuing the introduction into the BUS-Screen Framework, I will describe the basis for message handling.
IMPORTANT: First, please make sure you’ve read and understood my previous BUS-related blog post: http://scn.sap.com/community/abap/user-interface-development/blog/2015/03/24/bus-screen-framework–a-short-introduction/
In order to demonstrate how messages are handle using BUS-Screen Framework, we will create a dummy input field in our previously defined main screen (2000). We will check the value of this field and throw a message.
Notice the input field name corresponds to a public static attribute in our demo class. Therefore, we also have to define it there:
CLASS lcl_demo_main_screen DEFINITION INHERITING FROM cl_bus_abstract_main_screen FINAL. PUBLIC SECTION. " Screen fields are static as all screens are instantiated as Singletons CLASS-DATA cv_field TYPE char10. * ...
NOTE: Except control declarations (which are not supported in OO-context), all field bindings can and should be defined as public static attributes in their corresponding wrapper class.
In order to check the attribute value and throw a message, we will add an extra WHEN section in our previously defined HANDLE_PAI method.
METHOD handle_pai. * ... DATA lo_message TYPE REF TO cl_bus_message. DATA lv_message TYPE string ##needed. * ... CASE iv_function_code. WHEN gc_function_code_enter. IF cv_field NE 'ABC123'. MESSAGE e100(sap_guidelines) INTO lv_message. " Using a dummy statement MESSAGE ... INTO ... can be helpful " when accessing the 'Where-Used' functionality in a message class. * CREATE OBJECT lo_message EXPORTING * is_message = ... " Optional: MOVE-CORRESPONDING sy TO ls_message, where ls_message is of type symsg. iv_cursor_screen = me iv_highlighted_field = 'CL_DEMO_MAIN_SCREEN=>CV_FIELD'. " Passing the SY-MSG structure to the BUS message instance is optional. "If empty, syst fields will be automatically used. Alternatively, the ls_message structure can be filled manually. * ...
The idea is to let the PAI processing continue even if faulty and only display messages in the PBO section.
For the actual message display, we will redefine method PAI_END in the public section of our local demo class.
METHODS pbo_end REDEFINITION.
NOTE: Although the message-relevant functions are available in the CL_BUS_ABSTRACT_SCREEN base class, the actual display of the message should only be performed (ONCE) in the current instance of CL_BUS_ABSTRACT_MAIN_SCREEN.
METHOD pbo_end. super->pbo_end( ). * " Attribute gt_messages is filled automatically by passing reference 'me' " as parameter iv_cursor_screen in the CONSTRUCTOR of CL_BUS_MESSAGE. cl_bus_message=>get_most_severe_message( EXPORTING it_message = gt_messages IMPORTING ev_message = gv_message ). * IF gv_message IS BOUND. MESSAGE ID gv_message->gs_message-msgid TYPE 'S' NUMBER gv_message->gs_message-msgno TYPE gv_message->gs_message-msgv1 gv_message->gs_message-msgv2 gv_message->gs_message-msgv3 gv_message->gs_message-msgv4 DISPLAY LIKE gv_message->gs_message-msgty. " * " After displaying the message, the buffer should be refreshed. clear_messages( ). ENDIF. ENDMETHOD.
NOTE: It is important to understand the order in which PBO and PAI methods are called, and how to redefine them in your classes.
In the next blog post, I will show you how to implement the logic of a tabstrip and sub screens using the BUS-Screen Framework.