Learn, Practice, and Improve with SAP C_MDG_1909 Practice Test Questions

Explanation:

In SAP MDG, "Agent Selection" (determining who receives the next task) can be handled entirely through configuration and standard administrative tools, bypassing the need for custom ABAP coding.

A. Organization management transaction PPOME and the corresponding customizing:
MDG can leverage the standard SAP Organizational Management (OM) framework. By linking MDG workflow steps to Positions, Jobs, or Organizational Units defined in PPOME, the system automatically resolves which users belong to those entities at runtime.

C. A specific assignment of a single user or a special user...
in the workflow configuration: In the Rule-Based Workflow (RBW) configuration, you can use User Agent Groups. These allow you to hard-code a specific User ID or, more commonly, use system variables like "Last Processor" or "Requester" to route the change request back to the person who started or previously touched it.

E. A direct assignment to a specific role built in PFCG in Business Rule Framework plus:
This is the most common "No-Code" approach. In the BRF+ decision table DT_USER_AGT_GRP_XXX, you can enter a PFCG Role (e.g., SAP_MDGM_ROLE_APPROVER). The workflow will then automatically distribute the task to all users who have that specific role assigned to their user profile.

Why the other options are incorrect:

B. A workflow step condition that is defined in the Workflow Builder transaction SWDD:
While SWDD is the foundation of SAP Business Workflow, modifying conditions there is considered technical development/workflow design. In the context of MDG 1909, the "Rule-Based Workflow" is designed so that you stay out of SWDD and handle logic in BRF+ or IMG activities.

D. The mail configuration... using transactions SOST and SCOT:
These transactions are used for monitoring and troubleshooting the delivery of emails (e.g., checking if a notification was sent). They are purely administrative for the mail server and have no functional logic to "determine" or assign the processors of a Change Request.

Reference:
SAP Help Portal: Master Data Governance > Configuration of Master Data Governance > Process Modeling > Workflow > Rule-Based Workflow > Define User Agent Groups.

Explanation:

In SAP MDG, validations are not "always on" by default for every step. They must be explicitly triggered through the configuration of the Change Request (CR) Step Properties. Depending on whether you use a standard or rule-based workflow, the configuration path differs.

C. Configure checks and enrichment spot properties for a standard business workflow:
For "Classic" workflows (non-rule-based), you define the behavior of the step in the MDG Customizing under Process Modeling > Workflow > Other Workflow > Define Change Request Step Properties. Here, you specify which Check and Enrichment spots are active for that specific step to ensure data integrity before moving to the next stage.

D. Configure properties of the change request step for a rule-based workflow:
In the Rule-Based Workflow (RBW), step properties are defined in the IMG under Process Modeling > Workflow > Rule-Based Workflow > Configure Properties of Change Request Step. This allows you to set flags such as "Validation" or "Optional" for each specific Step ID, ensuring the system executes the underlying BRF+ validations or UI-based checks when a user acts on that step.

Why the other options are incorrect:

A. Create a new business activity and use it in the change request type configuration:
A Business Activity (like MAT1 for Create Material) defines what object is being handled and which UI is used. It does not control the granular validation behavior of individual workflow steps.

B. Enable edition for the required entity type in the data model:
This is a Data Modeling task. While you must enable an entity for "Edition" to govern it within a Change Request, this setting controls whether the data can be changed, not how or when the validations are triggered during the workflow process.

Reference:
SAP Help Portal: Master Data Governance > Configuration of Master Data Governance > Process Modeling > Workflow > Define Change Request Step Properties.

Explanation:

A. Run the semi-automatic workflow setup using transaction SWU3 ✅
- This is the primary tool for initial workflow setup and troubleshooting. Transaction SWU3 (Automatic Workflow Customizing) performs essential configuration checks and can identify missing or incorrect workflow settings. It should be the first step when investigating workflow issues, as it validates the complete workflow environment including RFC destinations, event linkages, and background job scheduling .

