Open-source Workflow Evaluation An evaluation of the Activiti BPM Platform. Mikael Nilsson. M.Sc. Thesis within Computer Engineering AV, 30 ECTS

(1)

ECTS

Examiner: Tingting Zhang, [email protected]

Tutors: Anders Trollås, Cybercom Group, [email protected] Fredrik Håkansson, Mid Sweden University, [email protected] Scope: 29901 words inclusive of appendices

Date: 2012-06-29

M.Sc. Thesis

within Computer Engineering AV, 30 ECTS

Open-source Workflow

Evaluation

An evaluation of the Activiti BPM Platform

Mikael Nilsson

(2)

Abstract

The aim of this thesis is to evaluate the newly released open-source business process management platform Activiti. The platform is evalu-ated in the first instance by implementing the control-flow patterns which will be used at a later stage as a comparison with other platforms that have already been evaluated. Activiti comes with a web application called Activiti Explorer which is a graphical user interface between the process engine and the user. As all the desired features commissioned by the Cybercom Group were not available in the Activiti Explorer its source-code was extended. These extended features included support for several companies per installation and the ability to customize the layout of the components in user task forms. The report is concluded with a comparison between Activiti, jBPM, OpenWFE and Enhydra shark with regards to the control-flow patterns.

Keywords: Open-source, Workflow, BPM, BPMN 2.0, Activiti, Work-flow patterns, Control-Work-flow patterns

(3)

Acknowledgements

Thanks to...

 Anders Trollås, my tutor from Cybercom Group, for your help, guidance and support during this thesis.

 Fredrik Håkansson, my tutor from Mid Sweden University, for your help, reviews and valuable advice for my report.

(4)

Terminology

Acronyms

BPM Business Process Management

BPMN Business Process Model and Notation

(10)

Introduction

1

The concept of workflow has its early roots in industrialization and was introduced in order to increase efficiency in production. In the begin-ning, processes were carried out entirely by humans but today processes are carried out partially or totally by computer information systems. According to Medina-Mora et al. [1] processes can be organized into material processes, information processes and business processes. Material processes consist of the assembly and delivery of physical products. Information processes are related to automated computer software that fully or partially perform tasks with interaction from humans. Business processes are a higher level concept and consist of information processes and/or material processes. Business processes describe the organization's activities from a market-centred perspective and are engineered to fulfil a business contract or to satisfy the require-ments of a specific customer. This thesis deals exclusively with business processes implemented as information processes. [1]

The term “workflow” is used casually to refer to a business process, the specification of a business process, the software that implements and automates a process or the software that supports the coordination and collaboration of people that implement a process. What workflow is and which features a workflow management system should support are not fully agreed upon, even the definition of the terms differs among soft-ware vendors. [2]

Georgakopoulos et al. [2] defines the term workflow as a collection of tasks organized to accomplish some business process (e.g., processing purchase orders over the phone, provisioning telephone services, processing insurance claims). A task can be performed by one or more software systems, one or a team of humans, or a combination of these. Human tasks include interacting with computers closely (e.g., providing input commands) or loosely (e.g., using computers only to indicate task progress). In addition to a collection of tasks, a workflow defines the order of task invocation or condition(s) under which tasks must be invoked, task synchronization, and information flow (dataflow). [2]

(11)

workflow system more complex because all process specifications have their weaknesses and their strengths thus making it difficult to choose a process definition language that is suitable for a particular project. This thesis focuses on the Business Process Model and Notation language (BPMN) version 2.0.

The Workflow Patterns initiative was started in 1999 by Eindhoven University of Technology and Queensland University of Technology. The goal of the initiative was to provide a comprehensive examination of the various perspectives supported by workflow systems and their process definition languages. This was conducted by categorizing com-mon constructs used in real world processes. The purpose of the pat-terns is to provide an objective means of evaluating and comparing different workflow platforms and their definition languages. At the beginning they received little attention outside academia but, as of the present time, more and more vendors are evaluating their products and submitting the results to workflow patterns initiative. [3]

This thesis deals with the control flow patterns as described by Wil van der Aalst et al. (2003, 2006) [4][5]. Workflow patterns are related to design patterns in architecture and computer science and were first introduced by Christopher Alexander (1977) [6] in the field of architec-ture and by the Gang of Four 1995 [7] in computer science. Christopher Alexander provides the following definition, Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. [6]

Business Process Management (BPM) extends the concept of workflow by focusing on all aspects of processes within an organization. It has methods to handle both process reengineering and process redesign and it supports the complete business process lifecycle (Design & Analysis -> Configuration -> Enactment -> Evaluation) see figure 1. [8]

(12)

Business process lifecycle Design & Analysis Evaluation:

Process Mining Business Activity Monitoring

Design: Business Process Identification and Modeling Analysis: Validation Simulation Verification Configuration: System Selection Implementation Test and Deployment

Enactment: Operation Monitoring Maintenance Configuration Enactment Evaluation

Figure 1: Business Process Lifecycle [8]

The reengineering addresses the issues of system efficiency, system cost and it explores the use of new advancement in technology. Business process redesign improves the efficiency of business operations, the quality of products, reduces costs, meets new business challenges and increases customer satisfaction. A software BPM platform delivers greater control and visibility over processes and workflow integration with other applications. [8]

Open-source software has grown both in popularity and maturity and is becoming a viable alternative to commercial enterprise business prod-ucts. The advantages associated with choosing open-source software are that there is full control over the source code meaning that it is possible to learn how it works, to modify it, fix errors and continue its develop-ment even after the product has been discontinued. Another benefit is that there are no license fees and free community support is available. For many businesses this is not sufficient and therefore many products offer full professional support and extra features but this involves a fee. The disadvantages of choosing an open-source product are that it might not be sufficiently developed to the degree that it is able to be used in a demanding business environment. Enterprise open-source products are

