Skip to Content
Author's profile photo Sanjana Lingras

BRFplus : Decision Table Maintenance with wonder working features

Description: This blog describes about an ABAP utility for updating BRFplus decision tables in Production systems without logging into BRFplus UI. As well as describes how the governance on decision table maintenance can be achieved.


  • Basic knowledge on OO ABAP concepts
  • Basic knowledge on BRF+ framework

What is BRF Plus?

No matter how much one tries to minimize customization in a SAP system, some volume of custom business logic is usually unavoidable.  Historically, this meant introducing custom ABAP syntax in various user-exists, enhancements, BADI’s and custom programs. Given the complex and interdependent nature of an SAP system, it becomes imperative to carefully manage such ABAP based customization in order to ensure that business logic is in sync across various functional areas, and is not duplicated.  That’s where SAP Business Rules Framework Plus (BRF Plus) comes into play – a functionality that makes it possible to manage all of the custom business logic at a single place and in a re-usable way.

In general, BRF Plus functionality is available on any SAP NetWeaver based system at the appropriate enhancement pack level.

BRF Plus offers a unified modeling and run time environment for business rules that addresses both technical users (programmers, system administrators) as well as business users who take care of operational business processes (like procurement, bidding, tax form validation, etc.).

Why BRF Plus?

BRF plus Decision Table Maintenance in Production Environment:

BRF plus Decision tables contain rules or values configured and according to those rules the decisions are taken.

Decisions are high change components” – may be because of policy changes/regulatory changes/market’s changes/customer’s changes/etc. And they may lead to regular data maintenance in decision tables.

In current BRF Plus version, to maintain values in decision table, transport request has to be created and imported till production box. With current BRF Plus version, there is no way to maintain decision tables directly in production system. To achieve decision table maintenance functionality in PROD system, the only solution is via DSM tool (i.e. Decision Service Management).

Alternative way would be to achieve this functionality is via Application Exit but has few drawbacks such as no change log history, no backup of existing contents are taken, no version comparison for decision table contents, no proper governance on who can maintain rules, etc.

Here we will see the how can we develop ABAP utility which will help us to achieve decision table maintenance in production systems while overcoming the drawbacks of Application Exit.

This utility will also provide some exclusive features which are not available in standard BRFplus solution today:

  • Delta records upload functionality:

With Extra Selection Criteria Option on Selection Screen, it is possible to filter Decision Table Data for the value provided on screen for specific primary key of the decision table. This will enable fetching only specific rules from BRFplus decision tables and updating them with particular order back to decision table.

Current standard BRFplus solution does not offer delta records upload feature. Whenever excel with records is imported to the decision table it overwrites the contents in the decision table with the excel contents. This BRFplus mass upload utility have capability of uploading only new records to the decision table with the filtered data displayed on ALV Grid Display using Extra Selection Option.

This feature of delta records upload will be additional advantage and will reduce the risk of overwriting all the existing records of the decision table.

The records displayed on screen will be saved back to BRFplus without affecting other records which does not match selection criteria and are not displayed on screen. (Note: Excel Upload functionality is not available for delta upload functionality, this can be done only via Editable ALV grid).

  • Sorting & Sequencing :

This feature will allow to maintain rules in specific sorting order either ascending or descending , also sequencing can be done based on the columns. Priorities of the fields for sorting can be set in configuration table one time and based on it data will be always stored in sorted manner in decision table.

  • Sorting of rules from Specific to Generic criteria:

If we import records in decision table using “Import from Excel” button in BRFplus API, standard BRFplus will not sort the contents of decision table based on specific –> generic rule criteria.

Below is the example: In the example below if decision table is not sorted from specific to generic rule, it will satisfy the first rule itself in the decision table. We have two rules if customer is ABC and Sales org. is ABCD, discount is 5% and another rule is if customer is ABC and for any Sales Org. discount will 10%. In this case if input to decision table is Cust_no=‘ABC’ and SalesOrg = ‘ABCD’, first generic rule will be satisfied and o/p will be 10%.This is happening because rules are not sorted from specific to generic criteria. But same case will be handled properly if decision table is sorted. It will search most specific rule first instead of generic one. This can be handled with this tool by maintaining required Sorting Sequence for fields and keeping Sorting Order as Descending.

  • UNIX file backup of Decision Table Contents:

New feature of UNIX file backup is added in this utility. Whenever user will try to change existing records or add new records in the decision table, backup of existing decision table contents will be taken on UNIX file path on application server as a separate file. This backup can be used in case decision table data gets corrupted in future.

  • Change Log History for Decision Table Content Changes:

