Introducing SAP Master Data Governance (MDG)
Explaining MDG Data Quality Enhancements
Demonstrating MDG Data Modeling
Clarifying the MDG User Experience
Exploring MDG Process Modeling
Defining MDG Data Replication
Appendix: Demonstrating Data Transfer and Hierarchy Management

Learning Workflow Basics

Objective

After completing this lesson, you will be able to explain workflow basics

Process Setup

The diagram shows the data model and governance scope. Information is provided in the following paragraph.

The Governance Scope defines the customer-specific subset of the MDG data model, which is included in the governance process.

Further explanations:

  • Configurable data model elements are:

    • Entity types of storage and usage type 4
    • Attributes
    • Referencing relationships

  • Rules:

    • If an entity is not governed, all its attributes and subentities are not governed
    • If an entity is governed, all its key attributes are governed
    • If an entity is governed, all its mandatory attributes are governed * (based on the mandatory flag in the data model)

  • The Governance Scope can be defined:

    • When implementing MDG.
    • When MDG is already used (previously submitted change requests are completed with the data already maintained).
Screenshot of entity types. Information is provided in the next paragraph.

Entity Types or Attributes that have been removed from the Governance Scope:

  • cannot be changed in a Change Request.
  • are displayed in read-only mode and can be suppressed in the UI configuration.
  • can still be imported into the Active Area but not using Change Requests (Staging Area).
  • can still be replicated or exported.
  • are not changeable in Mass Change.
  • can be used to calculate derivations, but are ignored if values are set by a derivation.
  • can easily be added back into to the Governance Scope.
The graphic shows the flexible options for process flow models with MDG.

The figure illustrates the flexible options for process flow models with MDG.

Change Request Type - Several Change Request Types can be assigned to one Business Activity. In that case, the user must select the Change Request Type to use.

The Change Request Type determines:

  • The workflow template.
  • The data model and the entity types.

The possible workflow steps are defined in the workflow.

The Status of the change request and the workflow step are used in the process logic of the workflow to determine:

  • The possible actions in the UI.
  • The next workflow step.
  • The next change request status.

Facts about the workflow used by MDG domain:

  • SAP Business Workflow is the technology foundation in all cases.

  • Several standard workflow templates are delivered for specific purposes.

  • One generic Rule-Based workflow template (WS6080086) is delivered that uses the Business Rule Framework Plus (BRFplus).

Comparison of Workflows Used by MDG Domain

DomainStandard WorkflowCommentRule-Based WorkflowComment
FinancialsDefault–generic WF templateSimple (CR-type + step) or Advanced/Extended (Simple + entity type)OptionalSuccessful internal POC
MaterialOptionalStandard workflow availableDefaultAgent determination and step logic in BRFplus
Supplies/CustomerDefault–WF template per processAgent determination using customizing (BP) and using BRFplus (procurement/ sales and financial data)Possible 
Custom ObjectsPossible Possible 

Workflow Templates: Review and Adapt Using Transaction SWDD

Cheat Sheet for Direct Workflow Template Access

Template PurposeIdentifier
Single Object workflowWS75700040
Validation workflowWS75700019
Change Request workflow in MDG-FWS75700027
MDG-F Advanced workflowWS75700043
MDG-AF Rule-Based workflow (used in MDG-M)WS60800086
Workflows delivered for MDG-S EhP5WS60800041 / 48 / 59 / 68 / 95
New Create workflow for MDG-S EhP6WS53100044
MDG-C workflows EhP6WS54300003 / WS46000023 / 27
MDG-AF (Master Data Governance Application Framework)
MDG-AF Sub workflow for RBWFWS60800091

Note

WD7570019 is a simple Validation workflow to accept or reject whatever you feed to it. It can be triggered from the Validation BAdI or from BRFplus Validations. It is not like the other workflow templates that you directly link to a CR type. Consider it as a sub workflow triggered from Validation activities.

Major Components of SAP Business Workflow

The graphic shows the major components of SAP Business Workflow. Information about the components is provided in the next paragraph.

In addition to allowing work items to be displayed and administered, the integrated inbox supports the full mail functionality of SAPoffice.

The work item manager is responsible for processing work items, including deadline monitoring. Activities can also refer to methods that run in the background, and in this case, the work item manager initiates the call to the background processes.

Rules-Based Workflow (MDG 9)

Screenshot of BRFplus. Information about the EhP6 version is provided in the next paragraph.

Improvements since EhP6 version:

  • Descriptions are displayed beside the keys.

  • Switch to edit mode prevents unwanted changes.

  • Table Settings can be influenced and personalized in multiple ways.

  • XML Export/Import in the Tools menu only active if activated by personalization (Administrative Usage).

Screenshot of the automatic workflow customizing transaction. Information is provided in the following text.

Ensure that the workflow customizing is active, complete, and working:

  • Automatic workflow Customizing Transaction SWU3.

  • Linkage Type activation for BUS2250/related workflows (MDG customizing).

