SAP Community - NW ABAP Business Rule Framework (BRFplus)

Utility for copying MDG BRF+ workflow Decision Tables

2023-02-15T13:15:07+01:00

If for any reason, you have a fairly detailed segmentation of BP types and activities in MDG, there's a chance you have had to copy over BRF+ workflows.

Now, this is not a terribly difficult thing to do as the Import/Export functionality in BRF+ is a great feature. However minor changes can be a headache and I was getting tired of clicking the Import/Export button every time that happens.

Below is a little code I used to quickly copy over data the workflow BRF+ decision tables from one Change Request Workflow into another.

It's obviously rough. The error management could be improved, but it's good enough for occasional adjustment activity.

Helper Class

This is the local class I used as a helper.

CLASS lcl_brf DEFINITION.

  PUBLIC SECTION.

    METHODS get_reference_decision_tab

      IMPORTING iv_crtype TYPE string

      RAISING   zcx_mdg.

    METHODS get_decision_tab_object

      IMPORTING iv_name          TYPE string

      RETURNING VALUE(ro_object) TYPE REF TO cl_fdt_decision_table

      RAISING   zcx_mdg.

    METHODS get_decision_tab_data

      IMPORTING iv_name                TYPE string

      RETURNING VALUE(rt_decision_tab) TYPE if_fdt_Decision_table=>ts_table_data

      RAISING   zcx_mdg.

    METHODS copy_to

      IMPORTING iv_crtype TYPE string

      RAISING   zcx_mdg.

    METHODS copy_decision_table

      IMPORTING iv_name         TYPE string

                it_decision_tab TYPE if_fdt_Decision_table=>ts_table_data

      RAISING   zcx_mdg.



    METHODS constructor.



  PRIVATE SECTION.

    DATA mo_brf_query TYPE REF TO if_fdt_query.

    DATA mo_brf_factory TYPE REF TO if_fdt_factory.

    DATA mt_user_agent TYPE if_fdt_decision_table=>ts_table_data.

    DATA mt_non_user_agent TYPE if_fdt_decision_table=>ts_table_data.

    DATA mt_single_value TYPE if_fdt_decision_table=>ts_table_data.

ENDCLASS.



CLASS lcl_brf IMPLEMENTATION.

  METHOD constructor.

    mo_brf_factory ?= cl_fdt_factory=>if_fdt_factory~get_instance(  ).

    mo_brf_query ?= mo_brf_factory->get_query( ).

  ENDMETHOD.

  METHOD get_decision_tab_data.

    DATA : o_decision_table TYPE REF TO cl_fdt_decision_table.

    mo_brf_query->get_ids(

      EXPORTING

        iv_name   = CONV #( iv_name )

        iv_object_type = if_fdt_constants=>gc_object_type_expression

      IMPORTING

        ets_object_id = DATA(app_ids) ).

    o_decision_table ?= mo_brf_factory->get_expression( app_ids[ 1 ] ) .

    o_decision_table->if_fdt_decision_table~get_table_data( IMPORTING ets_data = rt_decision_tab ).

  ENDMETHOD.

  METHOD  get_reference_decision_tab.

    DATA : o_ref_decision_table TYPE REF TO cl_fdt_decision_table.

    mt_user_agent     = get_decision_tab_data( |DT_USER_AGT_GRP_{ iv_crtype }| ).

    mt_non_user_agent = get_decision_tab_data( |DT_NON_USER_AGT_GRP_{ iv_crtype }| ).

    mt_single_value   = get_decision_tab_data( |DT_SINGLE_VAL_{ iv_crtype }| ).

  ENDMETHOD.

  METHOD get_decision_tab_object.

    mo_brf_query->get_ids(

      EXPORTING

        iv_name   = CONV #( iv_name )

        iv_object_type = if_fdt_constants=>gc_object_type_expression

      IMPORTING

        ets_object_id = DATA(app_ids) ).

    ro_object ?= mo_brf_factory->get_expression( app_ids[ 1 ] ) .

  ENDMETHOD.

  METHOD copy_decision_table.





    DATA : o_decision_table TYPE REF TO cl_fdt_decision_table.

    TRY.

        o_decision_table = get_decision_tab_object( iv_name  ).

        o_decision_table->if_fdt_transaction~enqueue( ).

        o_decision_table->if_fdt_decision_table~set_table_data( EXPORTING its_data = it_decision_tab ).

        o_decision_table->if_fdt_transaction~activate(

            EXPORTING iv_deep              = abap_true

            IMPORTING et_message           = DATA(messages)

            ev_activation_failed = DATA(lv_actv_failed) ).

        if lv_actv_failed = abap_true.

          MESSAGE e000(zmdg) WITH 'Error updating' iv_name INTO zcl_messages=>sv_message_text.

          RAISE EXCEPTION TYPE zcx_mdg

            EXPORTING

              mo_messages = NEW zcl_messages( )->set_system_message( ).

        endif.



        o_decision_table->if_fdt_transaction~save( ).

        o_decision_table->if_fdt_transaction~dequeue( ).

      CATCH cx_fdt.

        MESSAGE e000(zmdg) WITH 'Error updating' iv_name INTO zcl_messages=>sv_message_text.

        RAISE EXCEPTION TYPE zcx_mdg

          EXPORTING

            mo_messages = NEW zcl_messages( )->set_system_message( ).

    ENDTRY.

  ENDMETHOD.

  METHOD copy_to.



    copy_decision_table( iv_name = |DT_USER_AGT_GRP_{ iv_crtype }|

                         it_decision_tab =  mt_user_agent ).



    copy_decision_table( iv_name = |DT_NON_USER_AGT_GRP_{ iv_crtype }|

                         it_decision_tab =  mt_non_user_agent ).



    copy_decision_table( iv_name = |DT_SINGLE_VAL_{ iv_crtype }|

                         it_decision_tab =  mt_single_value ).



  ENDMETHOD.

ENDCLASS.

Execution

Below is a sample code for using the class above.

START-OF-SELECTION.

  TRY.

      DATA(o_brf) = NEW lcl_brf( ).



      o_brf->get_reference_decision_tab( 'ZCR1' ).

      o_brf->copy_to( 'ZCR2' ).

      o_brf->copy_to( 'ZCR3' ).

    CATCH /gerp/cx_mdg INTO DATA(o_error).

      o_error->mo_messages->show_as_log( ).

  ENDTRY.

With that utility, I can update one workflow and then use the utility to copy to all the others.

This approach can be used in decision tables outside of MDG, but note that (1) the structure has to be the same and (2) you have to identify the application name is those situations as the Decision Table Name is not unique.

[BRF+ New Output Management]: Use DDIC Interface based Regular Custom Adobe Form – Handle ‘Spool request could not be found APOC_OR_MESSAGES 145’

2023-03-10T22:34:24+01:00

INTRODUCTION:

For the last few weeks, I have been working on a requirement that required a custom Adobe form for a standard GR label through NACE but later, we had to opt for new BRF+ O/P management. The ideal approach is to use fragmented Adobe form, but the number of fields was not there in the standard service interface. So, we opted for the DDIC interface option available in ‘Assign Form Templates’.

Challenge: To achieve this requirement, I had faced a couple of challenges:

Spool request could not be found - APOC_OR_MESSAGES (145): Discussed in this blog.
Dump - /BOBF/CX_FRW_FATAL – CLASS CL_APOC_OR_A_ITEM_GET_DOCUMENT: Create a Z* Driver program for the form individually and check the issue there – for my case, ADS Configuration was the issue, handled by me and basis tech guy
Bar code center alignment: Centre Alignment of BARCODE blog.

In this blog post we will cover the steps to print GR Label and handle Spool request could not be found - APOC_OR_MESSAGES (145).

MAIN CONTENT:

Firstly, get the name of the standard program – subroutine (Form routine) that you would be triggered in the back-end from the business process. You can later, choose any other sub-routine as well, if that one has better parameters as per your requirement. Make sure the sub-routine you are choosing has *PDF or ADOBE* naming pattern to have the FP_JOB_OPEN/CLOSE else you must manually change the printout subroutine.

** In my case, I have used Program – SAPM07DR, Routine - ENTRY_WE03_PDF.

2. Create an executable report ZAB_IM_SAPM07DR replicating subroutine-pool SAPM07DR, Includes ZIN_IM_M07DRTOP, ZIN_IM_M07DRSON_PDF from M07DRTOP, M07DRSON_PDF resp. and replace the std. includes with them in program ZAB_IM_SAPM07DR.

3. Go to SFP, create a DDIC interface as per the parameters exported in the sub-routine, handle the required processing logic, and create the required layout in ADOBE form to the interface.

4. Point of solution: In the subroutine, FORM_OPEN_PDF, just before FP_JOB_OPEN – handle the output parameters as below, as per SAP KBA 3016791 - Error 'Spool request could not be found.':

  gs_outputparams-getpdf   = abap_false.
  gs_outputparams-reqnew   = abap_true.
  gs_outputparams-covtitle = nast-tdcovtitle.
  gs_outputparams-nodialog = abap_true.
  gs_outputparams-preview  = abap_false.

Activate the program.

5. Share the name to functional or manage it in SPRO.

Application Area: 'Cross-Application Components'

Sub Application Area: 'Output Control'

Select the configuration step 'Assign Form Templates' (SSCUI 102313)

Maintain

(Don’t forget to transport the config data with customizing transport in testing client – Tcode SCC1).

Now functional will go to transaction OPD or below process, that will trigger Fiori launchpad.

And edit the entry for the configured form under ‘Form Template’ for Rules for ‘GOODS_MOVEMENT’ replacing the standard form and activate it.

Outcome:

Now create a document in the test client for Material document and go to MIGO, enter MBLNR -> output-> Display Outputs.

Enter a row with Preparation status & and details as per configuration.

Select the row and click Display document (pdf icon)

GR_LABEL - Z*FORM*

Reference links:

2736938 - Settings for processing program and form templates in billing document in new output management

2294198 - SAP S/4HANA output control - customized forms

2608890 - Standard S/4HANA Output Control settings for Purchasing (output forms and processing programs)

Topic page:

ABAP Topic: https://community.sap.com/topics/abap,

post and answer questions https://answers.sap.com/tags/833755570260738661924709785639136.

Follow me at Robin Thakral

IDOC Configuration for Sales Order via New Output Management

2023-05-16T10:08:34+02:00

In this blog I would like to share my knowledge and learning for triggering IDOCs for Sales Order using BRF+ OPD concept.

The document will focus on following points

Configuring Output type

Configuring Output type for Sales Order in OPD

Required Custom Code Changes

Mandatory system configuration

Debugging hints

Configuration steps for creating Z Output type

SPRO->Cross-Application Components->Output Control

Define Output Type

2.Assign Output Channels

Configuration steps for Output Type via transaction code OPD.

1. Run transaction OPD, Select Determination Step as Output Type

2. Determination Step: Receiver

3. Determination Step: Channel

4. Determination step: Output Relevance

Output Relevance is based on the business requirement, but entry must exist in this step.

If there is no specific business requirement, we can create it with generic condition like Overall Header = C (as mentioned in above screenshot).

Output type is attached to Sales Order once above steps are complete.

To enable new output management for sales order we need to activate it using following SPRO steps

