SAP MASTER DATA GOVERNANCE

FRAMEWORK CONFIGURATION AND

WORKFLOW DEVELOPMENT

RDP363



Exercise
Michael Boettcher, MDG Product Management
David Quirk, MDG Solution Management
















2

INTRODUCTION
Make master data governance workflow design more of a configuration and less of a development effort. With
businesses needing process transparency and business process efficiency, workflows are critical aspects of
governance. They are the backbone for introducing transparency to manage master data because without some type
of process control, the management of master data is often completely unstructured, neither guided nor controlled.
Creating workflows has been very expensive, at times hard-coded and often inflexible, putting a lot of effort in coding,
thereby proving to be semi-automated processes. These semi-automated processes can be replaced by a flexible
process, especially if the workflow is based on an integrated rules management.
SAP Master Data Governance combines the SAP Business Workflow tool with the capabilities of business rules
framework (BRFplus). This combination of SAP Business Workflow and BRFplus is referred to as rule-based workflow.
Since the technology of rule-based workflow is based on single-stack solutions, you dont need to worry about setting
up complex landscape environments. Rule-based workflow provides flexible processing and easy configuration.
Decisions take place iteratively based on the current state of the workflow; the status of the change request, and user
interactions and the flow is determined by decision tables populated by end-users.
Additionally, SAP Master Data Governance comes with a powerful framework allowing configurations across all
aspects of the change request process including UI configurations; custom validations and additional actions and
status values presented to an end user.
In this session, you will be introduced to the concepts of SAP Master Data Governance's configuration framework and
rule based workflow. You will make several change request configurations as well as setup the workflow decision
tables by enhancing an already existing workflow with an additional step. You will also learn to define your own action
and user interface for the additional process step.

Session Outline
Goal: The exercise below will guide you through customer specific enhancements of a predefined Master Data
Governance Process. This will include:
Adding a new process step including
o a step specific User Interface
o a step specific action called Check Quota
o changes to the Rule Based Workflow

The exercises must be completed in sequence as they build upon each other. Additional hint when working with the
rule based workflow: always save and activate your work


3

Naming Convention
Assignment of Group Numbers User IDs Change Request Types

Group
Number
User ID Change
Request Type
Group
Number
User ID Change
Request Type
Group 01 RDP363-01 SFZ01 Group 31 RDP363-31 SFZ31
Group 02 RDP363-02 SFZ02 Group 32 RDP363-32 SFZ32
Group 03 RDP363-03 SFZ03 Group 33 RDP363-33 SFZ33
Group 04 RDP363-04 SFZ04 Group 34 RDP363-34 SFZ34
Group 05 RDP363-05 SFZ05 Group 35 RDP363-35 SFZ35
Group 06 RDP363-06 SFZ06 Group 36 RDP363-36 SFZ36
Group 07 RDP363-07 SFZ07 Group 37 RDP363-37 SFZ37
Group 08 RDP363-08 SFZ08 Group 38 RDP363-38 SFZ38
Group 09 RDP363-09 SFZ09 Group 39 RDP363-39 SFZ39
Group 10 RDP363-10 SFZ10 Group 40 RDP363-40 SFZ40
Group 11 RDP363-11 SFZ11 Group 41 RDP363-41 SFZ41
Group 12 RDP363-12 SFZ12 Group 42 RDP363-42 SFZ42
Group 13 RDP363-13 SFZ13 Group 43 RDP363-43 SFZ43
Group 14 RDP363-14 SFZ14 Group 44 RDP363-44 SFZ44
Group 15 RDP363-15 SFZ15 Group 45 RDP363-45 SFZ45
Group 16 RDP363-16 SFZ16 Group 46 RDP363-46 SFZ46
Group 17 RDP363-17 SFZ17 Group 47 RDP363-47 SFZ47
Group 18 RDP363-18 SFZ18 Group 48 RDP363-48 SFZ48
Group 19 RDP363-19 SFZ19 Group 49 RDP363-49 SFZ49
Group 20 RDP363-20 SFZ20 Group 50 RDP363-50 SFZ50
Group 21 RDP363-21 SFZ21 Group 51 RDP363-51 SFZ51
Group 22 RDP363-22 SFZ22 Group 52 RDP363-52 SFZ52
Group 23 RDP363-23 SFZ23 Group 53 RDP363-53 SFZ53
Group 24 RDP363-24 SFZ24 Group 54 RDP363-54 SFZ54
Group 25 RDP363-25 SFZ25 Group 55 RDP363-55 SFZ55
Group 26 RDP363-26 SFZ26 Group 56 RDP363-56 SFZ56
Group 27 RDP363-27 SFZ27 Group 57 RDP363-57 SFZ57
Group 28 RDP363-28 SFZ28 Group 58 RDP363-58 SFZ58
Group 29 RDP363-29 SFZ29 Group 59 RDP363-59 SFZ59
Group 30 RDP363-30 SFZ30 Group 60 RDP363-60 SFZ60
4

