The DPIL Navigator

After specifying DPIL models they are compiled to an executable file that can be enacted by a rule-based execution engine, the DPIL Navigator.

The technologies currently used for supporting (business) processes mainly originate from the field of automation. Participation of people in these automation processes is usually low and the paths are mostly predetermined. The strength of the according systems lies in the orchestration of services and applications (cf. BPEL). They are not intended to explain their actions to human participants. Contrary to automation are processes which are mainly driven by human participation (human-centric processes). The activities performed must be flexible within certain boundaries. This requires differentiating between e.g. legal requirements and best practice already during the process design phase. The main function of a system supporting such processes therefore consists in supporting human collaboration. Therefore, it has to explain its actions to support informed decisions by the participants.

A crucial part of the project is an innovative representation of processes. The declarative process modelling allows for avoiding over-specification, modelling the causes of temporal sequences and differentiating between “hard” (e.g. legal) and “soft” (e.g. best practice) restrictions. The Process Navigation system allows the participants to take every path that has not been excluded and supports them on the basis of soft restrictions. In the example legal requirements would be adhered to in every situation and best practice would be recommended. The system’s design follows the architecture of a workflow engine. This eases its integration into existing infrastructures in place of a classic workflow engine. The declarative execution component forms the core of the system. The latest technologies for calculating and evaluating the next steps enable a scalable execution of real-world processes.

Tasks of a DPIL process model undergo a life cycle composed of events that is managed by the engine. A task, e.g., can be started and completed. The current state of a process is then the series of past events (1). Besides the static elements like human tasks, e.g., Apply for trip and Approve application, a process model may specify rules constraining that series of events, e.g., sequence(Apply for trip, Approve application). When the model is executed, the engine simulates one event ahead for every model element (2) and evaluates the resulting series of events on the basis of the rules (3). Each simulated event that does not violate any ensure rule is related to an action that the engine interprets immediately (4). A simulated start of a task by a certain participant, e.g., is interpreted as the assignment of this task to the participant. If the start event violates an advice rule, the action is marked as not recommended.

The principle is demonstrated w.r.t. two different instances "Business trip to Innsbruck" of the example process. Fig. 2 shows the web-based worklist for a non-student, e.g., a professor. The task Approve Application is not visible since its execution violates the mandatory (ensure) sequence rule. The execution of the other tasks, however, is possible. Fig. 3 depicts the worklist for a student. In case of a user in role Student, the execution of the task Book flight violates the recommended (advice) roleSequence rule. Note, that the execution of the task is still possible, however, the violation of the rule is highlighted through orange colour and the indication text from the model. Fig. 4 shows the task worklist for a third person in the situation where the trip application has already been started by the professor. In this case the execution of Book flight violates the recommended binding rule, i.e., the flight should be booked by the applicant herself.