(13)

their intended user group are more focused towards software engineers than business analysts.

1.1 Background and problem motivation

Activiti [9] is a new open-source light-weight workflow and Business Process Management platform. The development is led by Tom Baeyens and Joram Barrez and it is funded by the company Alfresco [21]. It had its first stable release on December 1st_{2010 and it has been in active} development ever since. The first stable release was version 5.0 and this was because the lead developers had previously worked on jBPM (up to version 4.0) before they left Red Hat to work for Alfresco. Activiti is a relatively new product and it lacks proper independent evaluations and scientific reports. Petia Wohed et al 2007 [10] conducted a pattern-based evaluation of the open-source BPM systems, jBPM version 3.1.4 [11], OpenWFE version 1.7.3 [12] and Enhydra Shark version 2 [13]. The process definition languages used were jBPM Process Definition Lan-guage (jPDL) for jBPM, XPDL 1.0 for Enhydra shark and the OpenWFE process definition language for OpenWFE. They used the patterns from the workflow pattern initiative as the basis for their study. As of today this is the only evaluation of open-source BPM products available at the workflow patterns initiative website. Many other BPM platforms and process languages have been evaluated against the workflow patterns and the result can be found on their website [3], but since the focus of this thesis is on open-source platforms the results from other platforms will not be discussed.

At the time of writing, both Activiti and its process definition language BPMN 2.0 have not yet been evaluated by the workflow pattern initia-tive. For this reason the IT consulting company Cybercom Group would like Activiti to be evaluated against both the control flow patterns and as an open-source product. The result from the pattern evaluation makes it easy to compare Activiti with other products. It is also easier to choose an appropriate product for a particular project by looking at its strengths and weaknesses with regards to its supported patterns. The result from the pattern evaluation of Activiti should therefore be com-pared to the result from the open-source BPM evaluation conducted by Petia Wohed et al 2007 [10] to determine which platform is more suita-ble with regards to the control flow patterns.

(14)

Activiti will also be evaluated as an open-source project by modifying and extending the source code to fit the requirements given by the Cybercom Group.

1.2 Overall aim and verifiable goals

The overall aim of this thesis is to evaluate Activiti and detail its strengths and weaknesses. This result from the control flow evaluation should be used at a later stage to determine the suitability of using Activiti in a particular project and to compare it against the other open-source BPM platforms (jBPM, OpenWFE and Enhydra shark). The goal is also to offer a short theoretical overview of the control flow patterns and a brief theoretical overview of the frameworks used by the Activiti open-source project.

In the practical part of this thesis an attempt to implement all the control flow patterns is made. The result should include:

 Table of the evaluation of Activiti against all Control flow pat-terns

 Comparison of Activti, jBPM, OpenWFE and Enhydra shark in regards to their support for the control flow patterns defined in [5]. The pattern support for jBPM, OpenWFE and Enhydra shark are taken from [10].

The Cybercom Group also requested the following extensions and modifications to Activiti Explorer, for creating an extended Activiti Explorer:

 Support for multiple companies within Activiti Explorer

 Support for customizing the layout of user task forms in Activiti Explorer.

 Support to change the main colours and logotypes in Activiti Ex-plorer.

 Support for a business payment model (ex. pay per process in-stance).

(15)

All of the above points must be implemented without changing the source code of the Activiti engine.

1.3 Scope

The theoretical and practical parts of the pattern evaluation will be restricted to the control flow patterns. When conducting the evaluation each pattern is implemented in Activiti Designer and graded with a '+' for direct support, '+/-' for partial support and '-' if the pattern is not supported [30]. Activiti is an open-source platform and the main interest in this study is in relation to the suitability of Activiti when choosing an open-source BPM platform. This, and the fact that the majority of com-mercial software is not provided with source code, is the reason why this study is limited to only open-source products.

Since the extended Activiti Explorer platform is a commission from the Cybercom Group both the theoretical and practical parts will primarily focus on how to achieve the requested features. The evaluation, from an open-source perspective, consists of implementing two extensions and fixing some minor bugs. A brief theoretical presentation of the project and the major frameworks is also provided. Finally a list of all the required changes and the classes created to implement the extensions and fixes will be presented in Appendices C and D.

1.4 Outline

 Chapter 2 introduces the reader to BPMN 2.0 and Activiti De-signer and to the control-flow patterns and then offers a short in-troduction to the foundation of the Activiti source code.

 Chapter 3 describes the methodology used in this thesis.

 Chapter 4 describes the implementation of the patterns and the modifications made to the source code.

 Chapter 5 presents the result of this thesis with tables for the pat-terns and screenshots of the added features.

 Chapter 6 presents the conclusion and discussion of this thesis.  Chapter 7 presents the ideas for future work regarding the

(16)

 Appendix A: contains a list with description of the process con-structs used in Activiti Designer when implementing the pat-terns.

 Appendix B: contains the definitions of all 43 control-flow pat-terns.

 Appendix C: contains a description of how the new features were added to Activiti Explorer.

 Appendix D: contains a description of how the improvements and bug fixes were added to Activiti Explorer.

 Appendix E: contains the XML implementation of the supported patterns.

1.5 Contributions

The author has contributed to the Activiti evaluation of the control-flow patterns, the XML specification for the custom form layout, ex-tensions made to the source-code of Activiti Explorer to support the requirements given by the Cybercom Group and the helper tools to facilitate the use of the extended version of Activiti Explorer.

(17)

Theory

2

This chapter consists of a brief explanation of the BPMN 2.0 notation language, Activiti Designer and the workflow patterns. The last part consists of an overview of the Activiti source code and the frameworks used.

2.1 BPMN 2.0

