SAP MDG Change Request Creation

In SAP MDG, each change request begins with mandatory fields that must be filled out before it can be saved.

Depending on whether your role allows access to save requests, you may experience some limitations when attempting to save them.

After clicking “Save”, I returned to the Web-Dynpro view to continue material setup. One thing that particularly stood out to me was how SAP MDG handles user interface (UI) configuration based on CBA: Context-Based Adaptation rules are being utilised when you see “UI Configuration with CBA.” When this appears on your screen, some context rules could be in play that require it.

SAP MDG allows for user interface (UI) adjustments at multiple levels – across an entire data model, specific change request steps or individual fields – providing users with more freedom in customising their experience when it comes to hiding or altering fields based on role or step requirements.

This flexibility provides opportunities to tailor user journeys more precisely than ever.

SAP MDG Request Steps

After I have written my request in SAP MDG, I always take one step backwards to double-check its logic and ensure a successful transaction.

Each step builds upon itself; therefore, going back to ensure consistency is part of maintaining consistency throughout.

If you have questions or are confused by what comes next, I will gladly review these parts in greater depth during follow-up sessions.

However, as an overview, the workflow then continues into the birth steps of the request process, where tasks will begin to be assigned.

Don’t panic if some templates don’t appear immediately – SAP MDG takes time to populate configurations entirely, especially if your environment is a demo or sandbox type.

Configuration of SAP MDG Workflow

One of the most rewarding parts of using SAP MDG is configuring its change request steps. I created my request — Z_MAD_0 — and implemented two new workflow steps, depending on whether a customer (C), vendor (V), or materials (M) data-related request existed.

All in all, convention and clarity prevail here!

SAP MDG steps can’t be directly edited; therefore, I navigated to its rules-based workflow section, searched by position and copied and edited existing entries to my requirements, saving each one back for my personalised process, with each copy-save process completed in SAP MDG.

SAP MDG provides ample room to define entities for change, user interface fields, and workflow steps; however, altering its standard configuration can cause unsupported setups or potential system issues.

To avoid these issues, I learned to create copies, configure workflows, and maintain integrity throughout SAP MDG.

SAP MDG Workflow Setup

One principle I follow when setting up SAP MDG workflows is never editing standard configurations directly.

While this may be tempting, adhering to the standard setup is key for long-term stability.

So, let’s dive into the SAP MDG system flow in its intended sequence of exploration. I find that adhering to this order helps us grasp not only individual steps but also their importance within their broader context.

Many of you are keen on exploring workflow configuration in SAP MDG, so let’s walk through it together!

Workflow Navigation in SAP MDG

As part of my typical SAP MDG workflow routine, we begin by clicking into the workflow section and exploring available templates, particularly an empty J workflow template.

Once you scroll down, you’ll come upon an option called ‘Define J Request’; here lies the real configuration process, and I would like to pause here and ensure everyone understands why this step is vital in SAP MDG.

As part of the SAP MDG workflow, one key feature is Processor Assignment, which identifies the user responsible for each stage in the process and plays a crucial role.

This feature, crucial when dealing with data governance roles, cannot be ignored.

SAP MDG Workflow Confidence

As I learn SAP MDG, I find that taking it slowly helps clear away most questions before they even appear. That is how I approach each session — slowly yet methodically.

Later, we will return to complex flows, but for now, keep this in mind: SAP MDG allows for flexibility if you know when and how to trigger it.

As we explore SAP MDG, let’s keep our curiosity piqued; every time we delve in, we may uncover something new about its workflow logic, user roles, or approval chains.

Business Systems in SAP MDG

When I started configuring SAP MDG, the first thing I tackled was setting up the business systems. I opened the technical settings section and began defining every relevant system.

For instance, imagine working with A4H and needing to transfer data to B4H — that’s precisely the kind of connection I mapped out.

To ensure smooth SAP MDG communication, I ensured that RFC connections were in place. The BASIS team handles these, so my role was to make sure all business systems were registered correctly. Once connected, I could pick B4H from the list and proceed confidently.

Logical and Business Systems in SAP MDG