C. Check the default workflow batch user (SAP_WFRT or WF-BATCH) ✅
- The workflow system user is critical for background processing. These dedicated users (SAP_WFRT in newer S/4HANA systems or WF-BATCH in classic systems) execute workflow steps automatically. If this user has incorrect authorizations, is locked, or is missing, workflows will fail to process properly . Checking this user's status and authorizations is a standard troubleshooting step .

Why the Other Options Are Not Correct

B. Run the relevant business configuration set using transaction SCPR20 ❌
- Transaction SCPR20 is used for managing Business Configuration Sets, not for workflow troubleshooting. This transaction is unrelated to workflow engine diagnostics and would not help identify why the workflow engine is not running properly.

D. Switch on the workflow engine business function in SWF5 ❌
- Transaction SWF5 is not a valid transaction for workflow configuration. Business functions are activated using transaction SFW5 , not SWF5. This appears to be a distractor with an incorrect transaction code.

References
SAP Help Portal: Set Up Workflow
SAP Knowledge Base Article 1574002 - WF-BATCH and SAP_WFRT Authorizations
SAP MDG Configuration Guides

Explanation:

Creating a User Interface (UI) for a custom data model in SAP MDG relies on the Floorplan Manager (FPM) framework and the GenIL (Generic Interaction Layer) to bridge the data model with the web-based screens.

B. Assign your application configuration to data model:
Once you have created your UI configurations, you must link them to the specific Data Model and Main Entity in the MDG Customizing. This ensures that when a Change Request is opened for that model, the system knows exactly which FPM application and configuration to launch.

D. Create a deep copy of the application configuration template:
SAP provides standard "Template" configurations (like USMD_ENTITY_VALUE2_PROXY). Instead of building a UI from scratch, you perform a Deep Copy of these templates. This creates the necessary Application Configuration, Component Configurations (Header and Form/List), and the required wiring.

E. Generate implementation classes (BAdI) based on the custom data model:
For the UI to "talk" to the custom data model, you must generate the Data Model-Specific Integration Class. This class (often referred to as the "Access Class") handles the mapping between the UI's GenIL layer and the underlying MDG staging tables.

Why the other options are incorrect:

A. Generate implementation classes (BAdI) using Floorplan Manager:
FPM is a UI framework for layout and events; it does not generate the data-binding implementation classes. The classes are generated based on the MDG Data Model, not the Floorplan Manager itself.

C. Create MDG communicator settings:
The MDG Communicator is primarily used to manage the behavior of the "Action Bar" (buttons like Submit, Approve, etc.) within the workflow. While important for the process, it is not a core step for creating the simple UI structure used to maintain the actual data fields.

Reference:
SAP Help Portal: Master Data Governance > Configuration of Master Data Governance > General Settings > UI Modeling.

Explanation:

When you create or enhance a data model in SAP MDG (Transaction USMD_MODEL), you are defining the metadata structure. This involves specifying how data is stored, its characteristics, and how it relates to other objects.

A. Attributes of the entity:
Once an entity is created, you define its Attributes, which represent the actual data fields (e.g., "Color," "Weight," or "Custom Classification"). These are assigned to the entity and can be defined as "Key" attributes or "Non-Key" attributes.

B. Relationship between entity types:
Entities do not exist in isolation. You must define Relationships to establish the hierarchy. This includes Leading relationships (defining the parent-child structure), Referencing relationships (for lookups), and Qualifying relationships.

D. Storage and use type of the entity:
This is the most critical property. You must choose between the four types:

Type 1: Changeable via Change Request; has its own database tables (e.g., Material, Supplier).
Type 2: Changeable without Change Request (Check table).
Type 3: Not changeable via MDG; used as a reference (e.g., Country codes).
Type 4: Part of another entity (e.g., Plant data belonging to a Material).

Why the other options are incorrect:

C. Configuration of the entity:
This is a vague term. In SAP MDG, "Configuration" usually refers to UI Configuration or Process Configuration (like Change Request steps). These are external to the Data Model definition itself.