BPMN stands for Business Process Model and Notation and version 2.0 specifies both a graphical notation language in addition to the XML notation language. It was developed by the Business Process Manage-ment Initiative and is now maintained by the Object ManageManage-ment Group since the merger in 2005. Business processes are modeled using connections, events, activities and gateways. Connections are used to connect activities, gateways and events together. Events are displayed as a circle and denote that something has occurred, for example start and end events. Events can also be throwing and catching events. Activ-ities represent a piece of work that is required to be conducted. The work can be automatic or manual with human involvment. Gateways are a means of splitting up or merging the execution flow in a process. The constructs used when modeling the control-flow patterns are de-scribed in Appendix A. [20]

2.2 Activiti Designer

The Activiti Designer is an Eclipse [22] plugin which allows the process developer to develop BPMN 2.0 processes using a graphical user inter-face with drag and drop components. Activiti Designer does not sup-port the complete set of BPMN 2.0 components and features at the present time, but more support arrives with each new version. Activiti 5.9 has just been released with support for some new components which, at present, are labeled experimental and which are not included in Activiti Designer. Experimental components were not used when modelling the patterns. For a description of the components used in the implementation of the workflow patterns see Appendix A.

(18)

2.3 Workflow Patterns

The Workflow Patterns initiative was started in 1999 by Professor Wil van der Aals and Professor Arthur ter Hofstede [3]. It was established to describe the fundamental structures in an imperative way [3]. These structures are reoccurring over and over again when modelling business processes. The research project first produced a set of twenty control-flow patterns for workcontrol-flow systems [4]. Since then patterns have evolved and they now cover the following workflow perspectives, control-flow, data, resource, exception handling and presentation. These patterns have been used to evaluate existing workflow systems so as to determine their suitability for a particular project and for the develop-ment of workflow systems. [24]

2.4 Control-flow patterns

In 2006 a new paper with a revised view on the control-flow patterns was released [5]. The new revised definitions were an effort to make the implementation and interpretation of the patterns less ambiguous by taking the strictest possible interpretations. In addition to the twenty revised patterns, twenty-three new control-flow patterns were also introduced. For the definitions of all 43 control-flow patterns see Ap-pendix B. The forty-three control-flow patterns can be divided into eight classes which are described below. [25]

Basic Control Flow Patterns 2.4.1

In the class Basic Control Flow Patterns are those patterns dealing with the execution order of activities and the ability to run activities concur-rently and patterns that deal with simple choice and merger. These patterns are the fundamental building blocks of a workflow system. The following patterns belong to the basic control flow patterns, for their definitions see Appendix B. [25]

1. Sequence 2. Parallel Split 3. Synchronization 4. Exclusive Choice

(19)

5. Simple Merge

Advanced Branching and Synchronization Patterns 2.4.2

In the class Advance Branching and Synchronization Patterns are pat-terns that deal with advance merging and synchronization constructs during which several branches come together. There is also a pattern that deals with the choice regarding which branches to activate. In the case of synchronization the subsequent activity should be called first when all the active branches have reached the construct, while in some patterns, only the first thread is passed to the subsequent activity while the others are blocked. There are also patterns that deal with the crea-tion and synchronizacrea-tion of threads within a branch. The following is the complete set of patterns belonging to the advanced branching and synchronization patterns and for their definitions see Appendix B. [25] 6. Multi-Choice

7. Structured Synchronizing Merge 8. Multi-Merge

9. Structured Discriminator 28. Blocking Discriminator 29. Cancelling Discriminator 30. Structured Partial Join 31. Blocking Partial Join 32. Cancelling Partial Join 33. Generalised AND-Join 37. Local Synchronizing Merge 38. General Synchronizing Merge 41. Thread Merge

(20)

Multiple Instance Patterns 2.4.3

In the class Multiple Instance Patterns are those patterns dealing with multiple instances of the same activity. The patterns deal with the initia-tion, the synchronization for completed instances and in dynamically adding new instances. The following patterns belong to the multiple instance patterns, for their definitions see Appendix B. [25]

12. Multiple Instances without Synchronization

13. Multiple Instances with a Priori Design-Time Knowledge 14. Multiple Instances with a Priori Run-Time Knowledge 15. Multiple Instances without a Priori Run-Time Knowledge 34. Static Partial Join for Multiple Instances

35. Cancelling Partial Join for Multiple Instances 36. Dynamic Partial Join for Multiple Instances

State-based Patterns 2.4.4

In the class State-based Patterns are those patterns dealing with syn-chronization, choice and which branches are able to be activated based on the state of the process instance. The state of a process instance is referring to its execution status and the related process and working data, which includes the status of activities. The following patterns belong to the state-based patterns, for their definitions see Appendix B. [25]

16. Deferred Choice

17. Interleaved Parallel Routing 18. Milestone

39. Critical Section 40. Interleaved Routing

(21)

Cancellation and Force Completion Patterns 2.4.5

In the class Cancellation and Force Completion Patterns are those pat-terns dealing with the forced cancellation and completion of running activities and process instances. These patterns can easily be implement-ed using exception handling. The following patterns belong to the cancellation and forced completion patterns, for their definitions see Appendix B. [25]

19. Cancel Task 20. Cancel Case 25. Cancel Region

26. Cancel Multiple Instance Activity 27. Complete Multiple Instance Activity

Iteration Patterns 2.4.6

In the class Iteration Patterns are those patterns dealing with the repeti-tive behaviour of a process. The following patterns belong to the itera-tion patterns, for their definiitera-tions see Appendix B. [25]

10. Arbitrary Cycles 21. Structured Loop 22. Recursion

Termination Patterns 2.4.7

