Advanced Validations: Architecture, Integration and Production Design (Part 4)

At senior and architect level, Validations should be understood as an end-to-end design problem rather than a list of isolated features.

Core design map
Why Validations Exist in MDG and How They Fit the Governance Flow: Understand the business and technical purpose of validations in SAP MDG, where they sit in the change request lifecycle, and how they differ from derivations and other rule types.

Designing, Configuring, and Troubleshooting Validation Rules in MDG: Learn practical techniques for designing BRF+-based validation rules in MDG, assigning them correctly in the data model, testing them, and diagnosing common runtime issues.

Troubleshooting and Performance-Tuning MDG Validation Rules in Production: Learn how to diagnose failing or slow validations in SAP MDG change requests, isolate root causes across rule design, data model, and workflow layers, and apply tuning techniques that keep validation processing responsive at scale.

Architecture and production criteria

• Always confirm rule assignment to entity, usage, and processing step in configuration, not just BRF+ logic correctness
• Always simulate the exact rule with captured runtime data before concluding the rule logic itself is defective.
• Build a layered test suite covering BRF+ simulation, in-context CR testing, and regression testing after related changes
• Cache reference/lookup data at the change request or batch context level rather than re-reading per entity.
• Confirm execution order relative to derivations before assuming a validation will see final values
• Document known rule execution order dependencies so future changes do not silently break existing validations
• Maintain a documented validation catalog mapping each rule to the business policy it enforces
• Maintain a validation issue log capturing entity type, message, step, and root-cause category to support recurring-issue analysis.
• Prefer request-level or step-level validations over entity-level checks when the business rule does not depend on per-entity uniqueness.
• Reserve expensive lookup-based validations for checkpoint steps rather than every field change
• Respect deployment-specific extensibility and debugging constraints; do not assume on-premise techniques are available in cloud editions.
• Scope rules to the correct create/change usage to avoid unnecessary reprocessing
• Test each rule against both compliant and non-compliant sample data before promoting to production
• Use warning severity for advisory guidance and reserve error severity for true policy blockers
• Verify extensibility and tooling access available for the specific deployment (on-premise, private cloud, public cloud) before finalizing design
• Verify secondary indexes exist on any custom tables queried repeatedly by feeder classes in high-volume scenarios.

Failure analysis and operational risk

• Adding expensive lookup-based validations that fire on every field change and degrade UI responsiveness
• Applying on-premise debugging assumptions to cloud-extensibility scenarios where direct ABAP access is not available.
• Assuming a validation is 'wrong' without first simulating it in the rule engine with the actual captured input data.
• Assuming validations can modify or default data; they can only evaluate and message, not set values
• Attaching entity-level checks when a step-level or change-request-level check would achieve the same governance outcome with far fewer executions.
• Building correct BRF+ logic but failing to verify its assignment to the right entity, usage, and processing step
• Creating decision tables with gaps or overlapping rows that produce inconsistent firing behavior
• Failing to scope the rule to the correct entity usage (create vs change), causing it to fire in unintended steps
• Ignoring the validation context (working vs. active version) when a rule seems to see 'old' data during cross-entity comparisons.
• Not logging recurring validation complaints, leading to the same root cause being re-diagnosed repeatedly by different support staff.
• Not testing with representative data combinations before moving rules into the productive rule set
• Overlooking that a derivation or another validation altered field values before the rule under test executed
• Re-reading reference or lookup tables inside a loop for every entity instead of caching once per change request context.
• Testing only in the BRF+ simulation tool without confirming behavior inside an actual change request
• Using error severity for rules that should be advisory, blocking legitimate business processes unnecessarily
• Writing rules that check raw input fields without accounting for derivation execution order

A strong production design connects functional or analytical semantics to integration boundaries, security, performance, transport/change control, observability, recovery and ownership. Trade-offs should be justified with evidence such as volume, latency, data quality, user behavior, operational SLA and downstream dependencies. Avoid treating a technically successful configuration or interface as complete until the business result is reconciled end to end.

A retail company implementing MDG for vendor master data needed to ensure that any new vendor located in a country requiring a specific tax registration format could not be approved without that field populated. The data quality lead defined a validation rule scoped to the vendor create process, evaluated at the point where the requester submits the change request for review. Initially the rule was written to check the raw input field before a related derivation rule populated a default classification, causing valid vendors to be incorrectly flagged as errors. The project team resolved this by confirming the rule execution order in the data model configuration and adjusting the validation to run after derivations, then retested with representative country-specific test data before moving the rule to the production rule set.

