Execution of process models requires a process engine to handle control flow and data dependencies. While control flow is well supported in available activity-oriented process engines, data dependencies have to be specified manually in an error-prone and time-consuming work. In this paper, we present an extension to the process engine Activiti allowing to automatically extract complex data dependencies from process models and to enact the respecting models. We also briefly explain required extensions to BPMN to allow a model-driven approach for data dependency specification easing the process of data modeling.
Today, organizations use process-oriented systems to automate the enactment of their
business processes. Therefore, processes are often captured in process models focusing
on the activities being performed. These models are executed by process engines as, for
instance, YAWL [
For the enactment of tasks, data plays an important role, because data specifies preand postconditions of tasks. A precondition requires the availability of certain data in a specified state while the postcondition demands certain manipulation of data. In modern activity-oriented process engines as mentioned above, these and further complex data dependencies (e.g., creating and updating multiplicity relations between data objects) have to be implemented manually through a process engineer by specifying the respective data access statements (see shaded elements in Fig. 1 left); this is an error-prone and time-consuming work.
In this paper, we explain an approach to model data dependencies in the process model itself and automatically derive data access statements from the process model as shown in Fig. 1 right. Process data utilized during activity execution is out of scope in this paper. We demonstrate the feasibility of this approach using the industry standard Process Designer Process Participant Business Process
Modeling
Business Process Model Repository
Graphical User Interface
Invoked
Applications Process Engine
Process Engineer
Data access statements Database
Business Process and Data Modeling Business Process Model with Data
Repository
Graphical User Interface
Invoked
Applications Process Engine
Database
for process modeling, the Business Process Model and Notation (BPMN) [
Next, Section 2 shows how to model complex data dependencies in BPMN; Section 3 shows how three simple conservative extensions of the industrial process engine Activiti suffice to enact complex data dependencies from a BPMN model. We conclude in Section 4. 2
BPMN provides the concept of data objects that are associated to tasks [
Figure 2 shows a standard BPMN model of a sim- case object: Order plified build-to-order pro- r [reOcrediveerd] [reOjerdceterd] [coOnfridremred] [Osrednetr] cess of a computer manufac- reu pk: o_id pk: o_id pk: o_id pk: o_id tscueertsesri,na(inigtnaOloirrcdisne)g.r Itahnnanttohwtiasatsiporrnoes-- frttcaaeunuM Cohrdeecrk coCmrlpeisoatnteent Porordceerss cfierisvteCdhfercokmedaancdusetoitmheerr ries- opCm Co[[ncmerwep]aotneedn]ts jected or confirmed. If it is pfkk::IcoIp__idid confirmed, task Create component list creates several Fig. 2. Build-to-order Process of a Computer Manufacturer Components to be ordered; based on these components the order is processed in a subprocess and, when completed, the Order is sent to the customer.
In BPMN, each data object has a name and a set of attributes of which one describes the state of a data object. Data flow edges express pre- and postconditions to the different tasks, e.g., Check order is only enabled if object Order exists in state received in the current process instance. However, when handling multiple orders in different instances in parallel, the process model does not express which order is correlated to which process instance. Likewise, BPMN cannot describe create, read, update, and delete operations on one or more objects of the same kind, possibly in 1:n or m:n relationship to other data objects. For instance, one cannot express that task Create component list of Fig. 2 creates several new Component objects and associates them to the Order handled in the process. Such data dependencies would have to be implemented manually.
In [
Most importantly, these annotations have operational semantics. In [
We implemented the approach of Section 2 to show its feasibility. In the spirit of adding
only few data annotations to BPMN, we made an existing BPMN process engine
dataaware by only few additions to its control structures. As basis, we chose Activiti [
First, we extended the XML specification by utilizing extension elements, which the BPMN specification explicitly supports to add new attributes and properties to existing constructs. We added the case object as additional property to the (sub-)process construct. The data object was extended with additional properties for primary key (exactly one), foreign keys (arbitrary number), and the data access type as attribute. The BPMN parser of Activiti was extended to read BPMN data objects with the new attributes and properties, and data associations. <exte.an.ss.ion> </extension>
BPMN Data Objects
Control Flow and Resource pre
A post loop [ resultSet.size() == 0 ]
SELECT ... FROM PRE WHERE ...
resultSet
Activity Behavior
UPDATE POST ... .bpmn file
Parser
Internal Representation
Engine
The actual execution engine was extended at two points: before invoking the execution of an activity to check the preconditions of an activity and before completing an activity to realize the postconditions, both with respect to data objects. At either point, the engine checks for patterns of data input and output objects and categorizes them. For instance, in Fig. 2, Order is input and output to Check order in different states. The engine classifies this as a “conditional update of case object Order”. The data operations at task Create component list would be classified as “conditional creation of multiple data objects that depend on the case object (1:n relationship)”. Classification proceeds from most specific to most general patterns.
When invoking an activity, for each matching precondition pattern a corresponding SQL select query is generated to read whether the required data objects are available. The query assumes that for each data object of the process model exists a table holding all instances of this object and their attributes. If there is an object instance in the right state, the SQL query returns the corresponding entry and is empty otherwise. The engine repeatedly queries the database until an entry is returned (i.e., the task is enabled), as shown in Fig. 3. Then the activity is executed. Upon completion, an SQL insert, update, or delete query is generated for each matching postcondition pattern, and executed on the database.
Altogether, we had to extend Activiti at merely 4 points to realize our concept, as illustrated in Fig. 3: (1) at the XML, (2) at the parser and internal representation, (3) when checking for enabling of activities, and (4) when completing an activity. The extensions required just over 1000 lines of code with around 600 lines being concerned with classifying data access patterns, generating, and executing SQL queries. The extended engine, a graphical modeling tool, example process models, a screencast, and a complete setup in a virtual machine are available together with the source code at http://bpt.hpi.uni-potsdam.de/Public/BPMNData. 4
In this paper, we presented an approach how to automatically enact complex data
dependencies from activity-centric process models. They key concepts required are
data objects associated to tasks; a few annotations allow to express relations between
data objects and the particular data operation. Our modeling tool helps to easily specify
the required annotations in a graphical user interface. From these annotations, SQL
queries can be automatically generated and executed from a process engine, covering
all fundamental data access operations: create, read, update, and delete of single data
objects and of related data objects in 1:n and m:n relationship [
Compared to other techniques and engines for enacting data dependencies from
models, our approach is less intrusive. The object-centric modeling paradigm [
Acknowledgements. We thank Kimon Batoulis, Sebastian Kruse, Thorben Lindhauer, and Thomas
Stoff for extending the Camunda modeler [