BUS-Screen Framework - Message handling

[TudorRiscutia]

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

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.