In the class Termination Patterns are the patterns that deal with the termination and completion of a process. The following patterns belong to the termination patterns, for their definitions see Appendix B. [25] 11. Implicit Termination

43. Explicit Termination

Trigger Patterns 2.4.8

In the class Trigger Patterns are those patterns dealing with the external signals that might be necessary to start certain activities. The following

(22)

patterns belong to the trigger patterns, for their definitions see Appen-dix B. [25]

23. Transient Trigger 24. Persistent Trigger

2.5 Activiti source code

The Activiti open-source project consists of many different modules. The modules that are found in the Activiti 5.9 subversion repository [26] are activiti-cactus, activiti-camel, activiti-cdi, activiti-cxf, activiti-engine, activiti-mule, activiti-osgi, activiti-spring, activiti-webapp-exploirer2 and activiti-webbapp-rest2. The code is written in Java and it is using the build manager Maven. The modules that are of interest in this study are primarily the activiti-engine, which is a BPMN 2.0 process engine and the activiti-webapp-explorer2, which is a web interface that uses the process engine. All the source code is licensed under the Apache Li-cense, Version 2.0 [14].

2.6 Activiti Explorer

Activiti Explorer [27] is a web application that is built with the Vaadin framework and it utilizes the Spring framework to start the process engine. It has an easy-to-use interface for starting processes and han-dling human tasks. On the task page, the tasks appear in the user’s inbox or, if they are assigned to a group, under the queued menu. The process page allows the users to start new processes or to view the current execution state on an already started processes belonging to the user. The manage page is visible for users with administrator rights. The administrator can deploy new processes in this page, delete old ones, manage users and groups and investigate the content in the database tables. [27]

Spring Framework 2.6.1

The Spring framework assists in the building of enterprise Java applica-tions by allowing the programmer to focus on the problem rather than on pluming code [15]. The module used by Activiti is the inversion of control container, which is responsible for managing objects lifecycles, and this is conducted by means of dependency injection. The main

(23)

instead of at compile time, which is the usual way of loading objects. This is conducted by specifying all objects to be loaded in an XML file that is parsed by Spring and the objects are then instantiated and loaded into a container, accessible from the Java code. This makes it possible to add objects to the software without the necessity to recompile it. Apart from the late binding, it is also possible to assign values (this includes other objects loaded by Spring) to objects using either the constructor or setters directly in the XML file. This is of course a small sub set of the features provided by the Spring framework but deals with those used in Activiti.

Vaadin 2.6.2

Vaadin [16] is a Java framework for rich internet applications. Vaadin is based on the Google Web Toolkit (GWT) [17], and it is a rapid applica-tion development framework to build secure rich internet applicaapplica-tions. It allows the programmer to write an Internet application directly in Java and compiles it to both the client and server software. The client and server communicate via asynchronous Javascript (AJAX) and thus there is no requirement for any browser plugins. See figure 2 for the complete communication chain.

Web Service DB EJB Your Java Application Vaadin UI Components Java Web Server Web Browser Client-Side Engine

Figure 2: Vaadin communication [28]

Vaadin UI Components

All user interface components that are available in Vaadin are listed in the inheritance diagram in figure 3.

(24)

Figure 3: UI Component Inheritance Diagram. [28]

The Component class is the top most class in this hierarchy. The compo-nents used when creating input forms are all descendants of the Field class and they are all implementing the AbstractField interface. Fields are components that have a value that can be changed directly in the interface by the user. Fields use the Vaadin data model which means that the value is handled as a Property. A Property is an interface that uses get and set methods which take a value of type Object. This makes the interface compatible with all types of components and values since all objects inherit from the Object class in Java. For the inheritance diagram of the Field class see figure 4. [28]

(25)

Figure 4: Field Interface Inheritance Diagram. [28]

Activiti Process Engine 2.6.3

The central point of the Process Engine API is the ProcessEngine class. To create an instance of the ProcessEngine the ProcessEngineConfigura-tion object can be used via the Spring framework [15], xml or directly in Java code. To handle multiple instances of the ProcessEngine the Pro-cessEngines class can be used and it contains methods for safely creating and closing all running engines. Once an engine is up and running its services containing the workflow/BPM methods can be obtained by calling the corresponding getters on the engine object, see figure 5 for all available services. [29]

ProcessEngine

RepositoryService ManagmentService TaskService HistoryService

IdentityService FormService RuntimeService

Figure 5: Activiti Engine and its services [29]  Repository Service

The RepositoryService provides access to the repository of pro-cess definitions and other deployments. It is used for deploying to the database and retrieving deployed items. [29]

(26)

 Management Service

The ManagementService is used for maintenance and administra-tion operaadministra-tions on the process engine. [29]

 Task Service

The TaskService provides access to tasks and form operations. [29]

 History Service

The HistoryService provides access to information about ongoing and past process instances. [29]

 Identity Service

The IdentityService provides information on users and groups. [29]

 Form Service

The FormService provides access to form data. [29]  Runtime Service

The RuntimeService provides access to process instances, defini-tions and deployments. [29]

(27)

Methodology

3

The methodology used in this thesis consists, in the first instance, a theoretical study on BPM, workflow patterns, Activiti and Vaadin. The second part is a practical implementation of the patterns and the exten-sion of the functionality of Activiti Explorer.

3.1 Literature studies

The online library at Mid Sweden University was used to search for articles and publications regarding BPM and workflow patterns. The workflow patterns initiative website [3] also contained many sources. The following documents were found [1][2][4][5][8][10] via the online library or at the workflow patterns initiative website. To learn about Activiti and Vaadin the main websites [9][16] were used as the primary sources and, in addition, the following books were used [18][19].

3.2 Workflow patterns initiative

The workflow patterns initiative website [3] together with the papers [4][5] were the main source of information regarding the patterns. The sources were used when studying the theory behind the patterns and for the implementation and to evaluate the result.