E. Change request types of the entity:
Change Request Types are part of Process Modeling, not Data Modeling. While an entity is eventually assigned to a CR Type so it can be governed, this assignment happens in a different area of the IMG (Customizing), not within the entity property definition in USMD_MODEL.

Reference:
SAP Help Portal: Master Data Governance > Configuration of Master Data Governance > General Settings > Data Modeling > Edit Data Model.

Explanation:

When standard role-based assignments are insufficient and you need "complex" logic (e.g., routing based on specific material groups, purchase orgs, or custom thresholds), SAP MDG provides two primary paths within the Rule-Based Workflow (RBW) framework.

A. A service name can be assigned in the BRFplus decision table to control the BAdI call:
This is the most flexible method for highly complex scenarios. In the BRF+ table DT_NON_USER_AGT_GRP_XXX, you can enter a Service Name (a custom string). This string acts as a filter for the BAdI USMD_SSW_GET_ORG_STRUCTURE. When the workflow hits this step, it calls the BAdI, passes the Service Name, and your custom ABAP logic determines the exact agents at runtime.

B. In BRFplus, a decision table with a user agent value column can be filled with an organizational structure entry:
Even without coding, the BRF+ table DT_USER_AGT_GRP_XXX supports a variety of agent types. You can populate the "User Agent Value" with a User ID (US), Organizational Unit (O), Position (S), or Job (C). This allows you to leverage the existing HR/Organizational structure to resolve a group of responsible people dynamically.

Why the other options are incorrect

C. A change request type can be configured accordingly so that individual agent determination is allowed:
While Change Request Types define the high-level process, there is no "individual agent determination" flag within the CR Type configuration that solves complex routing. CR Types point to a workflow pattern; the logic itself resides in the BRF+ or BAdIs.

D. A business activity can be defined for a change request step as an agent determination activity:
This is technically inaccurate. A Business Activity (like MAT1 or BP1) links the Change Request to the Data Model and UI. It does not function as a workflow step or an agent determination mechanism.

Reference:
SAP Help Portal: Master Data Governance > Configuration of Master Data Governance > Process Modeling > Workflow > Rule-Based Workflow > BAdI: Determination of Agents for Rule-Based Workflow.

Explanation:

In a hub-based deployment of SAP MDG, Reference Data (also known as Customizing) includes values like Payment Terms, Industry Keys, Countries, and Tax Categories. These values must match across the landscape for data to flow smoothly.

A. If reference data only exists in the SAP MDG system, then replication to the target system can fail:
SAP MDG uses the Data Replication Framework (DRF) to send master data via IDocs or SOA services. If you create a Vendor in MDG using a "Payment Term" that does not exist in the target ERP system, the target system will reject the incoming message with a "Value does not exist" error. Synchronizing ensures the target system can "understand" the data it receives.

D. If the reference data only exists in the target system, then it is not available during change request processing:
During the creation or change of master data in MDG, the UI provides dropdown menus and search helps based on the data in the MDG Hub's check tables. If a specific "Plant" or "Company Code" exists in the target system but hasn't been synchronized to the MDG Hub, the user will be unable to select it on the Change Request, preventing the data from being governed correctly.

Why the other options are incorrect:

B. If reference data only exists in the SAP MDG system, then it is not available for governance workflows:
This is incorrect. If the data exists in the MDG system, the workflow can see it and process it just fine. The issue isn't the workflow's ability to run; the issue is the downstream system's ability to accept that data (as addressed in Option A).

C. If reference dataonly exists in the target system, then they are automatically excluded from the governance scope:
Reference data is not "excluded" from the scope; it is simply missing. SAP MDG does not automatically "detect and exclude" differences; instead, the missing data causes validation failures or prevents users from completing their entries.

Reference:
SAP Help Portal: Master Data Governance > General Settings > Data Modeling > Preliminary Steps > Synchronizing Customizing.