Skip to main content

BRF+ Rules

BRF+ (Business Rule Framework plus) plays a crucial role in complex, parameter-driven industries like steel manufacturing. These industries require flexible and highly tailored logic, which varies significantly depending on product, plant, or customer. In such scenarios, maintaining logic close to the domain experts—rather than in ABAP or AVC—enables more agile adjustments and better alignment with business needs. BRF+ empowers business teams to model and maintain decision logic directly, reducing dependency on technical consultants.

mdVC comes with an out-of-the-box connector for calling BRF+ rules from within your configuration logic.

BRF+ rule example

warning

This example does not reflect a meaningful business scenario; it’s intended purely for demonstration.

Task​

To trigger a BRF+ function, use the Task Implementation /mxp/vcha_cl_va_task_brf. When creating the task, pass the BRF+ function ID:

new /mxp/vcha_cl_va_task_brf( '7FB9DBBA40781FE086CED3D189915F64' ) "function_id for BRF+ function FU_VCHA_DEMO_MXP_STEEL

This task can be integrated like any other in your configuration flow. See Usage for details.

The task performs the following steps:

  • Maps configuration values into the BRF+ context
  • Executes the BRF+ function
  • Maps the returned results back into configuration
  • Captures messages raised in BRF+ and adds them to the log

BRF+ Function Contract​

You're free to define the BRF+ function structure — no DDIC bindings or other developments are required. Simply create the function and assign rulesets or expressions.

Value Mapping is based entirely on naming conventions and the BRF+ signature, offering high flexibility. You can extend your logic without modifying ABAP, as long as the naming is correct.

info

At present, data objects for BRF+ must be manually created—there is no automated generation.

Signature

Context​

The context includes everything passed into BRF+.

Supported data object types:

  • Element
    Use this format: <<characteristic_name>><<_suffix>>
    Suffix options:

    • (no suffix): maps the actual value if assigned
      → Use element type Text for CHAR, Number for NUM, etc.
    • _MIN: maps the lower bound of an interval
      → Use the same type as the characteristic value
    • _MAX: maps the upper bound of an interval
      → Use the same type as the characteristic value
    • _RDO: maps the read-only flag
      → Use element type Boolean
    • _HDD: maps the hidden flag
      → Use element type Boolean
    • _FIX: maps whether the value was entered by a user (and should not be overwritten)
      → Use element type Boolean

  • Structure
    Optionally used to group fields logically (e.g. IS_INPUT). This can also be skipped if using flat elements.

  • Table
    Used for multi-valued characteristics.
    Tables must contain elements as defined above, and follow the same naming convention.

Result​

The result section includes everything returned from BRF+ to mdVC. All data objects to be updated must be declared as results.

Use the same names as in the context, but with a R_ prefix. For example, to return a value for PRODUCT_FORM, define a result data object named R_PRODUCT_FORM.

It’s highly recommended to initialize the result from the context as the first rule in your ruleset, e.g. R_PRODUCT_FORM = PRODUCT_FORM.

This ensures only explicitly changed values are overwritten, while others remain unchanged.

Messages​

Messages created via log actions in BRF+ are forwarded to the AVC log. Use one of the following supported application objects:

  • /MXP/VCHA with subobject BRF
  • FDT with subobject FDT_MSG_ACTION

Message Action

Application Exit​

When referencing a value like PRODUCT_FORM in BRF+, providing a value help and validation logic is often useful. BRF+ supports this via Application Exits.

mdVC provides two pre-delivered exit classes:

  • /mxp/vcha_cl_fdt_exit_qppd
    Uses QPPD values based on name equality
  • /mxp/vcha_cl_fdt_exit_char
    Uses characteristic values based on name equality

To activate, simply assign the desired class in the application exit field of the BRF+ element.

Application Exit

Limitations​

Currently, characteristic names must not exceed 24 characters. This is due to the strict name-based mapping rules described in the BRF+ Function Contract.