Logon information

nn = Group number from 01 60

Replace nn with your two-digit group number
Logon to the SAP System M18 Client 800
Username: RDP363-nn
Password: welcome (If prompted to change your password please change it to RDP363-nn)
Logon with SAP NetWeaver Business Client 3.5
Please logon to the system using SAP NetWeaver Business Client Desktop (NWBC) in version 3.5 from the start
menu or using the shortcut on the desktop:




Do not use NWBC 4.0

NWBC 4.0 uses a new design and layout, so that you will not be able to follow the description of the exercise and
particularly the screenshots in the solution section.

Additional Note: When creating flight connection data, use the naming convention nn## where nn = your group number
and ## = a number of your choosing, different for each connection you create.



5

Exercises - Overview












6

BACKGROUND REFERENCE MATERIAL FAMILIARIZE YOURSELF
WITH THE SETUP
Reference material
See below for the background setup done for this exercise.
Background
.
Change Request Type
Change Request Type SFP01 has been copied to SFZXX (replace XX with your group number) and the underlying
Workflow template has been exchanged to Workflow-Template WS60800086 (which is used as the template for Rule
Based Workflows). The switch to the Rule Based Workflow has been done to:
enable the SAP Customer to take advantage of the BRF (Business Rules Framework) which allows Business
Experts with limited technical knowledge to adapt the MDG Workflows
show how easy it is to switch from a regular (Business Workflow based) process to a Rule Based process
(Business Workflow + BRF)

The Copy has been done through the Master Data Governance Implementation Guide (transaction MDGIMG)
Create Change Request Type:

7




8

Change Request Type SFP01 has been copied to SFZXX (replace XX by your group number):









The Workflow Template has been exchanged (using the template for the Rule Based Workflow):





SFZXX
9

Be aware that the standard UI Configuration has been defined in the Change Request Type:




Define the Change Request Steps. This has been done through this IMG activity:





10

To simplify the configuration the step definition of an existing Change Request Type can be copied and adapted to the
specified by the process definition (original - before adaptation):



Adapted to this process








11

For regular Business Workflow-based processes it would be necessary to assign processors to the Change Request
Steps through the MDG IMG activity Assign Processor to Workflow/Change Request Step number.




For regular Business
Workflow based processes
only. Not needed here.
12

For the Rule Based Workflow this is been done in the BRF plus (more specific: in the decision tables). The BRF plus
configuration also can be started from the MDG IMG:






13

The Single Value Decision Table shows what happens if the process is in a specific step (here: 01 - Add Connection
Details) and an action (like 05 Finalize Processing) is triggered by a pushbutton on the corresponding UI:



For Finalize Processing the system moves into Change Request Step 03 Approve and the new Change Request
Status is 04 Final Check to be performed. The Condition Alias links the 3 decision tables together. For example
here the condition alias is set to APP which is used to determine the user responsible for executing this step from the
User Agent Decision Table.




The User Agent Decision Table shows for Condition Alias APP that the system will change into CR Step 2 Approve
Change Request and that the processor will be a special user, specifically the Initiator/Last-Step User of the workflow
process.



14

Note: This is done to simplify the definition of this exercise. Typically the workflow would be sent to users with a
specific role/position in the organization, shown here as a reference for you (not applicable to this exercise). In this
case, shown below, the processor would be defined by all users that are assigned to position 50010131- Flight
Operations Manager.



As a further reference, not needed for this exercise, any relevant users would need to be assigned to the relevant
organizations (transaction PPOME):

Organization: Search for Flight*. Check if your user is assigned to the positions: Flight Product Manager, Flight
Application Expert, and Flight Operations Manager

If it is not assigned:
Search for your User
Drag&Drop User




Hint: You can display the Organization ID by clicking on Column Configuration (Icon on the upper right corner).

Repeat this for all positions.

Save

15

Run the application
Start the application (transaction NWBC => Governance for Flight Data Model). Replace XX with your group number.





Request:




SFO
LH XX01
16

Process:



17

Approve:



















18

Background Completed!
You have executed the pre-configured business process flow and understand the design of the rules based workflow
built via the decision tables.

Further Info for Technical Experts
Generated Tables
If you are curious to see where the data is stored. Take a look at the MDG persistency. By using transaction
MDG_DATA_MODEL enter the data model as SF and you shall be directed to the MDG repository.

19

