Rules in Business Process Descriptions

Business process descriptions lay out how agents (e.g. business partners, employees) interact in order to successfully accomplish a given goal. In this respect, business process descriptions fit our introductory definition of business rules (c.f. Section 4.1): they form statements about how a business is done and they govern the behavior of the involved participants, which can be both humans and information systems.

A business process description – often also called a workflow or business protocol – is com-prised of a number of steps (tasks, activities), dependencies among those steps, routing rules, events and a description of the participants and their roles.

The formal description of (business) processes and other stateful systems has been subject of intensive research for many years. Well known formalisms to describe such dynamic systems are Petri Nets [60], Statecharts [41], UML sequence diagrams [58], the pi-Calculus [52] and various types of action logic (e.g. Concurrent Transaction Logic [14]).

These theoretical frameworks form the logical foundation of several of the currently relevant business process description languages, e.g. the Business Process Execution Language for Web Services (BPEL4WS) [71] (which is based on Petri Nets).

In the following we will describe how rules of the kind we outlined above in Section 4.2 can be found in the description of business processes. We use the classification presented in [59], who distinguish structure related, role related, message related, event related and constraint related rules.

Structure Related Rules

Structure related rules describe how the tasks of a process are interconnected with each other, i.e. how they are grouped and which interdependencies exist between the activities.

S1 S0

t1: [C1] A1

t2: [C2] A2 t3: [C3] A3

S2

Figure 4.2: An automaton based abstraction of a business process

This kind of information is normally captured by the underlying process model, e.g. by a Petri Net or a Statecharts model. However, we can encode that information using rules as an alternative notation.

The transformation of an automaton to a set of rules (and facts) is a straightforward under-taking; for example, consider the automaton shown in Fig. 4.2; it is comprised of three states S0, S1, S2 (drawn as circles) and three transitions t1, t2, t3 (drawn as arrows), which describe how the process evolves. Each transition tn is guarded by a condition Cn and is associated to an action An, which will be executed during the transition. This semantics can be represented by the following set of facts and production rules:

(in-state S0)

(def-rule t1: (def-rule t2: (def-rule t3:

(and (in-state S0) (and (in-state S0) (and (in-state S1)

(C1)) (C2)) (C3))

=> => =>

(execute-activity A1) (execute-activity A2) (execute-activity A3) (retract (in-state S0)) (retract (in-state S0)) (retract (in-state S1)) (assert (in-state S2)) (assert (in-state S1)) (assert (in-state S2))

The fact (in-state S0) tells the rule engine that the described system is in state S0 initially.

Each of the rules t1, t2, and t3 represent the transitions; for instance, rule t1 will fire if the system is in state S0 and if condition C1 is satisfied, just like the transition defined by the automaton. The execution of the rule t1 will lead to the transition from state S0 to state S2, along with the execution of the associated action A1.

Role Related Rules

Role related rules govern the participants that are involved in a process. In [59], role assignment rules are proposed to assign an activity to a certain role. For instance, in an e-commerce transaction, we could use a role assignment to assign the activity of the delivery service to a carrier.

if (delivery action is performed) then (Role-type is Carrier)

Other role related rule types are role binding rules, i.e. the assignment of a role to a particular business entity, and event raiser rules, which may trigger events related to the roles.

Message Related Rules

Message related rules regulate the use of information in a process; it is assumed that the entities propagate information by exchanging messages. A message is a data structure, for instance a tree based XML document. In [59], three types of message rules are proposed: message distribution rules which govern the distribution of messages , message assignment rules which assign messages to activities, and message dependency rules which can be used to derive the dependencies between messages.

As an example, consider the following rule:

if(FlightBookingActivity has Input)then (Message contains (departureDate, arrivalDate, fromAirport, toAirport)

The rule above is a message assignment rule for the input of the flight booking activity, expressing that the input assigned to that activity has to contain departure and arrival date, and the departure and arrival airports.

Event Related Rules

Event rules govern the behavior of processes in reaction to expected or unexpected events.

Activity influence rules regulate which activities are affected by which events. To determine which events are handled by which event handler activities (i.e. which activities should be carried out in case certain events occur), event handler rules can be defined.

As an example, consider the following rule:

if(delivery time exceeded) then (send email to customer)

This event handler rule indicates that if there are unforeseen troubles with the delivery, the customer must be notified.

Constraint Related Rules

These rules steer the use of constraints in a business process, represented by the pre- and post-conditions of the activities involved in the process. A pre-condition describes the requirements that must hold in order to achieve any of the activity’s results. If a pre-condition is not fulfilled and an activity is still carried out, the results are undefined. A post-condition describes the effects the execution of the activities will achieve. If an activity is carried out with a valid pre-condition, we can expect that the effect formula will evaluate to true in the world state after the activity is completed, given that no errors occur.

The following rule is an example of a postcondition:

if(FlightBookinActivity is completed) then (Seat must be reserved) A more thorough discussion of the specification of activities is given in Chapter 3.