Skip to Content



Even when end users maintain MDG objects (e.g. BPs) via single object maintenance with the help of MDG workflows, it may happen that numerous of these single maintain objects MDG Change Requests (CRs) should be approved / decided in one step.

This is perhaps needed when several object changes / creations are prepared in single maintenance mode but should be activated in one definite point of time and in one step.



Solution approach

This can be done via the MDG API or directly in the business workflow. This solution approach describes the way working with the business workflow. An ABAP report selects the relevant CRs. The relevant CRs can be get out of the BWF table SWWWIHEAD selecting by task number, status and WF template. In this example, the following code example fits for many cases:

* get workflow ids of process tasks
  SELECT * FROM swwwihead INTO TABLE lt_workflow_ids
                        WHERE wi_rh_task EQ 'TS60807954' " task when RBW waits for user approval
                          AND top_task   EQ 'WS60800086' " RBW
                          AND wi_stat    EQ 'READY'.


When you know some MDG, you recognize that we work here with the rule-based workflow because the workflow template WS60800086 is applied.


Table USMD2400 contains the assignment of the BWF workflow id and the CR number, so a select statement on USMD2400 will result in a list of relevant CRs that are ready to be approved resp. activated.

Additionally you can implement further restrictions of CRs that have to be approved, e.g. creation date of CR or even object data of the MDG object, e.g. country code of BP address, etc. Therefore it’s needed to get the object data of the master data that is in the CR. For this you can work with the MDG CR API, here an example (not complete!):


* read data from relevant CRs via model_ext API
        i_usmd_model = 'DM'   ß put here your data model, e.g. BP
        eo_instance = lr_model_ext
        et_message  = lt_usmd_messages ) .

   CLEAR lv_vdat .

   LOOP AT lt_crequests INTO ls_crequest.
     CLEAR lt_key_all.
     CLEAR lt_sel.

         i_crequest = ls_crequest-usmd_crequest
         e_count = lv_count
         et_key_all = lt_key_all ) .



Having now identified all CRs that are ready to be approved, the approval resp. activation step can be executed.

As a first step we read the relevant workflow containers that belong to the CRs resp. workflow items. A code example:


LOOP AT gt_alv_crs INTO ls_alv_cr WHERE appr_sel EQ 'X'.

     lv_workitem_id = ls_alv_cr-tsk_wi_id .

         workitem_id                    = lv_workitem_id
*       LANGUAGE                       = SY-LANGU
*       USER                           = SY-UNAME
*       BUFFERED_ACCESS                = 'X'
*       RETURN_CODE                    =
*       IFS_XML_CONTAINER              =
         simple_container               = lt_container
*       MESSAGE_LINES                  =
*       MESSAGE_STRUCT                 =

     READ TABLE lt_container INTO ls_container WITH KEY element = '_WI_OBJECT_ID' .

     lv_object_type = ls_container-value+10(10).
     lv_object_key = ls_container-value+20(18). 


Now add the action result into the workflow container, in this example and (and in standard MDG case ) this is the value ’09’ for approval resp. activation. This has the same effect like an end user would click the “Approve” button on the MDG UI.


READ TABLE lt_container INTO ls_container WITH KEY element = 'ACTION_RESULT' .
     IF sy-subrc EQ 0.
       ls_container-value = '09' .
       MODIFY lt_container FROM ls_container INDEX sy-tabix.
       ls_container-element = 'ACTION_RESULT'.
       ls_container-value = '09'.
       APPEND ls_container TO lt_container.

 It is recommended to set the PROCESSOR variable, here an example: 

     READ TABLE lt_container INTO ls_container WITH KEY element = 'PROCESSOR' .
     IF sy-subrc EQ 0.
       ls_container-value = <user id>' .
       MODIFY lt_container FROM ls_container INDEX sy-tabix.

Finally the most important step is to execute an event “PROCESSED” to the workflow engine. The effect will be that the workflow engine continues with the operation of this workflow with the given, prepared input data, i.e. the action “09” and the processor value.

         object_type             = lv_object_type
         object_key              = lv_object_key " CR number
         event                   = 'PROCESSED'
*       COMMIT_WORK             = 'X'
*       EVENT_LANGUAGE          = SY-LANGU
*       LANGUAGE                = SY-LANGU
*       USER                    = SY-UNAME
*       IFS_XML_CONTAINER       =
*       RETURN_CODE             =
*       EVENT_ID                =
         input_container         = lt_container
         message_lines           = lt_messages
*     MESSAGE_STRUCT          =



The result will be that all CRs that have been identified before as ready for approval, are approved resp. activated – in one step in the same point of time.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Varun Jain


    Even I got same requirement and we declined because whole purpose of governance is  lost if approve is approving without looking on it. Than it become at rubber stamp process .

    May be industry experts can comment on it SAP can come with new solution .



  2. Michael Theis

    Hi all,

    please be aware that this “approach” heavily violates the main use case of Central Master Governance! An automated approval of any MDG, Central Governance change request is very unlikely done by using the multi-eye principle of data requesters, data stewards and data approvers.

    From SAP development and maintenance perspective, we cannot recommend this approach! This is not the intention of using SAP Master Data Governance, Central Governance!

    Kind regards



Leave a Reply