ABAP custom table is designed which will keep track of changes to the decision table. This table will capture the details as – 1. BRFplus decision table name, 2. User ID (user who made changes to the decision table), 3. Date (system date on which change was made) and 4. Timestamp (Time stamp at which changes were made) and 5. Unix File Path where Back up of Decision Table Data is saved.

  • Dynamic Design of the Utility:

This utility to upload data can be used for any decision table. Everything will be configured in custom table and after maintaining few configurations utility can be used for any decision table. We need not make any changes to the ABAP code to use this utility for other decision tables. This tool is based on dynamic design and code is written in dynamic fashion.

  • Editable ALV Grid Display:

The Utility Tool is provided with Editable ALV Grid Display, where, Existing Rows can be modified/deleted, New Rows can be inserted, Rows can be duplicated and changed as per requirement.

  • Version comparison feature:

With version compare feature any two back up files of decision table contents can be compared or any backup version can be compared with current version. This version comparison will be based on primary key field values and will denote inserted/changed or deleted rows based upon primary key values.

Key Features of the utility:

Working of the Utility:

Decision table maintenance utility will simplify the process of maintaining rules in BRFplus decision tables. We will see step by step working of the tool:

1.Selection screen:

Information Help: Help is provided on click of ‘i’ Button on Selection Screen describing Purpose and Features of the Tool and what are pre-requisites to use the Tool.

User Manual: The User Guide can be downloaded at specified path on clicking User Manual Button.

Fetch Data: Decision Table Data can be displayed using Fetch Data button with Extra Selection Criteria as Filtering Option.

2. Output screen :

Editable ALV Grid Display with Append, Insert, Delete and Duplicate Row Options.Data Upload with Excel File, User Manual Download and Information Help. Differentiation of Input and Output Columns with different colors.

With Extra Selection Criteria Option on Selection Screen, it is possible to filter Decision Table Data for the value provided on screen for one of the columns.

Only one value can be provided at one time as below:

3.Decision table update : Whole / Delta

This for whole data update, similar way for specific condition value decision table can be updated.

On click of SAVE, once save is successful:

Excel download/ upload functionality:

4.Version Compare functionality:

With Decision Table Version Compare Tool, Decision Table Data changed using Decision Table Maintenance Tool can be compared i.e. tool will be used to compare different versions available for Decision Table data in back up files.

Using Decision Table Version Compare Tool:

  • Any two Backup Files of Decision Table can be compared with each other.
  • Backup File can be compared with Current Version of Decision Table.
  • Backup File Contents can be displayed on screen in ALV Grid Display.

After clicking on Display Versions button, change log history with back up files will be displayed.

When user clicks on Compare version button comparison will be shown as below:

Based key fields comparison will happen and will indicate inserted / deleted or changed rows.

Similarly, display back up file display contents in Grid ALV and backup versions can be compared with the current version.

Logic Implementation:

1.Design a custom table to hold all the necessary configurations for decision tables.

For example decision table name, free entry for variable name , variable values, decision table fields data types , flag to identify whether the field is input or output column , sorting sequence to sort fields priority wise also sorting order either ascending or descending , key flag to indicate whether the field is part of primary key or composite primary key.

2.Using this custom table, ABAP dynamic code can be written to fetch data from any decision table, update rules into decision table or perform version comparison.

3.Read the configuration from custom table and develop dynamic logic as per the requirement.

4.To fetch data from decision table faster way is to implement enhancement inside GET_FORMATTED_DT_DATA method of class CL_FDT_DT_EXCEL.

We can put some restrictions such as this custom code inside enhancement will run only for specific decision tables which are configured in configuration table. We can export Decision table name to memory id via ABAP calling program and later import it from memory ID inside enhancement and check if it exists in configuration table then only execute custom code to read or to take backup of decision table data.

5.Call method as shown below

6.After calling this method decision table current content should be stored on application in the UNIX file as per the custom code we have written inside the enhancement.

7.This UNIX file can be read into the internal table and then can be used for further modifications such as display DT data on ALV, display delta records (filtration based on specific condition), updating, deleting and inserting records into the DT.

8.Now only part remaining is how to save the updated data back to BRFplus. SET_TABLE_DATA method can be used to store records back to the decision table.

9.Define an object of type CL_FDT_DECISION_TABLE.

10.Call method to set data to decision table.

11.Perform Deep activation and save decision table data. After the activation is successfully, user id , decision table name and date time stamp can be stored in custom table to maintain change log history.

