Show TOC

Background documentationSimulation


Simulating the processing of a function, expression, or action is useful to test the object'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.

Note Note

Although simulation is a tool that lets you easily test the object behavior, the object to be run in simulation mode must have been saved before. Changes to an object that you have only made on the fly without saving are not reflected in simulation mode.

End of the note.


The function and all of its referenced objects (both direct and indirect) are active, or there is at least an older active version available in the system (prerequisite valid only for simulation in generation mode).


Simulation Mode

The simulation tool offers the following modes of operation:

  • Interpretation Mode

    In this mode, the system uses the objects involved in the simulation by drilling down through their design-time definition. For a quick one-time simulation run, this can be faster than using generation mode. Direct simulation of expressions or actions (that is, without being assigned to a function) is supported only in interpretation mode.

  • Generation Mode

    In this mode, if there is no source code available for the function, the system first generates source code for the objects involved in the simulation when you click Execute. This leads to a short execution delay because of the time needed for the generation of classes and methods. However, using generation mode has the following advantages over interpretation mode:

    • Executing generated code is much faster than interpreting the structure of the objects involved every time the simulation is run. Especially if you want to simulate a function that is the entry point to a very complex structure of rulesets and expressions, or if you need to simulate a function in many iterations with different test data, it is usually recommendable to use generation mode rather than interpretation mode.

      Moreover, code generation is only necessary if any of the involved objects has been changed since the last time code was generated. If no changes have been made, the system immediately loads and executes the source code that is already available, thereby further accelerating execution.

    • In generation mode, simulating a function is done in exactly the same way as the system executes the function in a live system at runtime. Therefore, generation mode gives you an exact preview of the function's live behavior in terms of performance or potential problems.

    Note Note

    Generation mode can only be used with functions, not with expressions or actions. Also, only functions that are currently active or for which an active version exists can be simulated in generation mode.

    End of the note.
Action Settings

When you perform a simulation, it is normal that you want to investigate the system behavior without causing any effects that could interfere with productive business processes. Running a simulation as an isolated process is relatively secure as long as there are only expressions and rules to be simulated. As opposed to that, things can be different if during the simulation, actions are triggered. Actions can trigger system activities that go beyond the boundaries of BRFplus and may have a significant impact on current business processes. For example, under normal circumstances you would not want a simulation to send real emails to real persons, or to start a system workflow.

Because triggering actions can have these unwanted side effects, actions are by default only partially executed during a simulation run, thereby bypassing all business-critical steps. However, if you need to know whether a triggered action is working properly, you can force the system to trigger actions during simulation by setting the Execute Actions flag.

Note Note

To avoid any misconceptions, here is a more detailed explanation of what the Execute Actions flag does internally and what not:

  • From a technical perspective, actions that are part of the execution path of any function, expression, or superordinate action to be simulated are always executed. This is true regardless of the setting of the Execute Actions flag. As a consequence, actions are always shown in the detailed simulation log. Also, if you are debugging a simulation session, you will realize that the system actually processes the code related to an action.

  • However, with the Execute Actions flag set to false, the system processes the code related to an action but, unlike normal processing, does not commit the pending changes or activities defined for the action before exiting the action-related source code. With this execution strategy, you can check the system behavior during simulation to the largest possible extent, but still without having to care for any unwanted side effects as outlined above.

End of the note.
Object Types

The simulation functionality is basically a feature offered for BRFplus functions. However, you can also directly simulate a particular expression or action without having to assign it to a function first. This makes it easier for you to quickly check the runtime behavior of your expressions.

Note Note

From the system's perspective, simulation is always done for a function. This is true even if you choose to directly simulate an expression or an action. In that case, the system automatically creates a temporary function in the background, assigns the expression or action to it, and then simulates the temporary function.

End of the note.

If the object that you want to run in simulation mode is under version control, the system lets you decide which of the available versions should be simulated. You can choose from the following options:

  • Last Active Version

    With this option, the system checks the version list of the object for the most current version that has been activated, starting with the current version and then moving back to the past. If the object has never been activated (or if there once was an active version that has been deleted in the course of time), starting the simulation with this option will raise an error message. This option is the version default for simulation runs.

  • Latest Version (Inactive)

    With this option, the system uses the most recent version of the object for the simulation, even if it is currently inactive. This allows you to check the effects of a change even in a productive system without endangering the correctness of rule processing for real business transactions. It is up to you to decide whether the simulated behavior should be made productive or not: If yes, activate the object; if not, revert the object to its previous active version (or simply leave the changed object without saving). This option is only available for objects whose current version is not active.

  • As of Date/Time

    With this option, you can define a point in time for which you want to simulate how the runtime behavior of the object in question would have been at that time. The system compares the given date and time with the time stamps of the object versions that have been stored in the database. The system looks up the next available active version of the object that has been activated earlier than the given date and time. If such a version exists, it is used for the simulation. Otherwise, the system raises an error message. This option is only available for objects for which versioning is set on.

Context Data

For simulating a function or expression, the system offers two different ways of passing values to the context data objects of the object to simulate:

Manual Data Entry

In this mode, the system offers you an entry field for each context data object (broken down to each data object's elementary constituents). Once you have entered the desired values, you can execute the simulation and check the result.

Test Data Import

In this mode, you can import test data for the simulation that have already been collected in an external spreadsheet file. This is helpful for the following reasons:

  • If you have a complex scenario with a wide variety of different input data, using a spreadsheet can help you to automatically generate the necessary test data. This takes away the burden from you of having to enter endless lines and columns of data, which can be both tedious as well as error-prone.

  • Executing the simulation in batch mode for all records in the import data file produces a result file where you can find the calculated result for each combination of input data. This result file can serve not only as a simulation log but also as a means of process documentation that helps you to prove which context data records have already been tested in the simulation.

If you want to use the test data import for the first time for a particular function or expression, we recommend that you start using the Create Import Field Structure function first. With that, the system creates a spreadsheet file that reflects the structure of the context data exactly as it is expected by the import function. You can then populate this export file with test data and finally import the data for simulation.

Once you have your test data ready for import into the simulation, there are two approaches for processing the data:

  • Single data processing: With this approach, you select always one of the imported test data records per simulation run. You can then choose between the simple Execute option (only the result is displayed after simulation execution) or the detailed Execute and Display Processing Steps option (a detailed log of all the calculation steps is displayed). Note that both options are only available if there is no more than one record selected for the simulation.

  • Batch processing: With this approach, you can select any number of the imported test data records and let the system do a simulation for each of them. To accomplish this, proceed as follows:

    1. In the simulation tool, make the desired adjustments with respect to the selection and click Continue.

    2. In the Simulation Data section, choose Import Test Data, select the spreadsheet file that contains the data, and choose Import.

    3. Once you have successfully imported the data, select the records you want to be included in the simulation and choose Export Result to Excel.

    When the simulation is done, the system creates a spreadsheet file that contains one row for each of the selected test data records in which you can find the context data and the calculated result for that context.