SAP MDG simplifies the task of creating both logical and business systems. Still, I took great care in selecting each application row before proceeding through system setup – this is where replication objects come into play.

I needed to specify the replication objects (materials or business partners) that SAP MDG required to direct data efficiently across systems.

Selecting an ideal view object made an immensely impactful statement about system behaviour and stability.

SAP MDG: Comparison between IDoc and Web Service

As part of setting up SAP MDG, selecting an ideal data replication method was paramount. I decided between IDoc and web service for replication.

For most MDG processes, I favoured IDoc because of its reliability and popularity for master data replication purposes.

SAP MDG does not permit dual configuration for objects; I therefore used either IDoc or service replication per object to ensure my system remained predictable and stable. When in doubt, I reviewed each object’s requirements to make an informed choice.

SAP MDG Key Mapping and Application Settings

Configuring key mapping in SAP MDG was like solving a puzzle. Sometimes the source system required a key value “X,” while its target required it to be changed to value “Y.” Mapping was used as the solution.

I explored options like ‘Not Defined, Harmonised and No Key Mapping. Most often, however, I left it as “Not Defined”, although sometimes specific scenarios called for another setting – something SAP MDG offered as flexibility that I appreciated greatly.

Controlling Replication Behaviour in SAP MDG

Within SAP MDG, I could select when and how data was replicated. With its two modes, ‘Direct Output’ and ‘Hold Output’, available to me, real-time updates were best met using Direct Output mode.

As soon as a change request was activated, data began flooding across systems immediately. To accommodate batch environments, I configured Hold Output and scheduled background jobs for sending IDocs. SAP MDG allowed for easy control over tailored data flows.

Object-Dependent Defaults in SAP MDG

SAP MDG offered me another advanced feature I discovered while replicating materials or financial objects: object-dependent defaults.

Based on whether I was replicating materials or finance objects, validity and replication timing settings differed accordingly.

Materials in SAP MDG don’t rely on validity periods, while finance objects do. Once I was aware of this fact, I could fine-tune the settings to meet each data domain perfectly.

Replication Model in SAP MDG

After conducting initial configurations in SAP MDG, I developed a replication model that defined which objects, such as cost centres or materials, should replicate to which systems.

Once I selected my model, SAP MDG automatically implemented any prior communication settings and assigned target systems via RFC for seamless data transfers, with no manual repetition necessary – just an accurate mapping in the replication model.

Activating and Managing SAP MDG Replication Models

With everything set, I activated my replication model in SAP MDG – it felt like turning on a light! Within moments, data began flowing as expected.

If I ever needed to stop replication temporarily, SAP MDG allowed me to deactivate its model without losing data or requiring any additional work, resulting in an elegant solution that minimised data loss and effort. Clean, simple, and efficient: that sums it all up nicely!

SAP MDG Replication Settings

At SAP MDG, my first order of business is activating replication settings. When I click “Activate”, an alert appears, asking me to confirm this action. Once activated, I ensure that all grids have been added successfully.

As soon as there’s any misconfiguration, such as incorrect message type or connection details, I immediately see an error notification.

Replication Settings in SAP MDG allow for customisation when replicating data; in particular, if I wish to replicate certain pieces only under certain conditions, I can utilise BAdI (Business Add-In).

SAP MDG provides me with the flexibility to tailor the process to my unique requirements.

BAdIs and Workflow in SAP MDG

At SAP MDG, the BAdI system method plays a pivotal role during workflow execution and subsequent data replication. I then configure the target systems accordingly once this task has been completed.

If I need to initiate follow-up change requests or notify of their activation after activation is completed, using BAdI is beneficial in automating post-activation processes in SAP MDG.

Configuring Services and Classes in SAP MDG

Setting up SAP MDG involves specifying a service name and class. This service name is directly connected to BAdI, while its associated class contains logic that executes under specific conditions. It provides robust control over how and when particular actions occur.

I read through several documents outlining all the BAdIs utilised by SAP MDG and found their reading helpful in understanding which BAdIs pertain most closely to my use cases.