SPRO->Cross-Application Components->Output Control->Manage Application Object Type Activation

Mark status as Application Active for Sales Document.

Custom Code Changes

At the time of defining Output Type, we can add a Z callback class. Create a Class by coyping standard class CL_SD_SLS_OUTPUT and add same under Z Output Type

In case of IDOC we need to modify method GET_LEGACY_DATA of class ZCL_CL_SD_SLS_OUTPUT

ET_LEGACY_DATA should be populated with Z output type.

Mandatory System Configuration

Customizing for SOMU

Check if the Content Repository "SOMU_DB" exists in transaction OAC0.
The recommendation is the following:
Description: Output Management DB Storage
Storage type: SAP System Database
Storage subtype: Normal
Version: 0047
Content table: SFORM_A_STORAGE

Check if the Content Repository "SOMU_DB" is assigned to Category "SOMU" in transaction OACT.

Refer Note 2279725 for more details.

2. Open transaction SBGRFCCONF to check if supervisor destination and Inbound destination is defined or not.

Supervisor destination should exist in SM59.

For detailed steps follow Note 2292571.

Once above steps are followed, it will trigger IDOC for sales order.

Debugging Hints

Following are the debugging points which can be used if trigger output does not work for any reason

First and easiest: Breakpoint at constructor in call back class.

2. Breakpoint at function module APOC_OR_ISSUE_OUTPUT. This will trigger in update task so update breakpoint should be activated first.

I have tried covering all the issues which I have encountered during my Research. Hope it is helpful for you. Happy Learning!!

Syniti RDG provides a new functionality-Importing of UI Field Property Rules by Change Request Step from one change request to another change request.

2023-09-07T11:04:10+02:00

Concento Rapid Data Governance(RDG) is a a SAP endorsed app based on SAP Master Data Governance. SAP Master Data Governance is a powerful solution to improve the quality and consistency of information across organizations by consolidating and centrally governing master data.

This blog illustrates a copy feature in RDG. It involves multiple transactions and steps in SAP application for creating UI field rules in BRF+ and is considered as a complex process. With this feature, we can copy the field property rules from one change request to another change request type by change request step in a single screen.

Below are the steps to copy the field property rules from one change request to another change request by CR step in RDG:

In the main RDG menu, select “Field Property Configuration.”

Users must select the change request type to copy the field property rules from the existing change request type.

Select the “By CR Step Type” option in Select Rule Type dropdown.

After selecting the change request type, the user must select the CR step to copy the rules.

After selecting the CR Step, click on “Import” button to start the process of copying the rules.

After clicking on import button, select the source change request, source change request step and the entities and click on “Save”.

Select the suitable package.

The UI property rules are copied from source cr to target cr .

The copied rule is generated in BRF+ automatically when we do the above process in RDG UI.

Concento RDG is a certified SAP BTP solution and is available on SAP App Store

Your opinions and feedback are highly appreciated, and feel free to post them in the comments section.

Please follow and read more interesting blogs at https://blogs.sap.com

You can also find and post questions about the product here: SAP Master Data Governance Community

MDG-S: MDG rule-based workflow

2023-10-01T11:29:15+02:00

Introduction:

This blog post will describe in detail how to trigger email using using Rule Base Workflow(WS60800086)

Requirement:

Bank data in vendor master data when changed (Account no., IBAN, A/C holder name, etc), or deleted, an email notification to be triggered to the vendor

Email available in the general section of vendor (LFA1) to be used to send the notification.

Email to be triggered to the SPU owners.

Solution:

For this requirement, I have enhanced the existing sub-workflow WS90100004 using transaction SWDD and the step already defined where BRFplus workflow (WS60800086) to call the sub-workflow. I did not pursue the BADI approach. Set up is already there I just enhance the existing subworkflow WS90100004

Steps to be followed:

Tcode: MDGIMG

Based on the CR type check the decision table

Single Value Decision Table

Non-User Agent Decision Table

Sub-workflow WS90100004 Overview

Enhance Subworkflow WS90100004

This WS90100004 workflow has 2 steps added:
- Check for CR Status – Condition steps: Check the status of the CR if status equal = 'AM' (changed by vendor MD team) then trigger email to Vendor and SPU owners
- NOTIFICATION OF BANK ACCOUNT CHANGE – Activity steps: All the ABAP logic ( (Email recipient and email content) placed here in the class /BPMDG/SU_CL_BANK_CHANG_NOTIF and method SEND_NOTIF_BANK_ACCOUNT_CHANGE.
- Workflow End

Created 1 Workflow containers: CR_STATUS

I hope this blog was useful for those of you trying to get email notification configured for MDG.

Syniti RDG provides a new functionality-copying the business rules from one change request to another change request

2024-01-15T16:04:05+01:00

Concento Rapid Data Governance(RDG) is a SAP endorsed app based on Data Governance. It also helps business users to automate many of important steps to implement the MDG.

For example, the user can create different types of business rules effectively to the respective change request in less amount of time. RDG provides a user-friendly interface where all its functionalities would be in a single screen.

In traditional SAP MDG system, the user with low technical knowledge is considered as a high technical task of copying the business rules from one change request to another change request type. RDG is now capable to copy different types of rules in easier way and in less amount of time effectively.

Below are the additional steps to copy the business rules from one change request to another change request in RDG:

In the main RDG menu, select “Manage Business Rules”.

Select change request type to which user want to copy the business rules from existing change request type.

After selecting the change request type, click on import button to copy the rules.

After selecting the existing change request type, the different types of business rules present in that change request can be seen. Then we have to select the rules which we want to copy to the current change request type and click on save button.

A status window will be popped up by displaying the status of business rules.

The rules which we selected are copied from existing change request to current change request and got generated automatically in Business Rule Framework Plus to respective change request type.

Below are the some standard screens related to brf+ where the copied rules generated automatically.

Concento RDG is certified SAP BTP solution and is available on SAP App Store

MDG DQM: Troubleshooting DQM validation rules for central governance - Product Master S/4 HANA

2024-01-30T16:03:50.529000+01:00

Hi All,

Season's greetings!!

In 2023 I focussed on sharing my insights on the data quality management module of SAP Master Data Governance through multiple blogs( "as if it was used be called in the old website"). If you have missed some of these then here is a quick link to all of the content published earlier.

As I start 2024, I have delved a little deeper into this topic and with the new community platform launched, I was excited to share some of the insights from SAP Master Data Governance data quality management on this new platform.

So without further Adieu let's dive in !!

INTRODUCTION

In this blog post we will cover a few steps on how we can troubleshoot the BRF+ validations which is the underlying framework for MDG DQM. This module of MDG is still evolving rapidly as we move towards cloud first and a clean core approach. As MDG developers we are still pretty comfortable with classical BADI's for doing validations and we all know it's quite easy to troubleshoot the rules. But when it comes to DQM we might wonder how do my rules get called? how can i troubleshoot my rules if they are not working as expected?

So let's see how we can troubleshoot the rules.

MAIN CONTENT

DQM rules will be triggered when we click the check button on our MDG UI.
Once click on check the MDQ adapter CL_MDQ_COMMON_ADAPTER_PROD class will be called which will in turn call the MDQ rule engine class CL_MDQ_RULE_ENGINE_CHECK.
This rule engine check method will internally call many other methods and one of the methods which gets called is CL_MDQ_BRFPLUS_HANDLER, this class is responsible for executing the BRF+ functions by calling other standard methods. In this class, we can put a breakpoint in the execute_function method.
Inside execute_function we will find an FDT method which processes the BRF+ function.
Inside the process method, we will get the class name associated with the BRF function ID.
Using this class name we will call the process_dynamic method of the FDT.
Inside this method look for the process_pure method which will have the entire BRF+ generated code for a rule which you have created in DQM.

By following these steps you can easily navigate through the DQM validation rule framework troubleshoot your rules and make sure they are working perfectly fine.

Scenarios which need troubleshooting:

1. You import your rule from one system to another, the rule is approved and enabled for check-in change requests but still doesn't work.

2. You modified your BRF+ logic as per your requirements after the initial build, however, the latest rules don't reflect this.

System details:

S/4 HANA 2023 FPS00.

CONCLUSION

By following the above steps you will be easily able to troubleshoot DQM rules for SAP Master Data Governance central governance.

Hope you find this information useful.

Regards

Anirban

Business Rule Framework Plus(BRF+)

2024-04-16T12:38:55.042000+02:00

What is BRF Plus? Why we need to use BRF+ ?

There will always be some amount of custom business logic available in the SAP system, even if we strive to minimize customization. Such ABAP-based customization must be handled carefully in order to prevent duplication of business logic and to keep it in line with other functional areas. Herein lies the value of SAP Business Rules Framework Plus (BRF Plus), a feature that enables centralized and reusable management of all custom business logic.

In general, BRF Plus features can be accessed on any SAP NetWeaver-based system with the relevant enhancement pack installed.

Both technical users (programmers, system administrators) and business users who manage operational business processes (like bidding, procurement, tax form validation, etc.) can benefit from BRF Plus's unified modeling and run-time environment for business rules.

The application programming interface and user interface that BRF+, or Business Rule Framework Plus, offers is extensive for defining business rules. We can define business rules with it without having to write ABAP code.

Application : In BRF+, to start anything first we must have to create the application.

Type of Storage Types :

Storage Type	Client	Transport Request	Cross-Application Usage
System	Client-Independent	Transportable or Local	Can use system objects.
Customizing	Client-Dependent	Transportable or Local	Can use system and customizing objects
Master Data	Client-Dependent	Local	Can use system, customizing, and master data objects

Data Objects: Describes data types of the variable. They are the data carriers helping in signature or context of a function, variables in a rule or rulesets, building blocks for Decision tables, Etc. You can create data objects by defining attributes like element type, length, decimals or you can directly bind to existing DDIC elements.

Expressions: Expressions are the computational units with well-defined logic. Usually, expressions are self-sustained and process the user input and gives result back to the caller.

Rules: Rule is a central entity in BRF+ which builds the business logic. Evaluation of rule gives you the decision for the question in context

Rule sets: Simply, collection of rules. Each rule set can be assigned to exactly one function. Priority can be set at rule set level for defining the order of execution.

To Create Application : BRF+ or BRFPLUS is the transaction code to access the application.

Next, we click the Create Application Pushbutton. Below Pop-up will opened up and enter the required fields.Click on Create and Navigate To Object after filling out Name, Short Text, Text, and Development Package for Software Component. Another option is to store in the Temporary($tmp) Package.
Next, we'll press the "Save & Activate" button.

Next, within this application, we will talk about the following elements.
1. Create an element in the data object.
2. Create a structure in the data object.
3. Make a Table Data Object
4. Produce a Decision Table Expression

There are 3 ways to bind the data object in Binding Type :

Create an element in the data object : The following steps are shown in the figure below after you right-click on the application: After completing all the required fields, we will click the designated button.

There are three options under this option, which is called Binding type.
Bind to DDIC Element: Select a DDIC Element that shares your attributes.

Bind to an Existing BRF+ Element: Select an Existing BRF+ Element that possesses the same attributes.

No Binding: Maintain the details freely.
Therefore, in this case, if we select any of the first two options 1 or 2 Name, Text, Element Length, and Element Type will be automatically filled in from the DDIC element or an already-existing BRF+ element.
However, if we select the No Binding option, we will have to enter all necessary information, including the element name, text, short text, element length, and element type.

After entered all the required fields, click on Create and Navigate To Object button and then click Save & Activate buttons to activate it.

Structure Creation: The same application should be used to create the structure.
It is not necessary to build a structure if our result contains just one column. There is also no need to create a structure if the output for a single condition is a single row. If more than one column appears in our result, we should make a structure with all of those columns. Additionally, a structure must be shown if the output consists of multiple rows. The generated structure must be used to create a table in order to produce multiple rows as output.

To Create a Structure, Select our application and follow the instructions shown in the figure below After that, we must complete the required fields to create the structure. However, before that once more, there is a choice named Binding Type, which has the following options:-

a) Bind to Structure Type (DDIC)
b) No Binding
c) Binding to CDS View: Not to be used