3.3 Workflow patterns evaluation

When evaluating Activiti against the patterns, Activiti Designer was chosen as the process development tool. Because it is an official tool and offers an easy graphical environment with drag and drop components. There are other BPMN 2.0 modelling tools, for example, Activiti Model-ler, which is a web based modeller but these do not offer support for Activiti specific extensions to the BPMN 2.0 language. For the evalua-tion of the patterns, the requirement is that a graphical development tool is to be used and that the patterns are able to be implemented through its use. [30]

Implementing the patterns 3.3.1

The description of the pattern was read first and from this the motiva-tion was provided as were the, context and implementamotiva-tion. Once the pattern had been fully understood an attempt was made to implement it

(28)

in Activiti Designer. If the functionality of the pattern was achieved then the evaluation criteria and product evaluation was read. Finally, the finished implementation was graded according to the product evalua-tion criteria. If the funcevalua-tionality was not achieved then further reading with regards to Activiti and BPMN 2.0 was conducted. Once all the attempts have failed then the pattern is considered to be not supported. [30]

When grading the support for the patterns a “+” sign is given to the patterns that are directly supported, meaning that one of the language constructs satisfies the evaluation criteria of the pattern. For partial support “+/-“ is given, meaning that there is some limitation when implementing the pattern. The “–“ sign is given to patterns that are not supported. A pattern is considered to be not supported if any form of programming or scripting is required or the solution results in a spa-ghetti diagram. [30]

3.4 Product comparison

The Activiti open-source BPM platform was compared to the other BPM platforms by looking at the support for the different control-flow pat-terns. The patterns support for the different platforms is discussed for each control-flow patterns class. The pattern support for jBPM, Open-WFE, and Enhydra Shark comes from this study [10] and the result is also available at the workflow patterns initiative website [30].

3.5 Building the extended version of Activiti Explorer

The extended platform was created by extending the Activiti Explorer to support several companies per installation and the customization of user input forms. Since Activiti is an open-source project, the source code for Activiti Explorer was downloaded with Apache Subversion and modifications were made directly in the code. The development tool used was Eclipse with the Maven plugin installed. The code was firstly examined in order to discover a means of implementing the different features. Once a sound strategy had been determined that did not in-volve many changes, the implementation commenced. Following this, a great deal of testing was conducted to ensure that the implementation worked as intended. During the course of the project some bugs and

(29)

solution. At the conclusion of the project, version 5.9 of Activiti was released. All the changes had been made to version 5.8 and these were re-examined and brought over to version 5.9 one at a time and all the changes documented (see Appendix C and D for details).

(30)

Implementation

4

The first part of this chapter shows the implementation of all control-flow patterns with a description and a diagram for the supported pat-terns. In the second part the implementation of the extended version of Activiti Explorer is explained.

4.1 Control-flow patterns

All patterns are modelled using the Activiti Designer which is an eclipse plugin. A brief description is provided for all the patterns and a graph-ical diagram is additionally shown for the supported patterns. The graphical diagrams are saved as a png file in Activiti Designer and they depict the graphical representation of the process being modelled. When modelling the patterns, all tasks are represented by a user task that is assigned to the initiator. This simplifies the testing easier as the same user both initiates the process and receives all the user tasks. For each of the supported patterns there is also a detailed XML in Appendix E.

Pattern 1 – Sequence 4.1.1

The pattern is directly supported by using a “Sequence Flow” construct between activities. For its graphical representation see figure 6.

Figure 6: Pattern 1 - Sequence

Pattern 2 – Parallel split 4.1.2

The pattern is directly supported by using a “Parallel Gateway” con-struct. For its graphical representation see figure 7.

(31)

Figure 7: Pattern 2 - Parallel split

Pattern 3 – Synchronization 4.1.3

The pattern is directly supported by using a “Parallel Gateway” con-struct. For its graphical representation see figure 8.

Figure 8: Pattern 3 - Syncronization

Pattern 4 - Exclusive Choice 4.1.4

The pattern is directly supported by using an “Exclusive Gateway” construct. For its graphical representation see figure 9.

(32)

Figure 9: Pattern 4 - Exclusive choice

Pattern 5 - Simple Merge 4.1.5

Figure 10: Pattern 5 - Simple merge

Pattern 6 - Multi-Choice 4.1.6

The pattern is directly supported by using an “Inclusive Gateway” construct with conditions on the outgoing “Sequence Flows”. For its graphical representation see figure 11.

(33)

Figure 11: Pattern 6 - Multi-choice

Pattern 7 - Structured Synchronizing Merge 4.1.7

The pattern is directly supported by using an “Inclusive Gateway” construct. For its graphical representation see figure 12.

Figure 12: Pattern 7 - Structured synchronizing merge

Pattern 8 - Multi-Merge 4.1.8

(34)

Figure 13: Pattern 8 - Multi-merge

Pattern 9 - Structured Discriminator 4.1.9

The pattern is not supported. Support for this pattern is referred to in the BPMN specification but Activiti Designer does not support the complex gateway construct.

Pattern 10 – Arbitrary Cycles 4.1.10

The pattern is directly supported by using the “Exclusive Gateway” construct with “Sequence Flows” to construct the loops. For its graph-ical representation see figure 14.

Figure 14: Pattern 10 - Arbitrary cycles

Pattern 11 - Implicit Termination 4.1.11

The pattern is directly supported by the BPMN process language and when all paths have reached an end event the process is terminated. For its graphical representation see figure 15.

(35)

Figure 15: Pattern 11 - Implicit Termination

Pattern 12 - Multiple Instances without Synchronization 4.1.12

