Skip to Content
Author's profile photo Sanjana Lingras

BRFplus Application Exits: Ability to maintain decision tables.

Have you ever heard about BRFplus capability of maintaining decision table entries in Production or Quality environment? Recently we came across a requirement where user wanted to maintain a decision table in Production environment.

As we know “Decisions are high change components” – may be because of policy changes/regulatory changes/market’s changes/customer’s changes/etc. And this may lead to regular data maintenance in decision tables.Usually decision table entries are maintained via transports (create transport request in dev. sys. and import till prod. sys.)  but there is way to maintain decision tables directly in production environment.  This will reduce all the change management efforts involved in getting decision table entries transport imported to production system and again if we have already implemented all the BRFplus rules correctly then it will reduce the build efforts as well.

How can we make decision table maintainable in production system?  :: The Business Rules Framework (BRFplus) integrates many options to adapt business rules to custom needs. One way to overcome such inevitable restrictions with BRFplus is with “Application Exits.

This blog will help in understanding the concept of BRFplus application exits and example of making decision table maintenance possible in production environment.

Pre-requisite: Basic knowledge of BRFplus and ABAP Object Oriented Programming (OOP).

What we will cover in this blog?             

  • Introduction: What are BRFplus Application Exits?
  • How to make decision table maintainable in prod or non dev. systems?
    • Create a BRFplus Application.
    • Create an application exit class.
    • Implement the application exit method
    • Add the exit class to your application
  • Test the functionality of decision table maintenance.

Let us start!!!

1.       Introduction: What are BRFplus Application Exits?

Usually a BRFplus application is associated to an ABAP package, in BRFplus all objects like functions, rule sets, expressions, data objects, etc. are created within an application. The application defines some standard settings for all of its contained objects like storage type and package assignment.

With the concepts of application exits, BRFplus allows to extend its common in the scope of an application and its contained objects. E.g. it is possible to implement a customer specific authorization check mechanism.

An Application Exit is technically based on an ABAP class that implements the specific interface “IF_FDT_APPLICATION_SETTINGS”. You can assign one such class for each application and can be achieved via the workbench UI.

The interface IF_FDT_APPLICATION_SETTINGS defines a set of static methods – the real application exits. For every method or exit a corresponding Boolean attribute needs to be set as ‘TRUE’. This attribute indicates whether the interface method is actually implemented and the exit should be called.

An exit-method is called by the BRFplus framework only, if the corresponding Boolean attribute is set to TRUE.

We will see the detailed steps on how to set this attribute in implementation of the application exit method.


Below is the list of few important application exits:

Application Exit Method



This exit allows to enhance or even completely replace the default authority checks of BRFplus.


This method is called whenever a BRFplus object is checked for consistency.


Before a BRFplus object can be activated it needs to be in consistent state, with the activation veto exit it is possible to prohibit the activation due other external dependencies.


With this application exit the changeability of customizing objects can be altered.


This exit simply gives notification, if an object is saved.

2.       How to make decision table maintainable in prod or non dev. systems?

We need to implement two application exits “AUTHORITY_CHECK” and “GET_CHANGEABILITY” to make the decision tables maintainable in non-development environment.

Application exit AUTHORITY_CHECK:   If the AUTHORITY_CHECK application exit is implemented, it is called before the standard authorization check is performed. The result of the custom check is returned as a Boolean parameter ev_passed. Additionally, the standard authorization check can be either skipped completely or only for referenced objects.

Signature of AUTHORITY_CHECK application exit: few important parameters


ID of the object to be checked


Activity type of authorization


Indication of whether the check was passed successfully


Indicates whether standard checks shall be skipped


Whether standard checks for referenced objects shall be skipped.

Application exit GET_CHANGEABILITY:  The changeability exit allows overruling the client settings for the changeability of customizing objects. For customizing objects, the default settings can be overridden with this exit method at object level. If BRFplus objects are not changeable, changing parameter “CV_CHANGEABLE” is initially ‘ABAP_FALSE’ and “CT_MESSAGE” contains error messages.

To make the object changeable, CV_CHANGEABLE must be set to ABAP_TRUE and error messages must be deleted from CT_MESSAGE.

Signature of GET_CHANGEABILITY application exit: few important parameters


ID of the object to be checked


Indicates whether the default changeability shall be overruled


Error messages in connection with changeability.

  • Create a BRFplus Application

  • Go to t-code “BRFPLUS”, it will take you to BRFplus workbench.
  • Then create your application ‘ZAPPEXIT_TEST’.



  • Then click on “Create and Navigate to object” then SAVE & ACTIVATE the application.
  • Then create a decision table. Go to contained objects tab.




  • Insert the columns to the decision table.


  • Then activate the decision table. Now decision table is “ZDT_MAINT1” is ready and active.

  • Create an application exit class
  • Go to SE24, create a class “ZCL_APP_EXIT”.Then go interfaces tab and enter the interface name as “IF_FDT_APPLICATION_SETTINGS”.


  • Then go to methods tab, you will be able to see list of all the available methods for that specific interface. Now save and activate the class.


  • Now create class constructor and set authority_check and get_changeability methods as “ABAP_TRUE”.
  • Click on the tab “CLASS_CONSTRUCTOR” and set the required attributes for authority check and get changeability.


  • Go to the code and set the attributes below is the sample code. Save and activate the class.


  • Till here class creation and attribute setting is complete.
  • Implement the application exit method
    • Now let’s see how to implement the methods AUTHORITY_CHECK and GET_CHANGEABILITY.
    • The authority check can be made configurable where user IDs can be maintained in custom table to whom authorization to maintain decision table to be granted. So if user who is accessing decision table is present in custom table then only required access will be granted to the user.
    • System ID
    • Perform the check on activity type and based on the activity pass the abap_true value to ev_passed flag.

