BRF+ Masterclass: Decision Tables, Rule Services, ABAP Integration & Real‑World Scenarios – Hands‑On Tutorial | Part 44 | FreeLearning365

 

BRF+ (Business Rules Framework Plus) – Decision Tables, Rule Services & Integration: A 25,000+ Word Hands‑On Masterclass

Day 14 of the S/4HANA ABAP Development & Fiori Track

By @FreeLearning365 and Tech Partner @techbook24

Introduction: The Rule Change That Caused a Panic Transport

Friday 4:58 PM. The CFO calls Arjun: “From Monday, the approval limit for purchase orders is raised from $50,000 to $75,000. Please make the change.” Normally, Arjun would modify the hard‑coded constant in the workflow condition, unit test, open a transport, move it through the landscape — a three‑day process. But Monday is the next business day. The business can’t wait. Arjun smiles and says, “No problem, I’ll give you access to change it yourself right now.”

Because Arjun had already refactored the approval threshold logic into BRF+ (Business Rules Framework Plus) — SAP’s decision engine that allows non‑programmers to maintain business rules in a controlled, transport‑enabled environment. The CFO logs into the BRF+ workbench, updates a decision table value, simulates, activates, and the new limit takes effect instantly across all purchase order workflows. No ABAP change, no transport, no delay.

In this tutorial, you’ll learn how to build exactly such a rule. We’ll explore the BRF+ architecture, create a comprehensive decision table for PO approval thresholds, combine it with other rules in a ruleset, and integrate it with ABAP — both from reports and from the workflow we built in Part 43. You’ll also see alternatives like decision trees and formulas, and understand when BRF+ shines vs. when to keep logic in code. By the end, you’ll be able to externalize business rules with confidence and transform the way your organization reacts to change. Let’s empower the business.

1. BRF+ Fundamentals – The Rule Engine for ABAP

1.1 What Is BRF+ and Why Does It Matter?

BRF+ (Business Rule Framework Plus) is a framework within the ABAP stack that enables the modeling, simulation, and execution of business rules. It provides a web‑based workbench (FDT_WORKBENCH) where you define rules without coding. Rules are stored in the database and can be changed and activated immediately (with proper authorizations). The execution is blazing fast because the framework generates optimized ABAP code.

1.2 The Object Hierarchy

• Application: a container for all rule objects. Typically, you create one application per business domain (e.g., Z_PURCHASING).
• Function: the executable unit. A function has a defined context (input/output parameters) and contains one or more rulesets. It is what you call from ABAP.
• Ruleset: a collection of rules (decision tables, decision trees, formulas, etc.) and a logical resolution strategy (execute all, stop on first true, etc.).
• Expressions: atomic pieces of logic — decision tables, case expressions, formulas, decision trees, etc.
• Data Objects: reusable structures, tables, and elements for the function context.

Arjun will create an application Z_PURCHASING, a function PO_APPROVAL_RULES, and within it a decision table for the approval limit and a decision tree for discount calculation.

2. The TechBook24 Scenario – Externalizing Three Rules

The business wants to control the following without ABAP intervention:

• PO Approval Threshold: based on PO net value and purchasing group, determine the required approval level (None, Manager, Director).
• Early Payment Discount: based on vendor and payment terms, calculate a discount percentage.
• Vendor Block Reason: based on vendor’s country and previous delivery performance, decide whether to block the vendor for automatic PO creation.

Arjun will build the approval threshold rule first, fully integrate it with the workflow, and then quickly create the discount rule using a decision tree.

3. Building the PO Approval Decision Table – Step‑by‑Step in FDT_WORKBENCH

3.1 Creating the Application and Function

Transaction: FDT_WORKBENCH (or URL /sap/bc/webdynpro/sap/fdt_wd_workbench). Arjun clicks “Create” → “Application”. He enters:

• Application ID: Z_PURCHASING
• Short Text: “TechBook24 Purchasing Rules”

He saves. Then inside the application, he creates a “Function”:

• Function ID: PO_APPROVAL_RULES
• Short Text: “Determine approval level for PO”

Screenshot Description: FDT_WORKBENCH with the application tree showing the new function.

3.2 Defining the Context (Input/Output)

In the function, he opens the “Context” tab. He creates Data Objects:

• Input Elements:
  • IV_NETWR (type NETWR, amount).
  • IV_EKGRP (type EKGRP, purchasing group).
• Output Elements:
  • EV_APPROVAL_LEVEL (type CHAR2, values: ‘00’ none, ‘01’ manager, ‘02’ director).
  • EV_APPROVAL_TEXT (type STRING).

He can also use Structures. He creates a structure S_INPUT with both fields, but simple is fine for now.

3.3 Creating the Decision Table

Inside the function, he right‑clicks “Rulesets” → “Create Ruleset” RS_DETERMINE_APPROVAL. Inside the ruleset, right‑click → “Create Decision Table”. Name DT_APPROVAL_LIMIT.

The decision table editor opens. He defines:

• Columns (Conditions):
  • Condition 1: IV_EKGRP (equals).
  • Condition 2: IV_NETWR (between, or less/greater). He adds two condition columns for lower bound and upper bound: IV_NETWR >= and IV_NETWR <.
• Columns (Results):
  • EV_APPROVAL_LEVEL
  • EV_APPROVAL_TEXT

Then he populates the table rows with real data:

EKGRP	NETWR >=	NETWR <	Level	Text
*	0.00	50000.00	00	Auto Approved
*	50000.00	100000.00	01	Manager Approval Required
*	100000.00	999999999.99	02	Director Approval Required
SPEC	0.00	20000.00	00	Special Auto
SPEC	20000.00	999999999.99	02	Special Director

He sets the “First Match” strategy (stops at first row that matches). He uses the asterisk * as a wildcard for all purchasing groups, then overrides for specific groups like SPEC.

Screenshot Description: Decision table editor with the rows above and the columns mapped.

3.4 Simulating the Decision Table

Without activation, he clicks “Simulate”. A pop‑up asks for input values. He enters NETWR = 75,000, EKGRP = ‘001’. The simulation returns Level ‘01’, text “Manager Approval Required”. He tries NETWR = 120,000 → Level ‘02’. For EKGRP = ‘SPEC’ with 30,000 → Level ‘02’. The rule works perfectly. He activates the function.

4. Calling BRF+ from ABAP – The Integration Code

4.1 Using the Generated Class

BRF+ generates a static class for each function, named CL_FDT_GENERATED_..._. Arjun retrieves the class name from the function properties (General tab → “Generated Class Name”). For his function, it’s CL_FDT_GENERATED_Z_PURCHASING_PO_APPROVAL_RULES.

He writes an ABAP report to test:

DATA: lo_function TYPE REF TO if_fdt_function,
      lo_context  TYPE REF TO if_fdt_context,
      lt_input    TYPE fdt_t_data_object,
      lt_output   TYPE fdt_t_data_object,
      lv_level    TYPE char2,
      lv_text     TYPE string.

" Get function instance
lo_function = cl_fdt_generated_Z_PURCHASING_PO_APPROVAL_RULES=>get_function( ).

" Create context and set input values
lo_context = lo_function->get_new_context( ).
lo_context->set_element( iv_name = 'IV_NETWR'  ia_value = '75000.00' ).
lo_context->set_element( iv_name = 'IV_EKGRP'  ia_value = '001' ).

" Process the function
lo_function->process( EXPORTING io_context = lo_context
                      IMPORTING eo_context = lo_context ).

" Get output values
lo_context->get_element( EXPORTING iv_name = 'EV_APPROVAL_LEVEL'
                         IMPORTING ea_value = lv_level ).
lo_context->get_element( EXPORTING iv_name = 'EV_APPROVAL_TEXT'
                         IMPORTING ea_value = lv_text ).

WRITE: / 'Level:', lv_level, 'Text:', lv_text.

He runs the report; output matches the simulation. This code can be placed anywhere — in the workflow, in the BAdI, in the OData service.

4.2 Integrating with the Workflow from Part 43

In the workflow template ZWF_PO_APPROVAL, instead of the hard‑coded condition &PO_VALUE& <= '50000.00', Arjun modifies the background step that reads PO data. After reading PO value, he adds another background step that calls a method ZCL_WF_PO_HELPER=>DETERMINE_APPROVAL_LEVEL. That method internally calls the BRF+ function, determines the level, and sets the container element APPROVAL_LEVEL. Then the condition branches on APPROVAL_LEVEL instead of direct value comparisons. This fully externalizes the logic.

He also changes the agent rule to accept the level as input and route to the appropriate user list (already configurable). Now, the business can modify the decision table to change approval routing without touching the workflow.

4.3 Performance Considerations

Arjun verifies the BRF+ call overhead using SAT. The call takes ~2 ms, negligible. For high‑volume scenarios (thousands of POs), he ensures the function is activated in “Production Mode” (the generated class uses compiled code). He also caches the function instance as a static attribute if needed, but for most use cases, the generated class already handles caching.

5. Building a Decision Tree for Early Payment Discount

5.1 Requirement

TechBook24 negotiates discounts with vendors. The discount percentage depends on:

• Vendor type (preferred, regular)
• Payment terms (immediate, 30 days, 60 days)
• PO value range

This is a classic decision tree scenario. Arjun creates a new function DISCOUNT_RULES in the same application. He defines input: IV_VENDOR_TYPE, IV_PAYMENT_TERMS, IV_NETWR. Output: EV_DISCOUNT_PCT.

5.2 Creating the Decision Tree

In the ruleset, he creates a “Decision Tree” expression. The root node checks IV_VENDOR_TYPE:

• If ‘PREF’: go to branch node check IV_NETWR ranges:
  • If >= 0 and < 50000: then check payment terms → if immediate: discount 2%, if 30 days: 1%, if 60 days: 0%.
  • If >= 50000: discount 3% immediate, 2% 30d, 1% 60d.
