MDG Material workflow: Adding a button to a workflow step

The three major technical areas of an MDG application are:
Data Model
User Interface
Workflow process

Implementing a customer specific requirement involves changing one or more of the above technical areas.
In this blog, we will discuss a requirement that involves changing the workflow process.

Workflow is very central to MDG scenarios. Each of the MDG scenarios of create, change, block or mass processing of master data has a workflow process. Depending on the scenario, in any given workflow step, a user may perform data enrichment or approval of the change request.

Generally speaking, that are various aspects to a end-to-end workflow process: the number workflow steps, user roles responsible for each workflow step and actions available at each step, the UI display for each workflow step etc. These aspects of the workflow process are specific to each customer and their MDG implementation. The customer requirement is often carried over from the customer's existing master data management (mdm) strategy. The customer specific requirements may araise from something that the business experts are used to or it may be specific to the customer's industry. Partly because several elements of the existing mdm strategy works well for customers, and partly to reduce the end-user-training overhead for the new mdg system. Irrespective of the reason, changes to workflow process are quite common in any MDG implementation.

As MDG implementer, you customize the out-of-box solution to customer's needs.
So today lets discuss a simple scenario of how to add a custom button to a workflow step. These custom buttons (displayed at the top of the UI when user selects a workflow item from inbox) have a custom behavior.
Lets split the implementation into two parts.
1. Make a custom action (a button) appear in the UI.
2. Associate a custom behavior with this button.

In this blog post we discuss the simple steps to achieve the first, namely, make a custom button appear on the UI. This is a simple process that only takes a few steps.

1. Create a custom action.
2. Associate the custom action with a step type.
3. Test the change.

1. Create a custom action.

Navigate to tcode mdgimg. General Settings> Process Modeling> WorkFlow>Define Actions for Change Request UI.

Click on 'New Entries' to create an Action. When saving this change, you will be prompted to provide a customizing request. Create/Select a customizing request number. Save the entry.

A new action  is added.

2. Associate the custom action with a step type.
Back in MDGIMG, navigate to General Settings> Process Modeling> WorkFlow>Define Step Types and Assign Actions.

Select a Step Type that you want the button to be assigned to. Remember, to select a step that is part of the process and that is available for the user in question. These considerations will be revisited when we configure the BRFPlus decision tables in the next part of this blog.

Once row is selected, click on 'Assign Actions'. This kind of navigation is not very intuitive to newbies, but will be used across various parts of MDG configuration.

3. Test the change.
Once the above configurations are done, go through the workflow process till it reaches the above configured step type.

Notice that the button is available to end user.
In the next blog post, I'll show you how to add functionality to the button.

This link has numerous related MDG image posts.

End-to-end Data Flow between MDG and ERP systems.

In this blog we will be discussing data; the various types of data, its flow between MDG hub system and ERP system. Before we start, let's list the types of data we will be discussing here: Master data, Transactional data and Customizing data.
Master data is the only type of data end users (data stewards) will be modifying within MDG system. Material is an example of master data. It includes the identification data (e.g. Material ID), descriptive data ( e.g. material description) and process data(e.g. material type). Changing the value of material description does not affect the material unit of measure or characteristics.

MDG maintains master data while ERP uses the master data.

Arrow 1:
Lets consider the specific case of "Material" as the master data.
Customizing data is created by MM functional person. This customizing data created (as a result of configurations) by MM functional person, influence the way MM related end user (like MM01, MM02 etc) transactions in ERP, behave at runtime. e.g. Field control settings.
The same customizing settings influence the way MDG screens work as well. In other words, MDG uses a lot of this customizing data for its functioning. For instance, Field validations: MDG 'Create Material' screen would have the same field validations as MM01 screen on ERP. The field control settings, in both cases, are based on MM customizing settings.

If MDG is implemented as a Hub system (as opposed to being co-located on ERP client as a true add-on), it does not immediately have access to the customizing data in ERP. In this case, the customizing data has to be explicitly moved from ERP system to the MDG system. MM functional person can identify the specific data and tables that needs to be copied. This document provides a great overview of the alternate strategies used for customizing synchronization.

Arrow 2:
In addition to creating master data, MDG is used to perform updates to existing data.
Existing data is also used, in Embedded Search scenario, to search and ensure that a duplicate master data entry does not already exist.
Where does the existing data in MDG come from?
This is created, at system go-live/cutover, by an initial data load. All the master data (cleansed version) is moved from client systems to MDG system. in case of MDG-M, the data is loaded to MARA, MARC etc tables.