Screenshot of a single object workflow. Information about step IDs is provided in the next paragraph.

The figure illustrates a single object workflow. The step IDs are explained next.

Step ID explanation of the single object workflow:

Explanations of the Step IDs

Step ID

Step Name

Task

Description

Processing Comment

Binding

000228

Status Change: Changes to Be Executed

TS75707951

Set Status of Change Request

Background

 

000047

Execution of Changes

TS75707943

Process Change Request

--> USER

&APPSTEP& = 1

000260

Status Change: Final Check to Be Performed

TS75707951

Set Status of Change Request

Background

 

000306

Validation

TS75707952

Check Change Request

Background

 

000068

Final Check

TS75707980

Approve Change Request

--> USER

&APPSTEP& = 2

000298

Activate Changes

TS75707953

Activate Change Request

Background

 

000294

Status Change: To Be Revised

TS75707951

Set Status of Change Request

Background

 

000288

Revision After Rejection

TS75707981

Revise Change Request

--> USER

&APPSTEP& = 3

000302

Discard Changes

TS75707936

Discard Change Request

Background

 

Material Change Request Types

Screenshot of the overview of the Change View 'Type of Change Request'. Information about reviewing and creating Change Request Types is provided in the next paragraph.

  1. Review or create your own Change Request Types:

    • The default set of five CR-Types delivered by SAP and activated using the BC-Set.

    • Each CR-Type is linked to one of the predelivered Business Activities.

    • The connection to the workflow determines the main processing logic.

    • For Material, the standard workflow WS6080068 is delivered and using the connection to Business Rules Framework (BRFplus), a flexible and enhanced workflow definition and control engine, is available.

  2. Check that the following business activities are in your system and that they are assigned to the default data model MM.

    • MAT1

    • MAT2

    • MAT6

    • MATA

    For more information, see Customizing for Master Data Governance under: General Settings→Process Modeling→Change Requests→Create Business Activity.

  3. Create new change request types for data model MM, or validate after import using the business configuration set (BC-Set). For more information, see Customizing for Master Data Governance under: General Settings→Process Modeling→Change Requests→Create Change Request Type. Alternatively, you can run system transaction SM34 and view cluster VC_USMD110.

The following settings exist in the substructures of the change request types:

  • MAT01:
    • Entity type: MATERIAL
    • UI Config: MDG_MM_APP_BS_MAT_GEN
    • Msg. Output: "W Issue Error Messages as Warnings"
    • Business Activity: MAT1 Create Material
  • MAT02:
    • Same as for MAT01
    • Business Activity: MAT2 Process Material
  • MAT06:
    • Same as for MAT01
    • UI Config: MDG_MM_APP_BS_DEL_GEN
    • Business Activity: MAT6 Mark Material for Deletion

MDG Rule-Based Workflow - Details on Main Branch

The graphic gives an overview of the MDG rule-based workflow and details on the main branch.

The graphic shows an example of a MDG for Material - generic workflow.

The figure illustrates an example of a MDG for Material - generic workflow, which is controlled by rules.

The graphic shows various step types and actions.

The figure illustrates various step types and actions.

BRFplus Information

Important Terminology and Variables are:

STEP (Type 1: in Business Workflow BWF)
A workflow pattern in SAP Business Workflow consists of several steps which are connected to a TASK (BWF).
TASK (in Business Workflow BWF)

A task is a unit of work for a user, shown in the UWL or a background activity in BWF.

STEP (Type 2: In Rule-Based Workflow, RBW)

Steps in the context of RBW are defined in customizing (only Dialog steps) and are orchestrated by BRFplus-decision tables (Dialog and Background steps). Each RBW-step is a loop in the generic RBW-workflow (WS60800086) and can consist of several BWF-steps.

PROCESS_PATTERN (RBW)

Important container variable for controlling the main branch in RBW.

STEP_TYPE (RBW)

The step type determines the UI (approve, agree, revise). There are some predefined UI step types in RBW. Each step type has its own set of ACTIONS.

CONDITION_ALIAS (RBW)

A key that connects the three different decision tables in BRFplus for RBW.

ACTION (RBW)

An action is the resulting value of a UI-based user decision (click on button) in a certain RBW step.

Note

All variables/terminology can be found with slight differences in the BWF workflow container.

Methods for Workflow Troubleshooting

  • BOR Object BUS2250 (MDG Change Request).

  • In transaction SWO1, choose Test, and enter a Change Request ID. Then, perform:

    • Finalize inconsistent/incomplete Change Request:

      • Method ROLLBACK_2 —> Execute

      • => final check rejected

    • Check if processors are found:

      • Method GETAGENTS —> Execute

      • => results in a list of processors or errors

      • Transaction SWI1_RULE can be used to execute the rule for the user determination of a work item again

    • Assign Agent manually: SWI2_ADM1

