Designing BRFplus Rulesets for MDG Validation and Derivation Logic

Explanation

BRFplus rulesets in MDG are not standalone artifacts; they are wired into the governance data model through the Business Object Model (BOM) or through the customizing that links validation and derivation steps to BRFplus functions. Once you move past creating a single decision table, the real work is designing rulesets that stay maintainable as the number of fields, entity types, and country-specific conditions grows. Structurally, a BRFplus application groups related objects: catalogs (used to store reusable value lists such as valid combinations), rulesets or functions (the entry point invoked by MDG), and the expressions inside each function. A typical MDG derivation function takes context data (for example, a business partner's country, category, and industry) as input and returns a derived value (such as a default payment terms code) as output. A validation function typically returns a message or a boolean plus a message ID/number combination that MDG surfaces on the UI as an error, warning, or information message tied to the field or entity. Expression type choice matters for maintainability and performance. Decision tables are the most common choice for MDG rules because business users or data stewards can often maintain them without touching BRFplus expressions in code-editor style tools, and columns map naturally to entity attributes. However, decision tables become hard to manage once you have many independent conditions; in that situation, splitting logic into multiple smaller functions chained by a top-level ruleset is usually cleaner than one enormous table with dozens of columns. Rules (if/then expressions) are better suited to a small number of clearly ordered conditions, while decision trees suit hierarchical branching logic (for example, first branch on country, then on customer group). At runtime, when a data steward creates or changes a record in an MDG change request, the framework calls the relevant BRFplus function at defined processing events—commonly on save, on activation, or on specific field changes, depending on how the validation/derivation was assigned in configuration. The function executes against the current in-memory representation of the entity (not necessarily the persisted database record), which is why testing rules only against already-saved data can hide defects that only appear mid-change-request. A key intermediate-level skill is separating context data preparation from decision logic. Where multiple derivations need the same intermediate value (for example, a normalized industry code), calculate it once in a shared sub-function or shared expression referenced by multiple decision functions rather than duplicating the calculation everywhere. This reduces the risk of inconsistent results when the underlying master data changes. Versioning and transport also matter operationally. BRFplus objects are transportable, and each object typically carries an active and an inactive/draft version; only the active version is executed at runtime. A common intermediate mistake is modifying a decision table in a test client, forgetting to activate it, and then wondering why the change 'did not take effect' even though it was saved. Transport sequencing between the BRFplus application and any customizing that references its function ID must also be respected, since a missing or not-yet-transported function ID reference will cause runtime errors when MDG tries to call it. Finally, traceability is essential for production support: BRFplus provides simulation/trace capability that shows which expression fired and what values were passed and returned. Learning to read this trace, rather than guessing from the UI error message alone, is usually the fastest way to diagnose why a validation triggered unexpectedly or why a derivation produced a stale value.

Code example

* Illustrative only: conceptual pseudocode showing how MDG-side* processing might invoke a BRFplus function during a validation* step. Actual API/class names depend on your SAP release and* should be confirmed against your system's implementation, not* copied literally from this example. DATA: lv_country     TYPE land1,      lv_msg_number  TYPE symsgno,      lv_is_valid    TYPE abap_bool. * 1. Prepare context data expected by the BRFplus function*    (e.g., country, customer group, industry code)lv_country = ls_bp_data-country. * 2. Call the BRFplus function associated with this validation*    step (conceptual call - refer to your system's actual*    integration pattern, e.g. via the BO validation framework)* CALL FUNCTION 'Z_CALL_BRFPLUS_VALIDATION'*   EXPORTING*     iv_function_id = 'FUNCTION_ID_FOR_COUNTRY_CHECK'*     iv_country     = lv_country*   IMPORTING*     ev_is_valid    = lv_is_valid*     ev_msg_number  = lv_msg_number. * 3. Map the BRFplus result to an MDG UI messageIF lv_is_valid = abap_false.*   Raise message using lv_msg_number against the relevant fieldENDIF.

Real project scenario

A consumer goods company's MDG customer governance process needed country-specific tax classification defaults. The initial design used one decision table with over 30 columns covering country, customer group, industry, and sales organization combinations. As more countries were onboarded, business users struggled to maintain the table without breaking existing rows, and rule execution time noticeably increased on records with many attributes. The team refactored the ruleset into a top-level decision tree that first branched by country (a small, stable set of values), then delegated to per-region decision tables containing only the columns relevant to that region. This reduced table width, made ownership clearer (regional data stewards each maintained their own table), and improved traceability when investigating incorrect defaults.

Common mistakes

• Building one very wide decision table instead of decomposing logic into smaller, chained functions, making maintenance and debugging difficult. • Forgetting to activate a changed BRFplus object, then concluding the runtime behavior is broken when it simply has not changed. • Duplicating the same intermediate calculation (e.g., normalized codes) across multiple functions instead of centralizing it, leading to inconsistent results after a partial update. • Testing rules only against fully saved records, missing defects that occur against in-progress change request data. • Not verifying transport sequencing between the BRFplus application and the MDG customizing that references its function ID, causing runtime lookup failures after transport. • Assuming decision table row order does not matter when overlapping conditions exist, when in fact table evaluation logic can produce different results depending on row precedence settings.

Best practices

• Decompose complex logic into smaller, purpose-specific functions chained together rather than one oversized decision table. • Centralize shared intermediate calculations in one place and reference them from multiple rules to avoid inconsistency. • Always activate and retest BRFplus objects after changes before assuming behavior has updated in the target client. • Use simulation/trace tools to confirm which expression fired and with what input/output values before assuming a defect location. • Document ownership of decision tables (which team/data steward maintains which table) to prevent uncoordinated edits in shared rulesets. • Confirm transport sequencing between BRFplus applications and any MDG customizing referencing their function IDs before go-live in a downstream system.

Interview angle

Interviewers assess whether you can reason about ruleset design, not just tool mechanics: expect questions on when to choose a decision table versus a rule or decision tree, how you would decompose an overly complex ruleset, how BRFplus versioning/activation affects runtime behavior, and how you would troubleshoot a derivation returning an unexpected value using trace/simulation. Being able to describe a real refactor (splitting a large table, centralizing shared logic) signals hands-on production experience rather than tutorial-level exposure.