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 –
Sincerely appreicate any feedback/comments/questions.