Arrow 3:
Once the MDG solution is implemented and active, master data specialists will use the MDG functionality to create master data.
This data will proceed through the approval workflow. Once approved, the master data gets 'Activated'. At this point, data moves from MDG staging tables to active tables (in the case of ReUse).  If MDG were installed as a standalone hub, the data is still in ERP tables in the MDG system. It has to be replicated to the corresponding master data tables in the ERP client system.
This is implemented using the Data Replication Framework (DRF).

Please note that I assume ERP to be the client system. In generic terms, this down stream system/ that gets master data from MDG can be any system (Legacy, ERP, SRM, CRM etc).

Images: MM customizing transactions in SPRO, MDG customizing transactions; generated MDG tables; Data in MDG tables; Data in Mara; SMT mapping

Typical implementation steps for an SAP MDG project.

A project usually starts with a blueprinting phase.
In the case of MDG, I would recommend starting the project with a "initial configuration" phase. This is particularly true in cases where SAP delivers an out-of-box solution for the master data domain. For instance, if customer is planning a MDG implementation for Material, start with activating the out of box solution with the default data model and simple 2-step approval workflow in a sandbox environment.

Let me elaborate.
Depending on the Master Data that we plan to maintain with MDG, SAP may already provide an out of the box solution. Few such data models are Material, Supplier, Customer etc. But the Data Model, workflow process, rules and validation, UI of these solutions may not fit the customer needs. So the suggested approach is the following:
i. First implement the out-of-box solution. Activate the supplied BC Sets and follow through with rest of the configuration steps.
ii. Once this basic solution is implemented, demo the functionality and train the super users. A baseline solutions is a great place to start the blueprinting. Let business owners use the features

iii. This would let the stake holders compare and contrast their existing solution and processes with MDG.
iv. With this initial exposure achieved, initiate the blueprinting phase. The primary area of requirement gathering are :
          a. Data Model changes.
          b. Process definition (Users, Steps, Actions) to address the primary flow and fallout conditions.
          c. User Interface definition
          d. Validations/Checks and Derivations.
Remember to scope the project across phases.

You can reach me at SAPMDGCurious@gmail.com if you wish to discuss about MDG project, skills needed for MDG implementation, known challenges and risks.

View my images for a visual tour of MDG screens.

Using TREX for MDG Material

             While this blog discusses search in the context of MDG-Material, the concepts are applicable for other Data Models within MDG, as well.

             

             Search (Enterprise or Embedded) is an essential part of MDG Material implementation. Enterprise search is a more elaborate solution, with TREX and BWA components, that can be used to index and search content across SAP systems (SIDs). Embedded search uses TREX and can search and index content related to a single SAP system.

             In the absence of an Enterprise Search solution in the landscape, customers often start with the Embedded Search solution where a TREX instance (in a standalone server) is used to Index and Search Material Data, in both, Staging and Active areas.

Why index data in MDG Staging area?

Users often execute a search for Material 'before' they decide to create one. In addition to searching in Active Area, for the existence of a Material with same specs (to prevent duplicates), users need to search the Staging area as well. This is because, a similar Material change request may be halfway along the approval process.

Board implementation steps:

- Install and configure TREX. Use note 1249465.

- Configure Search connectors. Find for "Embedded Search" in this url.

- Index the data and start searching!

Relevant tcodes and reports: SM59; ESH_COCKPIT; TREXADMIN, ESH_TEST_SEARCH, ESH_ADM_INDEX_ALL_SC.

Related screen images can be viewed at the this link:

SAP MDG data model: A walk-through

SAP MDG solution essentially has the following main components:
- Workflow
- Data model
- User interface
- Validations and derivations
- Replication

Lets focus on the MDG data model in this post.
The data created (or modified) within MDG exists in two states:
- Active (approved, in terms of process) and available to be used by processes within client sytems (SAP ERP most commonly).
- Inactive data (that ing throughs still movi the approval process) that is persisted in the Staging area.

The tables, for the Staging area is automatically generated from the data model. The MDG implementer can view data within these tables at any time [SE16]. This is a good context to introduce the terms Flex and Reuse. These are two alternate approaches to MDG implementation. In the case of Flex, both the Active and Staging tables are generated as part of MDG data modelling. In case of Reuse (as opposed to Flex scenario), the tables for active data are not generated. The underlying ERP tables (that lie outside the scope of MDG) are used to store activated data. In other words, when data gets activated, the active data is copied to the ERP tables.

For now, lets consider just the tables used to save Staging data. This way, the below discussion is relevant for both Flex and Reuse scenarios. To get the table names,
- execute the standard ABAP report usmd_data_model [SE38]
- select the MDG data model, for instance MM.
- Next screen displays the list of generated table names.
The details include both the logical and physical table names.

Use the physical table names to view data [SE16].
The table contents show the Master Data as they move through the create or change Change Request process (decided by the underlying Workflow template in use).