In this blog I would like to share an innovative approach to a very common problem of displaying multiple messages on line item checks in MIGO transaction.
The solutions explored included implementation of BADI’s – MB_MIGO_BADI and MB_CHECK_LINE_BADI. Details are below –
MB_MIGO_BADI – As most of us would know that this BADI is provided for the sole purpose of addition of custom sub screens to MIGO Transaction. Even though this BADI has a CHECK_ITEM method to return multiple messages (to ET_BAPIRET2) but it has a limitation that only five active implementations of this BADI can be there in any system. So, this is not a foolproof solution. So, I needed to look at alternate ways.
MB_CHECK_LINE_BADI – I explored this and implemented CHECK_LINE method. Then it was observed that this BADI is generally only used to display a single message to application log that too is issued via the MESSAGE statement.
But the requirement was of mutliple messages so, there was trouble.
Further debugging of standard code for SAPLMIGO, I realized that we have the application log handler in a private variable P_LOG_HANDLE of local class – LCL_MIGO_LOG but unfortunately this was not accessible in the CHECK_LINE method of MB_CHECK_LINE_BADI. One way could have been to use ABAP Memory and Export the log handler’s value to CHECK_LINE method’s implementation and then add messages to application log. This needed implicit enhancement and ABAP Memory (which is OBSOLETE). So, this was not a preferable solution.
Now, comes the innovative solution. On analysis of standard code, I observed that we have internal table EMSEG of program SAPLMBWL accessible in CHECK_LINE method. Standard uses the same table to fill messages in the application log. So, I filled this table with our validation messages and then standard code did the trick of adding them to application log and it got rendered suitably on MIGO screen.
I felt this was a hack but still a preferred solution as it did not warrant any kind of project approvals or usage of OBSOLETE techniques.
Code snippet –
" Local data DATA: lt_message TYPE bapiret2_t, lt_emseg TYPE STANDARD TABLE OF emseg. APPEND VALUE #( type = 'E' id = 'SY' number = 614 ) to lt_message. APPEND VALUE #( type = 'E' id = 'SY' number = 615 ) to lt_message. APPEND VALUE #( type = 'E' id = 'SY' number = 616 ) to lt_message. LOOP AT lt_message ASSIGNING FIELD-SYMBOL(<fs_msg>). APPEND INITIAL LINE TO lt_emseg ASSIGNING FIELD-SYMBOL(<fs_mseg>). <fs_mseg>-msgid = <fs_msg>-id. <fs_mseg>-msgno = <fs_msg>-number. <fs_mseg>-msgty = <fs_msg>-type. <fs_mseg>-msgv1 = <fs_msg>-message_v1. <fs_mseg>-msgv2 = <fs_msg>-message_v2. <fs_mseg>-msgv3 = <fs_msg>-message_v3. <fs_mseg>-msgv4 = <fs_msg>-message_v4. <fs_mseg>-line_id = is_mseg-line_id. <fs_mseg>-global_counter = is_vm07m-global_counter. ENDLOOP. FIELD-SYMBOLS : <ft_emseg> TYPE ty_t_emseg. ASSIGN ('(SAPLMBWL)EMSEG') TO <ft_emseg>. IF <ft_emseg> IS ASSIGNED. APPEND LINES OF lt_emseg TO <ft_emseg>. ENDIF.
Sample Output –
Update: 19th June 2020 – I found another FM whihc offers an elegant way of getting all the BAL log handlers in memory.
FM is – BAL_GLB_SEARCH_LOG
Sample code snippet is below which will give a list of all log handlers in memory for a particular filter.
DATA: ls_log_filter TYPE bal_s_lfil, ls_message TYPE bal_s_msg, lt_log_handle TYPE bal_t_logh. APPEND INITIAL LINE TO ls_log_filter-object ASSIGNING FIELD-SYMBOL(<ls_log_search_object>). <ls_log_search_object> = VALUE #( sign = if_slad_select_options=>C_SIGNs-including option = if_slad_select_options=>c_options-eq low = CONV balobj_d( '<SLG1 log object name>' ) ). CALL FUNCTION 'BAL_GLB_SEARCH_LOG' EXPORTING i_s_log_filter = ls_log_filter IMPORTING e_t_log_handle = lt_log_handle EXCEPTIONS log_not_found = 1 OTHERS = 2.
Sincerely appreicate any feedback/comments/questions.