BUS-Screen Framework – Message handling

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.