The Declarative Process Intermediate Language (DPIL) is a declarative process modelling language that allows for specifying multiperspective and multi-modal exible, processes. The DPIL Framework provides a tool set for supporting exible and multi-perspective business processes based on the language DPIL. The DPIL Navigator 2.0 depicts a declarative execution engine for enacting models. It comprises a web-based responsive user interface which allows process participants to choose and perform tasks and o ers enterprise content management (ECM) functionality. In this demo paper, we present a declarative execution system that covers all process perspectives, in particular data and resource handling. The presented process execution software enhances and extends previous versions of the tool by several new features.
Background and Signi cance to BPM
In exible business processes the exact ow of activities cannot be fully
determined at design time. These processes require highly exible IT support. Flexible
processes are common in healthcare where, e.g., patient diagnosis and treatment
processes require exibility to cope with unanticipated circumstances.
Declarative models de ne execution constraints that the process has to satisfy [
In this demo paper, we present a declarative process execution system that
covers all process perspectives, in particular data integration and resource
handling. The Declarative Process Intermediate Language (DPIL) [
DPIL Navigator 2.0: Overview and Demo Guidelines In this section, we will brie y explain the functionality of the new DPIL Navigator 2.0 by means of a concrete example process. 2.1
DPIL Clinical Example Process and Case Study The following model is a sketch of a exible clinical evidence application process and contains many of the keywords and structures of the DPIL grammar: use group Doc use relationtype memberOf use repository FileStore {
url "http://..." user "UserID1" password "pw" id "-default-" } sequence(t1, t2) iff start(of t2 at :t) implies complete(of t1 at < t) produces(t, d) iff complete(of t at :t) implies write(of d at < t) process ClinicEvidence "Impose Clinical Findings" { task NF "Impose neurological finding" task CD "Get confinement of discretion" task PF "Impose psychopathological finding" document _NF "Neurological finding" at FileStore variable _CD "Confinement of discretion" variable _PF "Psychopathological finding" ensure produces(NF, _NF) ensure produces(PF, _PF) advise "Confinement of discretion should exist": sequence(CD, NF) advise "Confinement of discretion should exist": sequence(CD, PF) advise "Confinement of discretion should be obtained by a doctor": start(of CD by :i) implies relation(subject i predicate memberOf object Doc) milestone "findings imposed ": complete(of PF) and complete(of NF) }
First, the group Doc and the relation type memberOf of the organizational management system is referenced to make them usable in the model. Afterwards the connection to a CMIS1 compatible ECM system FileStore is de ned which enables the process to access documents of this repository. Furthermore the macro de nitions sequence and produces conclude the head section of the model. The macro sequence depicts a simple temporal dependency between two tasks while produces requires a value for a certain data object before a certain activity can be completed and, thus, describes an outgoing data dependency. The model describes the process of a clinical evidence application and separates it into the activities NF (impose neurological nding), CD (Get con nement of discrection) and PF (Impose psychopathological nding). Three data objects are part of the process. These are the document NF (Neurological nding), and the in-process variables CD (Con nement) and PF (Psychopathological nding). Below the described entities of the model two mandatory (ensure) rules require that the data objects NF and PF have to be written before the corresponding tasks NF and PF can be completed. The subsequent soft rules (advise) recommend that the con nement of discretion is available before performing the examinations. The third advise recommends that the con nement is obtained by a doctor. A milestone is reached and the case is completed after imposing both ndings. 2.2
The demo will show the functionality of the DPIL Navigator 2.0. The tool is based on the execution principle as visualized in Fig. 1. Tasks of a DPIL 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 1Dehctltapr:a/ti/vwewewx.eocaustiiosn-oapsena.polragn/ncinogmmiistsuteee–s/Sctempi-sby-step interpretation t0
t1 activity : Register performer : Alice action : ► activity : Register apcetrifoonrmer :: ✓Alice t2 activtiy : Impose Finding performer : Bob action : ► activtiy : Impose Finding performer : Alice action : ► activtiy : Confinement performer : Alice action : ► t0
t1 activity : A performer : Alice action : ► activity : A apcetrifoonrmer :: ✓Alice t 2 activtiy : Impose Finding performer : Bob action : ► (-1, 0, {R1}) activtiy : Impose Finding performer : Alice action : ► (0, -1, {R2}) activtiy : Confinement performer : Alice action : ► (0, 0, {}) DR. STEFAN SCHÖNIG
UNIVERSITY OF BAYREUTH series of past events. Besides elements like tasks a process may specify rules constraining that series of events. When the model is executed, the engine simulates one event ahead for every element and evaluates the resulting series of events. Each event that does not violate any ensure rule is related to an action that the engine interprets immediately. A simulated start of a task by a certain participant is interpreted as the assignment of this task to the user. If an event violates an advise rule, the action is marked as not recommended.
The tool o ers enterprise content management (ECM) functionality in form of the integration of the Alfresco CMIS system2 where process data is stored and managed. The web-based responsive interface of the DPIL Navigator is visualized in Fig. 2. Currently available human tasks and reached milestones are shown on the left hand side of the screen. Di erent modalities are encoded by means of di erent colours, i.e., actions that violate certain soft rules are highlighted by orange colour. The right hand side shows activity details, data variables and documents from the connected document store that the current user is allowed to interact with. The DPIL Navigator with some example processes deployed is accessible at http://navigator.kppq.de. 2.3
The presented software enhances and extends previous versions of the tool [
Maturity, Prototype, Screencast and Future Work The DPIL Navigator 2.0 is a well-evaluated prototype that is used for demonstration in academia as well as in industry. The DPIL Navigator with the example process deployed is accessible at http://navigator.kppq.de. A screencast is available at https://youtu.be/X0nrOHr4Bzk. The contribution of this tool demo is to show that also declarative process execution systems are ready to use for practical applications. For future extensions, we are currently developing a graphical DPIL editor to facilitate modelling.