• If ‘REGU’: similar but lower percentages.

He builds the tree visually, enters the conditions and result values. He simulates with different combinations.

Screenshot Description: Decision tree editor with branches and result values.

5.3 Comparing Decision Table vs Tree

Decision Table	Decision Tree
Best for flat, independent condition combinations	Best for hierarchical, dependent conditions
Easier for business users to scan	More intuitive for sequential logic
First‑match or all‑match semantics	Always first‑match based on tree traversal

For the approval threshold, the table is ideal; for the discount, the tree is clearer.

6. Advanced BRF+ – Expressions, Formulas, and Ruleset Composition

6.1 Formulas for Complex Calculations

Arjun needs to calculate vendor score based on on‑time delivery rate and quality acceptance rate. He uses a formula expression: IV_ON_TIME * 0.7 + IV_QUALITY * 0.3. He demonstrates the formula editor.

6.2 Ruleset Logic – Combining Rules

In the approval ruleset, he could add additional rules (e.g., a case expression for special vendor block) and set the ruleset resolution to “Execute All” (all rules fire, outputs are merged) or “Stop on First True”. He shows both.

7. BRF+ Monitoring, Transport, and Authorization

7.1 FDT_LOG for Execution Traces

Transaction FDT_LOG shows execution traces of BRF+ functions. Arjun activates trace for his function, runs the ABAP program, then views the log. It shows which decision table rows were evaluated and which matched. This is invaluable for debugging complex rules.

7.2 Transporting BRF+ Objects

BRF+ objects are transportable. He creates a transport request from the workbench (Application → More → Transport). He exports the application and its sub‑objects. He recommends always transporting the entire application to avoid inconsistencies.

7.3 Authorization and Self‑Service

To give the CFO access to update the decision table without full developer rights, Arjun assigns roles via FDT_ADMIN or custom roles with activity FDT_CHANGE and restricts to the application. The CFO logs into the workbench, changes values, simulates, activates — no ABAP transport. He demonstrates this end‑to‑end.

8. The Complete Hands‑On Lab – Building the Approval Rule Engine

1. Create BRF+ application Z_PURCHASING in FDT_WORKBENCH.
2. Create function PO_APPROVAL_RULES with context elements IV_NETWR, IV_EKGRP, EV_APPROVAL_LEVEL, EV_APPROVAL_TEXT.
3. Create ruleset and decision table DT_APPROVAL_LIMIT with the rows as described.
4. Activate and simulate.
5. Write ABAP program ZR_BRF_TEST to call the generated class and display result.
6. Modify the workflow ZWF_PO_APPROVAL (from Part 43) to call a helper method that internally invokes the BRF+ function and sets container elements.
7. Test workflow with a new PO; verify approval routing based on decision table values.
8. Change the decision table threshold from 50000 to 75000, activate, and re‑test — observe changed routing without any ABAP or workflow change.
9. Create a decision tree for discount, integrate into a pricing exit (optional).
10. Monitor with FDT_LOG.

Each step includes screenshots descriptions, code snippets, and expected results.

9. Best Practices, Pitfalls, and Alternatives

• Versioning: BRF+ functions have automatic versioning. Always simulate with the latest version before activating. Previous versions are kept and can be rolled back.
• Performance: Avoid complex nested queries inside BRF+. Use decision tables with direct condition matching; the generated code is optimized. For huge lookup tables, consider caching in ABAP or using a HANA DB procedure.
• Transport: Transport in a consistent state. If a function calls another, ensure both are in the same transport or sequence.
• When NOT to use BRF+: If the rule is extremely simple and never changes, ABAP code may be simpler. Also, for rules requiring heavy SQL access or loops, ABAP code inside a BAdI may be more readable. BRF+ is best for parameterized decision logic that changes frequently.
• Alternatives: SAP HANA rules engine (for native HANA artifacts), CDS table functions for some calculations, or simply configuration tables with customizing (SPRO). BRF+ sits between pure config and code.

10. Conclusion – The Agile ABAP Paradigm

Arjun has delivered not just a set of rules, but a new agility for TechBook24. The CFO can now adjust approval limits instantly, the procurement team can tweak discount logic, and IT is no longer the bottleneck. The combination of BRF+ and workflow automation creates a self‑service business process environment that competitors envy. You now have the skills to externalize logic and empower business users, making you a strategic partner in digital transformation.

Tomorrow, in Part 45 — the final part of the Developer Track — we’ll explore ABAP in the Cloud: ABAP RESTful Application Programming (RAP) full model, managed vs. unmanaged, draft handling, and side‑by‑side extensions. We’ll take everything you’ve learned and deploy it to SAP BTP, ABAP Environment. The journey to cloud‑native ABAP culminates. Don’t miss the grand finale.

Keep building, keep empowering.

End of Part 44 – BRF+ Deep Dive. Brought to you by @FreeLearning365 and tech partner @techbook24.