With a log message action, you can define system messages that the system writes into the application log during rule processing under certain circumstances. This can be useful for documenting the flow of processing in an application, and may even be legally required for auditing purposes, depending on your business case, region, and legislation.
Whether messages shall be logged at all, and if so, to what extent, depends largely on the respective settings for the application object to which a log message action belongs. All of these settings on application level are inherited by the log message actions. It is also on application level where you can define whether the default settings for log handling may be individually adapted by an action, or whether these settings represent a fixed guidance that must be followed.
Note
You can use report FDT_DEPLOYMENT_LOG
to analyze the application logs of BRFplus.
The following table lists the features related to the logging details:
Setting |
Comment |
---|---|
|
Defines the application log objects used for recording the log entries that are created by objects belonging to the application (for example, actions of type |
|
Defines whether an additional tag shall be added to the log entries, and if so, how this shall be accomplished. You can choose from the following options:
|
|
Controls whether the log data shall be permanently stored in the database or not. If not, log data is only kept in memory during runtime and is lost after the session. |
In the Log Messages
area, you define which messages shall be written to the log when the action is triggered. You can assign any number of messages to each log message action.
You can decide either to enter a free message text or to make use of any of the messages that already exist in the system. If you use an existing message, you have to enter the message class and number. Also, if the message contains parameters, the workbench prompts you to provide values for these parameters. Here, you can choose again between either providing a freely defined text for the parameter, or to assign a data object or expression that is evaluated at runtime.
Regardless of whether you define a free text message or reuse an existing message, you must define the message type. The following message types are available:
Abort
Error
Exit
Information
Status
Warning
Note
Should any of the message types listed above not be available for an action, this is due to a message type restriction that has been defined on application level.