The pattern is partially supported. By default, the multi instance task will synchronize and the subsequent flow will only be called once all instances are completed. In order to circumvent this a “Parallel Gate-way” is used to split the thread of control before calling the multi-instance. To specify the number of instances to be started, the Loop cardinality is set to the variable containing the number of instances. For its graphical representation see figure 16.

Figure 16: Pattern 12 - Multiple instances without synchronization

Pattern 13 - Multiple Instances with a priori Design-Time 4.1.13

Knowledge

The pattern is directly supported. The Loop cardinality for the multi-instance is set at the design time to the number of activity multi-instances in this case 3. For its graphical representation see figure 17.

(36)

Figure 17: Pattern 13 - Multiple instances with a priori design-time knowledge

Pattern 14 - Multiple Instances with a priori Run-Time Knowledge 4.1.14

The pattern is directly supported. The Loop cardinality for the multi-instance is set at the design time to a process variable. For its graphical representation see figure 18.

Figure 18: Pattern 14 - Multiple instances with a priori run-time knowledge

Pattern 15 - Multiple instances without a priori run-time knowledge 4.1.15

The pattern is not supported. The number of instances cannot be changed after the multi-instance task has started.

Pattern 16 - Deferred Choice 4.1.16

The pattern is partially supported. It can be modelled using a sub pro-cess with error events to cancel the remaining listeners after a choice has been made. Experimental support exists for the event based gateway construct and signals which should offer full support for this pattern (Support for this patterns is therefore expected in future releases). For its graphical representation see figure 19.

(37)

Figure 19: Pattern 16 - Deferred choice

Pattern 17 - Interleaved Parallel Routing 4.1.17

The pattern is not supported. There is no construct that offers serial execution of parallel activities.

Pattern 18 – Milestone 4.1.18

The pattern is not supported. Activiti has no support for states.

Pattern 19 - Cancel Activity 4.1.19

The pattern is directly supported by using an error boundary event attached to the activity being cancelled and issue an error message to cancel the activity. For its graphical representation see figure 20.

(38)

Figure 20: Pattern 19 - Cancel activity

Pattern 20 - Cancel Case 4.1.20

The pattern is directly supported, by encapsulating the process in a sub-process and using error events. For its graphical representation see figure 21.

Figure 21: Pattern 20 - Cancel case

Pattern 21 - Structured Loop 4.1.21

The pattern is directly supported. Both post- and pre-test loops can be constructed using exclusive gateways and a process variable. For the post-test loop see figure 22 and for the pre-test see figure 23.

(39)

Figure 22: Pattern 21 - Structured loop (post-test)

Figure 23: Pattern 21 - Structured loop (pre-test)

Pattern 22 - Recursion 4.1.22

The pattern is not supported. There is no means of specifying recursion in the Activiti Designer.

Pattern 23 - Transient Trigger 4.1.23

The pattern is not supported.There is no means of specifying triggers in Activiti Designer.

Pattern 24 - Persistent Trigger 4.1.24

The pattern is not supported. There is no means of specifying triggers in Activiti Designer.

Pattern 25 - Cancel Region 4.1.25

The pattern is partially supported, by encapsulating the region in a sub-process and using error events to cancel the region. For its graphical representation see figure 24.

(40)

Figure 24: Pattern 25 - Cancel Region

Pattern 26 - Cancel Multiple Instance Activity 4.1.26

The pattern is directly supported by using an error boundary event to cancel all remaining instances. For its graphical representation see figure 25.

Figure 25: Pattern 26 - Cancel Multiple Instance Activity

Pattern 27 - Complete Multiple Instance Activity 4.1.27

The pattern is directly supported, by using a boundary event or setting the completion condition of the multi-instance. For the graphical repre-sentation when using a boundary event see figure 26 and figure 27 for an example using the completion condition.

(41)

Figure 26: Pattern 27 - Complete Multiple Instance Activity (Boundary event)

Figure 27: Pattern 27 - Complete Multiple Instance Activity (completion condition)

Pattern 28 - Blocking Discriminator 4.1.28

The pattern is not supported. Activiti Designer does not support the complex gateway construct.

Pattern 29 - Cancelling Discriminator 4.1.29

The pattern is directly supported, using a sub-process and an error event to cancel the remaining activities. For its graphical representation see figure 28.

Figure 28: Pattern 29 - Cancelling Discriminator

Pattern 30 - Structured Partial Join 4.1.30

Pattern 31 - Blocking Partial Join 4.1.31

(42)

Pattern 32 - Cancelling Partial Join 4.1.32

Pattern 33 - Generalized AND-Join 4.1.33

The pattern is not supported. The parallel gateway executes the subse-quent activity when it has received the same number of input signals as the number of input branches, even if all signals come from the same branches.

Pattern 34 - Static Partial Join for Multiple Instances 4.1.34

The pattern is not supported. There is no means of triggering the subse-quent task without cancelling the other instances. Signals, which at present are labelled experimental, might be used to accomplish this.

Pattern 35 - Cancelling Partial Join for Multiple Instances 4.1.35

The pattern is supported, and can be modelled by using an error bound-ary event or by setting the completion condition to M=N. For its graph-ical representation see figure 29.

Figure 29: Pattern 35 - Cancelling partial join for multiple instances

Pattern 36 - Dynamic Partial Join for Multiple Instances 4.1.36

The pattern is not supported. The number of instances cannot be changed after the multi-instance task has started.

Pattern 37 - Acyclic Synchronizing Merge 4.1.37

The pattern is not supported. The “Inclusive Gateway” has to be used in a structured context.

Pattern 38 - General Synchronizing Merge 4.1.38

The pattern is not supported. The “Inclusive Gateway” has to be used in a structured context.

Pattern 39 - Critical Section 4.1.39

(43)

Pattern 40 - Interleaved Routing 4.1.40

