Explaining the BRFplus Core Features

Expression types form the core computational engine of BRFplus. Each expression type represents a self-contained computational unit with a well-defined logic. Expressions utilize a context and can nest other expressions to calculate, determine, or derive results. An expression can be viewed as an instance of an expression type, following the logic defined by that type. These expressions can be reused as building blocks within the rules, starting with a function as their top expression.

BRFplus offers a range of standard expression types, and new types are regularly added to enhance functionality. You also have the flexibility to create custom expression types for use in your rules.

BRFplus comes with a set of common expression types and is regularly enhanced by new expression types. You can also create your own expression types and use them in the rules.

• Boolean
• BRMS Connector
• Case Expression
• Constant
• Database Lookup
• Decision Table
• Decision Tree
• Dynamic Expression
• Formula
• Function Call
• Loop
• Procedure Call
• Random Number
• Search Tree
• Table Operation Expression

• Value Range Expression

BRFplus offers a list of commonly used predefined expression types. You can explore each expression type in detail on the SAP Help Portal.

However, to expand the functional capabilities of BRFplus beyond what's provided by the built-in expression types, you can create your own custom expression types. These user-defined expression types allow you to address specific requirements that may not be adequately covered or straightforward to use with the predefined options.

BRFplus includes powerful predefined expression types like decision tables, search trees, and formulas, which cater to a wide range of business rule scenarios. Nonetheless, there might be instances where these predefined types fall short or don't align with your specific use case. In such situations, you have the flexibility to craft your company-specific expression types.

It's important to note that the approach for user-defined expression types mirrors that of the built-in ones. These user-defined types leverage the same technical infrastructure used by SAP for the predefined types. Consequently, you can expect your custom expression types to exhibit similar behavior to the built-in ones in terms of performance, access control, and more. They are an extension of the BRFplus concept, ensuring seamless integration rather than serving as a separate add-on.

For more information, refer to the SAP Help Portal: Expression Type

The Case expression in question closely resembles the ABAP CASE statement. It operates by taking a case parameter and comparing its value to a set of test parameters. For each of these test parameters, a corresponding return parameter is defined within the When table.

When a match occurs between one of the test parameters and the case parameter, the associated return parameter is assessed, and a result is generated. In cases where none of the test parameters align with the case parameter, a different parameter is evaluated to determine the result.

It's important to note that all parameters involved can either be context data objects or nested expressions. Typically, the case parameter is a context data object, the test parameters are constants, and the result parameters are expressed as nested expressions.

The table operation expression offers a wide range of functionalities for efficiently managing and accessing data stored in a BRFplus data object of table type. This expression type empowers users to perform various administrative tasks and obtain statistical insights into table data objects. While some of the available features resemble those found in the aggregation and existence check modes of the DB lookup expression, their focus differs slightly.

The Table operations expression supports multiple functions for interacting with table data objects, including capabilities like Has at least, Has exactly, Has no more than, Count, Minimum, Maximum, Total, Average, First Row, Last Row, All lines, Sort, Delete first row, Delete last row, and Delete all lines.

In all these operations, there's also the option not to provide a selection condition. In such cases, the operation is applied to all rows within the specified table.

It's worth noting that among the operations listed above, Minimum, Maximum, Total, and Average can only be utilized in conjunction with a numeric table field. The BRFplus workbench assists users in identifying suitable columns within a given table by presenting only those fields that align with the requirements of a specific operation.

A decision table expression is a powerful tool for comparing a given input against a set of predefined combinations of conditions. Each combination is associated with a specific result, which becomes the expression's output when the input data aligns with that particular combination.

The decision table itself is structured as a table with the following key elements and settings:

• One or more columns representing distinct conditions for comparing input data.
• One or more columns are designated to hold the result returned by the expression when all conditions in a row are met.
• One or more rows, each unique in terms of their combined conditions.

When a decision table expression is executed, it processes business rules sequentially based on a set of input values. At runtime, the provided input data is compared to the defined conditions, starting with the first row. Each cell undergoes evaluation by comparing the column value to a set of range comparisons, resulting in a Boolean outcome. If all cells in a row evaluate to true, the evaluation ceases, and the expression returns the result corresponding to the current conditions. If not, the processing continues with the next table row until either a matching condition set is found, or the end of the table is reached.

