Are you the publisher? Claim or contact us about this channel

Embed this content in your HTML


Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog

older | 1 | .... | 3 | 4 | (Page 5) | 6 | newer

    0 0

    BRF+ does not support enforcing unique key constraints on its tables, even if the table is bound to a DDIC table type with a unique key. There is also no out of the box functionality to remove duplicates from a BRF+ table. I needed a simple and performance efficient solution for this requirement.


    • The duplicate removal can be implemented by a simple ABAP function using SORT and DELETE ADJACENT DUPLICATES
    • Using generic types for the method parameters makes for efficient procedure calls from BRF+

    Business requirement

    Our rule set consists of a list of rules that depending on input data modify parts (called entities) of a large data model (SAP Material). Due to performance constraints in the underlying system, only changed parts shall be written back and written only once. There is a n:m relationship between rules and data model parts. If a rule changes one or more entities, it adds the entity names to a list of entities to be written.


    ABAP has built-in commands for removing duplicate entries from an internal table via the commands SORT and DELETE ADJACENT DUPLICATES. We implement a static helper method that does the sort & delete.

    Alas, calling from BRF+ into ABAP comes at some price, as the framework uses a different data representation internally (inside BRF+) then externally (in the ABAP world), e.g. all text data is converted into a STRING type, and quantities and amounts are represented by structures (for details, see IF_FDT_TYPES in your system). So for every procedure call, the system needs to do a conversion internal → external for converting the method parameters when invoking the method and external → internal when retrieving the result.

    Luckily we can circumvent the conversion process by working with the internal representation directly. This is done by using generic types for our method parameter.

    Table type


    The BRF+ table consists only of a text line. The corresponding ABAP type is

    STANDARD TABLE OF if_fdt_types=>element_text WITH DEFAULT KEY

    which is an unstructured table of STRING elements.

    Method signature

    CLASS-METHODS make_unique_text_table       CHANGING         !ct_text TYPE TABLE.

    The CHANGING parameter ct_text can be passed any table, triggering BRF+ to pass in its internal table format. Note that this also eliminates checks on the caller side, so you need to be careful in BRF+ later on to pass in only table types the method can actually work with.

    Method implementation

    METHOD make_unique_text_table.     "Empty list means nothing to do     IF lines( ct_text ) < 2.       RETURN.     ENDIF.     "Sort & make unique     SORT ct_text BY table_line.     DELETE ADJACENT DUPLICATES FROM ct_text.   ENDMETHOD.

    The implementation merely contains the SORT& DELETE operations.

    Procedure call


    Using an expression of type Procedure Call makes the function available to BRF+.

    Generated call


    The invocation code generated by BRF+ does not contain any copying of the table or parameter conversion. If you modify the parameter type to a concrete DDIC type, you will see that the method invocation is wrapped in conversion code that copies the internal BRF+ table to the table type you specified.

    To Infinity! And beyond.

    The above mentioned technique for efficient procedure calls could be extended to structured tables as well if you re-create the BRF+ tables internally used structure in your ABAP code. You can have a look a the generated BRF+ code to understand how BRF+ generates its internal types. You would then just have to cast the generic type to the concrete one and do your ABAP processing on the data.

    Note however that you should only using ABAP coding as a last resort and for simplistic self-contained functionality, and stay in BRF+ as long as possible, for countless reasons (performance being the least of them). I have been using BRF+ for some years now, and this is the first occurrence of missing functionality that I encountered, and it was a minor one.

    0 0
  • 02/19/15--08:36: BRFplus Wish List
  • Hi Everybody,

    Not long ago I've asked Carsten Ziegler if he would like to open an Idea Place for community ideas/requests (Original Discussion).

    Unfortunately, he explained that it won't be practical because the BRFplus team is in full capacity so they won't be able to respond to requests.


    However, as time passed and I had the chance to work more intensively with BRFplus, I created my own (not final) wish list, which consist of useful features and annoying issues.

    I thought that I might share it with the community and allow you to express your opinion and add some of your own wishes.

    I'll try to follow your comments and add all ideas in order to create one complete wish list.


    My Wish List


    1. Reusable Constant ranges

    A reusable value range, which isn't restricted to one specific BRFplus element (Data object), but generally to the data type. This value range is convenient when used in Decision Table cells.

    For example: You may define a value range of countries GERMANY, AUSTRIA, FRANCE and use it both for source country and destination country.

    More info can be found Here.


    2. Expression Refactor Tool

    Refactor tool for used expression, i.e. to edit all the BRFplus objects which are using/referring expression A to refer to expression B instead (with the same result type, of course).

    For example, replacing formula expression 'Max Limit' (which is being used in many other expressions/rules) with new decision table expression.


    3. Structure Data Object - Find Component

    Option for Quick search of component (name) while Structure object is displayed.

    Currently, there isn't any find component and you have to scroll down and search the component manually, even if the structure is consists of hundreds of components (elements).


    4. Structure Components - Add Structure Prefix

    When you create two structure data objects with same data type, all their elements are created with the same texts (and name).

    As a result, when you use one of these elements and other BRFplus expression/rules, it is hard to tell which structure they are referring to.

    My solution was to enter for each and every used element and rename it by adding some prefix.

    It would be to have an option to add prefix for all the structure elements in the structure level.

    5. Loop expression - Local Variables + Initialization

    a. Option to define local variables in loop expressions.

    Sometimes you have to make some complex calculations during loop expression. These might require some internal variables which aren't relevant to the external context nor expression result.

    b. Initialization block before loop for internal initialization of variables/result before loop is processed.

    Currently it requires preliminary handling in external rule.


    6. Select Expression - Select Constant

    Additional function in all "Select Expression" context-relevant menus for quick selection of Constant expressions, restricted by the element/date type.

    I like to use Constants expression for better readability, maintainability and tractability (where-used). However, using them might be a little pain in the *** since you have to search them manually each and every time via "Select expression". Quick search of relevant-only constants would make the life much easier.


    7. Decision Table Simulation - Partial/Nearest Match Mode

    New simulation mode which allow you to find the matching percentage of decision table (How many columns has matched their condition) in order to find the nearest/best nominate for complete match. In this mode all table columns would be processed regardless if column condition was met or not.

    This might be really useful during QA phase for analysis of decision tables with many columns and tens/hundreds of rows. In case that no match was found due to some error it is really hard (almost impossible) to find out what is the reason behind it since you cannot tell which rows have nearest match.


    8. Decision table - Editable mode

    Option for setting the whole table in editable mode (only for direct values?).

    Currently, edit is possible only in cell or row level, but sometimes you are required to make some quick changes for multiple rows. The best option for now is using the Export/Import from Excel, but it also spent some time.

    9. Decision table - Drag&Drop in Cell Level

    Allowing quick drag and drop of cell value of one row to cell of the same cell (of the same column).


    Your Wish List


    What do you think?

    Would you like to share any of your own ideas?

    0 0



    This blog describes about the creation of a BRF+ application dynamically using CL_FDT* classes collection.




    1. Basic knowledge on OO ABAP concepts

    2. Basic knowledge on BRF+ framework




    Creation of BRF+ Application through a Simple report.


    Interfaces Used:



    2. if_fdt_application


    Here is the code snippet.


    Step-1: Paste the below in your report. Each step in the code is explained in detail through comments.


    DATA: lo_factory          TYPE REF TO if_fdt_factory,

           lo_application      TYPE REF TO if_fdt_application,

           lt_message          TYPE if_fdt_types=>t_message,

           lv_message          TYPE string,

           lv_boolean          TYPE abap_bool,

           lv_demo_appl_id     TYPE if_fdt_types=>id,

           lv_string           TYPE string.



                pv_sys TYPE abap_bool RADIOBUTTON GROUP r00,

                pv_mstr TYPE abap_bool RADIOBUTTON GROUP r00.

    * get a reference to the instance of the factory

    lo_factory = cl_fdt_factory=>if_fdt_factory~get_instance( ).

    * =============================================================

    * definition of the new application:

    * get an initial application object from the factory

    lo_application = lo_factory->get_application( ).

    lo_application->if_fdt_transaction~enqueue( ).

    * set values for the application, especially the name is important

    * You need to have a unique name for each application, here we use the

    * FDT Service class method to get the unique name.

    lo_application->set_application_component( 'BC' ).    "#EC NOTEXT

    lo_application->set_software_component('SAP_BASIS')"#EC NOTEXT

    lo_application->set_development_package( '$TMP' )"#EC NOTEXT

    *If you want the system to generate a unique name for you application

    *Uncomment the below three lines

    *data lv_name type if_fdt_types=>name.

    *lv_name = cl_fdt_services=>get_unique_name( ).

    *lo_application->if_fdt_admin_data~set_name( lv_name ).

    *Provide a user defined name to your application

    lo_application->if_fdt_admin_data~set_name( 'Sample_app' ). "#EC NOTEXT   ------------------------------"Sample_app" is the application name.

    * In FDT terms there are 3 different type of Applications, Local application,

    * system pplication and MasterData Application. The following lines shows how you

    * can create local Application, masterdata Application and system Application.

    IF pv_lcl EQ abap_true.

       lo_application->create_local_application( ).

    ELSEIF pv_sys EQ abap_true.

       lo_application->create_system_application( ).

    ELSEIF pv_mstr eq abap_true.

       lo_application->CREATE_MASTERDATA_APPLICATION( ).


    *To activate the application and you can see the error messages in lt_message if any errors occurred during activation


                IMPORTING et_message           = lt_message

                          ev_activation_failed = lv_boolean ).

    IF lv_boolean EQ abap_true.

    *     for some reason the activation failed -> individual handling needed

       lo_application->if_fdt_transaction~dequeue( ).


       lo_application->if_fdt_transaction~save( ).

       lo_application->if_fdt_transaction~dequeue( ).

    *     usually it makes sense to store the id for later access to the application

       lv_demo_appl_id = lo_application->mv_id.


    WRITE: 'The ID of the application created is: ', lv_demo_appl_id. "#EC NOTEXT

    Step-2: Click on execute button.


    Step-3: You can see the below selection screen. There are three types of applications in BRF+.

    1. Customizing/Local Application

    2. Master data Application

    3. System Application


    Selection screen.png

    Step-4: Select the type of Application you want to create and Click on execute button.


    Application ID.png

    Step-5: Copy the generated Application ID.


    Step-6: Goto BRF+ workbench.


    BRF+ tcode.png


    Step-7: You can see the below workbench logon page in your default browser. Provide the User credentials and Click on "Logon" button as shown below.


    BRF+ workbench logon pad.png

    Step-8: You can see the application created in the workbench with the properties provided in the report.


    BRF+ Application.png


    You are done with creation of a BRF+ application dynamically.


    I will continue posting blogs for dynamic creation of Data Objects, Expressions, Rules and Rulesets very soon.



    Sowjanya M


    0 0

    This is Sid; The topic of my Blogging activities in SDN will be initially for the Business Rules and BRFplus from a technical point of view and will follow it up by DSM and the areas in SAP. You may also find Blog and publications of Carsten Ziegler very helpful.


    Some of the organisations, if not most of them which I have worked with view the business rules the same way they would view any other kind of requirement in their blueprint. This way we will most likely end with a lot of rules, which has led to rebuilding them all back in ABAP in some cases. A more efficient way would be to determine the decision making components in the requirements and then take it further which would be ideally the regular or rapid change in the business. If the Business want to make changes to behavior regularly then the  decision making component and business rules will be a good basis for automating it. You may find Blog and publications of James Taylor on this very helpful.


    Saying that, If the Business want to make changes to behavior regularly and the Business Users want to make changes to the rules rather than a Technical User, Then restrictions on the BRFplus workbench actions play a major role. Restricting the business users from what they can do in the workbench would definitely make us all sleep a lot better for sure. It can be as simple as not allowing the business users to edit certain rules which again depends on the requirement we have. There are a lot of ways which we can achieve this, as one would say no two developers program the same way.


    I would say my approach would be handling through the application exit class in the BRFplus and assisting it by maintaining authorization data in custom roles. Below I have a basic scenario where the users are restricted by maintaining the data in authorization data of the role.


    First step would be creating the authorization fields, which we would be using in the authorization objects. We need authorization objects to maintain the data in the roles which we want the users to give access to.


    Once we have all the necessary fields the we need for the authorization abject, we can move onto creating the authorization object.


    Next we move on to creating the roles. Based on the business model and restrictions we intend to apply to the users we have to model our roles and use them appropriately.


    We can add necessary transaction to the roles.



    Once the roles have been created, we can move on to authorization maintaining the BRFplus expressions in the authorization data.




    We have to add the authorization object manually in the authorization maintenance and generate the profile.




    Here we can maintain all the universal unique identifications and the respective processing type access you would like to give the users. Once we have maintained the authorization data then we can restrict the users from the custom class maintained in the application exit class of the BRFplus application.




    Once the authorization data has been maintained, we move onto adding the users to the roles.




    Now we move onto creating the exit class and adding the application settings interface to the exit class.




    Once the application settings interface has been implemented, we can restrict users from the interface method authority_check.






    By passing the importing parameters ID and the activity of the method authority_check to the authorization object set the exporting parameter ev_passes respectively to restrict the user. All that which is left is to add the exit class to the BRFplus application.




    We can even restrict the user to certain actions, enhancing the expressions to suit our business requirements, creating expressions/rules dynamically from a report or any such, all of which I will be addressing in my future blogs. As I said earlier, it all depends on the requirement and what we will be comfortable giving access to the business users.


    Hope this was knowledgeable and will come in handy in your future endeavors and that you will stay with me for the next blogs.

    0 0

    Suppose you have a decision table defined in BRFplus, which contains a column which is bound to DDIC element PRODH_D (Product hierarchy).

    In the standard system, the product hierarchy consists of up to 3 levels. The first and second levels have 5 digits and the third level has 8.

    If you now want to define a range of allowed product hierarchies, you have the option to select starts with text or matches pattern in the direct value input box of the PRODH_D column..

    For the DDIC element PRODH_D, its better to choose starts with text for example for a 10 digit product hierarchy (i.e. level 2), because the system now can display the customized text from table T179T for the hierarchydirectly in the decision tables column.


    0 0
  • 03/19/15--15:48: BRFplus: Numbers with style
  • Did you ever feel the need to format numbers in BRFplus? Well I did.




    BRF+ does not offer a function for formatted number output, but this can be very easily fitted via trivial ABAP coding.


    Business requirement


    I recently had to implement a business check rule for characteristic values from Material classification. Numeric values are stored as floating point value (ABAP type f) in classification, even if they are defined as integer values (no decimal places). My existing check table on the other hand used NUMC as datatype, which gets turned into a BRF+ Text field (basically a String). When comparing values, BRF+ converts the float value to Text, but sadly in scientific format (e.g. 1.23E+02, instead of 123).




    OK, forget my obscure business requirement. The solution is shorter & easier to understand than the requirement.




    I hardly dare calling this assembly of definitions and built-ins (namely string templates) call "code". Arguably, you have to start SE80 to copy the following into a class of your choice.


    Note the usage of BRF+ internal types in the method parameters: This avoids type conversion overhead when going from BRF+ into ABAP method, thus providing excellent performance. This is similar to the approach for removing duplicate values from a BRF+ table.


    class Y0MX_MDG_BO_BRF_RULE_UTIL definition  public final create public .
    public section.  class-methods FORMAT_NUMBER    importing      !IV_NUMBER type IF_FDT_TYPES=>ELEMENT_NUMBER      !IV_FORMAT_WIDTH type I default 0      !IV_FORMAT_NUMBER type I default CL_ABAP_FORMAT=>N_RAW      !IV_FORMAT_STYLE type OUTPUTSTYLE default CL_ABAP_FORMAT=>O_SIMPLE      !IV_FORMAT_ALIGN type I default CL_ABAP_FORMAT=>A_LEFT    exporting      !EV_FORMATTED_NUMBER type IF_FDT_TYPES=>ELEMENT_TEXT .
    * <SIGNATURE>---------------------------------------------------------------------------------------+
    * | Static Public Method Y0MX_MDG_BO_BRF_RULE_UTIL=>FORMAT_NUMBER
    * +-------------------------------------------------------------------------------------------------+
    * | [--->] IV_NUMBER                      TYPE        IF_FDT_TYPES=>ELEMENT_NUMBER
    * | [--->] IV_FORMAT_WIDTH                TYPE        I (default =0)
    * | [--->] IV_FORMAT_NUMBER               TYPE        I (default =CL_ABAP_FORMAT=>N_RAW)
    * | [--->] IV_FORMAT_STYLE                TYPE        OUTPUTSTYLE (default =CL_ABAP_FORMAT=>O_SIMPLE)
    * | [--->] IV_FORMAT_ALIGN                TYPE        I (default =CL_ABAP_FORMAT=>A_LEFT)
    * | [<---] EV_FORMATTED_NUMBER            TYPE        IF_FDT_TYPES=>ELEMENT_TEXT
    * +--------------------------------------------------------------------------------------</SIGNATURE>  METHOD format_number.    ev_formatted_number = |{ iv_number      WIDTH = iv_format_width      STYLE = (iv_format_style)      NUMBER = (iv_format_number)      ALIGN = (iv_format_align)    }|.  ENDMETHOD.



    Use a BRF+ Procedure Call expression to invoke your string formatting. Just pass in the number and some options of your liking. Notice that for the typed input parameters like output style (IV_FORMAT_STYLE), the system automagically presents you / your business users with search helps and speaking texts:



    BRF+ is hands down the only choice for implementing business rules in an ABAP system. It is feature rich, understandable for the business user, yet powerful, reliant and high performing. And you never "get stuck" in your implementation, because you can always extend its functionality by simple ABAP coding. Your requirements are the limit.

    0 0

    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

    0 0


    Generating web service for a BRF+ Function.


    We can generate web service for a BRF+ function in local $tmp package or Development Package with workbench and customization request.


    The generation tool for web services and RFC-enabled function modules helps an application developer as well as a third-party user to process the rules defined in BRFplus. The tool helps to create web services and function modules in a highly automated fashion with minimal interaction.

    Generating web service with Local $tmp Package:

    Choose your function and click on Generate web service. Here we are generating web service for CATEGORY function in Z_AGE_CALCULATION application. Click on Generate web service.

    Popup will display and enter the required details as shown in the below screen shot. Click on Generate button.

    ZAGE_CALCUL web service successfully generated.

    Go to SE80

    Open local objects ($TMP)

    You can find the generated web services under Enterprise Services folder.

    Choose your web service & Process. So web-service has been created and active. To test the service click on execute button.



    The following screen will be appeared. Enter the AGE.


    Change to HTML code & enter age value i.e 25


    Click on execute

    Corresponding result will be displayed


    Check the service is activated at the SICF level or not. Enter the service and execute.

    Make sure that the service is active service


    Go to SOAMANAGER transaction. Browser will open with the following screen.


    Provide search pattern(web service name)& click on go.


    Choose the service & click on apply selection



    Click on configuration tab and create Endpoint.

    Specify the setting as specified in the following screen and click on save.


    Go to overview


    Click on Open WSDL document for selected binding or service


    Click on Open Web Service navigator for selected binding

    Click on Display selected Binding's or Service's WSDL URL


    The following URL will be generated

    Now web service has been generated successfully. So you can access this service from any plat form.


    Testing web service using SOAP UI:

    Open SOAP UI tool and specify the WSDL URL in the initial WSDL field and choose ok. If you want different project name you can enter.


    Click on request1  provide credentials(log on details)


    Double click on request1. Enter AGE in the request and click on run. Then you will get a response as show in the above.


    You can access this service anywhere.

    Thanks for reading.....

    0 0

    Here’s a new edition of my digest blog series providing an overview of the content I found when dealing with SAP Decision Service Management (DSM) and Business Rule Framework plus (BRFplus).

    Boosting Payroll Data Sources with BRF+

    Mary Doyle did a great job describing how BRFplus can be used in Payroll. Payroll is one of the topics I am often asked about … and my knowledge was just about non-existent zero up to now. Thanks for closing the gap.


    Remove Duplicate Values from a BRF+ table

    A rules engine never satisfies all of the needs of the possible use cases. Therefore, DSM/BRFplus has capabilities to plug in ABAP code easily. In his blog Jürgen Lukasczyk gives a nice example of how to do so.

    BRFplus Application Exits: Ability to Maintain Decision Tables

    This is a blog about how to use an application exit to maintain decision table data in production. Sanjana Lingras nicely explains the exit code. Make sure that you also read the comments as we no longer recommend the approach, instead we recommend the better approach based on DSM.


    BRFplus Wish List

    Israeli BRFplus Black Belt Shai Sinai came up with this interesting concept: A blog with his wish list for new features. Let’s see what other community members think about these wishes and what they come up with.


    BRFPlus: Restrict Users Through Application Exit Class and Roles

    Authorizations fields, roles, profiles, and objects are all Greek to you? Then be invited to read Adepu Siddartha’s blog. He also explains how to implement an authorization exit in BRFplus.

    Generate Web Service for a BRF Plus Application

    In the blog, Srinivas Diddi uses many screenshots and explanations to document how you can create a web service for a BRFplus function.


    BRF Plus: A Real Time Example

    This is a two-part blog series for beginners by Faisal PC:



    Thinking Beyond the Possibilities of SAP Event Management with SAP BRF+

    How do Event Management and DSM/BRFplus get along? Is it like Tom and Jerry or the opposite, Mickey and Daisy.  Gopi Chandrakesan thinks it is the latter and his blog explains why.


    BRFplus - The API Way

    Once more DSM/BRFplus mastermind Christian Lechner was on stage with a talk about BRFplus. This time his focus was the API and his stage was SAP Inside Track 2015 Frankfurt. He has uploaded his slides to slideshare.


    Business Rule Framework (BRF+) - Create Rules Using The Business Rule Framework

    This nice and very explicit tutorial shows you how to use the BRFplus rule in Governance, Risk and Compliance (GRC). Unfortunately, the author is unknown. There is no reason to write anonymously. 


    SAP GRC 10.0 Training BRF Plus Agent Rule

    A short video by Sam Kumar that shows BRFplus in GRC.


    BRF+ Agent Rule Based on Role Functional Area Field Using TABLE OPERATION and LOOP

    GRC is not my turf at all. Therefore, I am always happy to see practitioners write about it in combination with DSM/BRFplus. In his blog Madhu Babu shows us how to determine the role owner using a BRFplus application.


    CRM Rapid Applications - An Advanced Tutorial

    With this blog duo Christian Drumm introduces a nice application pattern using BRFplus. His excellent explanations and great level of detail make it one of my favorites. 


    SAP Variantenkonfiguration mit BRFplus / Netweaver Decision Service Management

    Patrick Müller lives in the same town as I do. He provides services in the area of Variant Configuration. BRFplus/DSM is one of his areas of expertise, as you can read on his new homepage (German only).


    Use a DSM / BRFPlus Decision Table to Create a Value List

    Jocelyn Dart shows how to provide a dynamic value list based on a decision table. The value list can then be used in other rules objects such as decision tables. As usual, top-notch quality by Jocelyn.


    Product Actions - A Utilities-Specific BRFplus Function with Multiple Usages

    SAP for Utilities is a solution that uses DSM/BRFplus a lot. In contrast to some other solutions in which I struggle to find the right content, the use of DSM/BRFplus in SAP Utilities is well documented.  Bettina Klinke added another blog which also links more material.


    Validação Online com TDF

    Karen Rodrigues introduces to the Tax Declaration Framework for handling Latin American tax madness with DSM/BRFplus. But that’s not all. Eduardo Chagas has created a blog series to explain the solution in great detail:



    This is high quality gaucho work do Brasil. What many people do not know: Sou um gurizinho também. Looking forward to seeing family in Sapiranga,RS later this year. 



    0 0


    Whenever starting a new project it is a best practice to define development guidelines. These guidelines shall govern the development process in accordance to best practices, architectural constraints etc. with the goal to deliver a solution of good quality. In theory the availability of guidelines should be sufficient achieve this goal. However in practice this is not the case as the guidelines are often neglected and you need to check the compliance of the guidelines. This can be done manually (e. g. via code reviews) but as this is extremely cumbersome you will usually go for tools that at least "support" the developer in delivering code that complies to the guidelines (not to say enforce him to do so).


    Within ABAP development there are several tools available out of the box like Code Inspector and ABAP Test Cockpit or further (free) third-party tools (like ConQat) that deliver some check functionality and can be enhanced with customer/project specific checks.


    Within business rule projects you have similar requirements with respect to guidelines and their automatic enforcement. So let us take a look at the situation within BRFplus. There is bad and good news when it comes to this topic:

    the bad part is that there are no SAP standard checks as compared to the ones delivered in SCI/ATC for ABAP development. This is comprehensible in the context of the BRFplus as a generic framework. The BRFplus offers a check functionality for its objects but this is more or less comparable to the syntax check in ABAP and assures the consistency of the object from a technical point of view. There are some further check functionalities in BRFplus like the check for lean trace readiness but again this covers only technical constraints. As mentioned before there is also good news: BRFplus is extremely flexible and can be enhanced at many spots in a modification free manner, so BRFplus does not hinder you in implementing the checks yourself.


    The following sections will explain how you can use the concept of the application exits in BRFplus and the BRFplus API to enforce your guidelines based on a sample scenario.


    Sample Scenario

    Let us assume that we have the following guidelines that shall be enforced in our rules project:

    • For the sake of readability the text field of the BRFplus objects has to be filled
    • For the sake of readability the short text field of the BRFplus objects must not be filled with any value (so that the text is displayed)
    • In case that the object under investigation is a decision table, a documentation has to be entered in the corresponding section


    In our sample scenario we also assume that SAP Decision Service Management is available and we have introduced a custom attribute "Email of Responsible". The data entry into this field is optional but in case data is entered it shall have the format of an email address. This condition represents the last constraint of our scenario.


    In order to enforce these guidelines we want to raise an error message whenever a BRFplus object is checked. If the BRFplus object does not fulfill the above mentioned guidelines its activation must not be possible.



    The following sections will show you how to implement the above mentioned requirements. Nevertheless I have to state a disclaimer that the code for sure is not perfect e. g. at some places a proper error handling is missing. Nevertheless the code shows the basic idea of the implementation. But now let's jump into the implementation


    As mentioned before we want to make use of the application exit mechanism in BRFplus. The usage of application exits in general is described in the document BRFplus Application Exits of Thomas Albrecht so we will not discuss the mechanism in detail here. In principle an application exit is a custom class that implements the interface IF_FDT_APPLICATION_SETTINGS and allows the enhancement of the BRFplus application at specific spots e. g. when a BRFplus object is changed. At these spots the corresponding method of the interface is triggered and enables the execution of custom code. As a prerequisite the application exit class has to be assigned to the corresponding BRFplus application.


    Taking a closer look at the methods of the interface we will see that there is one method called CHECK that is triggered when a BRFplus object is checked. So this method is definitely fitting for our requirements. There is also a method called ACTIVATION_VETO that is called when an activation of an object is triggered in order to prevent the activation of the object if necessary. This method seems is also a candidate for solving our requirements. The question is: do we really need to implement both methods? The answer to this question is no - as a check is implicitly triggered when the activation of an object takes place we can restrict our implementation to the CHECK method. The implementation of the class for the application exit looks like this:


    The class implements the interface IF_FDT_APPLICATION_SETTINGS and in addition we need to implement a class constructor. The implementation of the class constructor contains the setting of the class attribute GV_CHECK to ABAP_TRUE. This is necessary in order to tell the invocation mechanism of the application exit which methods shall be triggered. As we only need the CHECK method the implementation of the class constructor is done.

    Next we implement the check itself to ensure our guidelines. This is done in the method IF_FDT_APPLICATION_SETTINGS~CHECK:


    We do not directly put the code for the checks into the method itself but we delegate to another class (ZCL_BRFPLUS_VALIDATOR) that encapsulates the relevant checks (in order to reuse them in other scenarios as we will see later).

    The next step is then to implement the checks in the class ZCL_BRFPLUS_VALIDATOR. The called method CHECK_CONSTRAINTS has the following definition:


    Taking a look at the signature of the method CHECK_CONSTRAINTS which is identical to the one of the CHECK method of the application exit interface we discover that we do not get the complete information about the object to be checked but only its ID and its type. We therefore have to use the BRFplus API to get the relevant information. As a consequence the method logic is split into the following steps:

    1. get the reference of the BRFplus object via the ID
    2. trigger the private check methods (one method per check)

    Hence, the implementation of the method is given by:


    The red box contains the call of the BRFplus factory class that gives us the reference to the BRFplus object i. e. the reference to the interface IF_FDT_ADMIN_DATA that is implemented by every BRFplus object. This interface contains methods to fetch the information of BRFplus objects that is displayed in the general section of the BRFplus workbench. The green box contains the calls of the private methods that represent the single checks.

    In the next sections we will step through each private methods to get an impression what is necessary to implement the checks.

    (1) Check that texts exist

    This method shall check that the text field is filled for the BRFplus object that is subject to the check. This method is defined by:


    As you see we hand the reference to the BRFplus object which is of type IF_FDT_ADMIN_DATA into our method. The table CT_MESSAGES is used to hand back error messages if necessary.

    The implementation of the method is given by the following code snippet:


    You see that all the necessary information is at hand. We have to call the GET_TEXTS method (line 138 - 141) to fetch the texts of the BRFplus object. We get two parameters back. The parameter EV_TEXT contains the text in the logon language. The parameter ETS_TEXT contains a table containing all the available texts of the object i. e. all available translations. If we are on a translation system we can use this parameter to check if the translation has been done into all required target languages. We can then do your basic check.

    For the sake of the example we assure that the text has to be available in the logon language (line 143 - 154). If this is not the case we raise an error message. We consequently fill the fields of the BRFplus error table. Two fields are of specific importance: the field ID has to be filled with the ID of the BRFplus object under investigation as this will be translated by the BRFplus into the object name and type when displaying the error message. The TEXT has to contain the message text which is then displayed in the BRFplus workbench. Be aware that the relevant parameters like message ID, message class etc. are stored as public constants of the check class.

    The same check procedure is applied to the table of texts which must not be empty (lines 156 - 166).

    These few lines of code are sufficient to assure this first requirement of our guidelines. As you can see the effort is very low whereas the gain is definitely high as the first step for a readable rule representation is done.

    (2) Check that no short texts are entered

    This check shall assure that no short texts are filled in the BRFplus objects in order to enforce that the texts are displayed. From a design point of view this check is  the same as the check for the texts. So is the definition of the method shown below:


    The implementation of the method is given by the following code snippet:


    As in the case for the texts we use the method GET_TEXTS to retrieve the short texts i. e. the table ETS_SHORT_TEXT with all available short texts. The check itself and the filling of the error table is the same as in the check for texts presented before. Here we omitted the check for the short text in the logon language.

    Be aware that when using DDIC binding the short texts are automatically derived from the information available in DDIC. You can remove that information afterwards in BRFplus (and keep stuff really readable) but if you want to accept that situation for data objects with DDIC binding you can soften the check as shown in the next screenshot:


    Here we now first check if the object is a data object (line 172). Afterwards we cast the object to the data object specific interface IF_FDT_DATA_OBJECT. We then check if there is a binding and in case omit the check.

    (3) Check that custom attribute contains a valid email address

    This check method shall enforce the entry of a valid email address in the corresponding custom attribute. The data entry into the field is optional. The definition of the method is the same as for the two previous checks and given by:


    The implementation of the method is shown in the following code snippet:


    The custom attribute values can be retrieved via the method GET_CUSTOM_ATTRIBUTE_VALUES of the BRFplus admin interface (lines 192-194). This method returns a table of all available custom attributes. We fetch the right attribute from the table by identifying it via its UUID that we stored in the constant MC_ATTRIBUTE_ID (line 196). We first check that the attribute is not initial (as the filling of the attribute is optional) and then we use the class CL_ABAP_REGEX to do a basic check if the attribute value matches an email address in accordance to a regular expression (lines 203 - 206). If this is not the case an error message is attached to the BRFplus error table (lines 208-216).

    As in the methods before the effort to implement such a check is quite low (well ... the visible coding effort; the finding of the right regex might be a different story ).

    (4) Check that decision tables have a documentation

    Last but not least we want to check that decision tables have documentation. The method to do so has the following definition:


    This time we transfer beside the reference to the object also the object type to the method.


    The implementation of the method is given by:


    As we want to do the check only for objects of type "decision table" we have to do a filtering on that expression type. Naively one might expect that the parameter IV_OBJECT_TYPE already states if we have a decision table or not but this is not the case. As the decision table is an expression we first use the parameter IV_OBJECT_TYPE to make sure that the check is only executed for expressions (line 222). As we do the check only for an expression of the type "decision table" we have to cast the imported object reference afterwards to the interface IF_FDT_EXPRESSION. This way we can determine if we have a decision table or not using the instance attribute MV_EXPRESSION_TYPE_ID (line 226). We compare this attribute to the corresponding constant for a decision table that is available via the interface IF_FDT_CONSTANTS. After this filtering we use the method GET_DOCUMENTATION of the administration interface to get the documentation of the object. The semantic of the method signature is the same as in the case for the texts. We get the documentation in the system language via the parameter EV_DOCUMENTATION as well as the documentation in all available languages via the parameter ETS_DOCUMENTATION (lines 228 - 232). We perform the same logic on these parameters as we did for the texts namely we have to have the documentation available in the system language (lines 233 - 243) as well as at least one documentation in any language (245-255). if this is not the case we raise an error message. 



    After implementing the application exit class as well as the class containing the basic checks and assigning the application exit class to the BRFplus application, we test if we have reached our goal.


    The screenshot below shows an expression that belongs to an application with the application exit class assigned. As you can see when entering a short text and executing the check an error message appears. The message shows the name of the object, its type and the text of the error message itself.


    The same is the case for the other types of checks which are not shown here as screenshots (anyway I hope you believe me that this is the case)


    Whenever implementing a new application we can assign the application exit class and assure our quality requirements. That is quite good news, but maybe the implementation of the rules has already started before we could put the exit in place. Or there are some old rule implementations that have already been finished. We can for sure assign the application exit class afterwards (and we also should do so) but the checks will not run if the corresponding objects are not checked or changed. So do we have to manually check all the old objects now in order to align the "legacy rules" with our new checks? The next section will give an answer to that question.


    What about "legacy" code?


    For sure the manual check of the BRFplus objects is cumbersome and nobody wants to do that just to find out that everything is ok. Such a manual check is indeed not necessary at all. As we did within the checks of the BRFplus design-time we can now use the BRFplus API to get all the relevant objects and execute the checks on them. As we have the checks already in place (and have encapsulated them in a separate class) the effort to implement such a report is quite low.


    So for our "legacy" rules we implement a report that has as parameter the UUID of the application we want to run the checks on. The report shall display the results of the checks as an ALV for each object that has been checked. The check results shall be displayed as red (failed check) or green (passed check) traffic lights.


    The selection screen of the report is shown below and allows the entering of an UUID for a BRFplus application


    What do we have to do within the report? First we check that the ID belongs to an active application. This can be done using the class CL_FDT_FACTORY=>GET_ID_INFORMATION as shown below (there is a similar method of the class CL_FDT_ADMIN_DATA=>CHECK_ID whcih also does the job but this one must not be used as it is only for SAP internal usage)


    After that we have to fetch all the objects belonging to the application. This can be achieved using the so called query object of BRFplus. As you see in the screenshot below in line 53 we create that object using the BRFplus factory CL_FDT_FACTORY. Next we set the selection parameters for the application (and for all objects within) we want to perform our quality check on (lines 55-60). After that we call the SELECT_DATA method of the query object (line 64-68) to give us all the UUIDs of the objects within the application (table ETA_DATA).


    We loop at that table and call our check class ZCL_BRFPLUS_VALIDATOR for each UUID. The only thing left to do is to get the object type of the BRFplus objects we are running our check against. Here once again the CL_FDT_FACTORY class can help us via its method GET_ID_INFORMATION. This method returns the desired information (the method hands back a lot more information, so you should take a look at its complete signature). The code below shows these steps as part of the check report (lines 75-90).


    As the report should give us some readable output (beside the UUID) we fetch the (technical) name of the BRFplus object (lines 92-96) using again the query object and put together some basic information for the display of the check results. We show the UUID and the name of the BRFplus object and in addition the results of the checks as red and green traffic lights. The basic initialization of the output structure is shown in lines 98-103. Next we have to translate the error messages into the corresponding traffic light colors which is not shown here as there are no real secrets in doing so (just a lot of IF cases).


    In addition to make life a little bit more comfortable we want to allow the user to directly jump from the check result to the corresponding BRFplus object by clicking on its UUID. This is achieved by the standard ALV functionality for line selection. In the following screenshot we show the corresponding form that is triggered by a line selection of the ALV. The start of the BRFplus workbench is also no big deal. As we have the UUID of the BRFplus object we fetch the reference to the UI execution object of the BRFplus workbench using the BRFplus WebDynpro factory (CL_FDT_WD_FACTORY) as shown in line 256. Next we call the EXECUTE_WORKBENCH method exporting the UUID of the BRFplus object (lines 258-260). This starts the BRFplus workbench which opens the object belonging to the UUID.


    After the execution the report will show the following result:


    As you can see some checks failed. By selecting the object in the ALV we jump off into the BRFplus workbench. This is shown in the next two screenshots (do not take a too close look at the second one as you might find another inconsistency):



    The result i. e. the output of the report is quite rudimentary. Using the code snippets shown above you can easily enhance the output with additional information on the single objects like text or object type.

    Further Scenarios

    Beside the quality check of the rules via the application exit class or a report you can also think about hooking the checks into the release process of a transport request. This can be achieved using the BAdI CTS_REQUEST_CHCK i. e. its method IF_EX_CTS_REQUEST_CHECK~CHECK_BEFORE_RELEASE. As we have encapsulated the logic of our check a separate class the procedure of hooking the check into this BAdI is comparable to the one that we have shown in the report above.



    This blog hopefully gave you some ideas how you can use the application exits and the BRFplus API to perform checks ensuring your guidelines in your BRFplus projects as you would do it in your ABAP projects. The examples shown above are more or less a "finger exercises" to give you an impression what is possible (and how much code is needed to do get the relevant information about the BRFplus objects). In real life/projects the content of the checks will certainly be more sophisticated, but the basic structure will be comparable to what is shown here. So this should help you to get a kick-start in your implementation.


    If you start to use this concept I also want to make you aware of a possible pitfall when implementing the check via the application exit: Within the application exit class you can get access to all objects of the application (and beyond) using the BRFplus API. Nevertheless in any case you should avoid cross checks i. e. check other objects than the one on which the application exit is triggered as this can cause deadlocks when you model your rules. If you want to do checks that have to use information from different objects in your application use a separate report or integrate the checks into the release process of the transport. Within these events you can be sure that the modeling is finished and such cross-checks make sense

    0 0

    In this blog entry I would like to discuss some experience with decision tables created by DSM that are running on HANA. In my opinion it is one the most exciting technologies so far:

    • Business rules are far superiour to  customizing and makes SAP Business Suite and custom development more transparent and easier to change.
    • BRFplus (and also HANA) has the concept of decision tables which is one of the most useful expression type when using business rules. They are easy to use and also business experts can understand them.
    • With DSM you can push business rules down to HANA and I think this has enormous potential. One killer application is simulation of rule changes. So far this is a very complex task where business experts und technical consultants have to work hand in hand and they need system landscapes for tests. Wouldn’t life be much easier if this simulation possibility would be supported directly by your SAP application running on HANA?

    In this blog I’ll introduce some concepts, show a basic but somewhat realistic example and discuss some best practices and last but not least possible improvements for coming DSM versions.


    Welcome DSM!

    If you want to use HANA expressions in BRFplus you habe use the AddOn Decision Service Management called DSM. For the ones who don’t know the difference between BRFplus and DSM let me try an explanation. BRFplus is a technology of the SAP NetWeaver platform. Technically DSM is an AddOn to BRFplus that is seamlessly integrated into BRFplus - so BRFplus is not disrupted by DSM. The opposite is true: DSM completes BRFplus by introducing a number of features that are necessary for the management of business rules, f.e.:

    • better deployment mechanisms for rules
    • new tools for testing and debugging
    • better governance: you can centralize the development of rules systems and also introduce additional metadata that help you for migration and maintenance of rule systems


    In fact the DSM strategy goes even further and there also partner solutions that help you to deploy business rules to non-SAP systems. But all those features are beyond the scope this blog and instead I will discuss only the feature of pushing decision tables down to HANA. You may ask why are business rules in HANA important? Usually decision services implemented in BRFplus/DSM are called from ABAP for a single line item and return calculated values for single item. This is useful but with HANA we can do more:

    • In Big Data scenarios code pushdown to SAP HANA is reasonable. So decision services should be deployable to HANA.
    • Even in classic scenarios with data of moderate size the use of HANA is still promising since it allows you to simulate the effects of changes of rules systems. With HANA you can calculate the effects of changed rule systems on the fly and can analyze the results.

    The last aspect is most important since it makes SAP Business Suite transparent and easier to change and you can react faster if your business rules and practices when you have to react on competition, compliance, legal requirements and more.


    In an ideal (but not always realistic) architecture we would use the same decision table both for decision services on single business objects but also for mass operations on HANA database model. And in there are good news: DSM is HANA-ready! And this is how it goes: DSM has a new object type called Dynamic Database View and the view connects a data source to a decision table and the result is a HANA artifact which can be transformed into a transportable HANA artifact afterwards. So you still have to deal with transport of HANA artifacts which is still a little bit unhandy but if you built HANA side-by-side scenarios you will know everything you’ll have to know.


    So DDBV uses HANA decision tables which are well known. For the ones who have no experience with this technology I will explain in a few word: There are three possible ways HANA decision tables can operate:

    • They rely on a database table and can change the data.
    • The second option (and will discuss this), creates a calculation view having a result column that is calculated.
    • Another option is that the view relies on an Analytical or Attribute View and the decision table performs a projection: a certain row can be in- or excluded from the result set.


    By combing the data model (f.e. a HANA Calculation View) with a BRFplus decision table you can use the object in DB lookup expression in a BRFplus application.


    A simple but realistic example

    Wolfgang Schaper explained the steps for creating a decision table and in his Whitepaper he chose a database table but usually this won’t work since the data is usually scattered across many different tables – perhaps even customizing tables are involved. This makes it even more difficult since often you have to avoid hard coded constants. So what should you do? In general you will have no choice and create HANA Calculation Views. So if you are lucky and your developers have HANA skills then this will be an easy task.


    So let’s look at an example which is a typical and somewhat realistic use case since different tables and customizing tables are involved:

    • I have table ZITEM and ZPOSITION and both are in a one to many relationship.
    • ZITEM has an association to the central business data and in my decision table  would like to use the birth date from transparent table BUT000.
    • The elements of ZPOSITION have a classification attribute that should be used in my decion table and can contain values like VERY LOW, LOW, MIDDLE, HIGH, VERY HIGH.
    • Moreover I don’t want to hard code these values since they rely on customizing (transparent table ZCLASSIFICATIONS).


    To use a decision table in this scenario I have to transpose this item/position relationship ino a single table:

    • ITEM – for each entry of table ZITEM
    • BUYER – a Business partner number. This would be only useful in my decision table if I would like to define special rule for some partners
    • BIRTHDATUM – one attribute of BUYER form transparent table BUT000
    • CLASSIFCATION1 – corresponding to a value CLASSIFCATION1 in a customizing table ZCLASSIFICATIONS
    • CLASSIFCATION2 – corresponding to a value CLASSIFCATION2 in a customizing table ZCLASSIFICATIONS
    • CLASSIFCATION3 – corresponding to a value CLASSIFCATION3 in a customizing table ZCLASSIFICATIONS


    The values CLASSIFCATION1, CLASSIFCATION2 and CLASSIFCATION3 should be not equal NULL if for an item there exists a row in the ZPOSITION table having that value.


    This will be more clear when you see an example. These are the items, the first item is associated to a Business Partner:


    Each item has a certain number of positions, each has a classification:


    The classifications in my scenario are defined in a customizing table. Only those classifications are relevant in my scenario – the other ones can be omitted here:


    When I join everything together I get the following (flat) result. Please remark that some values (depending on above customizing table) should be take from the positions to the items:


    Now I can define a decision table that works on each item and defines a decision service that calculates output results. But therefore I have to join all those data in the described manner together. One possibility is to create a HANA view that performs the join.

    And this is exactly what you have to do when using DDBV: You may a Calculation View in your HANA Studio to perform some SELECTs and JOINs. You see the view such a view here:


    I’ll come back to the SQL statement used in the view later but at first I want to complete the workflow for creating a decison table based on a HANA view.


    The Design of a HANA Decision Table

    To access HANA data there is a new object type called dynamic database view (DDBV). With this object you can consume a table or an HANA view. Therefore I define DDBV for a calculation view and select database fields as result fields like shown below:


    As result data I define a new calculated field called CLASSIFICATION which is calculated in a decision table POSITIONS_DT:


    This decision table can be defined arbitrarily, f.e. as follows.


    As result HANA decision table is generated from the BRFplus decision table having the HANA Calculation View as datasource:


    In fact you can also define different input parameters for the decison table that can be used in the column expression but are not passed through into the view.


    So let me summarize:

    • The DDBV object is the link to a HANA artifact (f.e. a Calculation View) that is on a remote HANA DB (think of a schema of BW on HANA system  perhaps containing data even from non-SAP systems) or ABAP on HANA Systems (of course having HANA as primary persistence).
    • The decision table working on the view is optional. It is generated from a BRFplus decision table but the expressiveness is limited since you can’t use all
      expressions (think of custom defined ABAP formulas for example). Unfortunately the supported features doesn’t seem to be documented so you have to try it out.
    • Usually the data are consumed using an ordinary DB Lookup expression in BRFplus. But since you know the HANA artifact you can call them directly using ADBC for example or tie them to a ALV on HANA grid for further analysis.

    The Main Challenge: View Building

    As I told before, decision tables work on relational data and due to normalization they are spread over many database tables. So the main challenge is view building to create the input data for a decision table.


    Since DDBV supports HANA artifacts (working on a single ABAP table is often not realistic) HANA development is necessary and so are HANA artifacts that can be transported using CTS+. So you can start implementing this scenario but from my point of view it is not that comfortable as it could be. But here my opinion is very simple: If you can solve pain points with HANA development then you should definitely do this and start creating HANA views.


    For the sake of completeness I will mention another option: in scenarios where BW and HANA is involved you can generate HANA views from DSO: this is described in the HANA development guide. Please remark that this is possible when you are using an Enterprise BW but it should work also when working with an Embedded BW on operational data.

    SAP’s “Secret” Weapon: Core Data Services

    Since decision management is about making decisions based on operational data IMHO a plain ABAP approach would be best. Above mention DSO should be avoided unless you don’t have good reasons to do.


    In my opinion a future Version of DSM should support ABAP Database Views and these could extended them by result columns since this lead to pure ABAP based programming model, But wait, didn’t I wrote that classical database view are not useful. Yes, but this is only half of the truth since NW 7.40 ABAP supports new view building possibilities using ABAP Core Data Services. The advantage of this approach is that it is seamlessly integrated into ABAP Workbench and you don’t need care about the clumsy HANA transport mechanisms like HANA Transport Container. Unfortunately we can’t define calculation views in CDS (=extension of normal views) otherwise it would be very easy. At first you define a join for each relevant classification:


    Since multiple entries can occur we select only distinct ones:


    Then we join everything together:


    An SQL expert will immediately recognize possibilities for simplification and optimization. I show this example nevertheless since it was the only possibility to solve above described join in NW 7.40 SP4. In SP5 and later we have completely new possibilities and the optimization of above CDS views is “left to the reader as easy exercise”.

    This is what we can learn the following from example:

    • Pushdown of a decision table to HANA needs view building which should  be done using CDS since CDS is superior to classic ABAP Dictionary DB Views.
    • If there would be a way extend above view by result columns in CDS then it could easily linked to DSM.
    • IMHO ABAP CDS views should get parameters and we should use them not only in a decision table but also pass them to CDS for the reasons of  flexibility. Moreover it should be possible to pass parameters from DSM to CDS.
    • We should start to think whether the update after execution of a decision table should be performed on the application server. Perhaps it would also good to do it using a database procedure.
    • For more complex calculations we should start to think about nested decision tables but as far as I know this currently out of scope of HANA decision tables.

    Unfortunately DSM doesn’t support those techniques at the moment and so HANA development will be necessary in most real-word scenarios.



    So far DSM’s decision tables built on Dynamic Database Views are a little bit limited. Of course they do their job but together with advanced ABAP view buildung the implementation would be much easier. On the other hand the possibility of using arbitrary HANA Views in DSM is also a chance since you can also access data from non-SAP systems and even consume BW objects suing BRFplus which is useful especially in BW on HANA scenarios. If you need further information about this scenario you should look here and here.

    Another interesting aspect is that obviously the HANA-power of DSM is related to the features of the HANA database. So far decision tables are the only expression that can be pushed to down to HANA but it is obvious that every extension of this mechanism will make DSM much more valuable – think of nested decision tables for example. Here I expect more to come and this is why I already looking forward to SAP TechEd && d-code especially

    SAP TechEd && d-code 2014 session about SAP Decision Service Management.


    So my impression is: DSM made a good start on its HANA road. Now SAP has improved its infrastucture (especially HRF and CDS) and therefore synergies should be possible. So I think the DSM HANA story will continue and I am eagerly waiting for further annoucements.

    And last but not least I recommend every ABAP developer to inform about latest ABAP features (SAP Inside Track Munich this weekend is a perfect chance) and to fresh up his SQL skills since the invention of means a reinvention of the ABAP Dictionary and extension of the SQL capabilities of the AS ABAP.



    In the case you are interested I show you the SQL statements generated from above shown CDS views. You can use them directly to build HANA views using SQL:



                AND C1."ITEM" = ITEM."ITEM" )


                AND C2."ITEM" = ITEM."ITEM" )


                  AND C3."ITEM" = ITEM."ITEM" )



    Please remark that ZVCLSFDDPOS1, ZVCLSFDDPOS2and ZVCLSFDDPOS3 resp. are defined as follows:











    Please remark that CDS not only restricted to HANA but also available for any DB. But don't forget: they work in ABAP NW 7.40
    SP4 – so in later SPs CDS is much more powerful. And for really challenging scenarios I think HANA optimized SQL is still the best solution.

    0 0

    Well , I have been working to analyze the Business Rules Framework , designed for managing rules.

    Finally , I concluded that BRF+( which is also the tcode to access it from the SAP ECC box )

    is much much more than just mapping Z-tables ,which was frankly my initial impression about the tool and

    I must agree I was really wrong in my perception , as it is much much more than that .


    So I thought of writing this blog (out of my project experience) to help analyze if BRF+ is the right fit for managing rules .

    I have tried to put below some scenarios where usually  Z-tables are used and can be replaced with BRF+.


    1) Scenario 1 :

    a) Ask the question if your requirement is to ONLY fetch some values .

    b) If your answer for a) is Yes , BRF+ might not be the best fit .

    c) If your answer  for a) is No , then  Do you want to do something further with those values , validate some set of condition etc

    d) If your Answer is Yes  for c) .. Bingo !! BRF+ is the best fit


    Example :

    There is a requirement where you want to show in a report if a Customer is  Special i.e. if it is a MEDICAL , DEFENSE .

    So Firstly we  need to maintain the mapping between Customer Number & Type ( MEDICAL / DEFENSE/OTHERS )


    So based on the steps mentioned I can conclude that OK I want to get value for Type field for a given customer number

    and then check if Type field value is MEDICAL/DEFENCE , mark the customer as Special in the report .



    2) Scenario 2


    a) Do you have any validations in the code ?

    b)  Check What kind of validations : business checks lets say Some value should be in some given value range etc.

          or at save you want to perform certain validations at particular status

    c) If so , BRF+ is the best fit


    Example :


    You have a validation to check if Some Date should not be less than the current date . So instead of keeping in the code

    you can add it in BRF+


    3) Scenaro 3


    a) Do you wanna perform some actions , lets say at Save at a particular status - you want to send a mail

    b) If Yes , BRF+ is the best fit




    You want to notify Manager once the Change Master is "Released" , send a mail to "Production Manager"



    3) Scenario 4


    a) Do you want to trigger Workflow or an Workflow event .

    b) If Yes , again BRF+ is the best fit .


    Example :


    Most of the time we need to trigger workflow or wf events based on some set of conditions like in my project it was the Object status change.

    e.g. If the Change Master is set to status "Review" , start Workflow .

    I would loved to post some tutorials for above scenarios once I get some good time .


    Hope you find this blog helpful to identify BRF+ fitment for your use-case.




    P.S : BRF+ could be used for many other scenarios apart from above , but the above mentioned ones are based on my project experience .

             BRF+ could also be beneficial for doing a mere data retrieval out of custom mapping rules , where mostly ABAP'ers create a Z-table.

            Please follow the links provided by Carsten below in the comments related to evolution of BRF to BRF+

    0 0

    BRF+ Transports fails with errors then BRF+ application inactive in target system.


    Issue Explanation: When we import BRF+ application using transport from Dev system to SIT/UAT/Prod if transports imported with return code 12/8 then in target system that BRF+ application will be in active.


    Then we have two options to fix issue

    1. Using FDT_HELPERS tcode we can re import failed transports then it will activated BRF+ application in SIT/UAT/prod


    2. Create new transport with BRF+ application and import to target system if new transport import successful into target system then it will activate BRF+ application in Target system.

    Here I am covering first option next blog I will cover second option

    Step 1:

    Please prepare transport before release


    Step 2:

    Then Release Transport in Source system



    Step 3:

    Please inform Basis to run import job to target system


    Step 4:

    Check transport import log

    Tcode: SE01

    Provide your transport and click on Log Tab


    Step 5:

    Transport fails with return error code 8


    Step 6:

    Open BRFPLUS workbench and check BRF+ application it will be inactive mode in target system


    Step 6:

    Login into target system and Open FDT_HELPERS tcode in target system


    Step 7:

    Expand BRFplus -  Transport


    Step 8:

    Select BRFplus: Transport phase Execution


    Step 9:

    Click on Execute


    Step 10:

    Next you will see below screen


    Step 11:

    Provide your transport like below and select radio button After import Processing then click on Execute button



    Step 12:

    It will show you result is successfully generated BRF+ application in target system


    0 0

    One critical success factor in business rule projects is the communication between business and IT. This is not surprising since it holds for every IT project, but when it’s about business rules it becomes urgent. The reason is that in business rule projects business people have to define sometimes complex computations which are in fact algorithms. The challenge is that those algorithms are complex artifacts and they have to be designed carefully since they automate core processes.


    What skills are needed to define algorithms? How do we get an understanding for algorithms? SAP Mentor DJ Adams gave a TEDx-Talk in Birmingham where he explained why everyone should be learn how to code at school. He argued that information technology is so fundamental in today’s world that everyone needs to understand the basics even if he or she will choose a completely different job in the future. I totally agree with his opinion and for the ones who don’t know his talk I’ll share the link to the Youtube video of this talk about “our computational future”.



    But what’s the connection to business rules? I believe that business rules are part of our computational future. With business rules you can control the processes within ERP system so that they are transparent, easy to understand and easy to change. The rules are specified by business people and have to be translated into BRFplus that is in fact a formal domain specific language for rules.


    Usually people from an IT department will code those rules BRFplus and they will do it in a way that business people who are the owners of rule systems can read them. In BRFplus this is very easy:

    • As a BRFplus developer use (long) texts for BRFplus objects so that your rules are readable like normal text. Moreover use documentation and DDIC binding /resp. domain values so that data elements are displayed together with texts.
    • Define a special role for business people so that business people can start the workbench, read (but not change) applications and perform simulation.


    With a little bit effort a BRFplus developer is able to explain and to discuss a BRFplus implementation of a rule system with business people who are owner of the rule system. 


    But one challenge still remains: how is the rule system created? How do business people explain a BRFplus developer what to do? Here there are two possibilities: a business user can write a specification or he can create it together with a technical expert of a business rule system. I prefer the latter. The reason is that from my experience most specifications are error-prone: they contain typos, sometimes contradictions and sometimes they lack of precision. Therefore it is necessary to find a common language of business people and IT. For me decision tables are a very powerful and easy to understand so I use them very often and with much success. And if there are still misunderstandings between business and IT I prefer a direct conversation.


    But what is the root cause of communication problems between business and IT in the area of business rules? From the viewpoint of a rules developer I have to understand the requirements and translate into a formal language. With the help of above mentioned best practices I can do it in a way that business people can understand a rule system. But first I have to understand the business people and their requirements. IMHO one challenge is that many business experts without any IT education or comparable skill have difficulties to understand or think in formal languages. This can lead to consequences in a specification process of a rule system:

    • Developers are trained to use a top-down approach. At first they look at the overall structure of a rule system and define functional parts. In most cases they are very easy: in the first step you have to collect all data needed to perform checks and calculations. Then you perform the checks and calculations and later you look at special cases and exceptions. People who are not trained to analyze a problem this way often start to explain business rules by explaining exceptions and special cases. This often will lead to confusion and ugly implementations.
    • In the center of a business rule system like BRFplus are rules which have an IF … THEN … ELSE structure. Developers are very familiar with those. So they know that Boolean conditions with many operators like AND/OR are hard to understand and they will use parentheses to make the structure clear. On the other hand some people in business are not aware of the different semantics of “or” and “either or” for example. This can lead to more problems.


    The conclusion is very simple: Sometimes business experts are well trained since they’re familiar with software like Excel or Access but there are also others who have difficulties thinking in formal languages and Boolean logic.  I agree with DJ Adams: Everyone should have some basic skills coding so the barrier to specify and understand a formal rule system like BRFplus would lower. This doesn’t mean that everyone should have the skills of an experienced programmer but he should have a vague idea how an algorithm works and that a precise description is needed to create one. 


    When talking to business experts I often experience some difficulties to understand what they mean. I would like to give the following advice that could make the conversation easier:

    • Think of a rule system as a function with defined input and output parameters.
    • Be precise – try to avoid terms like “perhaps” in your specification.
    • Try to use a notation like DMN for specification of rule systems.
    • Use parentheses if you define complex Boolean conditions.
    • Use test cases and the simulation mode in BRFplus.
    • Don’t specify a rule systems by writing down special cases first – focus on the general case.


    On the other hand I also recommend that a BRFplus developer has at least a basic understanding of the business process and tries to understand how the rule system should work. So it’s the same old story: business and IT have to find to find a common language. I think BRFplus can be “spoken” by both if both sides are willing to do use it.

    0 0
  • 07/14/15--05:06: BRF+ Theme change
  • Hi All,


    This blog will assist you on how to change the BRF+ Theme..


    Login to your system and Execute the Tx --> BRF+


    Before Changing the Theme





    Now goto Tx --> SE80


    Give package – Web Dynpro component


    Object - FDT_WD_ADMIN_TOOL


    Under Web dynpro Applications choose fdt_wd_workbench


    Select display/change and provide the Access key




    In the properties tab add the below parameter


    Parameter = WDTHEMEROOT


    value = sap_chrome


    Note : You can choose your own value by using Application Parameters and URL Parameters - Reference - SAP Library


    And save it



    After Adding the Parameter just Log-off and Log-in. Now you can see the changed BRF+ theme




    Thank you Everyone...

    0 0

    Description :


    This Blog describes about dynamic creation of a decision table and it's entries using  CL_FDT* classes Collection.




    1. Basic knowledge on OO ABAP concepts
    2. Basic knowledge on BRF+ framework


    Requirement : Create Decision Table and it's entries dynamically in BRF plus  through simple report.


    Interfaces used :




    Step 1 :  Create an application in the workbench level as show in below.


    2015-08-17 16_08_06-BRFplus Workbench.png

    Create decision table dynamically for above application.



    Step2: Please paste the following code snippet in your report, required steps are explained in detail through comments.



    DATA: lo_factory         TYPE REF TO if_fdt_factory,

           lt_message           TYPE if_fdt_types=>t_message,

           lv_message          TYPE string,

           lv_boolean            TYPE abap_bool,

           lo_element            TYPE REF TO if_fdt_element,

           lo_table                TYPE REF TO if_fdt_table,

           lo_structure          TYPE REF TO if_fdt_structure,

           lv_element1_id      TYPE if_fdt_types=>id,

           lv_element2_id      TYPE if_fdt_types=>id,

           lv_element3_id      TYPE if_fdt_types=>id,

           lv_structure_id      TYPE if_fdt_types=>id,

           lo_constant           TYPE REF TO if_fdt_constant,

           ls_element            TYPE if_fdt_structure=>s_element,

           lts_element           TYPE if_fdt_structure=>ts_element,

           lv_string                TYPE string,

           ls_range                TYPE if_fdt_decision_table=>s_range,

           ls_table_data         TYPE if_fdt_decision_table=>s_table_data,

           lo_decision_table   TYPE REF TO if_fdt_decision_table,

            lo_function            TYPE REF TO if_fdt_function,

           lo_context              TYPE REF TO if_fdt_context,

           lts_context_id         TYPE if_fdt_types=>ts_object_id,

           lts_table_data         TYPE if_fdt_decision_table=>ts_table_data,

           lts_column              TYPE if_fdt_decision_table=>ts_column,

           lv_actv_failed          TYPE abap_bool,

           lx_fdt                      TYPE REF TO cx_fdt,

          lv_dt_id                   TYPE if_fdt_types=>id,

           ls_column               LIKE LINE OF lts_column.



    FIELD-SYMBOLS:     <ls_message>   TYPE if_fdt_types=>s_message,

                                      <lv_value>        TYPE any.



    * Get instance of the FDT factory.

    lo_factory = cl_fdt_factory=>if_fdt_factory~get_instance(

                               '002590F0DB231ED591961054F1DE0488' )."get the object id of the application

    *which was created in the workbench


    *creation of data objects.

    lo_element ?= lo_factory->get_data_object(

         iv_data_object_type = if_fdt_constants=>gc_data_object_type_element ).

    lo_element->if_fdt_transaction~enqueue( ).

    lo_element->if_fdt_admin_data~set_name( 'IV_VAR1' ).

    lo_element->set_element_type( if_fdt_constants=>gc_element_type_text ).



         et_message           = lt_message

         ev_activation_failed = lv_boolean ).

    IF lv_boolean EQ abap_true.

    * for some reason the activation failed -> individual handling needed

       lo_element->if_fdt_transaction~dequeue( ).


       lo_element->if_fdt_transaction~save( ).

       lo_element->if_fdt_transaction~dequeue( ).

    * usually it makes sense to store the id for later access to the application

       lv_element1_id = lo_element->mv_id.

       ls_element-position = 1.

       ls_element-element_id = lv_element1_id.

       APPEND ls_element TO lts_element.


      INSERT lv_element1_id INTO TABLE lts_context_id.


    * Create another element

    lo_element ?= lo_factory->get_data_object(

         iv_data_object_type = if_fdt_constants=>gc_data_object_type_element ).

    lo_element->if_fdt_transaction~enqueue( ).

    lo_element->if_fdt_admin_data~set_name( 'IV_VAR2' ).


    * set the element-type (see if_fdt_constants=>gc_element_type_* for

    * a list of available element types)

    lo_element->set_element_type( if_fdt_constants=>gc_element_type_text ).




         et_message           = lt_message

         ev_activation_failed = lv_boolean ).

    IF lv_boolean EQ abap_true.

    * for some reason the activation failed -> individual handling needed

       lo_element->if_fdt_transaction~dequeue( ).


       lo_element->if_fdt_transaction~save( ).

       lo_element->if_fdt_transaction~dequeue( ).

    * usually it makes sense to store the id for later access to the application

       lv_element2_id = lo_element->mv_id.

       ls_element-position = 2.

       ls_element-element_id = lv_element2_id.

       APPEND ls_element TO lts_element.


      INSERT lv_element2_id INTO TABLE lts_context_id.


    * create a result data element

    lo_element ?= lo_factory->get_data_object(

         iv_data_object_type = if_fdt_constants=>gc_data_object_type_element ).

    lo_element->if_fdt_transaction~enqueue( ).

    lo_element->if_fdt_admin_data~set_name( 'EV_RESULT' ).

    lo_element->set_element_type( if_fdt_constants=>gc_element_type_text ).




         et_message           = lt_message

         ev_activation_failed = lv_boolean ).

    IF lv_boolean EQ abap_true.

    * for some reason the activation failed -> individual handling needed

       lo_element->if_fdt_transaction~dequeue( ).


       lo_element->if_fdt_transaction~save( ).

       lo_element->if_fdt_transaction~dequeue( ).

    * usually it makes sense to store the id for later access to the application

       lv_element3_id = lo_element->mv_id.

       ls_element-position = 3.

       ls_element-element_id = lv_element3_id.

       APPEND ls_element TO lts_element.


        INSERT lv_element3_id INTO TABLE lts_context_id.


    * Populate the first column element

       ls_column-col_no     = 1.

       ls_column-object_id =   lv_element1_id.

       ls_column-is_result  = abap_false.

       INSERT ls_column INTO TABLE lts_column.



    * Populate the second column element

       ls_column-col_no     = 2.

       ls_column-object_id  = lv_element2_id.

       ls_column-is_result  = abap_false.

       INSERT ls_column INTO TABLE lts_column.


    * Populate the result column element

       ls_column-col_no     = 3.

       ls_column-object_id  = lv_element3_id.

       ls_column-is_result  = abap_true.

       INSERT ls_column INTO TABLE lts_column.


    * Create and set the Decision Table Expression.

       lo_decision_table ?= lo_factory->get_expression( iv_expression_type_id = if_fdt_constants=>gc_exty_decision_table ).

    * Enqueue the Decision Table Expression.

       lo_decision_table->if_fdt_transaction~enqueue( abap_true ).


    * Set the columns of the table

       lo_decision_table->set_columns( its_column = lts_column ).

    lo_decision_table->if_fdt_admin_data~set_name( 'DT_TEST' ). "user defined name. DT_TEST is the decision table Name


    * Create a function instance using factory object.

       lo_function ?= lo_factory->get_function( ).


    * Enqueue the function.

       lo_function->if_fdt_transaction~enqueue( ).

    * Set the context data object for the function.

       lo_function->set_context_data_objects( lts_context_id ).

       lo_function->if_fdt_admin_data~set_name( 'FN_TEST' ). "user defined name . FN_TEST is the function Name

    * Set the root expression of the function.

       lo_function->set_expression( lo_decision_table->mv_id ).


    *  Set the condition for column1 in cell(1,2).

       ls_table_data-row_no = 1.

       ls_table_data-col_no = 1.

       ls_range-position = 1.

         ls_range-sign     = if_fdt_range=>gc_sign_include.

         ls_range-option   = if_fdt_range=>gc_option_equal.

         CREATE DATA ls_range-r_low_value TYPE if_fdt_types=>element_text.

         ASSIGN ls_range-r_low_value->* TO <lv_value>.

         <lv_value> = 'MOURI'.

         INSERT ls_range INTO TABLE ls_table_data-ts_range.

         INSERT ls_table_data INTO TABLE lts_table_data.

       CLEAR ls_table_data.


    *   Set the condition for column2 in cell(1,2).

       ls_table_data-row_no = 1.

       ls_table_data-col_no = 2.

         ls_range-position = 1.

         ls_range-sign     = if_fdt_range=>gc_sign_include.

         ls_range-option   = if_fdt_range=>gc_option_equal.

         CREATE DATA ls_range-r_low_value TYPE if_fdt_types=>element_text.

         ASSIGN ls_range-r_low_value->* TO <lv_value>.

         <lv_value> = 'TECH'.

         INSERT ls_range INTO TABLE ls_table_data-ts_range.

         INSERT ls_table_data INTO TABLE lts_table_data.

         CLEAR ls_table_data.


    **Set the result column in cell(1, 3)

       ls_table_data-row_no = 1.

       ls_table_data-col_no = 3.

       CREATE DATA ls_table_data-r_value TYPE if_fdt_types=>element_text.

       ASSIGN ls_table_data-r_value->* TO <lv_value>.

       <lv_value> = 'MOURITECH'.

       INSERT ls_table_data INTO TABLE lts_table_data.

       CLEAR ls_table_data.


    *   Set the complete table data.

       lo_decision_table->set_table_data( its_data = lts_table_data ).


    * Perform deep activation & saving.


       lo_function->if_fdt_transaction~activate( EXPORTING iv_deep    = abap_true

                                                 IMPORTING et_message           = lt_message

                                                           ev_activation_failed = lv_actv_failed ).


    *  If the activation is successful save all object and release all locks

    *  else only release the locks.

       IF lv_actv_failed EQ abap_true.


           EXPORTING iv_deep              = abap_true ).

         WRITE : / 'Deep activation failed'.

         LOOP AT lt_message ASSIGNING <ls_message>.

           MESSAGE ID <ls_message>-msgid TYPE <ls_message>-msgty NUMBER <ls_message>-msgno

               WITH <ls_message>-msgv1 <ls_message>-msgv2 <ls_message>-msgv3 <ls_message>-msgv4

               INTO lv_message.

           WRITE: / 'Reason : -',lv_message.




             lv_dt_id = lo_decision_table->mv_id.


               EXPORTING iv_deep              = abap_true ).

             WRITE : 'The ID of the decision table created is:' ,lv_dt_id. '.

           CATCH cx_fdt INTO lx_fdt.

             WRITE : / 'Save failed with exception'.

             LOOP AT lx_fdt->mt_message ASSIGNING <ls_message>.

               WRITE :/ <ls_message>-text.





           EXPORTING iv_deep              = abap_true ).


    Step 3 : Click on execute button.


    Step 4: Go to the BRF plus workbench and open the objectID as shown below.


    Click on search button.

    2015-08-17 16_19_15-BRFplus Workbench.png

    we successfully created decision table and it's entries  dynamically.

    we can also check this decision table under the application which created  in step1.

    2015-08-17 16_26_22-BRFplus Workbench.png


    Thank you for reading this blog!!

    0 0

    HRF 1.0 SP05 delivers for the first time a Business Rules Management application that enables working with HRF as standalone*. With this application business users can view, create and edit rules in the system. Using the web UI, users can also create, configure and edit rule services and configure general parameters of the framework.


    To enhance the readability and edit of long rules we have enriched the rules language with “any of the following” (“all of the following”) keywords that can precede a list of short rules as inter-rules OR (AND).

    The user friendliness of creating and managing rules on complex objects was further enhanced with a more natural use of the keyword “all”.

    The language also supports now the Boolean operator “is not” (e.g. customer is not VIP instead of customer.VIP=false)


    Other investments included run-time performance improvements using “one-to-zero-to-one” data objects’” association type.

    As of SAP HANA rev. 97, a restart is no longer required after enabling the SAP HRF run-time plug-in. Additionally, the SAP HRF post-installation/upgrade configuration script can be executed in a single step (previously two runs were required to complete the activation of resources).


    * HRF is a free add-on available for standalone use only to customers that own a license for one of the HRF embedding applications (currently: Fraud Management, OPInt, TRP, Hybris Marketing; more to come) or HANA Enterprise Edition.

    For more information:

    HRF on SAP Community Network (SCN) -

    HRF Documentation on SAP Service Marketplace-

    0 0

    BRFplus—Business Rule Management for ABAP Applications

    Vor rund 5 Jahren habe ich in einem Blog das erste Buch zu BRFplus angekündigt. Nach Monaten der harten Arbeit von Thomas Albrecht und mir war es im Dezember 2010 soweit. Seitdem hat sich das Buch sehr gut verkauft und unser Verlag hat den Kontakt zu uns nicht abgebrochen.   



    Business Rule Management mit ABAP - BRFplus und SAP Decision Service Management

    In der Zwischenzeit hat sich BRFplus natürlich erheblich weiterentwickelt und mit DSM sind ganz neue Möglichkeiten der Nutzung von Geschäftsregeln hinzugekommen. Nach Gesprächen mit Verlag und potentiellen Koautoren haben wir uns entschieden keine neue Auflage zu veröffentlichen, sondern in einem größeren Kreis ein neues Buch zu schreiben. Zum Kreis der Autoren gehören neben Thomas und mir auch Christian Lechner, Tobias Trapp, Daniel Ridder, Wolfgang Schaper und Matthias Kucharska. Wie beim letzten Buch haben wir uns auch dieses Mal für ein SAP Press - Buch entschieden, das in Deutschland vom Verlag Rheinwerk herausgegeben wird. Nun ist die Arbeit fast geschafft. Der letzte Feinschliff wird gerade angebracht. Auf der Verlagsseite und im Buchversand werden bereits Vorbestellungen entgegengenommen. Lieferbar ist es ab dem 26. Oktober 2015. Bei Rheinwerk kann neben der gedruckten Ausgabe auch ein E-Book erworben werden. Das Buch (ISBN 978-3-8362-3743-7)erscheint in deutscher Sprache und hat circa 550 Seiten.



    Aus dem Inhalt

    • Modellierung und Anwendung von Geschäftsregeln
    • Einsatzszenarien
    • Regelsätze und Regeln
    • Ausdrücke und Aktionen
    • Test und Transport regelbasierter Anwendungen
    • Integration mit SAP Business Workflow und BOPF
    • Erweiterungsmöglichkeiten
    • Fehleranalyse
    • Best Practices
    • Vorgehen in Geschäftsregelprojekten

    Die Zusammenarbeit mit den anderen Autoren war sehr angenehm. Vielen Dank! Wir konnten unterschiedliche Sichtweisen und Erfahrungswerte in Kapiteln wie Einsatzszenarien, Best Practices oder Fehleranalyse vereinen. Damit stellt das neue Buch viele Inhalte zur Verfügung, die in unserem ersten Buch nicht berücksichtigt wurden. Ich bin sehr gespannt auf die ersten Rückmeldungen.



    This blog is about a new book for DSM and BRFplus. The book will be published in German language. Therefore, the blog is written in German.

    0 0
  • 09/14/15--10:21: Thank you contributors!
  • The Business Rule Management space started some years ago as a spin-off from the Business Process space. I've always told the marketing folks at SAP that business rules and business processes are two different things and that the one (rules and decisions) should not be seen only in the scope of the other (processes). It took some time for them to understand this. SAP BRM is often used in combination with SAP BPM. However, SAP DSM and BRFplus are mostly used within SAP business applications or as an alternative to custom code.

    I was very happy when we finally opened the Business Rule Management space and I started answering forum posts and writing articles. Soon Wolfgang Schaper and other members of the development team started to support me with contributions. Quickly, first users and consultants also became involved. Today, the Rule space has more than 400 followers which is pretty remarkable compared with the 530 followers of the BPM space (Sep, 2015). .

    An online community only grows when members receive support. Support is given by amazing people who like to share their knowledge and help others who are experiencing pain and frustration.I would like to use this blog to thank all of the contributors! A special thanks goes to the top contributors. You can find those from the last 12 months in the following diagram. Unfortunately, I do not have any numbers for the time before that but I still remember Rahul Tiwari, Lee Chisholm and others being very active some years ago.


    At the moment Christian Lechner leads the pack with clear margin. Not only is he very involved, but he also provides high quality answers in the forum. So I asked him to become a moderator. To my satisfaction, he promptly accepted and joined Jocelyn and me.

    Welcome Christian to the team of moderators!

    0 0

    Recently, we have seen several new, very big SAP DSM and BRFplus business rule projects. Taking a closer look at those projects helps us learn about new usage patterns. Sometimes we are surprised by the creativity shown by some customers and partners. In some rare cases we hit limitations. All of this has happened in the past few months. In this blog I want to share some improvements that were introduced with help of SAP notes. I think those novelties could be of interest to the community.


    Code Generation

    Our support team has created several notes with improvements for the code generation in BRFplus and DSM. One of the generator’s new capabilities is that it can now generate multiple classes for a function/decision service. Thanks to this improvement there is no longer a problem with generation limits. As a consequence, you can now also create decision tables with tens of thousands of rows. However, I still recommend not doing this. Your rule design would probably be odd in such a case. A decision table should not replace a database table. 


    Another optimization took place for use cases where many smaller expressions are often reused. In the past, the generator has created redundant code for smaller expressions and only bigger expressions were put into separate methods. Now this algorithm is much more intelligent. In a customer scenario, we were able to reduce the lines of code by magnitudes. As a side effect, the time to generate the code was reduced from minutes to seconds.


    • 2191058 - BRF+: Generation fails due to error
    • 2196004 - DSM: Deployment fails due to code generation errors
    • 2198952 - BRF+: Search tree generation issue
    • 2157081 - Code generation fails due to huge size of code
    • 2185426 - BRF+: Decision tree generation issue


    HTML Supported in Expression Type E-Mail Action

    A customer requested the creation of HTML e-mails with help of e-mail actions. This very same feature was also requested in the business rules forum. Today, I can announce that our support team made it possible. By default, the system creates a plain-text e-mail that looks like an exact copy of what you type into the Body entry field at design time. To use the HTML format with all kinds of HTML features, enter the following document type declaration as the first line in the Body field: <!DOCTYPE HTML>. With this declaration, the system no longer interprets the entire remainder of the mail content as plain text, but as an HTML document.


    • 2158477 - Enhance Send E-mail Action to allow HTML format


    Object Activation

    A customer with a huge rule base asked us for help because saving and activating objects took too much time. We analyzed the use case in depth. To our surprise, the customer had already spotted the problem and made a modification in the system. Often, customer modifications in deep layers of our code are not a good idea because customers can’t really assess the impact. Frequently data inconsistency and crashes are the result of modifications. But this time it looked very interesting and the increase in performance was remarkable - a factor of 10 and more in this giant use case. So we took the code home and did some analysis and test runs with it. Finally, we made turned it into a note to be able to share it with everybody.


    • 2199193 - BRF+: Performance improvement in BRF+ object activation


    Closing Words

    Thanks to all of the customers who help us improve the product. Sometimes you need a bit of patience. But be sure that we hear you. I want to express even more gratitude to those customers who give us tips or even provide solutions. This is absolutely awesome. It happens rarely but I am always amazed when it does. Please continue surprising me! 

older | 1 | .... | 3 | 4 | (Page 5) | 6 | newer