Object Type


Activity Type






Expression Type








Data Object












  • Pseudo Code:

IF   iv_activity EQ ‘2 ‘

OR iv_activity EQ ‘3’

OR iv_activity EQ ‘5’.

MOVE: abap_true TO ev_passed,

              abap_true TO ev_skip_check.


  • “EV_SKIP_CHECK” flag if set to TRUE, will skip standard authorization checks and will consider custom authorization check.
  • GET_CHANGEABILITY method: With this application exit the changeability of customizing objects can be altered. If object is not modifiable in particular system then customization settings can be altered and object can be made changeable.
  • Then code needs to be written in IF_FDT_APPLICATION_SETTINGS~GET_CHANGEABILITY to override the standard checks for the required objects and users, similar to IF_FDT_APPLICATION_SETTINGS~AUTHORITY_CHECK
  • Pass MOVE abap_true TO “cv_changeable”.
  • Next step to assign new application exit class to the application and test the functionality.

  • Add the exit class to your application
    • When the application exit class is activated, add it to the application and activate the application.


3.       Test the functionality of decision table maintenance: After assigning application exit class to the application, activate the application and test the decision table maintenance functionality.

So we created “ZDT_MAINT1” decision table and assigned application exit class to the application. Now try to maintain ZDT_MAINT1 in non-development environment like QA system where usually decision table authorizations will not be present.

  • Open the decision table “ZDT_MAINT1” and go to edit mode.
  • Maintain entries or try import / export from excel to decision table.


This way decision table maintenance can be achieved using application exits in non-dev or production environment. I hope this blog gave helpful insight on BRFPlus application Exits as well 🙂

Assigned Tags

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

      Hi Sanjana,

      Ok yes that's a nice write-up on how we used to do it...

      ....before SAP Decision Service Management gave us hot deployment and proper governance for BRFPlus, including multi-deployment to different systems, approval deployment workflows and test case management.   And of course HANA support to boot.

      I agree BRFPlus application exits are a lot of fun to work with... but of course if there is a standard supported solution then it's always worth considering TCO (Total Cost of Ownership) benefits that will bring. 

      Congrats on a nice write-up showing the power of BRFPlus application exits.



      Author's profile photo Carsten Ziegler
      Carsten Ziegler

      This is a very good blog. However, we do generally not recommend using the changeability exit. All other exists are perfectly OK to use. I have seen several customers that did not manage to tame the beast. Issues:

      • accidentially overwritten decision table content
      • users locking the decision table while generation runs results in interpretation mode which is very slow
      • no chance to check changes thoroughly (activation means immediate change)

      Therefore I fully agree with Jocelyn’s comment. That is one of the reasons why we have built DSM..

      Author's profile photo Daren Li
      Daren Li

      This very good blog shows without DSM:
      (1) to define a BRFPLus application with a decision table in development system
      (2) to maintain decision table contents in productive system using application exits

      But the example application is created locally, so it can not be transported into a productive system for maintaining the decision table contents in productive system. Furthermore
      codes needs to be written in IF_FDT_APPLICATION_SETTINGS~GET_CHANGEABILITY as follwoning:
      - cv_changeable = abap_true  (=> It is allowed to maintain decision table contents in productive system)
      - cv_change_recording = abap_false (=>no transport request is required for  maintaining decision table contents in productive system)


      Author's profile photo khushbu Agarwal
      khushbu Agarwal

      Hi Daren Li,

      "– cv_change_recording = abap_false (=>no transport request is required for  maintaining decision table contents in productive system) "
      This really helped


      Author's profile photo Gaurang Gujar
      Gaurang Gujar

      Hi Sanjana,

      In the above example you have shown the storage type as "system" and made it as local object.

      For local object the BRF expression won't ask a transport request and get_changeability is only for Customizing storage type . You can check the documentation for the same.

      I would like to know if there is something that can help us change the content of Decision Table or make Decision Table Editable for storage type System.



      Author's profile photo Pawan Kalyan K
      Pawan Kalyan K

      is it right way to do change contents of Decision tables in Production ? may be after implementing exit class?
      is implementing the exist class the only option to change contents directly in production?
      can we change rules/functions/objects directly in production?
      if not ,is there any other alternative? may be DSM?
      Please shed some light and clear my mind from all these doubts

      Author's profile photo Gokul Radhakrishnan
      Gokul Radhakrishnan

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


      Gokul Radhakrishnan

      Author's profile photo Adi Mogilevsky
      Adi Mogilevsky

      How do we transport Decision Table from Development Client 100 to 110?

      Author's profile photo Gal Kogan
      Gal Kogan

      Hi Sanjana,


      Our customer wants to create the following scenario :

      1- When sending output to Print Purchase Order from Storage location = X

      ( The purchase order contains the item data with this specific storage location = X )


      print this Output to printer number 100001


      2- When sending output to Print Purchase Order from Storage location = Y

      ( The purchase order contains the item data with this specific storage location = Y )


      print this Output to printer number 200002



      What would be the right way to create a BRF rule for that scenario ?


      Please Advise


      Best Regards

      Gal Kogan