For Option a & c, The required fields (Name, Short Text, Text) will automatically be filled in from the DDIC structure or the CDS View.
However, if we select option b, which is No Binding, we will have to manually fill in every required field.

Once all of these have been filled out, click Create And Navigate To Object, and lastly Save and Activate this structure.

Table Creation: In order to have multiple result rows based on a single condition in our decision table, we can create a table in the same application. Therefore, table creation is necessary in our case.
Select our application, then follow the instructions shown in the figure below.After that, fill out the fields required to create the table. We must first verify the Binding Type.
There are two options for creating tables in Binding Type:
a) No Binding
b) Binding to Table Type (DDIC)

If we select option b "Binding to Table Type (DDIC)" All required fields (Name, Short Text, Text, Table Line Type) from the DDIC Table Type are automatically filled.
If we select option a "No Binding" then it will have to manually fill out all required fields.
Therefore, choose Table line from the application in order to display Multiple Rows. Once all required fields have been filled out, click Create And Navigate To Object, and then save and activate this table.

Decision Table Creation :
The next important step is to construct our Decision Table using our application as well. Select the Decision Table and follow the steps outlined in the figure below.

Once Name, Short Text, and Text are entered, click on the Highlighted button.In the table settings, we can do the below enablement.

There is a checkbox labeled "Return all matches found" in Settings. If we don't select this option, even though multiple rows may exist based on the same condition, only one row will ever display for that condition.
Select the Result Data Object located in the same application as our recently created Table. Next, include the Condition Column.
Select the Application Data Element's Column:

To Select an object as the Condition Column, select it and then click OK. Declare a field as required in the condition column, indicating which column's value will be used to retrieve the value of the result columns.
Thus, the Condition Column's input needs to be required and selected columns comes as result.Select these components from the table.Click OK once all of the table's objects have been selected.Click the OK button to proceed. All of the selected columns now appear as Result Columns.
Save and Activate all Decision Table modifications after adding Table Contents. Now update this Decision Table with the Table Contents and Next, select "Start Simulation" to see if our decision table functions.

After entering the program name, select Execute. Will get the matched records as output.

Use of Decision Table in ABAP Program: In order to obtain the required output rows, we must now use our Decision Table in an ABAP program and pass the condition column value from the program.
In the same application, a function must be created for that.

Function Creation: To begin, right-click on the application, then follow the instructions in the figure below.

After entering the Name, Short Text, and text, press the Create and Navigate To Object button.
Next, fill in the remaining necessary fields, as indicated in the figure belowSelect our created Decision Table in Expression and Mode as Functional Mode. Next, select the Data Element for the Condition Column and the Table of Result Columns after adding the Context from existing Data Object. Next, select our result columns, which are tables from the same application that we created, under Result Data Object then save and activate every modification.

After that, we must select Create Code Template, copy the sample code, and utilize it in our ABAP programAt last, we need to save and apply all of the modifications. Following the use of this template in an ABAP program, all of the resultant columns and expected result values should appear in the program.

Rules and RuleSets : It contains set of rules which can be executed as soon as our BRF+ application Function is getting executed. Rules must be contained in the ruleset, as expressions (IF-THEN-ELSE logic). If-THEN rules are another name for plain rules.
A ruleset is an assemblage of rules. Select Event Mode by default. The Assign Ruleset option is under Event Mode. The function must then be given a ruleset. Please select the "Create Ruleset" button after selecting the "Assigned Rulesets" tab in the screenshot above. After giving the new ruleset a name, the screen below will appear. Following the creation of the ruleset, fill in the Name, Short Text, and Text fields. Then, click the Create and Navigate To Object button below.

Save and Activate the Ruleset function.
Next, utilize this ruleset in ABAP code from the function using the Code Generation Template.

Decision Tree: A binary tree of expressions can be defined using a decision tree expression. Condition Nodes are non-leaf nodes. The result is a Boolean. Left & Right nodes will move forward in accordance with the outcome. When a leaf node is reached, the designated expression is executed, and the result of the entire expression is returned as the corresponding result. A decision tree has two nodes at all times: left and right. Every node has decisions that are True (Yes) or False (No). Depending on that new branches (nodes) will proceed.

We can define business rules using the BRF+ interface without having to write ABAP code. These generated business rules can be used as substitution/validation rules or integrated into other SAP programs.

Use cases of BRF+ that can be used into S4HANA:
Output management for Billing and Purchasing – Output determination (SAP S/4HANA).
Integration with IMG transaction.
SAP business Workflows.
Cloud based Environment.

Conclusion on BRF+ :

It enables us to represent rules in an understandable manner and apply them again in various contexts.
BRF+ eliminates the need to create and maintain custom tables for validation. It also does away with the traditional developer approach of hardcoding values.
In essence, BRF+ is used to make decisions, and decision input and output values are kept up to date in Decision Tables, which have sophisticated validation features.

Roles that are required
SAP_BC_FDT_ADMINISTRATOR
WD Configuration :
/sap/bc/webdynpro/sap/fdt_wd_workbench
/sap/bc/webdynpro/sap/fdt_wd_object_manager
/sap/bc/webdynpro/sap/fdt_wd_catalog_browser

Application Exit Class in BRF Plus(BRF+)

2024-05-30T10:31:30.139000+02:00

An application exit class in BRF+ (Business Rule Framework Plus) is a custom ABAP class that we can create and use to add custom logic to expand BRF+'s functionality. Using this class, you can add custom methods that can be called when BRF+ rules are being executed. This way, we can handle particular business needs that aren't addressed by the standard BRF+ functionality and also helps to maintain the entries as system specific entries similar like SM30 t-code.

To achieve, we need to create a class by using SE24 t-code and add interface IF_FDT_APPLICATION_SETTINGS in the class.

After adding the interface IF_FDT_APPLICATION_SETTINGS, below methods will be added.

Execute the required procedures from the interface. The custom logic you wish to use with the BRF+ framework will be contained in these methods.

Implement the custom logic :

Within the ABAP class's methods, we can write our own logic. This could include complicated computations, data validation, or any other rules unique to your business.

In my scenario, BRF+ Decision table should work like SM30 in higher systems like Quality and Production. To do, we have written logic in AUTHORITY_CHECK method in the global class which we created.

EV_SKIP_CHECK -> flag if set to TRUE, will skip standard authorization checks and will consider custom authorization check.
EV_PASSED -> Indication of whether the check was passed successfully

In the constructor class, pass gv_authority_check equal to abap_true.

To register the global class in BRF+ transaction, open BRF+ and double click on the Application component.

In this manner, application exits in a non-development or production environment can be used for decision table maintenance. I hope this blog was also helpful in providing information about BRFPlus application exits.

Conclusion :

BRF+'s application exit classes offer an effective way to increase the platform's built-in capabilities. You can modify the BRF+ framework to satisfy complex business requirements by adding additional logic to the rule processing flow through the creation of unique ABAP classes and the implementation of particular interfaces.

Output management in S/4HANA

2024-07-17T17:21:59.714000+02:00

Output Management in S/4HANA

Introduction to output management

After working with many clients in different fields, I've noticed that most businesses struggle with output management. Each client has their own idea of what output means, whether it's PDF documents, forms, emails, or iDocs. While these views are somewhat correct, I think output management is about effectively communicating with customers or vendors using the right channels and documents.

When we talk about output management, I see it as combining "output" (like print, email, iDoc) with "management" (how we set it up to reuse the functionality). Output management in SAP S/4HANA is a big improvement in how businesses generate and distribute documents. This new framework solves the complexities and inefficiencies of the many old output solutions in previous SAP systems. This blog will mostly cover the output management features in on-premises S/4HANA.

Legacy Output Solutions

Historically, SAP provided several output management tools tailored to specific business areas:

SD Output Control (NAST): Used primarily for sales and distribution processes.
FI Correspondence: Handles financial document communications.
FI-CA Print Workbench: Manages print jobs for contract accounts receivable and payable.
CRM Post-Processing Framework (PPF): Deals with post-processing activities in customer relationship management.

While these tools were effective, they required customers to learn and maintain distinct frameworks for each business area. This led to a high total cost of ownership (TCO) and varied user experiences.

What is NAST

NAST is a central component in SAP for managing and controlling the output of documents. It is part of the SAP Output Control framework and is used primarily in the Sales and Distribution (SD) module, but its functionality extends to other areas such as Materials Management (MM) and Financial Accounting (FI).

Key features of NAST include:

Message control
Output type
Condition record
Processing routine
Transmission medium
Scheduling

NAST operates using the condition technique, which is the traditional method of working in SAP.

The Need for a Unified Solution

In SAP S/4HANA projects, the fragmentation of output management tools presented several challenges:

Complexity: Customers had to navigate and master different frameworks for different tasks.
Maintenance: Each framework required separate setup and ongoing maintenance.
User Experience: Disparate tools resulted in inconsistent user experiences across the SAP ecosystem.

What is Output Management in S/4HANA?

Output Management in SAP S/4HANA is a comprehensive framework designed to streamline the creation, formatting, and distribution of business documents. It modernizes and centralizes outdated output mechanisms, effectively meeting the diverse needs of various business processes.

Key features of S/4HANA Output Management include:

Centralized Configuration: Offers a single point of configuration for all output types, reducing complexity and easing maintenance. This common setup point can be used across different modules.
Flexibility and Scalability: Supports various output channels and formats, making it adaptable to diverse business needs and scalable for future growth.
Enhanced User Experience: Provides consistent and intuitive user interfaces, improving efficiency and satisfaction across different modules.
Simplified Maintenance: Eliminates the need for complex master data maintenance and extensive cutover activities.
Advanced Output Channels: Supports modern output channels like email, print, fax, and electronic data interchange (EDI), in addition to traditional methods.
Improved Template Management: Utilizes advanced tools for designing and managing document templates, such as Adobe Forms, enhancing document consistency and branding.

Different between NAST and Output management in S/4HAN

NAST (Legacy Output Control)

NAST is the traditional output control functionality used in earlier versions of SAP, such as SAP ECC. It manages the output of business documents through various channels like print, email, fax, and EDI. Key characteristics of NAST include:

Decentralized Configuration: Each application module (e.g., SD, MM, FI) has its own configuration, leading to complexity and redundancy.
Limited Flexibility: Customization and enhancement of output processes require significant effort and often involve custom ABAP development.
Condition Records: Utilizes condition records to determine when and how outputs are triggered.
Processing Routines: Depends on traditional forms like SAP script and Smart Forms for document formatting.
Separate Handling: Each business area (e.g., sales orders, invoices) has its own output determination and processing logic
It also covers Multiple Output Mediums and Error Handling and Monitoring

Output Management in SAP S/4HANA

The new Output Management framework in SAP S/4HANA is designed to overcome the limitations of NAST and provide a more streamlined and efficient approach. Its key features include:

Centralized Configuration: Provides a unified setup for all output types, reducing complexity and maintenance efforts.
Enhanced Flexibility: Supports various output channels and formats with easier customization options.
Advanced Template Management: Uses Adobe Forms for designing and managing document templates, offering more sophisticated formatting and branding capabilities.
Output Parameter Determination: Utilizes a modern method for determining output parameters based on business context, simplifying the output determination process.
Improved User Experience: Consistent and user-friendly interfaces across different modules enhance operational efficiency.
Integration: Seamlessly integrates with other SAP S/4HANA components and external systems, improving overall document management and processing.

Key Differences

Feature	NAST (Legacy Output Control)	Output Management in SAP S/4HANA
Configuration	Decentralized, specific to each module	Centralized, unified for all output types
Flexibility	Limited, requires custom ABAP development	Enhanced, easier customization
Forms and Templates	SAP script, Smart Forms	Adobe Forms
Output Parameter Determination	Condition records	Modern, context-based parameter determination
User Experience	Inconsistent across modules	Consistent and user-friendly
Integration	Separate handling for each business area	Seamless integration with S/4HANA components
Maintenance	Complex, higher total cost of ownership (TCO)	Simplified, lower TCO

Advantages and features of Output management

SAP S/4 HANA Output Management has the below features

Operates seamlessly in both cloud and on-premises environments.
Offers a unified solution for all output related tasks across the product and modules
Reduce master data maintenance and relatively less time consuming for activation
Supports standard extensibility for configuration documents
Offers central monitoring tools for key users, enhancing oversight and control.

Based on Business Rule Framework (BRF), offering greater flexibility in managing output processes.

How it works?

For determining output types in transactions, we can utilize Output Parameter Determination (OPD). Maintenance of OPD can function similarly to master data or be set up via transport management. I recommend using OPD as a client-specific change. Using transports can lead to confusion, especially if other rollouts are occurring simultaneously.

Prerequisites –

There are few back-end changes you need to do it before maintenance of OPD setup.

Check if your application object type is active
Check if your Output type is available and if you want to use your own output then create new one by doing copy of standard output type.
Assign channel to your Output type.
Assign Form Template to Output Type
Assign Email template to output type.

To use Output management, we need to activate the required object and if we activate Output management then system will redirect output always to Output management and not to NAST.

Main parameters in OPD (Output Parameter Determination)

Below are the key parameters,

Output management is BRF based functionality which can be setup by using below 7 steps in the SAP using OPD.

Let’s check in the system –

OPD (Output parameter determination) screen

There are multiple steps (as per above screenshot) which should be maintained to determine output in billing document as per this example, here we will take billing output type as an example.

1. Output Type –

This step begins by deciding whether to process the output immediately or later via a job. As shown below, for the combination of billing type F2 and output type BILLING_DOCUMENT, we can choose to process the output type immediately or through a background job (VF31F) at the time of billing document creation. Additionally, in the billing document, we can manually add the output type and set the dispatch time manually.

2. Receiver –

In this step, we can determine the output type for a specific role (partner function). If we have four lines with different roles and want to consider only the first two, we will mark the Exclusive indicator 'X' for the second line. This way, the system will only consider the first two entries and ignore any entries after the second line.

3. Channel –

In this stage, the 'Channel' will be defined. The channel could be IDoc, Print, Email, etc. This stage will also include an exclusive indicator.

For instance, if the exclusive indicator 'X' is set for IDoc as shown below, the system will not search for or determine the PRINT and EMAIL channels.

4. Printer setting –

In this phase, we can specify the printer and the number of copies to be printed after creating the document. Before setting up the printer in this phase, it is necessary to install the printer in SAP.

Additionally, please be aware that the new output management system supports Printer Spool Devices limited to PDF device types only (PDFUC: PDF Unicode 1.3 / PDF1: PDF ISO Latin1 4.60+).

This restriction is detailed under the Symptoms section in note 268480 and SAP Note. 2294198

5. Email setting –

In this phase, the sender's email ID can be configured. This means that when an email is sent to the customer, the sender's email will be set up here, and the recipient's email will be the customer's email address.

Additionally, we can also establish the email template in this phase. An email template specifies the format and content that the customer will receive from us via email.

6. Email recipient –

The email address (recipient address) retrieved in the billing document is sourced from BP master data or determined through this step.

If you have configured an email address here, this setting takes precedence.

Multiple email addresses can be maintained in this determination step by separating them with ';'.
You can also define the email type code with TO, CC, BCC.

7. Form Template –

This step is intended for maintaining the form template used for each output. Ensure that the form template maintained here has been assigned to the output type in SPRO -> Cross-Application Components -> Output Control -> Assign Form Templates.

If the language is not specified in OPD, it will be retrieved from the customer master data of the output recipient.

8. Output Relevance –

This step verifies if the output item is flagged as relevant for output.

If the relevance indicator is not set to 'X - true', the output item determined in the billing document will not be considered relevant for output.

Consequently, its status will remain 'In preparation' in the billing document under the output section.

OPD functionalities –

Adding extra predefined standard fields

Adding new columns or fields: OPD provides default fields that cover all necessary steps we've discussed. However, often after client discussions, we realize additional parameters are needed to define our objects in OPD differently.

In OPD, there are additional fields available that we can add as columns on the main OPD screen. These can then be utilized in determination combinations as needed.

To do this, navigate to Edit -> Table settings -> Insert column -> From context data object -> Search.

Click on search

Following this step, a list of standard additional fields will be available for us to add and utilize in OPD. If the required field is still not available, we can proceed with an enhancement to add the necessary field to this list. This process requires the involvement of an ABAP specialist.

Simulation functionality

Having reviewed all seven steps, we can use them to determine the output type in the transaction.

To preview the output in simulation mode, use the highlighted option below. This allows us to simulate the output effectively.

Key points and learnings –

Pros

As OPD is BRF based functionality, we can import and export data using predefined template.
New column (fields) can be added and can be removed as per requirement.
SAP S/4HANA output management is recommended but not mandatory.
The scope of SAP S/4HANA output management is not comparable with the scope of NAST.
SAP S/4HANA output control is not designed to completely replace NAST.
Innovations will only be made in the new framework (SAP S/4HANA output management)

Cons –

It will only cover the output part of NAST (print, email, partly EDI).
The rest – like system integration, workflow, or special function – is not (and will not be) in the scope of SAP S/4HANA output control.
Customers will lose all NAST features when switching to SAP S/4HANA Output Control. Using S/4HANA Output Control for applications that previously relied on NAST is only advisable in exceptional cases
iDocs are not fully supported by the new output management. There are few restrictions as compared to NAST.
NO ALE is supported in Output management.
No tool is available for conversion from NAST to Output management.

Reference –

https://community.sap.com/t5/enterprise-resource-planning-blogs-by-sap/output-management-in-sap-s-4hana/ba-p/13492419

https://help.sap.com/docs/SAP_S4HANA_CLOUD/a630d57fc5004c6383e7a81efee7a8bb/d7bd4b5d70d94f09bcf99b221a7a1688.html

Check out SAP notes related to the topic -

SAP Note 2292539 - SAP S/4HANA output control – configuration
2843926 - It is not possible to activate rules in App 'Output Parameter Determination' - SAP S/4HANA Cloud
SAP Note 2228611 –Output Management in S/4HANA
SAP Note 2248229 –SAP S/4HANA output control - download XML file
SAP Note 2292571 –SAP S/4HANA output control -technical setup
SAP Note 2292646 –SAP S/4HANA output control -form templates with fragments
SAP Note 2292681 –SAP S/4HANA output control –master form templates
SAP Note 2294198 –SAP S/4HANA output control -customized forms
SAP Note 2367080 –SAP S/4HANA output control -customized master forms

Leveraging BRF+ Decision Tables for Flexible Route Determination in SAP S4HANA

2024-08-26T12:24:49.653000+02:00

Use Case-

Discover how to streamline your sales order and stock transfer order (STO) processes in SAP S4HANA by replacing standard route determination with powerful BRF+ decision tables. This innovative approach empowers your business to integrate seamlessly with Excel, enabling efficient import and export of route data without IT intervention. Learn how to enhance flexibility, reduce manual effort, and gain valuable insights into your supply chain operations.

Perquisites:

Basic knowledge on ABAP concepts
Basic knowledge on BRF+ framework in S4 HANA 1709 and above
Knowledge on Route determination rules

What is BRF+

BRF+ is an ABAP based framework and part of the NetWeaver stack. BRF+ stands for Business Rule Framework Plus and it provides a comprehensive application programming interface and user interface for defining business rules. It enables you to define business rules without the need of wiring ABAP code. The generated Business Rules can be incorporated into other SAP programs or Substitution/Validation rules.

Services for BRF+ Activation in S4 HANA

In order to use BRF+ the following services need to be activated through transaction SICF:

/SAP/BC/WEBDYNPRO/SAP/FDT_WD_WORKBENCH

/SAP/BC/WEBDYNPRO/SAP/FDT_WD_OBJECT_MANAGER

–/SAP/BC/WEBDYNPRO/SAP/FDT_WD_CATALOG_BROWSER

You can launch BRF+ UI afterwards by entering t-code BRF+ or BRFplus. Further technical and functional detail about BRF+ is available at SAP help via this link.

Functional Configuration using BRF+

The steps in the BRF+ UI will consist of the follow steps:

