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.
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 cl_usmd_model_ext=>get_instance( EXPORTING i_usmd_model = 'DM' ß put here your data model, e.g. BP IMPORTING 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. lr_model_ext->get_cr_objectlist( EXPORTING i_crequest = ls_crequest-usmd_crequest IMPORTING 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 . CALL FUNCTION 'SAP_WAPI_READ_CONTAINER' EXPORTING workitem_id = lv_workitem_id * LANGUAGE = SY-LANGU * USER = SY-UNAME * BUFFERED_ACCESS = 'X' * IMPORTING * RETURN_CODE = * IFS_XML_CONTAINER = * IFS_XML_CONTAINER_SCHEMA = TABLES simple_container = lt_container * MESSAGE_LINES = * MESSAGE_STRUCT = * SUBCONTAINER_BOR_OBJECTS = * SUBCONTAINER_ALL_OBJECTS = . 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. ELSE. ls_container-element = 'ACTION_RESULT'. ls_container-value = '09'. APPEND ls_container TO lt_container. ENDIF. 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. ENDIF.
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.
CALL FUNCTION 'SAP_WAPI_CREATE_EVENT' EXPORTING 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 = * IMPORTING * RETURN_CODE = * EVENT_ID = TABLES input_container = lt_container message_lines = lt_messages * MESSAGE_STRUCT = . ENDLOOP.
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.