These days Business Information Systems (BIS) have a highly responsible task: they execute large parts of the business processes autonomously. So organizations become more and more dependent on their BIS. Business processes usually require a certain order in which activities have to be executed. On top of that, there are many other business rules that should be met by the execution of business processes, e.g., the famous Sarbanes-Oxley rules (cf. [1]) and the General Accepted Accounting Principles (GAAP). Business rules can be required by any stakeholders, such as management, government, shareholders and business partners, both clients and suppliers. In this paper we take it for granted that a BIS has some unknown errors and that the system is for all stakeholders more or less a black box. Instead of a human auditor we propose here an approach where the BIS is extended by an independent monitor system that checks the essential business rules on the fly and that reports violations of business rules or that interrupts the BIS to prevent the occurrence of a violation. As basic terminology we use workflow notions such as task, case, agent and resource. This is consistent with the terminology for accounting information systems where the REA (Resource, Event and Agent) data-model is used frequently. This model is an Entity-Relationship model for accounting information systems [2-4]. We assume that business processes are described by traces which are here defined as sets of events where events are partial functions that map event properties to property values. Event properties can be either a standard mandatory property such as time, case, task, agent or a certain type of resource that is involved in the event such as money or used materials. A property value can be either a task name, an agent, a basic value, or a rational number where the latter is also used to represent time stamps. The values of standard properties are restricted so they have property values of the right type. The syntax of the BRL, the business rule language we present here, is defined by the following abstract grammar:
F ::= ¬F | (F ∧ F ) | PS = E, . . . , PS = E | E = E | E < E.
E ::= X | DS | Σ(X : F )E | (E + E).
Here F denotes boolean formulas and E expressions that return a property value. The non-terminals PS and DS represent event properties and property values, respectively, and X represents variables that range over property values, which includes time-stamps. The value of the formulas and expressions are defined w.r.t. to a certain trace. There are three special workflow constructs with specific workflow semantics: formulas of the form e1 < e2, formulas of the form p1 = e1, . . . , pk = ek and expressions of the form Σ(x : ϕ)e. The first compares the values of e1 and e2 according to the ordering defined over the property values, which includes the time ordering over time-stamps. The formula p1 = e1, . . . , pk = ek states that the trace contains at least one event ev such that ev(p1) = v1, . . . , ev(pk) = vk where v1, . . . , vk are the values of the expressions e1, . . . , ek for the trace. The expression Σ(x : ϕ)e is a sum quantifier which sums the values of expression e for each property value x that occurs in the trace and satisfies the formula ϕ. For example, Σ(xt : (xt = xt))(Σ(xp : time = xt, payed = xp )xp) computes the total amount of money payed.
The sum quantifier allows us to formulate business rules about aggregates of used and produces resources such as “for each case at each moment the total amount of used bread does not exceed the amount of previously delivered bread”. In addition it can also be used to formulate more standard workflow rules concerning precedence, such as “an event for task a is always followed by an event for task b”. For example, the formula (Σ(x : time = x, task = a )1) > 0 checks if at least one event for task a has occurred.
In the full paper it is shown how for certain types of rules in BRL we can
define a monitor system that is able to check them on the fly and in parallel to a
business information system. This is done by translating parts of the evaluation
of business rules into the execution of a Petri net [