Overview of Validation in MDG

MDG framework offers several options for field validation and data validation. Field vs data validation? I distinguish it here to highlight the validation solution from UI during data entry versus the data validation that is done to measure and fix/remediate the quality of data already saved and active in the system.

When users enter data, following are few ways of validating this data:
- Required field check.
- Field value dependent on other fields and their values.

creatign descptive messages and displaying them

altering user navigation, for instance, stopping them from moving forward.


An important topic I like to add to all the blogs is how to trace the code and reach the logic. this also helps us when designing the solution.
so here we go for validation using badi....

How and why to enroll in our SAP MDG Training (e-Learning) offering?

Master Data maintenance is a great space to be in.

MDG is SAP's product offering for Master Data maintenance. Netweaver MDM is now retired and is being phased out. Netweaver MDM was a great product and I had trouble accepting MDG as a master data solution. I had worked on MDM from versions 5.5 through 7.1 and have seen the product evolve. But it is history now. It was a standalone solution and one of the primary issues with it was the long implementation times. MDG on the other hand, sits right on top of the ABAP stack and has a fraction of the implementation time.

Our eLearning sessions (plus additional course material including exercises and Q'nA) give you a great clarity about the way MDG is built and how to best design customer solutions using MDG.
So enroll in the training today and get started. We offer 30 day trial period. If your training expectations are not met, you can always get a full refund. Just send us a email requesting refund (no questions asked). The pre-requisite  is minimal (we all have blind-spots in our knowledge base, so we "assumed little" when developing the course content).

Pre-requisite: The course is built for professionals with following backgrounds:
i. a MDM professional with experience in master data maintenance projects and wants to shift their expertise to SAP MDG. OR
ii. an ABAP developer who wants to work on MDG projects OR
iii. someone with a technical background who is interested to know more about the inner workings of SAP MDG solution.

Why is MDG promising?
MDG is promising because master data is important.
The rapidly growing importance of data, to businesses, can hardly be overstated. Even laymen know that. But as business and technical professionals, we know the specific workings of this data and how it is used. We know that any analysis performed (in SAP BI, for instance), on this huge volumes of business/industry data, is only as good as the quality of master data that it is plotted against. The dimensions have to be accurate. The same goes for the efficiency of core processes (in ERP, for instance) that rely heavily on master data values.

Good luck with your career aspirations and wish you the very best in your efforts.

Understanding Entity Relationships in SAP MDG

There are four relationship type in SAP MDG. In this blog we will discuss the first three with samples. I'll cover foreign key relationship in a later blog with an accurate sample.

But, before we proceed with the implementation, let me outline the "business scenario" that we will use to understand entity relationships:
Rental Car Sample Scenario (Why fictitious scenario?): A Rental car agency (lets call it PRITZ) buys new cars on a regular basis, to maintain/expand their fleet of cars at various rental office locations, across the country. We will create a MDG solution to maintain the master data for the cars in the fleet. When PRITZ buys new types of cars (or sells existing cars), a business user (say Lisa) in PRITZ's headquarters will use our MDG solution to add the new car types into the system. If PRITZ decides to buy 80 Toyota Prius 2019 models for 13 rental locations, Lisa will use our MDG solution to add Toyota Prius as a new car type in the system and trigger the change request process. The change request then goes through the various departments of Maintenance, Operations and Sales. Master Data Stewards at each of these department will enhance the data with the right attributes and approve them. It is also important to point out that, MDG solution is to maintain the "master data" of Car type. Every time a new purchase order is created to buy additional cars (or an existing car type), it a "transactional data" in the system.

In the reference implementation of the above scenario, we have following relationships. BTW, the entire end to end implementation of this MDG solution can be viewed here.

But, to start with, the data model will look something like this.



Leading: In our example here, it is the a relationship between a RCAR (SUType1) and SUType4 entities. The key, RCARID, of RCAR is automatically added as the key for the SUType4 generated table

Qualifying:

Referencing:

It is important to note that the MDG eLearning series is being constantly updated. It is a one time fee to get life time access to the training material and it is constantly updated to add additional MDG scenarios.

Why use a fictitious scenario rather than a real world ERP scenario?
We decided to use fictitious scenario for several reasons. We go through the entire end to end realization phase with this sample scenario for custom object. This helps showcase all the capabilities of MDG. With a ERP scenario, it would help to know the master data object well. The simple rental car business scenario is relatively very simple to grasp. A MDG beginner can spend more time focussing on the details of MDG and its underlying technologies. As opposed to getting bogged down with Material, Plant, MRP, BOM, Routing and other details.
We will cover scenarios involving MDG Material solution in later additions of the eLearning content.

MDG Data Modeling basics.

Data modeling the first step with any mdg implementation. As with every other aspect of MDG, data modeling process is very flexible and generic. The flexibility ensures that MDG can address a variety of customer requirements and data model design specifications.

This blog highlights various rules and reasons behind the data modeling decisions. For an end to end solution implementation, check out the eLearning sessions posted here.

Once the data model is implemented in MDG and activated, the system automatically generates the underlying tables and structures. When the end users create or change data from the UI, the data is persisted in these generated tables.

Data Model for Z4 (a test data model):

The corresponding generated tables for Z4:

There are a variety of configuration options when creating an Entity. Each of the options affect the final MDG solution in a unique way. In this blog we consider the configuration options available with mdg data modeling and their significance. 

First step in mdg data modeling is to create a SU Type 1 (Storage and Usage Type One) entity. To draw an analogy with MDM, SUT1 in MDG corresponds to the Main Table in MDM.

For a simple Type1 entity, the Storage Type, Data Element and Description are the main fields. Leave the others as defaults. Data Element is a optional field here. When provided, the Data Element is a key field in the generated table.

For this Entity, I have added one attribute of type Z3COMMENTS. Pl. note that the Data Elements and Domains used in MDG Data Modelling already exist as part of a ERP solution or are created (using SE11 tcode) .

This is a simple data model with a single Entity. Suggested next steps:

1. The four Entity Types in MDG
2. Understanding relationship in MDG
3. Key Assignment and Deletion have a dependency on each other. These dependencies are enforced by the system. Try changing the default values to observe the specific dependencies.

Following three error messages show up when I try changing the Key Assignment to "Key Can Be Changed; Internal Key Assignment Possible".

4. Try creating the SUType1 entity with out the data element. Instead add an attribute of this type (of data element) to the Type1 entity. See the resulting change in the schema of the generated table.

Cheers!

SAP MDG customers: Top 10 questions for decision makers.

              Senior IT managers, Directors and other stakeholders know about the importance of an accurate Master Data. These are also highlighted well in pre-sales discussions. But, before a MDG implementation, do all the participants have an accurate understanding of:
- the implementation costs involved?
- risks and dependencies?
- the SAP infrastructure pre-requisite to ensure a smooth implementation?
- the implementation process?
- how workarounds affect the end results and benefits?

        While these factors are specific to each implementation, following are some questions that help stakeholders make the right decision and choose the right timing.

        We do offer an unbiased technical evaluation (at no cost to you). We can be reached at SAPMDGCurious@gmail.com. We urge you to include the following information in your request: Your name, title, corporate email id and link to your LinkedIn public profile. This is to help us address genuine requests with priority.

*mdm in this white paper refers to 'master data management' project and not to Netweaver MDM product.

What are the quantified benefits of a mdm process improvement project?
- With all approvals and data enrichment steps included, how long does it take to create a master data entry? How can this be improved (for instance, reduce the process from 3 weeks to 4 days)?
- Does the process involve use of multiple disparate systems.
- What are the top issues with your master data? What percentage of the data is duplicates? Which master data objects have a poor quality and why?
- How does the poor quality of master data affect the process and reporting in your organization today?
Irrespective of the mdm tools used, identify the business drivers and quantify the benefits.

Is MDG right for your IT landscape?
MDG is built on top of SAP ERP as an add-on. If you are trying to maintain master data that is relevant for SAP ERP (for instance, Suppliers, Customers, Cost Center, Profit Center, Material, Company, Consolidation Unit etc, that are based on SAP ERP and other business suite applications SAP CRM, SAP SRM), then MDG makes a perfect choice for a master data maintenance system.
On the other hand, if the enterprise systems, and its processes that use the master data are non-SAP (like Peoplesoft, Oracle, Seibel etc) then MDG is another master data tool in the market. It is no longer an obvious choice and has to be evaluated for its features alongside the other master data tools.

How do I prepare for a master data maintenance project?
Before making a choice of the software or launching a mdm project, pl. research to evaluate the quality of existing master data. Perform data-analysis to identify major areas of concerns with existing master data: is it duplicates, errors in data etc. This will help answer questions like the level of data cleaning to the performed during cut-over, loop holes in existing process that resulted in these issues etc.
Data quality analysis can be performed using SAP tools like BOBJ Data Services, Information Steward etc
The results of such an analysis, validates the effectiveness of existing processes. It can be used not only to build an effective business case for master data maintenance project, but, also creates a baseline to measure progress over various phases of the implementation.

Why MDG?
A primary benefit of using MDG is a short implementation cycle. A lot of MDG's underlying technical components are model driven and support a coding-free implementation. These technical components (SAP Business Workflow, BRFPlus, WDA FPM, ABAP Dictionary) have been around for a long time and are also used across several SAP products. They have evolved over time and each is a mature solution in its own right. MDG is built upon a very stable platform.
MDG is a relatively new solution and has evolved within the last three years. But, the fact that it is implemented on very mature technical components, gives it immense stability within a very short time span.

How to staff a MDG project?
The team size for a MDG implementation project is typically small. Staffing considerations include skills needed; number of resources and duration of their engagement; project phases when a skill is needed.
For an MDG implementation, you would need Basis administrator, Functional resource (domain expertise in master data and its processes), technical expertise in underlying technologies (Workflow, BRFPlus, Webdynpro for ABAP- FPM, ABAP development), project management, Security.
Basis skill is needed in the initial phase of the project to build servers, configure transports, set up RFCs connections (in MDG Hub installations)
Functional resource is needed in blueprint, testing, cut-over activities.
Security skills are relevant for building custom roles, provisioning end-users, admin-users etc for this solution.
Most of the skills are already available in a typical SAP shop.

Does SAP supply an out-of-box solution for my master data?
While MDG is an effective platform to implement applications, to maintain custom master-data-models, SAP supplies several data models out of the box. So before embarking on a custom-implementation, pl. confirm if there is an out of box solution or one that is in immediate road map of SAP MDG. Due diligence also needs to be performed on the extent of this functionality in terms of data model and creation processes. Notes (like 1701437) and how-to guides provide ample information.

Concerns about Implementation process, cost, time-line & project plan.
Depending on if an out-of-box solution is available for the data model, MDG implementation starts with enabling the SAP delivered functionality. For instance, to maintain Material, Supplier, Customer data models, the project would start with a rapid deployment of delivered solution followed by a gap-fit analysis.
Following the ASAP methodology, Blueprinting in this case involves a gap-fit analysis phase. During this phase customer specific requirements related to data model, Change Request process, user interface, validations & derivations are documented.
Realization includes a fairly short implementation process using various model-driven development tools.
Subsequently the project follows the traditional process of integration-testing, training, cut-over and go-live.

Can we reuse transaction codes, that already exists in ERP, to maintain the master data?
Most of the master-data models have existing maintenance functionality. This is true in the context of SAP ERP as transaction codes. For example FS01 for General Ledger Account, MM01 for Material, CS01 for BOM etc. A Major step within the Gap Fit analysis is comparing the existing Master Data Maintenance processes versus the proposed solution. Depending on the master data being maintained and the client systems for the master data, validations and derivations from the underling system may be reused.

Is SAP RDS solution a good fit?
SAP delivers Rapid Deployment Solutions (RDS). These are packaged services that go with various SAP product offerings. For instance, SAP CRM has several RDS solutions that are suited for customers. There are SAP RDS offerings for MDG implementation as well.
Some implementation partners also provide similar services. Please contact us for a comprehensive review of these packaged services. Weather a RDS solution is right for you depends on several criteria and is very specific to your requirements. In general, these packaged solutions are very specific in what they implement.

What are the infrastructure and licensing costs?
Master data maintenance is typically not a high volume, resource intensive process, as compared to systems that support transactional data. The infrastructure costs are often low for such an implementation. Primary deciding factor here is system landscape design (number of technical components added to the landscape and if they are co-located/how they share resources). Some of the technical components in the landscape may also be reused.

What are the long-term objectives?
Before embarking on a MDG project, like almost any other initiatives, it is good to list the long term objectives. In this case, following are couple of options:
- What other master data objects can be maintained using this MDG installation? Research on existing support for those data models as well as maintenance processes around that data model.
- How to effectively split the requirements across implementation phases? One way to do this is to go with a technical implementation in the first phase with minimal business functionality. This ensures that you get the technical components into your landscape with minimal risk to business processes. Once the MDG system, Enterprise Search, data & change request analysis and other components are in place, plan to extend with additional technical components, business processes and data models.

MDG implementation is a great opportunity to 'improve' on the mdm processes in your organizations. This is a better alternative to simply 'migrating' your existing mdm processes. We wish you the very best for a successful MDG solution in your organization!

In addition to helping you evaluate SAP MDG, we can also assist you with:
- Interviewing candidates for MDG positions
- Help you develop a MDG project plan
- Develop system landscape plan and architecture
- Evaluate the implementation-in-progress at various stages.

Please let us know if we can be of assistance.

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