The pattern is not supported. Ad-hoc processes are not supported in Activiti Designer.

Pattern 41 - Thread Merge 4.1.41

The pattern is not supported. startQuantity attribute of activities is not supported in Activiti Designer.

Pattern 42 - Thread Split 4.1.42

The pattern is not supported. completionQuantity attribute of activities is not supported in Activiti Designer.

Pattern 43 - Explicit Termination 4.1.43

The pattern is not supported. The Terminate End Event construct is missing in Activiti Designer.

4.2 Support for multiple companies

To support multiple companies without changing the code for the engine, the ProcessEngines class was used to register one engine per company. For a complete list of changes required to implement the multi-company support see Appendix C.

Company Database and Admin web application 4.2.1

When Activiti Explorer is initialized it loads a configuration file via Spring to start the engine. Since one engine will be used per company, it is necessary to start several engines and to add engines without restart-ing the application. Because of this, the configuration file was changed to contain the configuration for a JDBC connection to a MySQL database that stores the configuration parameters for the engines. See figure 30 for the database table. When the application starts it loads the JDBC connection via Spring and investigates all the records and sets up one engine per company and starts it.

(44)

Company PK CompanyName DriverClassName URL UserName Password MailServerHost MailServerUserName MailServerPassword MailServerPort MailServerDefaultFrom MailServerUseTLS

Figure 30: Company database table

To handle the administration of companies, a Vaadin web application was created that can be accessed by adding “/admin” to the URL. The Admin web application can be used to start and stop the engines for companies that are already in the database. The login information for the admin web application is stored in the Admin database table (see figure 31) and the password is stored using a SHA-1 cryptographic hash function.

Admin

PK UserName

Password

Figure 31: Admin database table

CloudProcessEngines 4.2.2

The CloudProcessEngines class was created to ease the handling of multiple companies. The class communicates directly with the engines, and all communications between a logged in user in Activiti Explorer and the engine pass through this object. All classes that have previously communicated with the engine were changed to communicate via the CloudProcessEngines with the exception of the classes handling the login of the user (see next section). When the process engines are regis-tered they are associated with a name, which in this case is the same as the company name. When getProcessEngine() method is called on the

(45)

ed with the logged in user and then calls the ProcessEngines class in order to retrieve the engine registered with that company name and then returns it. The Admin web application also communicates with this class.

Login 4.2.3

A new implementation of the logged in user interface was created with the addition of a field containing the company name. This class is at-tached to the application object and is therefore globally available. The login screen was also extended to include an input field for the company name. When the user attempts to log in, an engine is loaded associated with the given company and, if it exists, the user’s credentials (name and password) are sent to the engine for verification. If no engine is associated with the company name, then the login fails. After the login has succeeded and providing that the credentials were correct, the user object (with company name) is attached to the application object and the user is logged in.

User Cache 4.2.4

The user cache is used to cache users for the purpose of speeding up user lookup operations. Only one user cache does not work with multi-ple companies since they have different users, and because of this and the time constraints on this project, the user cache implemented simply retrieves users from the database instead of actually caching them.

Activiti Company Deployment Manager 4.2.5

This application makes it easier to create and modify company infor-mation that is used when deploying a new company. It is a Java applica-tion with a graphical user interface (GUI) that is using the Swing framework. The file format, when saving and loading the company deployment file, is a zip file with the structure shown in figure 32. The theme/img directory contains all the images for the theme, the us-ers/pictures directory contains all the pictures of the users and the processes directory contains all processes to be deployed.

(46)

/ theme users processes styles.xml img users.xml pictures

Figure 32: File structure of the company deployment zip file

To create a theme, one color is picked and the logos are loaded from a file or generated based on the first logo. After the color and logos have been selected the application will generate images for buttons and the menubar together with a css file to be used as a Vaadin theme. The algorithm used for the real-time preview of the menubar uses the hard-ware accelerated graphics and lower settings to make it faster on older machines. The algorithm used when generating the actual images uses the Java 2d graphics API with the best quality settings together with antialiasing. The theme can be exported as a Vaadin theme or saved in a zip file, making it usable for both the modified version in addition to the original version of Activiti Explorer.

Users can be easily added, deleted and edited directly in the application. The users are saved in an XML file, with pictures in a separate directory, for an example, see below. In the edit user dialog, groups can be added or removed. The dropdown menu of available users is loaded from the groups.xml file, which is located in the application directory. This file can be edited in a text editor to add more groups, see below for the xml structure.

The processes are merely a list of loaded process files that will be saved in the zip file.

(47)

<?xml version="1.0" encoding="UTF-8" ?> <users>

<user>

<userid>kermit</userid> <firstname>Kermit</firstname> <lastname>The Frog</lastname> <password>kermit</password> <email>[email protected]</email> <picture>kermit.jpg</picture> <groups>

<group id="admin" type="security-role">Admin</group>

<group id="management" type="assignment">Management</group> <group id="sales" type="assignment">Sales</group>

<group id="marketing" type="assignment">Marketing</group> <group id="engineering" type="assignment">Engineering</group> </groups>

</user> </users>

User xml file format

<?xml version="1.0" encoding="UTF-8"?> <groups>

<group id="admin" type="security-role">Admin</group> <group id="management" type="assignment">Management</group> <group id="sales" type="assignment">Sales</group>

<group id="marketing" type="assignment">Marketing</group> <group id="engineering" type="assignment">Engineering</group> </groups>

Groups xml file format

Deployment helper tools 4.2.6

To make it easier to set up the initial database and to write the configu-ration file used by Activiti Explorer when it is started, a command line Java application was created. The application takes the path to the Activiti Explorer, database info and credentials (to create the schemas and tables). It creates the activiti_cloud schema and a MySQL user with the same name and sets the privileges for this user to only use Select operations on the activiti_cloud schema. The password for the user is auto generated with a simple random algorithm. Finally, the configura-tion file with the credentials is created in the Activiti Explorer directory path.