Due to the sequential nature of rule processing, it's advisable to define rules starting with the most specific condition in the first row, followed by rules with progressively less specific conditions. This approach prevents situations where an input satisfying a broad condition leads to a result without allowing the system to test whether a more specific condition would be a better match for the input data.

It's worth noting that BRFplus check functions can help identify many sequential arrangement errors and alert you to potential issues.

Additionally, in the context of decision tables, you have the flexibility to export data to Excel and import data from Excel into the decision table, enhancing ease-of-use and data management.

Another versatile expression type is the formula expression. Formulas of this type can perform calculations on data objects in a wide range of ways, encompassing mathematical operations, and a diverse set of formula functions. These functions can utilize data objects from the context, those returned from other expressions, or even accept direct input values to create the formula. Building the formula can be achieved through predefined building blocks or by entering it directly in free text using the expert mode.

The available formula functions can be conveniently filtered by categories or search patterns, and each function is accompanied by documentation explaining its purpose and syntax. Users also have the capability to create custom formula functions.

The formula functions are organized into the following categories:

• Date and Time Functions: These enable calculations involving time intervals, various units of time measurement, leap year determination, and extraction of specific time components.
• String Functions: These facilitate string manipulation, including concatenation, extraction, string length determination, and string similarity assessments.
• Mathematical Functions: This category encompasses mathematical operations such as logarithms, exponentiation, and trigonometric functions.
• System Functions: These functions retrieve system-specific information like factory calendar details, operating system specifications, and logon language.
• Table Functions: Specifically designed for BRFplus table data objects, these functions retrieve information from or perform calculations on these objects, including maximum and minimum value determination, summation, averaging, and row count.
• Miscellaneous Functions: This category includes functions for quantity and amount conversions, number rounding, and checking for initial values.

Actions are a special type of expressions that do not return a value.

Actions are a distinct category of expressions designed for performing tasks that don't yield a return value. While action types share similarities with expression types, they don't produce result values; instead, their primary purpose is typically data manipulation. Like expressions, they can make use of context parameters and incorporate nested expressions or actions. Additionally, actions can be linked to a list of follow-up actions.

The standard BRFplus package includes four predefined action types:

• Send Email
• Start Workflow
• Log Message
• Procedure Call

It's worth noting that TRM introduces specific actions, which will be discussed further in Lesson 4 - Explaining the TRM Specific BRFplus Features.

The action type Log Message is designed to append one or multiple messages to an application log. These messages can be directed to specific logs defined by an object and a sub-object within transaction SLG0. You have the flexibility to choose between persisting these messages or storing them temporarily in memory. Furthermore, you can specify the message type, such as "Information, Status, Warning, Error, Abort, or Exit.

The text for these messages can be dynamically generated by incorporating values from expressions, context parameters, or predefined values. Placeholders are utilized to seamlessly insert these values into the text.

To review and analyze the log, you can access it through transaction SLG1, leveraging object parameters for detailed examination.

• Code generation happens automatically when the BRFplus function is called for the first time.
• Manual code generation can be triggered in the Function UI or by the Mass Generation Program.

To ensure optimal performance, BRFplus rules are transformed into ABAP code, resulting in a class with a process pure method that is executed at runtime. By default, code generation is automatically initiated the first time a BRFplus function is called. However, you have two manual options for triggering code generation. The first method involves navigating to the Code Generation tab and selecting Generate Function within the BRFplus Function User Interface. The second method utilizes the mass code generation program FDT_GENERATE_MANY_FUNCTIONS. These programs enable you to generate the function as needed, specifically when there are rule changes for the BRFplus function. In other words, code generation occurs selectively, triggered only in response to modifications made to the BRFplus function's rules.

As a recommended best practice, after importing any BRFplus changes into a production environment, it is advisable to regenerate the BRFplus function using the mass BRFplus generation tool (ABAP Program FDT_GENERATE_MANY_FUNCTIONS). This proactive approach helps prevent performance issues when the BRFplus function is first invoked as part of a business process. In case you encounter any generation-related problems, you can utilize the FDT_GENERATION_TOOL report to analyze the root cause and initiate the regeneration process as needed.

To view the BRFplus function trace, you can access it in two ways. First, by clicking the Trace button within the BRFplus workbench for a specific function. Second, for a particular form bundle, you can access the BRFplus trace through transaction history.

To activate the BRFplus trace and view it successfully, ensure that trace settings are enabled in the relevant configuration (for example for form processing, active the trace for the form bundle type), and the code generation process is completed without errors.