Version comparison between decision table versions:

  1. Every time before calling set_table_data, we can call method create_excel_from_dec_tab and it will call enhancement to take a backup of DT data into the UNIX file.
  2. So whenever user change the data, we will have earlier version present on the application server.
  3. Using these versions of UNIX files, version comparison functionality can be implemented.
  4. For the comparison logic Key Fields should be maintained in configuration table in key flag column.
  5. At first all non-matching rows from two version will be found out.
  6. If combination of key field from new version is found in old version but row is modified it will be considered as MODIFY.
  7. If combination of key fields from new version is not found in old version but row is in non-matching list derived earlier then it will be shown as INSERT in new version.
  8. If combination of key fields from old version is not found in new version but row is in non-matching list derived earlier then it will be shown as DELETE in old version.

Benefits of this utility:

  1. Decision table data can be viewed and updated in any environment development, quality or production without logging into BRFplus API.
  2. Effort saving in creating transport for new rule updation and moving it till production.
  3. Few features such UNIX file backup will always help in recovering older versions in case DT data gets corrupted due to some reason.
  4. Version comparison feature will provide overview on what changes have been done to rule.
  5. Control on access to BRFplus decision tables can be implemented via specific authority checks and roles.
  6. Change log history will be present for reference.


  1. We will also need to implement Application Exit to have this tool working in production environment.
  2. While implementing the enhancement, we need to take extra care to have this working only for decision tables which are configured in configuration table and should work for the specific calling ABAP program.