To make it easier to set up a new company a command line Java applica-tion was created. The applicaapplica-tion takes a zip file containing the theme to be used together with all users and processes (see Activiti Company Deployment Manager). It also takes the path to the theme directory and the database credentials. It firstly copies the theme to the Activiti Ex-plorer theme directory and then launches an offline process engine.

(48)

Then a schema and a user are created (they both have the company name). Following this, the process engine sets up the database and builds all the tables. All users are then added to the database via the engine and finally the processes are deployed. When everything is completed the process engine is shut down and the configuration and the database credentials are written to the Company table (for uml diagram see figure 30).

4.3 Support for a business payment model

The invoice can be reached from the admin web application (for an image see result chapter). For each company there is a date field and a button. By choosing a month and pressing the invoice data button an invoice for the selected month is downloaded for that company. The invoice is created by accessing the process engine for the selected com-pany and accessing its HistoryService. In order for this to work, the engine must be started and running. The invoice created is in a XML format for easy integration with the desired billing software, since it is a well-known standard in data serialization.

4.4 Support for custom layout in task forms

By default, all form components are as shown in figure 33. There is no means of changing this layout, thus, in order to provide the process developer with the ability to change it, Activiti Explorer was extended. In order to support different types of layouts, an XML specification (for the tags see below) for describing the layout was developed. When developing processes, each user task has an associated formkey proper-ty, the name of this property should be the same as the filename of the desired layout file for that form. If this field is left empty the default layout is choosen, which is one field per row. When deploying processes which are using custom layouts, the process definition file, together with all layout files, must be zipped and deployed as a zip file, this is because no changes are required in the code responsible for the de-ployment.

(49)

Figure 33: Standard form layout in Activiti Explorer.

XML specification 4.4.1

The following shows, all the tags available in the XML specification created for the purpose of offering the process developer the ability to customize form layouts: Form, block, row, column, field, divider, a, img, br, space.

 form

The form is the outer most tag and it contains the entire layout.  field

(50)

The field is the graphical component that is displayed together with its label. The field takes an id attribute, which should be the same as the id of the field in the corresponding task form in the process definition. The description attribute is a text attribute that is used as a tool tip text, which is displayed when the user is hovering over the input field with the mouse pointer. If the id of a field is not found in the process definition file then the field is not displayed. The field tag cannot contain any other tags.

 block

The block layout can contain any of the following tags: row, col-umn, field, divider, a, img and br. It has a type attribute which can be one of the following two values “divider” and “panel”. The divider has a line on top and the panel has four borders that can be styled by specifing a style name in the style attribute (the name should corespond to a style in the Vaadin theme). The caption of the block is the title that is written at the top of the block. A block is only displayed if at least one of its interior fields is also displayed.

 row

The row tag displays all its conponents on a single line. It can contain the following tags: field, a, img and space. The expand at-tribute can be either true or false, with the true meaning being that all the components are distributed with equal width over the entire row and the false meaning being that the components are laid out one after the other with their default width.

 column

The column tag lays out the components one per row with the difference is that the label is on the left side of the component instead of being on top, which is the default. The column can contain the folowing tags: field, divider, a, img and br.

(51)

The divider tag draws a line on the screen and the content of the element. It cannot contain any other tags.

 a

The a tag represents a url link. It can contain an img tag. Its attributes are href, used to refer to a static link and var, to a process variable that contains the link. If an image is not used the element is displayed.

 img

The img tag represents an image that is displayed. The image can be part of a link but cannot contain any tags. The src attribute is the URL in which the image can be reached. The alt attribute is the text that is displayed when the image cannot be located. The height and width attributes are used to change the default size of the image. All of these attributes are written directly to the HTML page that is viewed by the user.

 br

The br tag is used to write a linebrake by writing the br tag to the generated HTML page. The br tag cannot contain any tags, attribues or elements.

 space

The space tag is used to insert a space between components in the row tag when its expand attribute is set to false. It cannot contain any tags, attributes or elements

Validating custom forms 4.4.2

When developing custom forms a dtd file can be used to validate its syntax. The dtd can be found in Appendix C.

Extending Activiti to support the custom form layouts 4.4.3

The following classes were changed to add support for custom form layouts: FormPropertiesComponent, FormPropertiesForm, ProcessDefi-nitionDetailPanel and TaskDetailPanel. Their functions are to take data from the process engine and render the form and to send the data from

Open-source Workflow Evaluation An evaluation of the Activiti BPM Platform. Mikael Nilsson. M.Sc. Thesis within Computer Engineering AV, 30 ECTS

M.Sc. Thesis

within Computer Engineering AV, 30 ECTS

Open-source Workflow

Evaluation

An evaluation of the Activiti BPM Platform

Mikael Nilsson

Abstract

Acknowledgements

Table of Contents

Terminology

Acronyms

Introduction

1

1.1

Background and problem motivation

1.2

Overall aim and verifiable goals

1.3

Scope

1.4

Outline

1.5

Contributions

Theory

2

2.1

BPMN 2.0

2.2

Activiti Designer

2.3

Workflow Patterns

2.4

Control-flow patterns

2.5

Activiti source code

2.6

Activiti Explorer

Methodology

3

3.1

Literature studies

3.2

Workflow patterns initiative

3.3

Workflow patterns evaluation

3.4

Product comparison

3.5

Building the extended version of Activiti Explorer

Implementation

4

4.1

Control-flow patterns

4.2

Support for multiple companies

4.3

Support for a business payment model

4.4

Support for custom layout in task forms