During a materials governance rollout, business users reported that a validation intended to block creation of a material with an invalid unit-of-measure combination was not firing for certain plants. Investigation showed the rule was correctly built and tested in isolation in BRF+, but had only been assigned to the 'create' processing step in the data model configuration, while the problematic scenario occurred during a 'change' transaction that added the plant-specific data later. The team corrected the assignment to include both create and change usages, retested with the original failing scenario, and added a regression test case to the project's validation test suite to prevent recurrence.

During a mass vendor cleansing project, a validation checking bank-detail consistency was firing correctly for single change requests but caused a significant slowdown when 15,000 vendors were mass-changed in one batch of change requests. Investigation using BRFplus simulation and ABAP debugging showed the feeder class was querying a custom country-bank-format table once per vendor instead of caching it once per batch run. After introducing a context-level cache and adding an index on the lookup table's key fields, batch processing time dropped substantially, and the change request queue no longer built up during the nightly load window. The team also discovered a secondary issue: a validation was configured at entity level when it only needed to run once per change request, so consolidating it to a request-level check further reduced redundant executions.

• Adding expensive lookup-based validations that fire on every field change and degrade UI responsiveness
• Applying on-premise debugging assumptions to cloud-extensibility scenarios where direct ABAP access is not available.
• Assuming a validation is 'wrong' without first simulating it in the rule engine with the actual captured input data.
• Assuming validations can modify or default data; they can only evaluate and message, not set values
• Attaching entity-level checks when a step-level or change-request-level check would achieve the same governance outcome with far fewer executions.
• Building correct BRF+ logic but failing to verify its assignment to the right entity, usage, and processing step
• Creating decision tables with gaps or overlapping rows that produce inconsistent firing behavior
• Failing to scope the rule to the correct entity usage (create vs change), causing it to fire in unintended steps
• Ignoring the validation context (working vs. active version) when a rule seems to see 'old' data during cross-entity comparisons.
• Not logging recurring validation complaints, leading to the same root cause being re-diagnosed repeatedly by different support staff.
• Not testing with representative data combinations before moving rules into the productive rule set
• Overlooking that a derivation or another validation altered field values before the rule under test executed
• Re-reading reference or lookup tables inside a loop for every entity instead of caching once per change request context.
• Testing only in the BRF+ simulation tool without confirming behavior inside an actual change request
• Using error severity for rules that should be advisory, blocking legitimate business processes unnecessarily
• Writing rules that check raw input fields without accounting for derivation execution order

• Always confirm rule assignment to entity, usage, and processing step in configuration, not just BRF+ logic correctness
• Always simulate the exact rule with captured runtime data before concluding the rule logic itself is defective.
• Build a layered test suite covering BRF+ simulation, in-context CR testing, and regression testing after related changes
• Cache reference/lookup data at the change request or batch context level rather than re-reading per entity.
• Confirm execution order relative to derivations before assuming a validation will see final values
• Document known rule execution order dependencies so future changes do not silently break existing validations
• Maintain a documented validation catalog mapping each rule to the business policy it enforces
• Maintain a validation issue log capturing entity type, message, step, and root-cause category to support recurring-issue analysis.
• Prefer request-level or step-level validations over entity-level checks when the business rule does not depend on per-entity uniqueness.
• Reserve expensive lookup-based validations for checkpoint steps rather than every field change
• Respect deployment-specific extensibility and debugging constraints; do not assume on-premise techniques are available in cloud editions.
• Scope rules to the correct create/change usage to avoid unnecessary reprocessing
• Test each rule against both compliant and non-compliant sample data before promoting to production
• Use warning severity for advisory guidance and reserve error severity for true policy blockers
• Verify extensibility and tooling access available for the specific deployment (on-premise, private cloud, public cloud) before finalizing design
• Verify secondary indexes exist on any custom tables queried repeatedly by feeder classes in high-volume scenarios.

Senior interviews should test whether the candidate can connect the individual lesson areas, diagnose cross-layer failures, explain trade-offs and design a supportable production operating model.

Interviewers often probe whether a candidate understands the functional difference between validations and derivations, and whether they know that severity level controls workflow blocking behavior. A strong answer explains that validations evaluate rather than modify data, that error severity halts CR progression at the step where it fires, and that execution order relative to derivations is a common source of defects that experienced consultants explicitly test for.

Candidates are often asked how they would troubleshoot a validation that appears not to fire. A strong answer walks through checking rule activation, data model assignment to the correct entity/usage/step, actual field values at evaluation time, and BRF+ simulation with captured data, rather than assuming the rule logic itself is wrong first.

Interviewers assess whether a candidate can move beyond 'the rule is wrong' to a structured diagnostic method: confirming validation context, simulating the rule with real data, isolating feeder/BAdI logic from rule logic, and identifying performance anti-patterns such as per-entity database reads. Strong answers also distinguish troubleshooting approaches across on-premise (debugging access) versus cloud (extensibility-constrained) deployments rather than treating all environments identically.