Audits of executed decisions

With Decision Warehouse, system administrators and auditors can view and manage stored decisions and traces.

You can configure Decision Warehouse for the environment (test or production) in which Rule Execution Server is running (see Decision Warehouse).

Decision Warehouse uses any database that has a JDBC driver. You can specify more than one data source to support different databases. The trace output data is serialized in a proprietary XML format that supports the capability to query Decision Warehouse from the Rule Execution Server console. Using the query feature, you can define filters on the specified data source so that the console displays only the events or decisions in which you are interested.

By separating Rule Execution Server and Decision Warehouse for your test environments, you prevent performance loss on the production system and keep the test and production execution traces separate. In the production environment, the Decision Warehouse database must be periodically archived. Archiving the database keeps its size manageable and isolates the query database from the production database. In a test environment, users can write applications and enable ruleset monitoring to see which rules were executed for each test scenario.

With Decision Warehouse, system administrators and auditors can view and manage stored decisions (execution details or traces). A trace contains information of how a decision was computed: what rule flow was executed, the path to the executed rule flow tasks, which rules were executed, and other relevant execution information.

Each call to a rule makes a database call to log the trace information. The querying and auditing features of Decision Warehouse are supported through the Rule Execution Server console. To avoid concurrent access from real-time logging and querying, you must specify an archive trace database as the target data source for querying in the console.

To further optimize performance, you can have JMS write the trace output asynchronously to Decision Warehouse. Writing asynchronously to Decision Warehouse applies especially if the Decision Warehouse database is customized to consist of multiple tables that are designed to support queries. In this case, if data is not written asynchronously, it is preferable to write logged data as a CLOB to a single database table.

For auditors to trace a past transaction from the Rule Execution Server console, their permissions must prevent them from modifying rulesets or deleting traces from the data source. The administrator can use the resMonitors user group to give them read-only access through the console. Because auditors often need to understand which policies were applied in a transaction, they must be able to view the actual rule content. To generate hyperlinks to the rules in Decision Center from the console, you must deploy the ruleset from Decision Center and specify the appropriate deployment baseline. Even if there are many versions of a rule in Decision Center, the generated link refers to the version of the rule from the deployed ruleset. To enable the hyperlinks, the auditors need to be granted rtsUser permission in Decision Center.

In some cases, it is necessary to restrict auditors or business users so that they can view only specific transaction histories in Decision Warehouse. For example, if business users of ruleset A must not be allowed to view the transaction history of ruleset B, you must configure the Decision Warehouse target database to a data source that is specific to the client application. As a result of such configuration, trace data for ruleset A is logged to a different database than trace data for ruleset B. For audit purposes, you can install multiple Rule Execution Server consoles and configure each of them to access the trace database for the ruleset that it is monitoring.