Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 


in the last couple of months I was highly engaged in a SAP MDG-C customer project in Switzerland which ended up in an very successful go-live for the complete world-wide operating company (25000 employees, > 120 countries and > 180 Sales Orgs).

The project took overall only 6 months and the implementation phase was cut down to 10 weeks because of a very good and detailed business blueprint/ requirements definition phase.

Besides the typical challenges and tasks within the implementation phase one highlight was to use the SAP MDG Rule-based-Workflow within the SAP MDG-C application. As you know SAP ships very nice Standard Templates in SAP MDG-C based on the "classic Workflow" which support as well parallel processing based on Sales Orgs and Company Code (introduced with SAP MDG 7.0 SP02 called "distributed Workflow") but these templates did not fit to the requirements due to the fact that the company has no central team to approve global master data information upfront the local parts. Because of that I decided to go for the RBW workflow. Although the RBW Workflow was originally delivered for MDG-M it has no limitations to be used in MDG-C or MDG-BP/S. The Workflow layer is in this case independent from the data model and UI layer. All WF-tasks which are used within the RBW Template do work with MDG-C as well.

The following picture gives you an idea about the requirement/ process model.

As you can see the process is pretty straight forward: A Requestor sends the MDG Change Request to a Logistics Specialist. After processing the process continues with 5 more Business Roles. Important is that there are different processors for different Org Units. Because the requestor can add multiple Org Units to the customer master data object the process must support parallel tasks within one change request. In addition the business requested that some steps may be skipped based on the Org Unit itself. All this must be determined during the runtime of the process because of that thousands of combinations which are possible. All this has been delivered with the RBW Workflow and some Z-Customizing tables. In addition to the standard BRFplus tables “Single_Value decision table” and “None-User decision table” the Standard BADI Enhancements Sport which have been implemented read the Z-Customizing tables to determine the correct next step and processors. The standard decision table “User Agent decision table” has not been used at all.

The following BADIs has been implemented:

  1. Rule Context Preparation for RBW – to be able to add additional dimensions to the CBA in the “Single_Value decision table”, e.g. relevancy of a Business Role Step
  2. Calling of System Method for RBW – for a dummy split
  3. Dynamic Selection of Agent in RBW – for the agent determination and the amount of sub-processes (multiple elements)
  4. Handling of Parallel Results in RBW – to merge the parallel steps and define the next WF-Step number

The approach of parallel steps in a RBW Workflow is explained in a SCN Blog by Kefeng Wang:

Hope this experience helps you if you are at a point where you have to make a decision which Workflow Template to use.