Application creation- Create an Application using t-code BRF+.
Data Object Creation- Data Object Creation consists of all the variables used , which will be used for processing. These variables are basically input data to the BRF+ to process and to generate the output/result. In this use Case- We need to add relevant for Route determination- like Shipping point(TVST/Shipping condition(VSBED)/Country(LAND1)/Route(ROUTE)- Our Decision.
Function Creation- Next step , is to create Functions which is the core component - where the actual processing of the functionality gets executed.
Ruleset Creation- Inside the Functions we have a Rule Set , which is basically a container which holds all Set of Rules and these Rules are processed based on the decision tables.
Decision Table Creation- Decision tables are going to hold the data which consists of all possible Inputs & corresponding Output values- in this case our Decision is always “ROUTE”. Basically , the Data Objects import parameters validate against the Decision Tables and these Decision table will generate the outcome/result.

Simulation of the Business Rule- It is possible and recommended to simulate the Rule Set to see if your function is working fine. Go to the Function and navigate to the simulation screen

Now the Question is?- how to call this decision tables in SAP Sales order creation in place of Standard Route Determination.?In the function component . you have an option called Create Code Template - after selecting this , it shows the generated code template. The generated code is the one which you need to place in the EXIT_SAPL0VRF_001, Include ZXV00U01- Customer specific Route determination

Enhanced Efficiency and Flexibility

Direct Data Access: View and modify decision table data directly from your preferred environment (development,/quality, or production) without requiring BRF+ API logins.
Simplified : Streamline the process of creating and moving transport requests for new rule updates, saving time and effort.
Version Comparison: Gain a clear understanding of rule changes with the version comparison feature, facilitating effective tracking and analysis.
Granular Access Control: Implement robust security measures by defining specific authority checks and roles to control access to BRF+ decision tables.
Comprehensive Change History: Maintain a detailed record of rule modifications with the change log history feature, providing valuable reference

Looking to implement customer-specific route determination in SAP S4HANA without extensive coding? This use case demonstrates how BRF+ decision tables can provide a flexible and efficient solution. By leveraging BRF+, you can easily configure and manage route determination rules, enabling greater customization and integration with external systems like Excel. Share your thoughts and potential use cases for BRF+ in the comments below!

How to display ALV GRID with only structure

2024-09-13T10:39:24.855000+02:00

BRF+ Output Determination

2025-03-26T10:03:16.339000+01:00

BRF+ - Business Rule Framework Plus

Introduction:

BRF+ stands for Business Rule Framework plus which Provides a comprehensive application programming interface and user interface for defining business rules.
It enables you to define business rules without the need of writing ABAP Code.
BRF+ Function provides an interface between a business rule modelled with BRF+ and an application using that rule. The BRF+ function serves as a container for the entire business logic of a rule.
BRF+ is not new and even not directly related to SAP S/4HANA, but with the release of SAP S/4HANA 1610, BRF+ gained more attention since it is launched as the go-to solution for some business processes. The most important ones are the changes in Output Management for purchasing and Billing.
In order to use BRF+ with your SAP ECC system, your system must be on SAP NetWeaver 7.02 SP6 or above.
BRF+ supports features such as simulation, trace, transport, XML, export and import.
With SAP S/4 HANA a new Output Management Approach is in place. The complete configuration differs from the configuration that is used when Output Management is based on NAST (condition technique). The configuration is based on BRF+ in SAP S/4HANA is the target architecture is based on Adobe Document server and Adobe forms only. For the Form Determination Rules (along with other output parameters) BRF+ functionality is used.
Rules are Implemented as expressions which are assigned to the function. The rule input is known as “Context ”, and the rule output is called “Result”.
It is a part of SAP NetWeaver ABAP Stack.

Key Benefits:

All output parameters can be automatically determined via a configuration activity based on BRFplus. The benefits are:

You can send multiple messages to multiple recipients using multiple channels at the same time.
You can configure anything without the need for ABAP exits.
You can use each determination step on application-specific fields that can be extended.
You can use predelivered content/determination rules to simply run output control out of the box.
Extensibility via CDS is supported.

Important Note: Basis Team need to upload Standard XML Forms in SAP system. They import the forms by using BRF+ Transaction code.

If the forms aren't uploaded, we won't be able to see the Output Type in the OPD Transaction. We can get the details of Form from SAP Note: 2248229 with the help of Basis download the note.

Limitations in BRF+:

Idocs are not fully supported by the New Output Management. Their use is restricted to business applications that previously used NAST.
Only output types which can be mapped 1:1 to the NAST-KSCHL can use IDoc.
Only business partner-based communication is supported, but no communication to logical systems.
No ALE supports.
BRF+ doesn't fully integrate with the document management features provided by earlier SAP systems like SAP script or Smart Forms.
Compared to older output management solutions, error handling and debugging can be a bit more complex or less intuitive in BRF+.
It requires better integration of monitoring tools and workflows to identify issues with output processes, especially when compared to more established NAST error handling.

NAST to BRF+ Conversion Overview: There are several updates and enhancements in SAP regarding the conversion from NAST to BRF+ for output management.

1. Mandatory Use of BRF+ for Certain Documents: With the release of SAP S/4HANA 1511, output management using BRF+ became mandatory for Purchase Orders. Similarly, in later versions, BRF+ is required for managing outputs of Sales Orders and Billing documents, replacing the traditional NAST-based output management.
2. Increased Number of Supported XML Forms: In earlier versions like SAP S/4HANA 1709, over 12 XML forms were supported. This number has significantly increased in subsequent versions, with SAP S/4HANA 1909 supporting over 20 XML forms. This expansion allows for a broader range of output types and formats to be managed using BRF+.
3. Simplified Configuration and Integration: The configuration process for BRF+ has been streamlined to reduce complexity. It allows for the easy import of XML files for output determination, simplifying the setup and customization of output types.
4. Integration with SAP Fiori and Other UI Technologies: BRF+ integrates seamlessly with SAP Fiori applications and other UI technologies like SAP GUI and SAP UI5. This integration ensures a consistent and modern user experience across different platforms.

In NAST, the configuration path that needs to be maintained is quite complex. The steps need to be followed are:

Condition Table
Access Sequence
Condition Type
Output Type
Condition Record

For the BRF+ in S/4 HANA it is even simplified even business user can maintain Decision Table.

The steps need to follow are:

Output Type
Receiver
Channel
Printer Settings
Email Settings
Form Template

Activate or Deactivate SAP S/4HANA-Based Output Management:

We maintain this configuration because it enables the use of SAP S/4HANA-based output management for Purchase Orders (POs), which is necessary for integrating with other systems like the Ariba Network and managing output messages efficiently in the SAP environment.

Even if you do not activate the specific step for SAP S/4HANA-Based Output Management related to integration with the Ariba Network, BRF+ (Business Rule Framework Plus) can still be used in SAP.

Configuration Path: SPRO→ IMG → Integration with Other SAP Components → Business Network Integration → Integration with the Ariba Network Application-specific settings → Define Message Output Control → Method 2: Use SAP S/4HANA-Based Output Management → Activate or Deactivate SAP S/4HANA-Based Output Management

If you need to activate select the Mode: New output management is active and click on save.

Configuration steps:

Storage repository settings
Manage Application Object Type Activation
Define Output Types
Assign Output Channels
Define Rules for Determination of Master Form Template
Assign Form Templates
Assign Email Templates
Define Business Rules for Output Parameter Determination

1. Storage repository settings: Configuration: SPRO > Cross-Application Components > Document Management > General Data > Settings for Storage Systems > Maintain Storage System

SOMU_DB is a standard content Repository for Output Management DB Storage. If you can’t find the standard content Repository, click on the create tab and maintain the data mentioned below:

Content Repository: SOMU_DB Storage Type: SAP System Version: 0047

If you want to customize, select the standard one and click on Copy as tab as shown change the content Repository name and click on save.

2. Manage Application Object Type Activation Configuration: SPRO –> IMG –> Cross-Application Components -> Output Control -> Manage Application Object Type Activation

If you can’t see the standard Application object type in the screen, just click on Entries and click on Help button and select the required Application object type as per the requirement and maintain status as active and click on save.

3. Define Output Types: Configuration: SPRO –> IMG –> Cross-Application Components -> Output Control -> Define Output Types

The standard configuration is already set up. If the standard option is not visible, you can add it by clicking on "New Entries." To modify the output type, select the standard one, click "Copy As," assign the output type to the Application Object Type, and then save the changes.

4. Assign Output Channels: Configuration: SPRO –> IMG –> Cross-Application Components –> Output Control –> Assign Output Channels

In this step we can assign output channels to application object type and output type.

5. Define Rules for Determination of Master Form Template Configuration: : SPRO –> IMG –> Cross-Application Components –> Output Control –> Define Rules for Determination of Master Form Template

This step is used to establish rules that determine which master form template should be applied based on specific conditions or criteria.

In the "Define Rules for Determination of Master Form Template" step in BRF+, we maintain the rules and conditions that link specific criteria, such as document type, application area, or other relevant factors, to determine the appropriate master form template to be used.

6. Assign Form Templates: Configuration: SPRO –> IMG –> Cross-Application Components –> Output Control –> Assign Form Templates

This step is used to link specific form templates to the rules or processes defined in BRF+. This step ensures that the correct form template is associated with a particular business scenario or document type based on the logic defined in the earlier steps, such as the "Define Rules for Determination of Master Form Template" step.

It enables the system to dynamically assign the appropriate form template for generating documents, reports, or outputs based on the conditions set in the rule framework.

After Maintaining the data click on save.

7. Assign Email Template: Configuration: SPRO –> IMG –> Cross-Application Components –> Output Control –> Assign Form Template

This step ensures that the correct form template is associated with a particular business scenario or document type based on the logic defined in the earlier steps, such as the "Define Rules for Determination of Master Form Template" step.

After Maintaining the data click on save.

8. Define Business Rules for Output Parameter Determination: Configuration: Configuration: SPRO –> IMG –> Cross-Application Components –> Output Control –> Define Business Rules for Output Parameter Determination

I won’t see the option for Purchase contract. So, I need to add template related to purchase contract in BRF+ Transaction code.

In settings select User Mode: Expert

In the Tools tab, choose the XML import, add the standard XML form for the Purchase contract, and include the transport requests.
The Customizing Request will store all the configuration settings for BRF+ that have been maintained.
The Workbench Request will store the configuration settings for Output Types.

Now, the Purchase Contract option is visible in the Output Parameter Determination.

For each step, click on Edit Tab and Maintain the appropriate data and click on Activate button.

The system will display a pop-up tab like want to activate the Output Type click on yes.

It will remain empty because the Email Recipient will be selected from the vendor master data maintained during vendor creation.

All the configuration settings have been done. Now create the contract in ME31K Transaction code with the Agreement Type “WK.”

The Agreement Number – 4600000002

Go the Change mode in ME32K enter the Agreement Number and click on Message Tab as shown.

The status will display as In Preparation to set the status to complete, select the line and click on the send Output tab as shown.

The status will change to “To be Output”

After completion of this step come back and click on save the status will change to completed.

To check the print preview, click on the Display Document tab as shown.

In conclusion, BRF+ (Business Rule Framework Plus) for output management in SAP is a powerful tool that helps automate and control the way documents are generated and managed. It allows businesses to set up rules for different types of outputs, ensuring consistency and efficiency. By using BRF+, companies can reduce manual work, improve document formatting, and make smarter decisions on how to handle outputs. Overall, it helps streamline processes, making them faster and more flexible while improving business performance.

A little glance at S/4 Hana OUTPUT MANAGEMENT and compare its to our old friend NAST

2025-08-10T09:44:01.457000+02:00

As we already know, NAST output has been used over time, from ECC to S4/HANA, due to its reliability and its customization. Based on NAST, we could generate tons of outputs with different types, from simple PDF form or Adobe form to more complex output like EDI/IDOC or even XML.

However, Output management is introduced in S/4 HANA as S/4 HANA OUTPUT MANAGEMENT, as more “centralized” approach to output, based on BRF+ (business rule framework). FYI, BRF+ has been on SAP from ECC, which supported users specific customizations, based on the role, but applying this for S/4 HANA output management is new thing. Using S/4 HANA Output Management is a less-coding approach, compares to NAST, when you need to do bunches of customizations, which is prefer for consultants than end users.

For short, you can check out this table from our friend :

S/4HANA Output Management vs. NAST: When to Choose... - SAP Community

Technology	BRF+	SAPscript / Smart Forms
Customization Flexibility	Limited by service nodes	Customizable to your heart’s content
Form Type	Adobe Forms	SAPscript, Smart Forms
Output Types	Print, Email, XML, EDI	Print, Email, Fax, EDI
Multiple Outputs per Document	BRF+ (but expect headaches)	Easier management with condition records
Learning Curve	Steep—better grab some coffee	Familiar, like catching up with an old friend
Centralized Management	Yes—streamlined oversight	Traditional, less streamlined
Future-Proofing	Yes—leverages the latest technology	No—legacy technology means potential obsolescence
Recommended Use Case	Standard scenarios, new systems	Custom-heavy projects, legacy systems

For short, we can understand that, using NAST is like our reliable, multi functional car that can ramp up anything, just look not really good, but Output Management is introduced as sport cars, like a F1 Mercedes AMG W16, that could only drive on an F1 track.

The purpose of this blog is not to deep dive on theoretical questions how better or how worse of each method, but to know how the configuration of output management, is it much easier than a NAST approach?

Let I guide you steps by steps

HOW SETUP OF OUTPUT MANAGEMENT

To check out our Output Management, lets come to our SPRO -> Cross-Application Components -> Output Control

As we can see, there are bunches of configurations, that are very easy to recognize than our NACE t-code setup. As we know, NACE t-code is follow based on our condition technique setup, which it takes the combinations of key index and cross-check the condition record, then the medium things and routine things follow up.

Lets look how can activate the Output Management before NAST

Next step, we can go to Define Output Types

As we can see, for each Object Types, Output Management support not only different ranges of Output Type but also the variance of the Output, which is different approach from NAST.

Let’s take the Change for example. In NAST, we can retrigger the old output by in case of changes. The same output will be trigger once again when we hit save on the document. But for the Output Management, we could have our own “changes” output here.

Let’s check this output type for “Cash Sales Changes” as below

Double click on the Callback Class.

As we can see just one type of Output, we can see the API information or type of forms/mediums that the output can support in this case

Next step, as we remember from our Friend NAST, in order to generate an output , we need to know which medium (EDI, Printer, Email, Tax).. For each type of output, if you remember, we have this screen in NACE:

For Output Management, we follow BRF+ (Business Rule Framework), so we do not follow Condition Technique.

So it means that for each output type, you have different means of Channel (or Medium if you are in NACE/NAST). Each Output type has their own channel, and each output type has their own form templates or their own email templates. We can check at detail at “Assign Form Template” or ”Assign Email Template”

Enough for the setup, let’s get to the most important part of our Output Management.

instead of Output procedure or condition technique we have to deal with, Output management with the help of BRF+, use the “Business Rules for Output Determination”

As you can see, since its not follow the Condition Technique, Output Management helps user to setup the rule with friendly UI. However, for me Condition Technique is less complex than, because it is used not only for Output but also for Pricing for Sales, Pricing for Purchasing or Tax Determination (just my 2 cents).

Let’s get back to our Business rule:

For Output type, we can input the combinations we like (of course base on the table related to the situations, again, more user-friendly, less consultant-friendly (your pick)

For other’s determination, these can base on the same rule for Receiver, Printer Settings, etc. Just the same as Condition Record, but at more “user-friendly”

After all the setup, get back to how our Output type working in Transactional situation, in this case is the Purchase Order:

As you can see, when we activate the Output Management, the old screen of NAST is no longer, instead, its now generate new type of screen. In this screen, we input PRINT “channel” as our medium in this case. Click on line, choose button ”Display Details”:

Or we can look over if we use “EMAIL” channel, you can easily put CC or BCC for email address

CONCLUSIONS

As we can see how easily that users can access to their output and adjust their output with just simple modifications, even add emails for CC or BCC purposes. However, we also see that how frustration Output Management can bring out whenever if we want to have new type of forms, or any new heavy-customized oriented conditions, while NAST can provide us with just few clicks. So we surely know that S/4 Hana Output Management could be used in the situations that are more centralized, more " basic" and less "complicated", while our NAST could be trustworthy at all the time, but both of them are solutions to different scenarios so don't just stick to only one. Be flexible within the situation.

Function Expression in Business Rule Framework (BRF+)

2025-08-12T11:28:52.458000+02:00

Function in BRF+:

A function is the rule interface in BRF+ and acts as a link between the application code and the BRF+ code. A function carries a context and a result. It imports the context from the calling application and passes the context data to the assigned top expression or ruleset for further processing.

Create an BRF+ application or chose the application in which you wanted to add function Expression.

Right click on the application and select create > Function

Provide the function name, text and short text.

Click on create and navigate to object to save and activate the object.

Once clicked, it will navigate to the above screen. Here you have to assign the result data object based on the context data objects.

Types of Mode:

Function mode:

In functional mode, function execution starts with the assigned top expression. From this top expression, the processing may run through any number of nested subexpressions until a result is returned.

Event mode:

In event mode, the function is associated with a list of rulesets that are executed according to their execution priority and their position in the list.

Function and Event mode:

This mode is a combination of the modes mentioned above. At runtime, the function starts processing the assigned top expression. Once the expression evaluation is finished, function execution continues with the associated rulesets.

Analytical Mode:

It is mainly related to the Hana rules framework which is relevant to the runtime operations.

Signature

The function signature consists of two parts:

Context

The context is a container for data objects that you can assign as import parameters for the function. You choose the context data objects of a function according to the requirements of the calling application by which the BRF+ function is invoked. Also, the context data objects of a function define the scope of objects that can be accessed by the expressions that are evaluated during function execution.

Result

The result data object returns a result value that has been calculated by the expressions of which the function consists .

Note: For further in event mode, the result object is automatically set to the predefined actions table where the actions are recorded that have been triggered by the assigned rulesets.

Code Generation:

BRF+ provides a built-in code generation facility used to compile source code for as many rule constructs in a function as possible. With the help of generated code, BRF+ rules can be executed significantly faster than in interpretation mode.

Simulation:

You can simulate the function processing to test the function's behavior in a sandbox environment. Here, you can gain an in-depth insight into the system status for every single step the system takes during function processing.

Trace

In BRF+, you can request the system to create a processing log to keep track of all processing steps during function execution. The trace information is stored in the system and can be reviewed at any point in time.

Trace will be stored in Trace tables FDT_TRACE_*

Generation Services

For a BRF+ function, you can take advantage of different services that automatically generate code and other objects that are needed to bridge the gap between the ABAP backend system where a BRF+ function is hosted and other systems or environments that wish to access BRF+. The different services available address different usage scenarios. These can be categorized as follows:

Code Templates

A code template is a predefined snippet of ABAP code that you can use to call a BRF+ function from your application in the same system.

Generate

Function Module

You can use a generated RFC-enabled function module to call a BRF+ function that resides in a remote backend system. This is useful in cases where you cannot bring BRF+ and the calling application into the same system — be it for technical reasons (for example, different releases) or for organizational reasons (for example, missing authorization to develop in the remote system).

Web Service

You can use a generated web service to call a BRF+ function from a web application that is not ABAP-based, or that you can only integrate via its exposed services interface. From a technical point of view, web service generation is reusing the function module generation component of BRF+ and generates additional system objects needed for service enablement.

Here we will work on Function mode example:

Assign the top expression and in context add the required objects and finally assign result object suitable.

Top Expression:

Its is pre-condition of the function which will evaluate the number of nested expressions to find the result.

To execute the function click on simulation.

Click on continue

Select the input true or false and click on execute

Result :

Note : All the objects created will be stored in FDT_* tables

Conclusion:

Function provides a built-in code generation facility used to compile source code for as many rule constructs in a function as possible
Function is the most important BRF+ object and it represents a decision service , which is the element that is in fact invoked by the application and the entire application is invoked by function to stimulate and provide the output we can invoke using the code generation to create report program for executing in GUI.
we can perform pre-conditional and event of action related condition's like rules for executing in the based on the specified rule using the type of modes in the function expression.

Creating a Formula Expression in BRF+

2025-08-21T08:12:50.267000+02:00

Business Scenario
We want to determine the Pension Bonus Amount based on:
Employee Service Years
Pension Bonus Base Amount
The formula might look like:
Pension Bonus Amount = Pension Bonus Base Amount x Service Years

Step-by-Step: Creating the Formula Expression in BRF+
Step 1: Create a Formula Expression
Navigate to your BRF+ Application.
Click on Create -> Expression -> Formula.

Enter a name for the formula, e.g., Formula_1, and click Create.

Formula Expression is created here we can create formula by two modes Normal mode and Expert mode

Normal Mode and Expert Mode
Normal Mode
User-Friendly Interface: Designed for users who prefer a simplified, guided way of creating formulas.
Predefined Options: You select from predefined functions, operators, and variables.
Limited Flexibility: Less control over complex logic; suitable for straightforward formulas.
Use Case: Ideal for users who want to quickly create formulas without delving into intricate details or custom logic.
Expert Mode
Advanced Features: Offers a more powerful and flexible environment.
Direct Formula Editing: You can directly write and edit the formula expressions, often in a text-based way.
Greater Control: Supports complex logic, nested functions, and custom expressions.
Customization: Allows more detailed and precise formula definitions.
Use Case: Suitable for advanced users or scenarios requiring complex logic that cannot be easily achieved in normal mode.

Step 2: Define Data Elements (Mass Creation)
We need to define three key data elements:
Pension Bonus Amount (Result)
Pension Bonus Base Amount
Service Years
To create these:
Go to Application -> Create -> Data Object -> Element (Mass Creation).
Define each required element with the appropriate data type (e.g., Amount, Integer, etc.).

Add resultant data object

click on result data object click on `Search'
Select required field

Step 3: Build the Formula
Place your cursor after the | next to the Result Data Object.
Click on Insert Data Object and select:
Pension Bonus Base Amount and Service Years

Step 4: Test the Expression (Simulation)
Click Start Simulation.
Enter test values for:
Pension Bonus Base Amount (e.g., 300)
Service Years (e.g., 10)
Click Execute.

You should see the calculated Pension Bonus Amount
We get the output

Conclusion
Formula Expressions in BRF+ are a powerful tool for creating dynamic business rules and performing calculations using business context data. With both Normal and Expert modes available, users at any skill level can build and manage rules effectively—often without needing to write custom ABAP code.

In our example, we used a Formula Expression to calculate the Pension Bonus Amount based on an employee’s years of service and a base bonus value—something commonly needed in HR and payroll systems.

How to Create a Decision Tree in BRF+

2025-09-11T08:13:51.501000+02:00

How to Create a Decision Tree in BRF+
1. Introduction

The Business Rule Framework Plus (BRF+) in SAP allows business users and developers to define and maintain business rules without extensive ABAP coding.
A Decision Tree is a graphical way of modeling conditional logic where each branch represents a decision point.

This manual explains how to create and test a Decision Tree in BRF+.

2. Launch BRF+ Workbench

Open SAP GUI.

Enter Transaction Code: BRF+ (or BRFPLUS).

The BRF+ Workbench opens in a browser-based window.

3. Create an Application

In the Workarea, select Create → Application.

Enter details such as:

Application Name: Z_DEMO_APP

Description: Demo application for decision tree

Package: $TMP (for local) or assign to a transport request

Save the application.

4. Create a Function

Inside the application, right-click and choose Create → Function.

Maintain the following:

Name: Z_DECISION_TREE_FUNC

Mode: Event Mode

Save the function.

5. Create a Decision Tree Object

Right-click on the function.

Select Create → Expression → Decision Tree.

Provide details:

Name: Z_DECISION_TREE

Description: Example for discount calculation

Save the object.

6. Define Input and Output Data Objects

Create input data objects for decision making, for example:

Order_Type (Data Type: CHAR)

Customer_Category (Data Type: CHAR)

Define an output object to hold the decision result, for example:

Discount_Value (Data Type: NUMC).

7. Model the Decision Tree Logic

Open the Decision Tree in the graphical editor.

Add branches and maintain conditions:

IF Order_Type = 'ONLINE' → Assign Discount_Value = 10.

IF Order_Type = 'RETAIL' → Assign Discount_Value = 5.

ELSE → Assign Discount_Value = 0.

Save and activate the decision tree.

8. Test the Decision Tree

Right-click on the decision tree and choose Test.

Enter test values, for example:

Order_Type = ONLINE

Customer_Category = GOLD

Execute and verify the result returned in Discount_Value.

9. Conclusion

We have successfully created a Decision Tree in BRF+.
This object can now be used in business functions to replace hard-coded logic, making it easier to maintain and update rules without changing ABAP code.

For complex business rules, you may also explore Decision Tables or Formulas in BRF+.

Creation of Value Range in Business Rule Framework Plus(BRF+)

2025-09-24T06:59:09.471000+02:00

In Business Rule Framework plus (BRF+), a Value Range refers to an expression used to check if a specific value falls within a defined range or set of values. The outcome of a value range expression is always a Boolean (true or false), indicating whether the value meets the specified range condition.

Steps to create Value range in BRF+ .

Right click on application and followed with image attached.

Provide name, short description and click on create and navigate to object.

Create a data object of date and add in the condition and provide the condition if the input date is equal to fixed date and result will be displayed in true or false .

Save and activate . Now click on start stimulation and in next screen click on continue.

Select the date and click on execute .

If the selected date is in range it will be true

Select the date and click on execute .

If the selected date is not in the range it will be false

Conclusion:

Flexibility in Definition:
BRF+ offers the flexibility to define value ranges explicitly as reusable expressions or implicitly directly within other expressions like decision tables. The choice between explicit and implicit ranges depends on the need for reusability across different parts of a BRF+ application.
Boolean Result:
Value range expressions in BRF+ always yield a Boolean result, returning true if the tested value lies within the defined range and false otherwise. This makes them suitable for use in conditions within decision tables, loops, or other expressions that require a true/false evaluation.
Support for Various Operators and Types:
BRF+ value ranges support various comparison operators (e.g., equals, not equals, greater than, less than, between) and can be applied to different data types, including numeric values, text, and dates. This allows for comprehensive and precise rule modeling.
Enhancing Decision Logic:
Value ranges are crucial for building robust decision logic in BRF+. They enable the creation of rules that categorize or process data based on specific thresholds, intervals, or sets of allowed values, thereby automating and streamlining business processes.
Impact on Performance and Maintainability:
While implicit ranges offer quick implementation for ad-hoc conditions, explicit, reusable value range expressions contribute to better performance and maintainability in complex BRF+ applications by promoting consistency and reducing redundancy in rule definitions.
Limitations and Workarounds:
There can be limitations, such as the number of entries in a single decision table cell when defining ranges or sets of values. Workarounds, like using patterns or grouping properties, may be necessary to overcome such limitations and effectively model complex business rules.

BRF+ Object Creation using ABAP Z-Report

2025-09-24T07:11:38.092000+02:00

Introduction

When working with SAP BRF+ (Business Rule Framework Plus), Elements are the most basic building blocks. They represent data fields such as numbers, text, or dates, and act as reusable components for structures, tables, functions, and rules. Without elements, we cannot define or process rules effectively in BRF+.

In this blog, we will learn how to create BRF+ Elements programmatically using ABAP. This provides a scalable way to automate the creation of data objects and integrate them into larger rule frameworks.

Why Elements?

Describes data types of the variable. They are the data carriers helping in signature or context of a function, variables in a rule or rulesets, building blocks for Decision tables, Etc. You can create data objects by defining attributes like element type, length, decimals or you can directly bind to existing DDIC elements.

Reusability: Once created, elements can be used in multiple structures and rules.
Flexibility: Programmatic creation ensures consistency across environments.
ABAP Program to Create Elements
Below is a sample ABAP program (ZDEMO_BRF_APP) that:
1. Creates a BRF+ Application.
2. Defines three Elements (ELEMENT_1, ELEMENT_2, and CARRID).

*&---------------------------------------------------------------------*
*& Report ZDEMO_BRF_APP
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT zdemo_brf_app.

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,
      lo_element_1         TYPE REF TO if_fdt_element,
      lo_element_2         TYPE REF TO if_fdt_element,
      lo_element_3         TYPE REF TO if_fdt_element,
      lo_table             TYPE REF TO if_fdt_table,
      lo_table_1           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_input_number_id   TYPE if_fdt_types=>id,
      lv_result_counter_id TYPE if_fdt_types=>id,
     

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


PARAMETERS: pv_lcl  TYPE abap_bool RADIOBUTTON GROUP r00 DEFAULT 'X',
            pv_sys  TYPE abap_bool RADIOBUTTON GROUP r00,
            pv_mstr TYPE abap_bool RADIOBUTTON GROUP r00,
            pv_name TYPE char30.
*           p_ele_01  TYPE i DEFAULT 5,
*            p_ele_02  TYPE i DEFAULT 4,
*            p_ele_03  TYPE i DEFAULT 8,
*            p_ele_04  TYPE i DEFAULT 3,
*            p_ele_05  TYPE i DEFAULT 13,
*            p_ele_06  TYPE i DEFAULT 2.
*           pv_ele   TYPE char20,
*           pv_str TYPE char20,
*           pv_tab TYPE char20.

IF pv_name IS NOT INITIAL AND pv_lcl IS NOT INITIAL OR pv_sys IS NOT INITIAL OR pv_mstr IS NOT INITIAL.

* 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
*lo_application->if_fdt_admin_data~set_name( cl_fdt_services=>get_unique_name( ) ).
  lo_application->if_fdt_admin_data~set_name( pv_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( ).
  ENDIF.
  lo_application->if_fdt_transaction~activate(
             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( ).
  ELSE.
    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.
  ENDIF.
  WRITE: 'The ID of the application created is: ', lv_demo_appl_id. "#EC NOTEXT
ELSE.
  MESSAGE 'Provide all the required information' TYPE 'E'.
ENDIF.
*for creating Element,Structure,Table by Data Object


lo_factory = cl_fdt_factory=>if_fdt_factory~get_instance( lv_demo_appl_id ).
*                          if_fdt_constants=>gc_application_tmp  ).
* Note, that you are not required to use an application as input; however,
* we recommend to do so and work with a specific application instead of
* the generic local FDT applications.
*------------Element
lo_element_1 ?= lo_factory->get_data_object(
    iv_data_object_type = if_fdt_constants=>gc_data_object_type_element ).
lo_element_1->if_fdt_transaction~enqueue( ).
lo_element_1->if_fdt_admin_data~set_name( 'ELEMENT_1' ).

* set the element-type (see if_fdt_constants=>gc_element_type_* for
* a list of available element types)
lo_element_1->set_element_type( if_fdt_constants=>gc_element_type_number ).

******************************************************************************
* Alternately user can create an element using the service clas method
* CL_FDT_CONVENIENCE=>CREATE_ELEMENT as follows.
*
* cl_fdt_convenience=>create_element( EXPORTING iv_name = 'DEMO_ELEMENT_1'
*                                              iv_application_id = if_fdt_constants=>gc_application_tmp
*                                              iv_element_type   = if_fdt_constants=>gc_element_type_number
*                                              iv_activate       = ABAP_false
*                                    IMPORTING
*                                              eo_element        = lo_element ).
*******************************************************************************
* Set some attributes for the element.
lo_element_1->set_element_type_attributes(
  EXPORTING
    iv_length        = 6
    iv_decimals      = 2
    iv_only_positive = abap_false ).

lo_element_1->if_fdt_transaction~activate(
  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_element_1->if_fdt_transaction~dequeue( ).
ELSE.
  lo_element_1->if_fdt_transaction~save( ).
  lo_element_1->if_fdt_transaction~dequeue( ).
* usually it makes sense to store the id for later access
  lv_element1_id = lo_element_1->mv_id.

  ls_element-position = 1.
  ls_element-element_id = lv_element1_id.
  APPEND ls_element TO lts_element.
ENDIF.

* Create another element
lo_element_2 ?= lo_factory->get_data_object(
    iv_data_object_type = if_fdt_constants=>gc_data_object_type_element ).
lo_element_2->if_fdt_transaction~enqueue( ).
lo_element_2->if_fdt_admin_data~set_name( 'ELEMENT_2' ).



* set the element-type (see if_fdt_constants=>gc_element_type_* for
* a list of available element types)
lo_element_2->set_element_type( if_fdt_constants=>gc_element_type_number ).

lo_element_2->if_fdt_transaction~activate(
  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_element_2->if_fdt_transaction~dequeue( ).
ELSE.
  lo_element_2->if_fdt_transaction~save( ).
  lo_element_2->if_fdt_transaction~dequeue( ).
* usually it makes sense to store the id for later access to the application
  lv_element2_id = lo_element_2->mv_id.
  ls_element-position = 2.
  ls_element-element_id = lv_element2_id.
  APPEND ls_element TO lts_element.
ENDIF.

* create a third element
lo_element_3 ?= lo_factory->get_data_object(
    iv_data_object_type = if_fdt_constants=>gc_data_object_type_element ).
lo_element_3->if_fdt_transaction~enqueue( ).
lo_element_3->if_fdt_admin_data~set_name( ' CARRID ' ).
lo_element_3->set_element_type( if_fdt_constants=>gc_element_type_number ).

lo_element_3->if_fdt_transaction~activate(
  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_element_3->if_fdt_transaction~dequeue( ).
ELSE.
  lo_element_3->if_fdt_transaction~save( ).
  lo_element_3->if_fdt_transaction~dequeue( ).
* usually it makes sense to store the id for later access to the application
  lv_element3_id = lo_element_3->mv_id.
  ls_element-position = 3.
  ls_element-element_id = lv_element3_id.
  APPEND ls_element TO lts_element.
ENDIF.
* WRITE: / lo_element->mv_id .
lv_string = lo_element_1->if_fdt_admin_data~to_string(  iv_mode = if_fdt_constants=>gc_tostring_mode_complete ).
WRITE : / 'The result of to string method call Element: ' , lv_string. "#EC NOTEXT

Execution & Output

When you execute the above ABAP report, the newly created Application and Elements will immediately be reflected in the BRF+ Workbench (/nBRF+). You can navigate to the workbench to verify that the application ZDEMO_APP and its elements have been created successfully.

After running the program, you will see system-generated IDs for each element created. These IDs are crucial when referencing the elements in Structures, Rules, or Functions.

Conclusion

In the next part of this blog series, we will explore how to create Structures using these Elements. Subsequent blogs will also cover Table, DB Lookup, Loop, Formula, Rule, and Function in detail.

BRF+ Object Creation using ABAP Z-Report, Part 2

2025-09-25T06:39:29.292000+02:00

To create BRF+ Elements programmatically using ABAP Refer Previous blog

BRF+ Object Creation using ABAP Z-Report

In this blog, we will learn how to create BRF+ Structures and Table type programmatically using ABAP. This provides a scalable way to automate the creation of data objects and integrate them into larger rule frameworks.

Table type Creation: In order to have multiple result rows based on a single condition in our decision table, we can create a table in the same application. Therefore, table creation is necessary in our case.

ABAP Program to Create Structure and Table type

Below is a sample ABAP program (ZDEMO_BRF_APP)

REPORT zdemo_brf_app.

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,
      lo_element_1         TYPE REF TO if_fdt_element,
      lo_element_2         TYPE REF TO if_fdt_element,
      lo_element_3         TYPE REF TO if_fdt_element,
      lo_table             TYPE REF TO if_fdt_table,
      lo_table_1           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_input_number_id   TYPE if_fdt_types=>id,
      lv_result_counter_id TYPE if_fdt_types=>id,
     

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


PARAMETERS: pv_lcl  TYPE abap_bool RADIOBUTTON GROUP r00 DEFAULT 'X',
            pv_sys  TYPE abap_bool RADIOBUTTON GROUP r00,
            pv_mstr TYPE abap_bool RADIOBUTTON GROUP r00,
            pv_name TYPE char30.
*           p_ele_01  TYPE i DEFAULT 5,
*            p_ele_02  TYPE i DEFAULT 4,
*            p_ele_03  TYPE i DEFAULT 8,
*            p_ele_04  TYPE i DEFAULT 3,
*            p_ele_05  TYPE i DEFAULT 13,
*            p_ele_06  TYPE i DEFAULT 2.
*           pv_ele   TYPE char20,
*           pv_str TYPE char20,
*           pv_tab TYPE char20.

IF pv_name IS NOT INITIAL AND pv_lcl IS NOT INITIAL OR pv_sys IS NOT INITIAL OR pv_mstr IS NOT INITIAL.

* 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
*lo_application->if_fdt_admin_data~set_name( cl_fdt_services=>get_unique_name( ) ).
  lo_application->if_fdt_admin_data~set_name( pv_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( ).
  ENDIF.
  lo_application->if_fdt_transaction~activate(
             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( ).
  ELSE.
    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.
  ENDIF.
  WRITE: 'The ID of the application created is: ', lv_demo_appl_id. "#EC NOTEXT
ELSE.
  MESSAGE 'Provide all the required information' TYPE 'E'.
ENDIF.
*for creating Element,Structure,Table by Data Object


lo_factory = cl_fdt_factory=>if_fdt_factory~get_instance( lv_demo_appl_id ).
* =============================================================
* definition of a data object structure:
* get an initial data object structure from the factory
lo_structure ?= lo_factory->get_data_object(
    iv_data_object_type = if_fdt_constants=>gc_data_object_type_structure ).
lo_structure->if_fdt_transaction~enqueue( ).
lo_structure->if_fdt_admin_data~set_name( 'STRUCTURE' ).
lo_structure->set_elements( lts_element ).
**********************************************************************************
* Alternately user can create a structure by using the service class method,
* CL_FDT_CONVENIENCE=>CREATE_STRUCTURE as follows.
* Cl_fdt_convenience=>create_structure( EXPORTING iv_name = 'DEMO_STRUCTURE_1'
*                                                iv_application_id = if_fdt_constants=>gc_application_tmp
*                                                it_element        =  lts_element
*                                                iv_activate       = ABAP_false
*                                      IMPORTING
*                                                eo_structure      = lo_structure ).
***********************************************************************************

lo_structure->if_fdt_transaction~activate(
  IMPORTING
    et_message           = lt_message
    ev_activation_failed = lv_boolean ).


IF lv_boolean EQ abap_true.
  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.
  ENDLOOP.
  WRITE : lv_message.
*         for some reason the activation failed -> individual handling needed
  lo_structure->if_fdt_transaction~dequeue( ).
ELSE.
  lo_structure->if_fdt_transaction~save( ).
  lo_structure->if_fdt_transaction~dequeue( ).
*         usually it makes sense to store the id for later access to the application
  lv_structure_id = lo_structure->mv_id.
ENDIF.
*   WRITE: / lo_structure->mv_id .
lv_string = lo_structure->if_fdt_admin_data~to_string(  iv_mode = if_fdt_constants=>gc_tostring_mode_complete ).
WRITE : / 'The result of to string method call Structure: ' , lv_string. "#EC NOTEXT
* =============================================================
* definition of a data object table:
*     get an initial data object Table from the factory
lo_table ?= lo_factory->get_data_object(
    iv_data_object_type = if_fdt_constants=>gc_data_object_type_table ).
lo_table->if_fdt_transaction~enqueue( ).
lo_table->if_fdt_admin_data~set_name( 'TABLE' ).
lo_table->set_structure( lv_structure_id ).
INSERT lo_table->mv_id INTO TABLE lts_context_id.
***********************************************************************
* Alternately user can create a Table by using the service class method,
* CL_FDT_CONVENIENCE=>CREATE_TABLE as follows.
* cl_fdt_convenience=>create_table( EXPORTING iv_name = 'DEMO_TABLE_1'
*                                            iv_structure_name = 'DEMO_STRUCTURE_1'
*                                            iv_application_id = if_fdt_constants=>gc_application_tmp
*                                            it_element        = its_element
*                                            iv_activate       = ABAP_false
*                                  IMPORTING
*                                            eo_table          = lo_table ).
***********************************************************************



lo_table->if_fdt_transaction~activate(
  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_table->if_fdt_transaction~dequeue( ).
ELSE.
  lo_table->if_fdt_transaction~save( ).
  lo_table->if_fdt_transaction~dequeue( ).
*        usually it makes sense to store the id for later access to the application

ENDIF.
*   WRITE: / lo_table->mv_id .
lv_string = lo_table->if_fdt_admin_data~to_string(  iv_mode = if_fdt_constants=>gc_tostring_mode_complete ).
WRITE : / 'The result of to_string method call Table: ' , lv_string. "#EC NOTEXT


* cl_fdt_convenience=>create_table( EXPORTING iv_application_id = if_fdt_constants=>gc_application_tmp
*                                                iv_element_type   = if_fdt_constants=>gc_data_object_type_table
*                                                iv_activate       = abap_false
*                                                iv_name           = 'RESULT_COUNTER'
*                                      IMPORTING eo_element        = lo_result_counter ).
*
*  INSERT lo_result_counter->mv_id INTO TABLE lts_context_id.
*TYPES: BEGIN OF ty_element ,
*  name TYPE if_fdt_types=>name,
*  lv_element type if_fdt_types=>element_type,
*  END OF ty_element.
*DATA: lt_element TYPE TABLE OF ty_element,
*      lss_element TYPE ty_element.
*  lss_element-name = 'SFLIGHT_TAB'.
*  lss_element-lv_element = if_fdt_constants=>gc_data_object_type_table.
*  APPEND lss_element TO lt_element.


lo_table_1 ?= lo_factory->get_data_object(
    iv_data_object_type = if_fdt_constants=>gc_data_object_type_table ).
lo_table_1->if_fdt_transaction~enqueue( ).
lo_table_1->if_fdt_admin_data~set_name( 'SFLIGHT_TAB' ).
lo_table_1->set_structure( lv_result_table_id ).
APPEND lo_table_1->mv_id TO lts_context_id.

lo_table_1->if_fdt_transaction~activate(
  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_table_1->if_fdt_transaction~dequeue( ).
ELSE.
  lo_table_1->if_fdt_transaction~save( ).
  lo_table_1->if_fdt_transaction~dequeue( ).
*        usually it makes sense to store the id for later access to the application

ENDIF.
*   WRITE: / lo_table->mv_id .
lv_string = lo_table_1->if_fdt_admin_data~to_string(  iv_mode = if_fdt_constants=>gc_tostring_mode_complete ).
WRITE : / 'The result of to_string method call Table: ' , lv_string. "#EC NOTEXT

*
*  cl_fdt_convenience=>create_table(
*    EXPORTING
*      iv_name           =  'RESULT_TABLE'                " Name
*      iv_structure_name = lv_name
*      iv_application_id = if_fdt_constants=>gc_application_tmp                " Universal Unique Identifier
*      it_element        = lt_element              " Elements
*      iv_activate       = abap_true        " Activate changes?
*    IMPORTING
**      ev_table_id       =                  " Universal Unique Identifier
*      eo_table          = lo_result_table                " FDT: Data Object of Type Table
*  ).
*  CATCH cx_fdt_input. " FDT: Invalid Input

Execution & Output

When you execute the above ABAP report, the newly created Application , Structure and Table will immediately be reflected in the BRF+ Workbench (/nBRF+). You can navigate to the workbench to verify that the application ZDEMO_APP and its elements have been created successfully.

After running the program, you will see system-generated IDs for each element created. These IDs are crucial when referencing the elements in Structures, Rules, or Functions.

Conclusion

In the next part of this blog series, we will explore how to create DB Lookup, Loop, Formula, Rule, and Function in Subsequent blogs in detail.

SAP Community - NW ABAP Business Rule Framework (BRFplus)

Utility for copying MDG BRF+ workflow Decision Tables

[BRF+ New Output Management]: Use DDIC Interface based Regular Custom Adobe Form – Handle ‘Spool request could not be found APOC_OR_MESSAGES 145’

INTRODUCTION:

MAIN CONTENT:

Outcome:

IDOC Configuration for Sales Order via New Output Management

Syniti RDG provides a new functionality-Importing of UI Field Property Rules by Change Request Step from one change request to another change request.

MDG-S: MDG rule-based workflow

Introduction:

Requirement:

Solution:

Sub-workflow WS90100004 Overview

Syniti RDG provides a new functionality-copying the business rules from one change request to another change request

MDG DQM: Troubleshooting DQM validation rules for central governance - Product Master S/4 HANA

INTRODUCTION

MAIN CONTENT

Scenarios which need troubleshooting:

System details:

CONCLUSION

Business Rule Framework Plus(BRF+)

Application Exit Class in BRF Plus(BRF+)

Output management in S/4HANA

Leveraging BRF+ Decision Tables for Flexible Route Determination in SAP S4HANA

Enhanced Efficiency and Flexibility

How to display ALV GRID with only structure

BRF+ Output Determination

BRF+ - Business Rule Framework Plus

A little glance at S/4 Hana OUTPUT MANAGEMENT and compare its to our old friend NAST

Function Expression in Business Rule Framework (BRF+)

Creating a Formula Expression in BRF+

How to Create a Decision Tree in BRF+

Creation of Value Range in Business Rule Framework Plus(BRF+)

BRF+ Object Creation using ABAP Z-Report

Introduction

Why Elements?

ABAP Program to Create Elements

Execution & Output

Conclusion

BRF+ Object Creation using ABAP Z-Report, Part 2

ABAP Program to Create Structure and Table type

Execution & Output

Conclusion