EXERCISE 1 SIMPLIFY THE REQUESTORS USER INTERFACE
In order to maintain the data by the requestor a simple user interface is required that displays the attributes in the style
of a form.
Simplify the Requestor UI by providing him only those fields that he has knowledge of. The requester is not able to
(and should not) fill in the Airport Codes (Departure Airport, Destination Airport) and details about the schedule.

There are several ways to simplify the process, e.g.:
Configure the UI (and remove the Checks for this field)
Exchange the UI (and remove the Checks for this field). We will do this in order to demonstrate how a different
UI could be attached to a change request step very easily

Basically you need to perform these steps for exchanging the UI:

1. Start the MDG configuration (MDGIMG transaction) Navigate to Process Modeling -> Change Requests
node of the tree
2. Configure the properties of your change request step
3. Exchange the UI in the first step of your Change Request Type
a. Use the UI Configuration ZMDG_SF_APPL_FLIGHT_RQ in the change request steps as this has to
be carried out by the requester - 00 Initiate the request



20

EXERCISE 2 ENHANCE THE DECISION TABLES WITH THE
ADDITIONAL PROCESS STEP AND ACTION
Now that we have a good grasp of the current process flow in the system lets go a step further and enhance the same.
Lets take a scenario where we get a request to enhance the workflow by a step called Check Landing Quota. The
processor of Change Request Step 01 - Processing should add a landing quota. Depending on his knowledge he
might be able to do this easily or it might be a problem for him which slows down the process. Therefore on the one
hand the field should be added to the user interface and on the other hand a new Change Request Step should be
introduced that adds the flexibility to forward the task of checking the landing quota to a specialist that is able to do this
easily.
The new change process shall now have an initial request step, then a data processing step, a check landing quota
step and then a final approval.
Please use the change request type having the suffix ID matching your group number! (see table Assignment of Group
Numbers User IDs Change Request Types)

You need to perform the below mentioned steps:

Start the MDG configuration (MDGIMG transaction) Navigate to Process Modeling node of the tree
Add Change Request Step for the Landing Quota Specialist
In order to navigate from the Processor Step to the Landing Quota Step actions need to be defined. This has
been prepared for you as this is a global setting that can be reused by all Change Request Types. Navigate to
the appropriate node where you Define Actions for the different change request user interfaces and view the
new action Check Landing Quota
A new Step Type has been created to link the Change Request Step to the Actions
Every step in the process flow has a Change Request Status attached to it to depict the current state of the
workflow (This has been prepared for you as this is a global setting that can be reused by all Change Request
Types)
Add step specific user interfaces by navigating to the Configure Properties of a change request step
o Use the UI Configuration ZMDG_SF_APPL_FLIGHT_CQ in the Change Request Steps
01 - Processing
03 Final Check
o Use the UI Configuration ZMDG_SF_APPL_FLIGHT_REQ in the change request steps as this has to
be carried out by the requester
00 Initiate the request
02 Revision

Now the field is available for the processor. But he might not be able to get this information. So he needs to be
able to forward that task to somebody else. For this we need to introduce a new CR Step (and corresponding
actions) and link it to the Workflow. In order to reduce the complexity of the exercise the same UI will be used
as in step 01 Processing
Enhance the decision tables of the workflow
Single Value Decision Table
a. The new step type has to be used in step 01 Processing as this is the place where the new CR Step
04 Check Landing Quota should be initiated (via the Action CQ Check Landing Quota)
b. The rule is: If the (previous) step currently is 01 Processing / Add Connection Details and the
(previous) action is CQ Check Quota move to the new step 04 Check Landing Quota
c. Since this is a user task let the Condition Alias QUO be assigned to start the User determination
User Agent Decision Table
21

d. For simplicity reasons we use the same organization as for the 01 Process CR Step. The assigned
Step Type will be a reuse of 03 Process as this has the original actions assigned (w/o Check
Landing Quota)
e. Always remember to Save and activate all the decision tables after any change is made to the decision
tables
f. Perform the similar configuration as above navigate from the Landing Quota Confirmation to the
Approve step (see diagram below for process flow depiction)




Run the newly configured business process:

Request
o Requester reduced UI complexity
Process
o Processor additional field (full UI) and additional action called Check Landing Quota
Check Landing Quota
o Processor Full UI with actions to Finalize Processing / Send for Revision
Approve
o Approver Full UI

2012 by SAP AG. All rights reserved.
SAP and the SAP logo are registered trademarks of SAP AG in Germany and other countries. Business Objects and the Business Objects logo are trademarks or
registered trademarks of Business Objects Software Ltd. Business Objects is an SAP company. Sybase and the Sybase logo are registered trademarks of Sybase Inc.
Sybase is an SAP company. Crossgate is a registered trademark of Crossgate AG in Germany and other countries. Crossgate is an SAP company.