I hope this blog gave helpful insight on how the Decision table mass upload utility can be implemented.


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Nabheet Madan
      Nabheet Madan

      Thanks Sanjana Lingras for the blog. I liked the idea but have few concerns.

      • I am just thinking with this tool we will have a high chance of inconsistency being introduced between your Dev/Quality/Production box. Imagine something is working fine in Dev/Quality but in production it was not as someone maintained the entries locally and vice-versa. It will totally defeat the purpose of testing the configuration entries via D->Q->P as you will be maintaining them directly in production. What exactly was trigger for this tool?
      • Since this tool is already designed can you please check if it can be open sourced?
      • How are you updating the tables?



      Author's profile photo Sanjana Lingras
      Sanjana Lingras
      Blog Post Author

      Hi Nabheet,

      1.Trigger to develop this tool is its ability to maintain rules in decision tables directly in production. Instead of moving those via transport, you can set up governance process to review the rules provided by business and maintain them in PROD. As decision are regularly changing component, everytime maintaining them via transport and moving till PROD could be cumbersome process.

      Also this functionality is not available in current BRF version, it is available in DSM tool which needs to be licensed separately.

      2. We have not thought of the way to open source it.

      3. Methods to update rules in BRFplus decision tables , I have already mentioned in the blog.

      Thanks for providing valuable feedback.


      Author's profile photo Mike Pokraka
      Mike Pokraka

      It’s technically impressive and not a small piece of work, but I’m sorry I don’t see the point. It just looks like reinventing the wheel.

      Storage type Master Data exists for exactly the purpose of productive maintenance. And you get a nice web-based UI that can do a whole lot more, plus the ability to test your rules before 'switching them on'.

      And when you reduce decision tables to two dimensional config tables you’re losing a lot of the power BRFplus.

      The version control in BRFplus is very good, so why build another one with less features?

      Sorry, I don’t mean to be overly critical, and it really does look like a good piece of work. But I really don’t see any advantage. Especially given the amount of effort.

      Author's profile photo Sanjana Lingras
      Sanjana Lingras
      Blog Post Author

      Hi Mike,

      Thanks for the feedback. With current BRFplus version , even if you try to create application with storage type as Master Data , it will allow you to create only ‘Local’ application which cannot be imported to QA or PROD.

      Features like maintainability of rule in PROD system , version comparison are available in DSM tool which needs licensing cost. Several times client is not ready to invest in extra license cost especially when there are many regional standalone systems.

      In such cases , it is also essential to have records maintained in decision tables in PROD system due regularly changing decisions or business rules.

      This is complex solution and can be built on case to case basis depending upon the necessity.



      Author's profile photo Mike Pokraka
      Mike Pokraka

      Sorry but I still don’t get it. Complex solution for what? I’m missing the problem you’re trying to solve.

      For your initial load, you can transport an expression with Master Data storage type manually or use XML. Then you can maintain in production. You have version comparison with BRFplus’s version control.

      Everything you’ve described so far can be done without code.

      I’m not criticising what you’ve built (thumbs up for that), only the why. I can’t find anything that would justify the substantial effort.

      Author's profile photo Sanjana Lingras
      Sanjana Lingras
      Blog Post Author

      Hi Mike,

      As per my understanding below features are not available in BRFplus which comes as add on with ECC 7.0 : (These are available in DSM (decision service management ) tool which has separate license cost but not standard BRFplus version)

      1. Version comparison of contents of decision table : Which rules are newly inserted , deleted or changed rows from two different versions of decision tables.
      2. Delta upload of rules : Filtering of records based on specific value and uploading new delta records at the same without disturbing the order of other existing rules.
      3. Updating decision tables in PROD: It is not possible to maintain new rules directly in production system in BRFplus decision tables and it is required as rules are dynamic and gets changed regularly. (Updating rules in decision tables in PROD environment is possible in DSM but not in BRFplus version which comes with ECC)
      4. Sorting & Sequencing : This feature will allow to maintain rules in specific sorting order either ascending or descending , also sequencing can be done based on the columns. Priorities of the fields for sorting can be set in configuration table one time and based on it data will be always stored in sorted manner in decision table. This feature I have explained very in the blog , whenever we upload rules via excel in BRFplus those do not get sorted automatically. Before uploading the rules we need sort them manually in the excel and then upload and they may cause issue in execution because whichever rule is first in the order will be executed first in BRFplus.
      5. Unix file backup : In case user corrupts the current set of rules in the decision table then there will not be any backup available to recover the lost data in available BRFplus version. This tool will always keep latest back up of decision table data on application server.

      I hope you are clear on why this tool is required.


      Author's profile photo Mike Pokraka
      Mike Pokraka

      Spend some time exploring the existing features of BRFplus. I can also recommend the SAP Press book.(*)  

      I’ve switched your 2 and 3 around, because it makes more sense in my reasoning.

      1. Possible with standard BRFplus versioning

      3. Yes it’s possible using Master Data storage type.

      2. Not really relevant if you’re editing inline as per previous point. Otherwise Excel is a perfectly good way to go, and in my experience often preferred by users. As an aside, I wouldn’t put large amounts of data into BRFplus decision tables. For some scenarios it’s better to create a table and do a DB lookup.

      4. BRFplus can’t sort, but I don’t think it has to. Sorting could break compound lookup criteria. BRFplus already does overlap checks and generates warnings for conditions that can’t be reached. So the user will know there and then if there’s an issue.

      5. Why? That’s what version control is for. Or use XML Export if you have to.

      (*)PS: I don’t mean this in any condescending or arrogant way – you obviously know some of BRFplus’s technicalities in great detail, but I am getting the impression you are missing some fundamental info on some really great features.

      Author's profile photo Sanjana Lingras
      Sanjana Lingras
      Blog Post Author


      First of all decision table maintenance is not possible directly in production system with current BRFplus version. It is also not possible with Master Data storage type.

      When you create BRFplus application with Master Data storage type , you can only create LOCAL application , which means you can never import that application to QA or PROD.

      PFB the screenshot for reference , if we cannot move BRF application to prod then there is no point in creating and maintaining it locally. We need to follow proper transport path to move object from DEV --> QA ---> PROD.

      Decision table maintenance in PROD is currently only available in DSM tool. And if we want to achieve the same in BRFplus then can be done via Application exit and with the help of above tool.

      BRFplus versioning: I have not mentioned about object level versioning i.e. versions to show changes in object definition. I have mentioned about the versions to see differences in the records or rules maintained inside the decision tables which is not possible with current BRF version. In our scenario we have 2000 to 2500 rules maintained in single decision table , in such cases we need to have this feature to understand inserted/deleted and changed rules.

      DBlook up : If we intend to do everything in custom table then no need to go for BRFplus. Again accessing some custom table from BRF via DBlook up will not be good option and also performance intensive. Again we have seen lot of performance improvement after using decision tables for rule maintenance.

      I have just clarified your points again.



      Author's profile photo Mike Pokraka
      Mike Pokraka

      I disagree with all your points.

      Yes we can maintain decision tables without transport. Think about it: what's the point of master data storage type if we can't maintain it locally?

      It is non-transportable by design, that's why it's local. You create it directly in the system or use XML or Excel import/export. I've given you the links in the documentation - see XML above. Also review chapter 8.2 in the book - it may be from 2011, but still relevant.

      Please correct your blog.

      Author's profile photo Allan Chiu
      Allan Chiu


      Hello Sanjana -

      Nice blog.  We have a very similar restriction/requirement.  Good to know this is possible, do you have any sample code of the utility?  Would like to be able to view a working sample.


      Author's profile photo Aziz Md
      Aziz Md

      Dear Sanjana,


      I got stuck with the same issues where I have to Insert/Modify new entries at BRF+ tables in Production system itself without creating Transport Request. I will be great full if you kindly share the complete solution including the codes to me - (email address removed by moderator)

      Appreciating your this solution.

      Thank You,



      Author's profile photo Gokul Radhakrishnan
      Gokul Radhakrishnan

      Pls check OSS note 2674741 - How updating of Decision Tables BRF+ and transport request system works