Change Request (CR) Process Configuration

Change Request Framework

The graphic shows the technical concept of the change request framework including the (logical) action, business activity, change request type, action, change request step types, and change request step (number).

The assignment of Step Types to Step Numbers is done:

  • in the BRF decision tables (for the Rule-Based Workflow).
  • in the Workflow Step (for other MDG workflows).

Enhanced Flexibility

The graphic shows the definition of a local action for enhanced flexibility. A logical action is a high-level process definition that is not tied to any business object, allows the flexible navigation between user interfaces, and an enhanced determination of business activities.

The figure illustrates the IMG activity to set actions, and explains them.

The graphic shows how to set a business activity. A business activity implements the logical action on a particular business object type. It is a configuration object that is associated with a change request type. If associated with more than one change request, the user has to decide which change request type to execute.

The figure illustrates the IMG activity to set business activities, and explains them.

The graphic shows how to set properties of change request steps. It defines the UI on the change request type step level, enabling process flexibility. This overrules the configuration on the logical action/business activity level.

The figure illustrates the IMG activity to set properties of change request steps, and explains them.

Business process experts can assign a user interface to a change request step.

MDG provides far-reaching control over user interfaces at every level from the change request step upwards. See section "Logical Actions, Business Activities, and UI Navigation".

The graphic shows the customizing activity Define Step Types and Assign Actions and its screens. You assign actions to step types and the actions define the next available steps. These actions are represented in the UI by using the buttons. They can be standard actions or customer-defined actions.

The figure shows the customizing activity Define Step Types and Assign Actions and the screens, which are called, when this activity is started.

Screenshot of the relations between actions and step types.

The figure illustrates the relation between actions and step types, concerning the user interface.

The graphic shows the steps in creating a change request and the assigned properties.

The figure illustrates to steps in creating a change request and the assigned properties.

The graphic explain the possible step properties in a change request. For each step, business process experts can define enhancements and check by enriching parts of data by assigning an enrichment spot, skipping unnecessary checks, and ensuring validations occur by assigning checks. They can set field properties for entity types and attributes by specifying which fields are relevant, and which relevant fields are required, by setting field properties. They can also assign a user interface by assigning a different Web Dynpro Application to the standard one configured for the data model, allowing maximum flexibility on the change request step level.

The figure explains the possible step properties in a change request.

Screenshot of the enhancements and checks. Information about how business process experts can apply enrichment spots and check is provided in the next paragraph.

The checks and enrichments are called in the following sequence:

  • Standard checks except duplicate check.
  • Enrichments in the configured sequence.
  • If data changed in an enrichment call, the standard checks are repeated for the changed data.
  • Duplicate check

Detailed settings are possible and you control the following features:

  • Sequence: The sequence in which enrichment spots are executed.
  • Message Output: Set the severity of messages raised (error or warning).
  • Relevant: Sets the relevance of a check. Dependencies exist with field properties on entity type and attribute level (see next section).
  • Execution: Always executed or executed when data changes.
The graphic explains the possibilities of setting field properties and check logic by asking is a field required? Is a field relevant (used)? Which checks are applicable?

The figure explains the possibilities of setting field properties and check logic.

Screenshot of the field properties on various levels. Information is provided in the following paragraph.

The determination of the field properties is defined on various levels:

  1. Change Request Step specific field properties
  2. BAdI Implementation (USMD_ACC_FLD_PROP_CUST_DEP_SET)
  3. MDG Data Model Configuration
  4. Field Properties from the Reuse Area

Level (1) overrules (2) overrules (3) overrules (4).

The relevance of Checks can be defined on two levels:

(a) Change Request Step and Entity: Reduce Checks to "Basic Check only" or use "All Configured Checks"

(b) Change Request Step: Except for Basics Checks, all checks can be set to "not relevant"Level (a) overrules (b)

Level (a) overrules (b).

Required Field Checks

  • Checking required fields (defined by the Field Properties) is executed by the MDG Framework or by the Reuse Area Check. This depends on the Reuse Class implementation.
  • For Custom Objects (in the Reuse Option) the Reuse Area Check should be used (but might depend on the complexity and existing checks of the object).

The Change Request Specific Configuration is also available for MDG-S, MDG-C, and MDG-M, and the required field checks are executed:

  • For MDG-S and MDG-C by the Reuse Area Checks.
  • For MDG-M by the MDG Framework (Reuse Area Checks need to be set to "not relevant").

Explore the Workflow Features for End Users

Business Scenario

As a master data steward on an MDG project, you are required to initiate Change Requests and check the status of Change Requests in the project.

You are also required to understand the MDG project workflow.

Note

In this exercise, when the values include ##, replace the characters with the number that your instructor assigned you.

Use the prepared MDG System T41 client 400.

ExerciseStart Exercise
Learning

SAP FacebookSAP YoutubeSAP LinkedIn