BRFplus Application Exits: Ability to maintain decision tables.

[sanjana_lingras]

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	Description
AUTHORITY_CHECK	This exit allows to enhance or even completely replace the default authority checks of BRFplus.
CHECK	This method is called whenever a BRFplus object is checked for consistency.
ACTIVATION_VETO	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.
GET_CHANGEABILITY	With this application exit the changeability of customizing objects can be altered.
SAVE_NOTIFICATION	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

IV_ID	ID of the object to be checked
IV_ACTIVITY	Activity type of authorization
EV_PASSED	Indication of whether the check was passed successfully
EV_SKIP_CHECK	Indicates whether standard checks shall be skipped
EV_SKIP_REFERENCED	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

IV_ID	ID of the object to be checked
CV_CHANGEABLE	Indicates whether the default changeability shall be overruled
CT_MESSAGE	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	Value	Activity Type	Value
Application	AP	Create	1
Expression Type	ET	Change	2
Expression	EX	Display	3
Data Object	DO	Delete	4
Ruleset	RS	Activate	5
Function	FU
Catalog	CA

• 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.

                  RETURN.

• “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 :smile: