Show TOC

Background documentationFunction

 

A function is the rule interface in BRFplus and acts as a link between the application code and the BRFplus code. For your convenience, you can let the system generate an ABAP code snippet that you can use for easy integration of a BRFplus function into your application.

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. After processing, the function returns the calculated result to the calling application.

Features

Mode of Operation

A function can be designed for one of the following modes of operation:

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

  • Functional 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 continuous with the associated rulesets.

For more information, see Modes of Operation.

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 BRFplus 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 Note

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

    End of the note.
Rulesets

For a function where you have set the mode of operation to either Event Mode or Functional and Event Mode on the Properties tab, the system expects that you assign one or more rulesets that are processed when the function is processed. You can create a new ruleset to be assigned to a function directly from the editing work area of a function. For an already existing ruleset, however, you first have to navigate to that ruleset and define the desired function as the ruleset's trigger. Once this assignment has been made, the ruleset is listed on the Assigned Rulesets tab of the function.

Note Note

When you execute a function that triggers more than one ruleset, the system starts by executing the first ruleset and waits for its termination before it starts the execution of the next ruleset, and so on. This is a prerequisite for the system to be able to pass parameters that may have been modified by a ruleset from one ruleset to another. There is no parallel processing of the assigned rulesets.

End of the note.
Assigned Rulesets versus Executable Rulesets

In the BRFplus workbench, you can choose between two different view modes with respect to rulesets:

  • Assigned Rulesets

    In this mode, the system displays all rulesets that have been assigned to the current function, regardless of their activation status. This means that there may be one or more rulesets listed that are currently not ready for execution and will be skipped without further notice when the function is triggered. Also, choosing this view mode enables the Create Ruleset button that you can use to create a new ruleset and assign it to the current function in one single step.

  • Executable Rulesets

    In this mode, the system displays only those rulesets that have been assigned to the current function and are either currently active or for which an older active version is available that can be used for ruleset execution.

    Note Note

    The system lists all assigned rulesets that are executable from a technical point of view. Therefore, a ruleset that is currently disabled is still listed as long as there is an active version available. As opposed to the activation status, enabling or disabling a ruleset is a business-driven decision, not a technical question. At runtime, the function triggers all executable rulesets. However, a disabled ruleset terminates immediately without taking any actions, and returns control to the trigger function.

    End of the note.
Ruleset Execution Priority

In case there is more than one ruleset assigned to a function, the rulesets are triggered according to the order in which they appear in the function's list of assigned rulesets. You can influence the execution order for the rulesets by defining a priority for each involved ruleset. The priority is a numeric value between 0 and 99 that you can define for a ruleset. The default priority for a newly created ruleset is 0, meaning that there is no priority defined for that ruleset. The list of assigned rulesets is sorted by that priority in ascending order so that the ruleset with the lowest priority value is executed first, followed by the ruleset with the second-lowest priority, and so on.

You set the ruleset execution priority in the ruleset maintenance screen of the BRFplus workbench. To accomplish this, enter the desired value as Priority in the Detail section.

Note Note

In contrast to the general rule outlined above (lower priority number means higher priority), the system treats the default value 0 differently. A priority of 0 means that there is no priority at all for such a ruleset. In other words, a ruleset with priority 0 is triggered only after all other rulesets of the same function that have a priority > 0 assigned have been executed. The system gives you a visual hint for that by displaying “undefined” in the priority column for a ruleset with priority level 0, whereas for all other priority levels, the numeric value is displayed.

End of the note.
Dependencies, Cardinality, and Visibility

The relationship between a function and its assigned rulesets is not absolutely obvious at first glance. For a better understanding of the underlying concept, keep the following in mind:

  • Function and ruleset are modeled in a 1:n relationship. That is, one function can have any number of rulesets assigned, whereas a ruleset can only be triggered by exactly one function.

  • The relationship between function and ruleset is established from the ruleset's perspective, not vice versa. As a consequence, the system keeps track of which function is assigned to a particular ruleset, but not the other way round. This means that a function does not know the rulesets for which it is assigned as a trigger. This is true although the assigned rulesets of a function are listed in the BRFplus workbench for a function.

  • The one-way perspective from ruleset to function is also reflected in the following aspects of the system behavior:

    • If a function has been assigned to one or more rulesets as a trigger, these rulesets are shown in the where-used list of the function, but not in the Uses section of the repository tree in the BRFplus workbench.

    • When you activate a function and request that also the subordinate objects of the function are activated if necessary, this recursive activation does not touch any rulesets for which the function may have been assigned as a trigger.

      The same applies for all other activities related to a function that can be carried out recursively, like copying or checking a function. Here, too, any rulesets to which the function may be assigned are not taken into account.

Code Generation

BRFplus 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, BRFplus 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 BRFplus, 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.

Generation Services

For a BRFplus 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 BRFplus function is hosted and other systems or environments that wish to access BRFplus. 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 BRFplus function from your application in the same system.

  • Function Module

    You can use a generated RFC-enabled function module to call a BRFplus function that resides in a remote backend system. This is useful in cases where you cannot bring BRFplus 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 BRFplus 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 BRFplus and generates additional system objects needed for service enablement.

Code Templates

BRFplus comes with predefined code templates that you can use to let the system generate an ABAP code snippet. After having made some minor adaptations to this snippet, you can copy and paste it into the code section of your application from where you want to invoke BRFplus rule execution. You can choose whether the function is called with or without trace information, and you can decide whether the explanatory in-line comments are visible in the code or not.

Web Service and Function Module Support

For function invocation, BRFplus supports the generation of web services as well as of RFC-enabled function modules. This enables you to integrate the rule execution power of a BRFplus function into a service-oriented software environment, or into a remote ABAP system calling BRFplus via RFC (Remote Function Call).

Advanced Checks

In addition to the standard consistency checks that are available for each BRFplus object via the Check button, the system offers additional checks for functions:

  • Assigned Rulesets

    With this check, the system analyses the correctness and consistency of all the rulesets that are assigned to a function. This check is only available for functions running in Event Mode or Functional and Event Mode.

  • Lean Trace Readiness

    With this check, the system drills down through the hierarchy of all objects assigned to a function and determines whether there are any objects for which versioning has not been switched on. If any such object is found, the function is considered not to be ready for tracing because tracing of a function is only possible if all involved objects are under version control.

  • Inactive Objects

    With this check, the system drills down through the hierarchy of all objects assigned to an activated function and determines whether there are any objects that are currently inactive. For each inactive object, the system sends a corresponding message to help you analyze the object. However, due to technical restrictions of the system architecture, it may sometimes be impossible to present the complete path to the inactive object in the message. In such a case, you have to look up the respective object manually.

    Note Note

    According to the cascading activation strategy of BRFplus objects, a situation where an active object is using an inactive object can normally not occur. However, the following scenarios are valid and can lead to this kind of situation:

    • An active function run in functional mode uses an active top expression (or any of its dependent objects) that is changed and deactivated at a later point in time. Here, the function remains active. When the function is processed, it uses the last active version of the top expression, not the latest inactive version. In this scenario, reactivating the function solves the issue.

    • An active function run in event mode has been assigned to an inactive ruleset. Here, the BRFplus activation strategy cannot directly detect the problem because the relationship between functions and ruleset is internally modeled such that only a ruleset knows its assigned function, whereas a function is not aware of its assigned rulesets. As a consequence, reactivating the function does not solve the issue. Rather, you have to activate all assigned rulesets.

    End of the note.

    This check is especially helpful if rule modeling is set up as a shared task with several involved persons with different responsibilities. In this kind of working scenario, it can easily happen that changes to dependent objects are made that are not brought to your attention. The Inactive Objects check lets you keep track of such unexpected changes.

More Information

Modes of Operation

Building Functions

Generating Web Services and Function Modules

Expressions

Ruleset

Tracing

Versioning