Building and Assigning BRFplus Rules for MDG Validations and Derivations

Explanation

Building a BRFplus rule for MDG starts with correctly scoping the function signature to match what MDG will pass at runtime. In practice, this typically means creating a BRFplus application dedicated to the governance domain (for example, a customer or material rules application), then creating a function whose context structure mirrors the relevant MDG entity attributes exposed at that validation or derivation point. Consultants should consult the MDG data model and the standard rule framework documentation for the entity in question to confirm exactly which fields are available in context, since not every attribute on a business object is necessarily passed into every rule execution point. Once the function signature is defined, the next step is choosing the right expression type for the logic. Decision tables are the most common choice for business-rule-style logic: rows represent conditions (for example, customer group, country, or material type combinations) and columns represent the resulting values or messages. Decision tables are attractive because business or governance analysts can maintain them directly without needing to understand expression syntax, and they scale well when the number of rule combinations is data-driven rather than deeply nested conditional logic. Decision trees suit hierarchical either/or logic where conditions branch sequentially. Formula expressions handle calculations. Table operations and procedure calls extend into more complex scenarios like looking up a custom Z-table or calling a function module, though heavy custom logic embedded in a formula expression should be viewed cautiously since it starts to resemble hidden ABAP without the maintainability benefits BRFplus is meant to provide. For validations, the function result typically needs to conform to the message structure MDG expects, allowing the rule to raise an error, warning, or success indicator tied to a specific field or entity. Testing this properly requires simulating the function in the BRFplus workbench with multiple representative context combinations, including edge cases like blank or unexpected values, before ever assigning the function inside MDG configuration. For derivations, the function's result data object supplies the derived value, and testers should verify behavior both when the source data is present and when it is missing, since MDG derivation timing (for example, on segment creation versus on explicit user action) affects whether stale or blank values might already exist in the field. Assignment inside MDG is the step that actually wires the tested BRFplus function into the change request runtime: this is configured through MDG's validation and derivation configuration, referencing the entity, usage, BRFplus application, and function ID. A frequent point of confusion is that a function can test successfully standalone in BRFplus but appear to do nothing inside MDG, which almost always traces back to either an incorrect assignment (wrong usage or event), a context mapping mismatch between MDG's data model field names and the BRFplus data object structure, or an authorization/versioning issue where an unreleased or inactive version of the BRFplus application is active in the target system. Troubleshooting should start by re-confirming the function executes standalone, then checking the assignment configuration, then checking system trace or debugging tools available in the MDG environment to see whether the call is even reaching BRFplus. In S/4HANA on-premise and private cloud editions, this configuration and workbench access generally follows the same on-premise development model as ECC-based MDG hub deployments, while cloud-based or public cloud scenarios may have more restricted or differently packaged extensibility options for custom rule logic, so teams should verify what level of BRFplus custom development access is actually available in their specific deployment before committing to a design that assumes full on-premise flexibility.

Code example

* Example: Simplified BRFplus function signature pattern used for an MDG validation* (illustrative structure, not literal syntax of the BRFplus workbench UI) Function: ZMDG_VAL_CUST_PAYMENT_TERMSContext (input):  CUSTOMER_GROUP    TYPE STRING  PAYMENT_TERMS     TYPE STRING  SALES_ORG         TYPE STRING Result (output):  MESSAGE_TYPE      TYPE STRING   " E, W, or S  MESSAGE_TEXT      TYPE STRING  FIELD_NAME        TYPE STRING   " field the message is attached to Processing:  1. Decision table: lookup(CUSTOMER_GROUP, PAYMENT_TERMS) -> ALLOWED (X or blank)  2. If ALLOWED = blank:       MESSAGE_TYPE = 'E'       MESSAGE_TEXT = 'Payment terms not permitted for this customer group'       FIELD_NAME   = 'PAYMENT_TERMS'     Else:       MESSAGE_TYPE = 'S' * This function is then assigned in MDG validation configuration to:*   Entity: Customer (Business Partner)*   Usage:  Field-level validation on PAYMENT_TERMS*   Event:  On save / on field change (per configuration)

Real project scenario

During a phased MDG rollout for material master governance, the project team builds a derivation rule that automatically sets the material's basic unit of measure category based on material type and division, using a decision table maintained by the data governance lead. During integration testing, the rule works perfectly in BRFplus simulation but never fires in the MDG UI. The consultant traces the issue to a mismatch: the derivation was assigned to the wrong usage step (triggered only on initial creation, not on a later segment addition), which is corrected by reassigning the function to the appropriate event, then retesting the full create-and-edit change request cycle.

Common mistakes

• Designing a decision table with overlapping or ambiguous row conditions, producing inconsistent results depending on table evaluation order. • Forgetting to test blank, null, or default values in context data, causing runtime dumps or silently skipped derivations in production. • Embedding complex nested logic inside a single formula expression instead of decomposing it into smaller reusable BRFplus objects, making later maintenance difficult. • Assigning a validation function to the wrong event or usage step so it either never triggers or triggers too early before dependent data is available. • Not distinguishing error, warning, and success message types correctly, which can unexpectedly block change request submission when only a warning was intended. • Assuming BRFplus custom development access is identical across on-premise, private cloud, and public cloud MDG deployments without verifying actual extensibility scope for the target system.

Best practices

• Design decision tables with mutually exclusive, clearly ordered conditions and always include a defined default/fallback row. • Keep BRFplus functions single-purpose and compose complex logic from smaller reusable expressions rather than one large formula. • Always test the full context value space, including blanks and boundary values, before assigning a function into MDG. • Maintain a clear mapping document between MDG entity/usage/event assignments and the BRFplus application/function IDs for support handover. • Confirm the target system's BRFplus application version is active and correctly transported before assuming a logic error when a rule doesn't fire. • Validate extensibility and customization scope for BRFplus in the specific S/4HANA or cloud deployment before designing rules that assume unrestricted on-premise-style access.

Interview angle

Interviewers often probe whether a candidate can debug a 'rule that should work but doesn't' scenario, since this is one of the most common real support ticket patterns in MDG BRFplus work. A strong answer walks through the layered troubleshooting approach: confirm standalone BRFplus simulation succeeds, verify the MDG assignment (entity, usage, event), check context field mapping, and confirm the correct application version is active — demonstrating structured diagnostic thinking rather than guesswork.