Masaryk University Faculty of Informatics

}w
 !"#$%&'()+,-./012345<yA|
Masters thesis

Extension of the iQ Workow Engine

Bc. Duan vancara

Brno, 2013

Declaration
Hereby I declare, that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Bc. Duan vancara

Advisor: RNDr. Ing. Lucie Pekrkov

ii

Acknowledgement
I would like to thank to RNDr. Ing. Lucie Pekrkov and colleagues at inQool, a.s. for their valuable input and encouraging words, to my girlfriend and friends for their support, and, last but not least, to my family for constantly reminding me to work on the thesis.

iii

Abstract
This thesis addresses the issue of the initial steps in the business process life cycle, mainly the simulation. For this purpose, it describes the three selected BPMN 2.0-compliant business process management tools and compares their modeling and simulation features. Based on the output of the overview, an innovative simulation engine is proposed, designed and implemented. This is done by employing the characteristics of BPSim, a rather young simulation standard. In the end, the usage and capabilities are demonstrated on selected business processes.

iv

Keywords
BPM, BPMN, business process management, business process model and notation, BPSim, process simulation, Bizagi, jBPM, Bonita

Contents
1 2 Introduction . . . . . . . . . . . . . . . . . . . . Business process management . . . . . . . . . 2.1 Business process . . . . . . . . . . . . . . . . 2.1.1 Denition . . . . . . . . . . . . . . . . 2.1.2 Classication . . . . . . . . . . . . . . 2.2 Business process management . . . . . . . . . 2.2.1 BPM life cycle . . . . . . . . . . . . . 2.2.2 Process development stakeholders . . . 2.2.3 Benets of BPM . . . . . . . . . . . . 2.3 BPMN . . . . . . . . . . . . . . . . . . . . . . 2.3.1 BPMN elements . . . . . . . . . . . . 2.4 Optimization and simulation . . . . . . . . . 2.4.1 Optimization . . . . . . . . . . . . . . 2.4.2 Simulation . . . . . . . . . . . . . . . Business process tools overview . . . . . . . . 3.1 Bonita BPM . . . . . . . . . . . . . . . . . . 3.1.1 Modeling possibilities and ease of use 3.1.2 Palette of elements . . . . . . . . . . . 3.1.3 Import/export . . . . . . . . . . . . . 3.1.4 Simulation . . . . . . . . . . . . . . . 3.2 jBPM . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Modeling possibilities and ease of use 3.2.2 Palette of elements . . . . . . . . . . . 3.2.3 Import/export . . . . . . . . . . . . . 3.2.4 Simulation . . . . . . . . . . . . . . . 3.3 Bizagi Process Modeler . . . . . . . . . . . . 3.3.1 Modeling and ease of use . . . . . . . 3.3.2 Palette of elements . . . . . . . . . . . 3.3.3 Import/export . . . . . . . . . . . . . 3.3.4 Simulation . . . . . . . . . . . . . . . 3.4 Summary . . . . . . . . . . . . . . . . . . . . 3.4.1 Bonita BPM . . . . . . . . . . . . . . 3.4.2 jBPM . . . . . . . . . . . . . . . . . . 3.4.3 Bizagi Process Modeler . . . . . . . . Engine extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4 4 4 5 5 6 7 8 8 8 11 11 12 15 15 16 17 17 18 19 20 21 22 22 23 24 24 26 26 28 28 28 29 33

iQ Workow Engine . . . . . . . . 4.1.1 Activiti . . . . . . . . . . . 4.1.2 What is missing . . . . . . 4.2 Solution proposal . . . . . . . . . . 4.2.1 BPSim . . . . . . . . . . . . 4.2.2 REST service . . . . . . . . 4.3 Architecture and design . . . . . . 4.3.1 API domain model . . . . . 4.3.2 REST API . . . . . . . . . 4.3.3 Simulation engine API . . . 4.4 Implementation . . . . . . . . . . . 4.4.1 Technologies . . . . . . . . 4.4.2 Key examples and features 4.5 Simulation of selected processes . . 4.5.1 Manual invoice delivery . . 4.5.2 Loan request . . . . . . . . 5 Conclusion . . . . . . . . . . . . . . . A CD content . . . . . . . . . . . . . . .

4.1

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

33 33 34 34 34 35 36 36 37 38 48 48 50 53 53 59 65 68

Chapter 1

Introduction
Nowadays, when the complexity of business operations grows beyond the boundaries of sustainability, the companies need a structured collection of procedures and practices that help to maintain the complexity on a tolerable level. This is a job for the business process management (BPM). BPM manages the life cycle of processes from their conception to their death through design, modeling, execution, monitoring and optimization. The initial phases are accompanied by the immaturity and insuciency of input data which causes the uncertainties and increases the process risks. Simulation is a powerful tool for eliminating these weaknesses and brings an overview on the process behavior. The rst chapter of the thesis introduces the business process management, classication of processes and their life cycle. Next it deals with the usual actors in the process development, states the benets of BPM and presents the standard notation for business process modeling Business Process Model and Notation (BPMN), specically the BPMN 2.0. The chapter ends with the description of optimization and simulation. Business process tools are a crucial part of the BPM. The modeling and simulation capabilities of three selected tools Bonita BPM Studio, jBPM and Bizagi Process Modeler were reviewed in the second chapter. This includes their licensing, ease of use, palette of elements, BPMN 2.0 compliance, import, export and simulation process and settings. The side-by-side comparison of these tools concludes the chapter. The beginning of the third chapter is dedicated to the iQ Workow Engine a workow engine used and developed in inQool, a.s. which is the target for an extension, an innovative simulation engine. The extension solution is proposed in the next few sections with the architecture and design description. Used technologies and few selected implementation details and features are dealt with in the middle part. Next, the engine presents its capabilities on the chosen processes and a brief comparison of the results produced by our engine and the tools from the review ends the chapter. Last but not least, the conclusion summarizes the work done on this thesis with the future prospects of the engine.

Chapter 2

Business process management

Everyday we face a challenge of planning and organizing events, holidays, free time activities and so forth. Similarly, companies and organizations around the world require precise management and systematic process of dening their goals and ways to achieve them. Both these challenges could be described as processes with denitive set of repetitive tasks and transitions between them. Level of repetition is a good indicator whether the process should be studied, modeled and optimized. Business process management (BPM) provides us with best practices and set of tools for doing just that.

2.1

Business process

What exactly is business process management? In the not-so-many decades of its existence, there has not been given a unied denition of the term. In order to understand BPM, we should start with a business process denition. 2.1.1 Denition

According to Hammer and Champy[1], a business process is a collection of activities that takes one or more kinds of input and creates an output that is of value to the customer; a business process has a goal and is aected by events occurring in the external world or in other processes Johansson[2] dened a business process as a set of linked activities that take an input and transform it to create an output. Ideally, the transformation that occurs in the process should add value to the input and create an output that is more useful and eective to the recipient either upstream or downstream. Another denition was coined by Davenport[3] and it says that a business process is a structured, measured set of activities designed to produce a specied output for a particular customer or market. It implies a strong emphasis on how work is done within an organization, in contrast to a product focuss emphasis on what. A process is thus a specic ordering of work

2. Business process management activities across time and place, with a beginning, an end, and clearly identied inputs and outputs: a structure for action. It can be seen that there are some minor dierences, but they agree on these points about a business process: it consists of a set of activities having a specied order, a beginning and an end it transforms an input to a value-adding output, both being clearly identied

Moreover, for a process to be applicable, it should be reproducible and use resources. To sum it up, a business process can be dened as an ordered set of activities with a beginning and an end, that transforms specied input into value-adding output reproducibly with the use of resources. 2.1.2 Classication

Imagine a typical car factory. Its main goal is to produce and sell cars. However, this would not be possible if there were no transportation and supplier services, accounting, etc. It is obvious that they form an integral part of the factorys business process, but their role is dierent. We can divide processes into three basic categories according to their role in the business strategy[4]: primary processes the business is built around them and they produce valuable output desired by external customer (e.g. car factory produces cars) secondary processes they provide additional activities by processing secondary output from primary processes (e.g. car company resells engines to other companies) supporting processes other processes depend on them (e.g. accounting)

2.2

Business process management

Now when we know what exactly a business process is, BPM can be understood more easily. According to Gartner Research[5]: Business process management (BPM) is a process-oriented management discipline. It is not a technology. This denition from jBPM5 Developer Guide[6] goes into more detail and says that: BPM is an iterative discipline that denes multiple stages that are executed in repeated cycles, which provides us a path of continuous business process improvements. BPM can also be seen as a set of best practices with a lot of focus on improving the way the company does its job.

2. Business process management Let us add another denition by van der Aalst et al.[7], who describe BPM as: Supporting business processes using methods, techniques, and software to design, enact, control, and analyze operational processes involving humans, organizations, applications, documents and other sources of information. Those are three very dierent views on BPM. From the managements point of view, it helps us to improve processes continuously and to promote eciency and eectiveness. But technical aspect is what interests us more. From this point of view, BPMs goal is to manage life cycle of the process. 2.2.1 BPM life cycle

Figure 2.1: Business process management life cycle[8]. In order to create a fully functional and usable business process, it has to go through several stages of development. The life cycle consists of ve stages[9] as shown in gure 2.1: Design the rst step in the cycle. It is crucial to identify what is the main goal and what is important for the customer. Possible organization changes should be discussed. These activities are based on appropriate collected data and detailed analysis of the company. Key performance indicators are stated. Modeling the business process is fully specied and validated, analysis is transformed into formalized graphical and textual models. Modeling tools are used, models are comprehensible for common consumer but still embracing and detailed for experts in the eld.

2. Business process management Execution the process is implemented, tested and deployed, often using a business process management system (BPMS). Process denition language is used for implementation. Monitoring the process is being monitored. Shortcomings and drawbacks are being identied based on key performance indicators evaluation. Optimization monitoring phase results are interpreted and new business needs are taken into account. The requirements are incorporated into the optimized analysis. After the phase is done, the cycle continues with the rst step. Process development stakeholders

2.2.2

Life cycle of the process is managed by a group of people and every step requires a specialist in the eld. Following roles are needed in order to develop high-quality solution with as little shortcomings as possible: process analyst, process architect, process developer and process owner. 2.2.2.1 Process analyst

An analyst should be able to create minimal yet operational process model. Therefore he needs to understand business quite well. He is required to document the process in details, collaborate with other stakeholders and model high-level process denition. 2.2.2.2 Process architect

An architect needs to be process denition language expert, at least from the business point of view. He should be detail oriented and understand business as well. He is responsible for ensuring high delity of the process, making implementation choices and process models analysis. 2.2.2.3 Process developer

Skills involve high technical knowledge of process denition language, web services, XML and enterprise applications. Developer is required to implement processes, user interfaces and empower the analysts. 2.2.2.4 Process owner

The owner of the process is responsible for the process as a whole and denes process metrics which are important for the evaluation. He is responsible for process analysis, performance and business alignment.

2. Business process management 2.2.3 Benets of BPM

Formal denition of processes, graphical models and thorough analysis can bring detailed insight into how the process works. Usually there is a large potential in identication of previously unknown problems, bottlenecks and even improvements. The most noticeable benets are as follows[10]: increased visibility and knowledge of companys activities, increased ability to identify bottlenecks, increased identication of potential areas of optimization, reduced lead-times, better denition of roles and duties in company, good tool for fraud prevention, auditing, and assessment of regulation compliance.

Adoption of BPM introduces well-documented activities into operation that promotes workow and prevents a total collapse of the business.

2.3

BPMN

Phases of the business process life cycle incorporated process denition language and business process model. There have been attempts to standardize unied notation for business process denition. Some more successful than others1 . One of the most successful eorts is the creation of the BPMN Business Process Model and Notation. BPMN was developed by the Business Process Management Initiative (BPMI) in 2004. BPMI later that year merged with Object Management Group (OGM) and they continued developing BPMN to provide a notation that is readily understandable by all business users, from the business analysts that create the initial drafts of the processes, to the technical developers responsible for implementing the technology that will perform those processes, and nally, to the business people who will manage and monitor those processes[11]. In January 2011, ocial specication of BPMN 2.0 was released and it became what we now know as BPMN. 2.3.1 BPMN elements

The notation consists of a great number of constructs, it is therefore important to divide them into dierent groups of modeling detail. Shapiro, in his presentation on updates in BPMN[12], stated four classes of constructs (see g. 2.2):
1. Another well-known industry standard is Web Services Business Process Execution Language (WSBPEL) https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel

2. Business process management Simple elements that can be used to create simple models with start and end events, sequence ows, tasks, sub-processes and gateways. A common usage of the class is process capture. Descriptive adds more rened elements, such as message start event, text annotation, association. . . Class extends previous one and adds details to the process capture, e.g. extends routing logic or adds information about resource or role requirements. DODAF an architecture framework of the United States Department of Defense, elements for enterprise architecture based on design primitives and patterns. Complete all-encompassing class of elements.

Figure 2.2: BPMN categories according to Shapiro[12]. Only the rst two classes are interesting for us and sucient for our purposes. BPMN denes four basic categories2 of graphical elements ow objects, connecting objects, swimlanes and artifacts. 2.3.1.1 Flow objects

This category is formed by a small group of key elements:

2. Classes form cross-section of categories elements from one category can be in any class.

2. Business process management Event is represented by a circle. An event occurs when something happened and inuences the ow of the business process. There are three types of events based on the relationship with the process: start event, intermediate event and end event. Activity is represented by a rectangle with rounded corners. An activity symbolizes some work unit, that must be done in order for process to continue. There are two types of activities task and sub-process. The symbols are similar, except that sub-process contains plus mark in the middle of the rectangle. Gateway is represented by a diamond shape with an internal symbol. The symbol indicates type of the gateway, either converging, or diverging. Gateways control interaction among ows within a process. Connecting objects

2.3.1.2

Flow objects within a process must are connected together to represent orchestration of the process denition. This is ensured by the connecting objects: Sequence ow is represented by a full arrow. It connects activities, gateways and events within one pool. Obviously, the orientation of the arrow is given by the direction of the ow. Message ow is represented by a dashed arrow. It is used to send a message or a signal from one pool to another. Association is represented by a dotted arrow. It is used to connect an object with an additional piece of information (artifact, data or text). Swimlanes

2.3.1.3

Swimlanes are used for grouping purposes. Flow objects grouped together may be associated with a specic role in an organization or represent entire building that is involved in the process. . . There are two types of ow objects: Pool is represented by a rectangle with a label aligned to the left if spread horizontally or to the top if spread vertically. It usually indicates borders of the process all the objects from one process are placed inside the pool. Lane is represented similarly to the pool and must be placed inside the pool. The lane often groups together objects that have been assigned the same owner, role, etc. Artifacts

2.3.1.4

BPMN was created with the exibility in mind. Additional information, details and extensions are represented by the artifacts:

10

2. Business process management

Figure 2.3: Sample of a BPMN diagram. Data object is represented by a pictogram of a single sheet of paper. It is used to designate that certain data are used or produced by an activity. Group is represented by a rectangle with rounded corners that is drawn with a dashed line. It provides a visual mechanism to group diagram elements informally. Text annotation is represented by an open rectangle with solid line. It is used to provide additional information to the connected element.

2.4

Optimization and simulation

Every business process costs money, human resources or time. These are crucial elements that can break a seamless business operation when in shortage. Therefore every manager must strive for the best process denition possible and optimal employment of the resources. Optimization plays a signicant role in this case. 2.4.1 Optimization

Optimization is one of the main ve parts that make up business process life cycle. It is the last segment of the cycle, but on the other hand, it greatly inuences the process

11

2. Business process management design and modeling. There are several kinds of optimization based on the amount of impact it has on the process structure and on the continuity of the process performance improvement. 2.4.1.1 Continuous process improvement

As can be seen from the name, continuous process improvement (CPI) is a technique that improves the process performance continuously. It does not interfere with the process structure and achieves its goal by redening used and adding new resources. Picture a loan application process. The applicant must rst manually ll out a complicated form and send it to the validation unit. If successful, there is no delay and application proceeds forward in the process. But in many cases, the form contains some discrepancies and must be returned to the applicant. This can be solved at least partially by introducing information system to the process. Validation of the form is instant and the applicant can see his mistakes immediately so that the amount of wrong form submissions drops signicantly. 2.4.1.2 Business process reengineering

Business process reengineering (BPR) stands for a technique that is process-invasive, that means the process structure is changed. Boundaries of the process stay the same, but the arrangement and denition of the activities inside the process changes. Denition given by Hammer and Champy[1] says, that BPR is the fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical contemporary modern measures of performance, such as cost, quality, service, and speed. For example, a loan application validator becomes responsible for rejecting the loan if some conditions have not been met. This change saves time for approval committee and an invalid loan application does not go through the activities pointlessly. 2.4.1.3 Business process redesign

Business process redesign (BPRD) is similar to BPR in terms of continuity of improvement. They both introduce step changes in the performance. However, BPRD operates on the top level of the process structure, changing boundaries and arrangement of the processes themselves. In the context of the loan application process, BPRD may introduce direct connection between the process and loan approval process, for example, the loan can be automatically approved when the applicant is a spouse-less woman with two children and mortgage. 2.4.2 Simulation

CPI, BPR and BPRD change the process or processes locally and bring performance improvements in some places. But they disrupt the balance of the process structure and

12

2. Business process management the total value added by their usage does not have to be always positive. To protect the overall health of the process, a technique is needed to comprise the process performance in general. Such a mechanism is brought by simulation. Business process simulation (BPS) embodies the concept that a process consists of discrete events that are interconnected and their occurrence depends on resource availability, probability distribution and dened quantities. 2.4.2.1 How simulation works

BPS may be executed when a process model is complete. The simulation needs a couple of additional attributes, like resource availability (accountants work time is between eight oclock in the morning and four oclock in the afternoon), resource quantity (we have two such accountants), typical activity duration, maximum activity duration. . . When there are exclusive gateways, the probability of each branch or the conditional expression should be dened, so that the simulator knows what path to choose. Number of individual process executions is also important as it eliminates common variation errors in numbers. The simulation may be accompanied by an animation which helps visualize the process. Also real-time graphs can be generated in order to show key performance indicators during the simulation run. These include spread of dierent characteristics related to costs or resource usage over time. As a result, the simulation outputs various statistical data, performance measures, that can be further analyzed and compared. Then a useful and correct conclusion can be drawn. The simulation does not ensure that the business process is optimized, but it gives us a tool to nd strengths and weaknesses in our model. 2.4.2.2 Simulation model

From a technical point of view, business process simulation is a complex process and requires a specic attention. Tumay proposed a model[13] that simplies the view of the simulation. The model consists of four basic building blocks (see g. 2.4): Entities ow objects, tokens or transitions, these are the objects that are processed by resources. They may have also attributes. Examples are products, documents and applications. Resources they are the units that add value to entities. For example service representatives, surgery tools and transportation vehicles are resources. Activities they are linked by connectors to represent the ow of the entities through the simulation model. Examples are branching, assembly, split, join, etc. Connectors connectors are used for linking processes and activities. They are helpful for dening parallel ows and rework situations based on deterministic, probabilistic, or conditional decision rules.

13

2. Business process management

Figure 2.4: Building blocks of a simulation model[13].

14

Chapter 3

Business process tools overview

Business process management is a tremendously growing eld and new BPM suites are emerging at a high rate. There is plenty of available suites and tools for business analysts, most of them are commercial, some are free and some are even open-sourced. Free and open-source BPMN 2.0-compliant BPM tools were chosen for comparison as they are not only feature-rich and sucient for common use, but they can compete with the proprietary solutions backed by large companies. We selected the following three suites, based on their popularity, ease of use and range of features: Bonita BPM Studio, jBPM and Bizagi Process Modeler. The rst two are open-source solutions and the third is free as long as you need the modeler only. Following text presents several views on the chosen BPM platforms. The main focus is on the simulation capabilities, but other aspects, that directly or indirectly inuence simulation options, are taken into account as well. These aspects involve modeling possibilities and ease of use, palette of supported BPMN elements and export/import options. The comparison is a basic stone for the development and extension of the current process engine used by inQool.

3.1

Bonita BPM

Bonita BPM is developed by Bonitasoft company founded in 2001 by Miguel Valds Faura. The companys aim is to provide competitive alternative to existing commercial solutions. Their success was conrmed in 2011 when number of downloads surpassed 1 million and number of paying customers reached 250. Even though the suite is free of charge and the source code is available online under the GPLv2 license, Bonitasoft oers dierent levels of paid subscriptions. They provide additional features such as SQL wizard, documentation generation, engine performance optimization, LDAP synchronization and so on. The suite is available for all the major platforms (MS Windows, Linux, Mac OS) and architectures (32-bit, 64-bit). Bonita BPM comprises three solutions: Bonita BPM Studio for graphical process design, Bonita BPM Portal for task management and process monitoring and Bonita BPM Engine, which serves as a workow engine and integration tool. Together they create complex system for the whole business process life cycle. From the simulation point of view, only BPM Studio is relevant and reviewed. The version of the BPM Studio used is 6.0.3.

15

3. Business process tools overview

Figure 3.1: Bonita BPM Studio screenshot. 3.1.1 Modeling possibilities and ease of use

BPM Studio is an Eclipse-based1 desktop application with user interface intuitive enough even for the people unfamiliar with the Eclipse platform. The main window is in the basic conguration divided into 4 views: modeling canvas in the top right corner being the largest, palette of elements on the left, tree view/overview in the bottom left corner and properties tabs in the bottom right corner. User composes the diagram by dragging the elements of choice from the palette and dropping them onto the canvas or by selecting them in the palette and clicking on the desired spot in the canvas. The latter induces the impression of sluggishness, the rendering seems quite slow. It may be caused by the editor trying to help the user align the elements, but the visual guidelines (which would back up the assumption) appear only after a while. When there is at least one element in the diagram, it can serve as a starting point for the further expansion. This is allowed by the presence of additional markers right next to the selected element. They represent all possible kinds of elements that can be added to the diagram with the input transition going from the source element. Graphical representation of elements conforms to the BPMN diagram specication and selected colors are quite intuitive. Overall the modeling could be a painful experience, especially when refactoring and moving elements around too much. On the other hand, it is very intuitive and simple when the users know exactly what they want.
1. Eclipse is a Java-based IDE and also a platform that provides basic infrastructure and building blocks for developing general purpose applications (see http://wiki.eclipse.org/Platform).

16

3. Business process tools overview 3.1.2 Palette of elements

The palette is simple and comprehensible, but does not fully support the descriptive (see 2.3.1) model. Supported ow objects are: tasks human, script, abstract, receive, send, service and call activity sub-processes event sub-process gateways exclusive, parallel, inclusive events start: event (basic), signal, message, error, timer end: event (basic), signal, message, error, timer intermediate: event (basic), timer, throw message, catch message, throw signal, catch signal, catch error, throw link, catch link, non-interrupting boundary timer event

As can be seen, the ow objects are quite complete and do not lack any common element. On the other hand, connecting objects palette is incomplete as it does not contain message ow and thus it consists only of the sequence ow and association. This is a great limitation such that diagrams created in Bonita BPM Studio do not visually capture the connection between message events from dierent pools. Number of supported artifact types is also quite low: the palette contains only text annotation. Data object and group artifact are not included. Modeler supports both swimlane and pool so the elements can be logically (and visually) grouped. 3.1.3 Import/export

Bonita uses its own format for storing diagrams and process properties. It is an XMI2 compatible XML document that contains process denition, connectors, data and simulation properties, layout information etc. 3.1.3.1 Import

When importing a process denition, the user is oered several input formats: Bonita 6.x processes designed with Bonita Studio of version 6 and higher Bonita BAR 5.9/5.10 processes designed with Bonita Studio 5.9 or 5.10 BPMN 2.0 processes dened in BPMN 2.0

2. XMI XML Metadata Interchange, standard proposed by OMG for exchanging metadata information

17

3. Business process tools overview XPDL 1.0 processes dened in XPDL (compatible with Bonita 4) jBPM 3.2 processes designed in jBPM 3.2

The most important is the possibility to import BPMN denition, Bonita enables the user to choose between .bpmn and .xml le sux. Import is seamless and the graphical alignment of elements is almost identical to the original (provided the original stores information about the layout). 3.1.3.2 Export

There are two kinds of export available for the user. The rst and the more accessible one is the internal Bonita export. It oers the possibility to transfer the project between dierent installations of the suite, therefore it is not suited for non-Bonita users. After the export button is clicked, the dialog window containing several conguration options (destination path, selecting resources, properties, dependencies. . . ) pops up. The extension for this export is .bos. The second and the more useful one is the Export as feature. It does not come with too many output formats, but it supports standard BPMN 2.0 export (also the export to image is available). This enables the designer to create the diagram in BPM Studio and use it further in other suites. 3.1.4 Simulation

The point of excellence for BPM Studio is the simulation and its features. The simulation process setup could be divided into three steps: resource management, load prole denition and simulation settings for diagram elements. Resource management is used for denition of resources available to the process execution simulation. The denition aggregates the general resource information (resource name, quantity, target quantity), resource cost (cost unit currency, cost per use xed costs, time cost per time unit of choice) and resource calendar (denition of time periods in which the resource is available). The resource calendar is dened on a weekly basis, which means that it is possible to make the resource available lets say every Wednesday from 8 AM to 4 PM, but there is no way of adding any exception to the rule (for example it is impossible to dene that the sledge is not available on the December 24th , because Santa Claus is using it for delivery). Either way, the calendar is quite sucient. Load prole denes the process instance injection during the simulation. The denition consists of the prole name and the injection periods. At least one period must be present. The periods properties are: the beginning (date and time), the end (date and time), number of instances and repartition type. The repartition type can take on two values: Constant the instances are dispatched in a constant way along the period Direct all the instances are injected at the start of the period

18

3. Business process tools overview There could be multiple load proles. They are independent from the process denitions so they can be reused. Simulation attributes for elements are set in the properties panel of the BPM Studio. There are four groups of elements that have dierent simulation settings: Pools the estimated time for a single instance of the process and the instance simulation data Connecting objects the probability of taking the transition or the transition condition Flow objects exclusivity of outgoing transitions, whether the task is contiguous, execution time, estimated time, maximum time, data and resources (resource, quantity, duration) Other objects there are no settings

When all the needed properties and attributes are set, the simulation can be executed. Before the actual execution the user sets the sampling interval which is a duration interval used to collect data for the report. The simulation report output is created in two versions - HTML version and PDF version. Regardless of the format they are identical. The report mainly consists of graphs that show execution times, waiting times and resource costs. First the complete process results are shown, then there are details of all the activities of the process and resources used through the simulation.

3.2

jBPM

jBPM project is a BPM solution developed by JBoss. Actually, jBPM itself is just a module inside Business Logic integration Platform, but its installation provides all the tools needed for the business process life cycle management. The version of the reviewed project is 5.4.0. By default, the installation contains following software: JBoss Application Server3 , Drools Guvnor, jBPM5 GWT process server, jBPM5 GWT console, web process designer and Eclipse with jBPM5 plugin. The focus of the review is not on the jBPM process engine, but on the web process designer jBPM Designer 2.4.0.Final that comes with the package. Eclipse with the jBPM5 module contains BPMN designer as well, but its capabilities are not nearly as complete as of the Web process designer and it does not support simulation. The platform is open-source so the user contribution is possible and even encouraged. Web nature of the project enables it to run on multiple platforms, it is possible to use any Java application server of choice, the JBoss Application Server is not mandatory.
3. JBoss AS has been recently renamed to WildFly

19

3. Business process tools overview

Figure 3.2: jBPM Designer screenshot.

3.2.1

Modeling possibilities and ease of use

Web process designer is based on the Oryx designer, which is a popular BPMN designer used throughout the business process suites. The popularity of the designer is arguably caused by the fact that it is written in JavaScript, so it is extremely easy to extend, improve and x even for the less experienced. In order to create a process denition the user has to navigate through Drools Guvnor repository to the knowledge bases and click on the Create new New BPMN2 Process link. After a while loading times can be a little annoying after some time the designer shows up in the right panel of the view. Width of the view can be adjusted so that it takes up all the horizontal space which can not be said about the vertical space. Fortunately, the editor has a full screen mode and a very simple user interface (UI). The main region of the view is taken up by the modeling canvas. There is a palette of the elements on the left and properties panel on the right. Then there are two toolbars an upper toolbar with all the controls and a lower toolbar with export buttons. The actual modeling is done by dragging the elements from the palette and dropping them on a desired place in the canvas. It is possible to move the elements around the canvas, the rendering speed is much better then that of Bonita BPM Studio. Selected element contains a context menu with the controls that help to make the modeling easier for example there are shortcuts for adding proper elements to the ow. There are two basic color schemes prearranged, they are both well-grounded and adjustable color

20

3. Business process tools overview scheme of each element can be changed individually. Overall experience with the modeling is very pleasant, on the other hand the visual integration with Drools Guvnor is a bit clumsy and rough. The full screen mode solves this only partially as it is impossible to save the diagram without the interaction with the Guvnor interface. 3.2.2 Palette of elements

As it was mentioned before the palette occupies left side of the designer view. It can be hidden so that there is more space for the modeling canvas. The user can choose from two perspectives that can be changed via the combo box: jBPM BPMN2 (Full) and jBPM BPMN2 (Minimal), which is just a subset of the full perspective. The full perspective is almost complete descriptive set of elements. The ow objects contain: tasks human task, manual task, script task, send task, receive task, service task, business rule task, reusable sub-process, embedded sub-process, ad-hoc sub-process gateways exclusive, parallel, inclusive, event-based events start: event (basic), message, timer, escalation, conditional, error, compensation, signal end: event (basic), message, escalation, error, cancel, compensation, signal, terminate intermediate: event (basic), message (throw, catch), timer, escalation (throw, catch), conditional, error, signal (throw, catch)

The supported connecting objects are: sequence ow, undirected association and unidirectional association. The only swimlane representative is the lane, the pool is not supported. Additional information can be introduced by these artifacts: data object, text annotation and a group. Some patterns became an established part of the analysts dictionary. Selection of these can be found in the palette in the Workflow Patterns section. Namely: arbitrary cycles, deferred choice, exclusive choice, implicit termination, multiple instances without synchronization, parallel split, sequence, simple merge, synchronization, synchronization merge and XOR split. Although the palette oers rich variety of ow objects, it does not support message ows and pools. The reason for this is that collaborations are not supported by the jBPM runtime[14]. This indicates that the support should not be expected in the near future and when the users need to create a collaboration diagram, they should use some other tool instead.

21

3. Business process tools overview 3.2.3 Import/export

The jBPM Designer uses BPMN-like XML with some extensions (simulation properties. . . ) document for storing the modeled process. This ensures smooth conversion between relevant process denition formats. 3.2.3.1 Import

There are two formats of process denition that can be imported into the designer. The rst one is a proprietary JSON format that works only in the jBPM itself it can be used to transfer the process denition from older jBPM version to a newer one. The second is a genuine BPMN 2.0 format and this should work generally with any other platform that supports BPMN 2.0 export. However, during the testing, many attempts to import outputs generated by various tools were not successful. 3.2.3.2 Export

The bottom toolbar in the main designer view serves as a holder of the export buttons. There are exactly six buttons: ERDF, JSON, PDF, PNG, BPMN2, SVG. Each of these represents an output format for the process denition export. The selection looks spectacular, but only a couple of them are really handy: BPMN2 and JSON. Remaining four are not suitable for further use. JSON format was mentioned here before it is a proprietary format used across the history of jBPM and is useful when transferring the model between versions. BPMN2 export is much more benecial as it is supported all over the BPMN suites. 3.2.4 Simulation

jBPM 5.4 was the rst release to include simulation features directly in the web-based designer[15]. The simulation controls and properties are subtle and well hidden for a common user. The main toolbar contains a small button with an icon of a light bulb from there the user is able to execute the simulation. Simulation properties for the process can be set in the properties panel. There are six types of elements for which the simulation settings dier: The process itself it is possible to set the base currency4 and base time unit (milliseconds, seconds, minutes, hours, days, years) Start event wait time and time unit Intermediate event time unit and distribution type and based on the distribution type, there are these choices:
4.

normal mean processing time and standard deviation

ISO 4217 format for example EUR, USD. . .

22

3. Business process tools overview uniform, random maximum processing time and minimum processing time Poisson mean processing time

End event time unit, distribution type, minimum, maximum and mean processing time and standard deviation (all of these settings are shown, but only some of them are used based on the selected distribution type) Sequence ow probability in %, 0 meaning the transition will never be used and 100 meaning the transition will always be used Task cost per time unit, currency, sta availability, time unit, working hours, distribution type and processing time settings based on the distribution type (see Intermediate event item)

When the settings are complete, the user can run the simulation. It is based on the execution of paths in the process and their probability. These paths can be shown by clicking on the light bulb button and Process Paths option. Beware of the loops in the diagram as they create an innite number of dierent paths and make process paths computation and even simulation impossible. Before the actual simulation run, desired number of instances, injection interval and interval must be set. The results are shown in the new tab of the designer window. They are formed by three perspectives: process, activities and paths. The process perspective focuses on the execution of the process. It shows the execution time (minimum, maximum and average) and number of instances by activity in comprehensible charts. There are several kinds of charts available: bar chart, horizontal bar chart, pie chart, table, timeline and line chart. The activities perspective shows the results activity by activity. Detailed charts are available showing execution and waiting times, resource utilization and resource cost each of these comes in three variants: maximum, minimum and average. Selection of graphs is not as rich as in previous perspective, there is only a bar chart and a table. And nally the paths perspective: it shows the path image and path instance execution pie chart (or a table) compared to other paths. While the presentation of the results is impressive, the simulation itself works only sometimes and its complicated setup may become annoying after a couple of executions. The complexity (in a good way) of settings can barely compare to those of Bonita Studio, especially the resource availability customization is not sucient.

3.3

Bizagi Process Modeler

The last of the reviewed BPM tools is the Bizagi Process Modeler. The name suggests that it is not a complete suite, however the aim of the analysis is on the modeling and simulation capabilities and they are fully supported in the modeler. With over 20 years in the business, Bizagi is a company with strong background and customer base. The

23

3. Business process tools overview

Figure 3.3: Bizagi Process Modeler screenshot. modeler is a part of the Bizagi BPM Suite and serves as a development tool for the initial stage of the business process life cycle. Although the suite is paid, the modeler itself is free of charge. It comes only in the MS Windows version, which is a big limitation for companies using multiple platforms. 3.3.1 Modeling and ease of use

First thing that strikes the eye of the user when the application starts is the ribbon toolbar similar to those used by Microsoft in their latest applications. The toolbar contains all the controls organized into series of tabs. Other than that, the view is almost identical to every other tool available for the same purpose modeling something. There is a palette toolbar on the left and large canvas in the middle. The modeling is basically the same as in the jBPM designer drag and drop from palette and context menu with reusable elements. The responsiveness of the designer is also at the same level with the aforementioned designer. The only thing that separates them is the ease of settings it is more complicated to change the type of the object in the Bizagi process modeler. 3.3.2 Palette of elements

Bizagi designer oers the richest palette of the selection. It is divided into ve sections: Flow, Data, Artifacts, Swimlanes and Connectors. The names speak for themselves, but let us list all the elements.

24

3. Business process tools overview 3.3.2.1 Flow

This section contains the ow elements of the BPMN specication. There are six basic components with several subtypes available: Task (none), manual, human, service, receive, script, send and business rule. It is also possible to dene loop types: none, standard and multi-instance. These events can be attached to tasks: message, timer, error, compensate, conditional, single, multiple, parallel multiple and escalation Sub-process sub-process and reusable sub-process. As the sub-process is conceptually the same as task, it has the same loop types and attachable events. Gateway exclusive, parallel, inclusive, event-based, exclusive event-based, parallel event-based, complex Start event (none), conditional, timer, signal, message, multiple and parallel multiple. Intermediate event (none), timer, message (catch, throw), signal (catch, throw), link (catch, throw), conditional, compensate, escalation, multiple (catch, throw), parallel multiple. End event (none), terminate, message, signal, compensate, escalation, error, cancel and multiple. Data

3.3.2.2

The data section contains the data artifacts data object and data store. 3.3.2.3 Artifacts

The artifacts oered in Bizagi Process Modeler are by far the most complete and diverse. This section contains: group, annotation, image, header, formatted text and custom artifact. 3.3.2.4 Swimlanes

Swimlanes in the modeler are present in their entirety. Beside the common pool and lane element, there is a milestone it serves as a sub-partition within a process. 3.3.2.5 Connecting objects

Last but not least, the connecting objects are also complete. The palette contains sequence ow, association and nally a message ow. This means that the Bizagi Process Modeler is the only one that can capture the collaboration diagram.

25

3. Business process tools overview 3.3.3 Import/export

The Bizagi Process Modeler uses their own format for storing modeled processes and their properties. It is an archive containing set of XML les, for example the diagram is dened in XPDL5 and the simulation properties are stored following the BPSim standard6 . 3.3.3.1 Import

Import is accessible from the Export/Import tab in the main toolbar. It oers three options: import from Visio, from XPDL and Attributes import. Non-existence of direct import from BPMN is a letdown, however conversion between XPDL and BPMN can be conducted in external tools. 3.3.3.2 Export

The designer is consistent in the export possibilities as it oers the same options as the import and adds only image export. 3.3.4 Simulation

As it was mentioned before, the simulation model is driven by the BPSim standard denition. It is an advantage since the standard was developed in cooperation with many BPM authorities. It also enables easy interchangeability and interoperability. The simulation properties and scenario denition process may confuse the rst-time users from the start as it is dierent as in other tools. Nevertheless, it does not necessarily mean a bad thing. On the contrary, the wizard, which appears after the click on the Simulation View button, presents a comprehensive way of setting simulation properties. The whole operation is divided into four steps Process Validation, Time Analysis, Resource Analysis and Calendar Analysis. Process Validation does not have much in common with the actual process validity and executability. At this step the user denes two basic properties: Start event maximum arrival count this number is the upper limit of how many times the process simulation begins in the selected start event. It is set on the start event. Split probability when the process contains multiple possible paths, the split probability needs to be dened for the simulation to determine the number of each individual simulation runs on the specic path. It is set on the exclusive gateway or in a non-standard case on any other element that has multiple outgoing transitions.

5. XPDL stands for XML Process Denition Language and it is a interchange format for business process denitions. 6. BPSim is a WfMC standard. It denes a specication for the Parameterization and Interchange of process analysis data allowing Structural and Capacity Analysis of a process model providing for Pre-execution and Post-execution optimization[16].

26

3. Business process tools overview In addition, this is the rst step that enables the scenario properties denition. These properties include name of the scenario, description, author, version, start (date), duration, base time unit, base currency unit, replication and seed. The next step is Time Analysis. This is where the time spent on tasks is set. There are several ways of dening the time property: Duration a duration dened using the ISO 8601 standard. It consists of days, hours, minutes and seconds. Constant a oating point or integer value specifying the amount of base time unit. Continuous distribution normal, truncated normal, uniform, triangular, lognormal, beta, negative exponential, gamma, Erlang and Weibull distribution. Discrete distribution binomial or Poisson distribution.

Beside the task properties, the intermediate events arrival intervals are dened here as well. They represent the interval after which a specic event occurs and will keep occurring every time interval until the arrival count is reached. The denition of resources is present in Resource Analysis. The user can manipulate simulation resources, change their type (entity or role), set their quantities, xed costs and costs per hour. The resources are then available in the diagram for the detailed specication for the individual tasks. Usage of multiple resources for single task is determined based on logical conjunction or disjunction whichever is selected in the resource editor. The costs are dened for the separate tasks as well. The time analysis is enriched with wait time property which is dened exactly as the processing time. The last step of the wizard is Calendar Analysis. While in the previous step the resources were set up, this step includes dening their availability over time. This is enabled by creating the resource calendar via the Calendars button in the toolbar. The calendar has various properties, such as: Name name of the calendar. Start time start time in hours and minutes. Duration miscellaneous values from minutes, through hours, up to four weeks. Recurrence pattern the repetition frequency of the calendar (days, weeks, months and years). Range of recurrence boundaries of the recurrence, the start is mandatory, the end is optional.

The availability of resources should be dened for every single calendar. The default value for each resource is the one dened as quantity in the previous step.

27

3. Business process tools overview Once the required data is dened, the simulation can be run. It is done by clicking on the Run button and then on the Start button. The real time analysis accompanies the execution. It consists of: status of resource usage, number of tokens completed, average time per activity, total processing time for each activity and average waiting time for each activity. When the simulation is complete, the outcome may be viewed via the Results button. It shows the usage percentage, total xed cost and total unit cost for each resource. The process statistics are displayed in a table which is divided into rows by the individual activities. Each row contains these columns: name, type, tokens completed, tokens started, minimum time, maximum time, average time, total time, minimum time waiting, maximum time waiting, average time waiting, standard deviation waiting, total time waiting and total xed cost. The statistics can be exported to Excel.

3.4

Summary

The following tables (3.1, 3.2 and 3.3) represent the most relevant features and their comparison for the three BPMN modeling and simulation tools. They are divided into ve sections one general and four for each sub-section of the overview (modeling, palette, import/export and simulation). 3.4.1 Bonita BPM

Bonita BPM is a poor candidate when it comes to modeling the processes. The palette does not oer such variety of elements as the competition. This could be forgiven as most of the time the selection of elements is sucient and in fact the only necessary element that is missing is the message ow. What is not so forgivable is the rendering speed and sluggishness of the graphical interface. Apart from the fact, that it does not support BPSim standard, the simulation abilities are the best of the reviewed tools. Importing external processes works just ne, so the Bonita BPM is a great candidate for simulating processes modeled elsewhere and using Windows is out of the question. 3.4.2 jBPM

Modeling in jBPM designer is a delight and the palette supports much more elements than Bonita BPM. But still the message ow is absent. If this is not the issue, the designer is well-suited for its purposes. Moreover the application is web-based so it can be deployed everywhere where JBoss AS (or any other suitable application server) runs. On the other hand the simulation is the weakest point of the designer. Especially the resource utilization denition is almost non-existent. Another big aw is that the simulator can not handle loops in the process it operates only on nite paths. The designer is suitable for process modeling, but not so much for the simulation.

28

3. Business process tools overview 3.4.3 Bizagi Process Modeler

Modeling in Bizagi Process Modeler is almost as easy as in jBPM designer, the palette oers the best selection of elements and it nally supports message ows. From this point of view, this tool is on par with jBPM designer and maybe a little ahead while Bonita BPM barely catches up. Simulation features are rich, very well organized and easy to use. The support of BPSim standard is sucient, missing only expression evaluation, interruptible tasks and task priority. As a whole, the Bizagi Process Modeler is the best candidate for the initial part of the business process life cycle. But poor export options restrain its use as a single purpose tool. Combined with the dependency on the Windows platform this might result in a decision to rather use Bonita BPM (which is ahead in simulation options) or Bonita BPM together with jBPM designer jBPM designer for modeling and Bonita BPM for simulation.

29

Bonita BPM General Release License Deployment type Platform Modeling BPMN 2.0 Drag and drop Element context menu Color schemes Notes 6.0.3 GPL Desktop Windows, Linux, OSX Yes Yes Yes default Sluggish interface and rendering

jBPM 5.4.0.Final GPL Web Windows, Linux, OSX Yes Yes Yes default, high contrast, custom The modeler is a part of the jBPM deployment and cannot be used without the Drools Guvnor

Bizagi Process Modeler 2.5.1.1 Freeware Desktop Windows Yes Yes Yes default, black and white Less intuitive context menu

3. Business process tools overview

Table 3.1: General and modeling features comparison

30

Bonita BPM Palette Tasks Sub-processes Gateways abstract, call activity, human, receive, script, send, service event exclusive, parallel, inclusive

jBPM business rule, human, manual, receive, script, send, service ad-hoc, embedded, reusable exclusive, parallel, inclusive, event-based

Bizagi Process Modeler business rule, human, manual, receive, script, send, service reusable exclusive, parallel, inclusive, event-based, exclusive eventbased, parallel event-based, complex conditional, message, multiple, parallel multiple, signal, timer compensate, conditional, escalation, link (catch, throw), message (catch, throw), multiple (catch, throw), parallel multiple, signal (catch, throw), timer cancel, compensate, error, escalation, message, multiple, signal, terminate sequence ow, association, message ow pool, lane, milestone data object, data store, formatted text, group, header, image, text annotation, custom No

Start events

error, message, signal, timer

Intermediate events

catch error, message (catch, throw), link (catch, throw), noninterrupting boundary timer, signal (catch, throw), timer error, message, signal, timer

compensation, conditional, error, escalation, message, signal, timer conditional, error, escalation (catch, throw), message (catch, throw), signal (catch, throw), timer cancel, compensation, error, escalation, message, signal, terminate sequence ow, association lane data object, group, text annotation Yes

3. Business process tools overview

End events

Connecting objects Swimlanes Artifacts

sequence ow, association pool, lane text annotation

Workow patterns 31

No

Table 3.2: Palette features comparison

Bonita BPM Import/export Import Bonita 6.x, Bonita BAR 5.9/5.10, BPMN 2.0, XPDL 1.0, jBPM 3.2 Bonita (internal), image, BPMN 2.0 No No Yes Yes Yes No No Yes PDF, HTML

jBPM BPMN 2.0, JSON

Bizagi Process Modeler XPDL, Attributes, Visio

Export Simulation Standalone simulator BPSim support Scenarios Resource management Expressions Distribution-based values Real-time preview Graphical reports Report output Additional notes

ERDF, JSON, PDF, PNG, BPMN 2.0, SVG No Noa No No No Yes No Yes internal Simulation does not support loops

XPDL, Visio, Attributes, image No Yes Yes Yes No Yes Yes Yes XLS

3. Business process tools overview

a.

Newer versions added this support

Table 3.3: Import/export and simulation features comparison

32

Chapter 4

Engine extension
4.1 iQ Workow Engine

InQool1 is a young software company based in Brno, formed predominantly by former or current students of Faculty of Informatics, Masaryk University. Its activity can be divided into two groups custom-made software solutions built on various technologies and own ready-made products that serve as rst class software products or as a platform for custom-made solutions. iQ Workow Engine2 falls into the second category, mainly as a platform for further extensions that result from analyzing the clients requirements. The goal of the engine is to streamline business processes and reduce their complexity by means of ensuring the workow, task checking, key performance indicators measurement, reporting and document workow. This can only be achieved with a rst-class quality process management platform. The Activiti BPM Platform is a basic and the most important building element of the iQ Workow Engine. 4.1.1 Activiti

The Activiti project was started in 2010 by Tom Baeyens and Joram Barrez, the former founder and the core developer of jBPM, respectively[9]. It is funded by Alfresco3 and integrated into the Alfresco system to provide necessary process engine features, but its development is independent. The tool stack in Activiti BPM Platform consists of ve individual components that manage major part of the business process life cycle: Activiti Engine the core component of the stack that performs the operations directly related to business process execution, such as BPMN 2.0 process parsing, validation, execution and workow task management. Activiti Explorer a web application that serves as a control room for process deployment, execution, modeling, task and user management. Activiti Modeler a web-based business process modeler for creating BPMN
http://www.inqool.cz/en http://www.inqool.cz/en/products/iqworkflow Alfresco is known for its document management system. See http://www.alfresco.com

1. 2. 3.

33

4. Engine extension 2.0-compliant diagrams built on Signavio Core Components code, now part of Activiti Explorer. It does not have simulation capabilities[17]. Activiti Designer an Eclipse plugin used similarly as Activiti Modeler to create BPMN 2.0-compliant diagrams, but oers additional features, such as Java service task and execution listeners, process unit testing, etc. It does not have simulation capabilities. Activiti REST a REST interface on top of the Activiti Engine. What is missing

4.1.2

Except for Activiti REST, the iQ Workow Engine makes use of all the Activiti components and adds tweaks, tools and product-specic customizations on top. When we take a look at the list of Activiti components, it is clear that the modeling phase as well as the optimization phase of the process life cycle suer from the absence of a process simulation tool. This is why we, at inQool, decided to propose a new simulation engine as a part of the practical section of this thesis.

4.2

Solution proposal

In the business process tools overview (see chapter 3), we looked into the selected BPM modeling and simulation tools. The discoveries made there lead to an idea to implement our own standalone BPMN 2.0-compatible process simulation engine based on the BPSim standard. To summarize the proposal, we want to build an engine that meets the following requirements: BPMN 2.0-compatible engine Partial compliance with the BPSim standard with respect to extending the engine to the full support in the future Standalone simulation with as little dependencies on other systems as possible Advanced resource availability denition support Simple expressions support, especially in conditional transitions

These requirements should be conrmed in the section that presents the functionality on given set of BPMN processes. 4.2.1 BPSim

BPSim (Business Process Simulation) is a fairly new standard that came to light earlier this year. The version 1.0 is dated to February 7th , 2013. It is a result of joint eort coordinated by Denis Gagne and Robert Shapiro under the Workow Management Coalition (WfMC) supervision. According to the specication[18]:

34

4. Engine extension The specication is meant to support both pre-execution and post-execution optimization phases of business process life cycle. The specication consists of an underlying computer-interpretable representation and an accompanying electronic le format to ease the transfer of the data between dierent tools. BPSim framework is a standardized specication that allows business process models captured in BPMN 2.0 (or XPDL) to be augmented with information in support of rigorous methods of analysis. The BPSim meta-model is captured using Unied Modeling Language (XML) and the interchange format is dened using an XML Schema Denition (XSD). Priority was given to ensure that the interchange format is human readable. This has side eects that the format does not adhere to all the best object oriented practices. Meta-model and interchange format allow for the capture of both inputs and outputs of the process analysis.

When implemented correctly, the BPSim framework should bring us the support for resource management based on iCalendar format4 and expressions in desired places. 4.2.2 REST service

Representational State Transfer (REST) is a set of architectural practices by which a Web service can be designed with focus on the resource as a corner-stone upon which the architecture is built[20]. It follows four basic principles: Use HTTP methods (GET, POST, UPDATE. . . ) explicitly. Be stateless. Expose directory structure-like URIs. Transfer XML, JavaScript Object Notation (JSON) or both.

The simplicity of these principles enables quick and easy development of standalone module that serves as a Web service for process simulation. We can consider the BPMN 2.0 model plus the accompanying BPSim model to be a resource around which we can build a RESTful service.
4. iCalendar is a data format for representing and exchanging calendaring and scheduling information[19]

35

4. Engine extension

4.3

Architecture and design

The application structure will be divided into three modules: API, implementation and REST API. This section deals with the API and the REST API module, the implementation will be analyzed in another section. 4.3.1 API domain model

There are three separate domains to be concerned with: the BPMN 2.0 data model, the BPSim data model and the simulation data model, which groups previous two models together.

Figure 4.1: Simulation data model. BPMN 2.0 data model is dened in the XSD documents accessible on the Object Management Group website5 . The model does not need to be adjusted in any way, as the structure comprised within the document is fully sucient for the simulation needs every relevant BPMN element has its own class so the categorization within simulation can be done easily. Transformation from the XSD to a set of classes will be described later.
5. http://www.omg.org/spec/BPMN/2.0/

36

4. Engine extension BPSim data model is also dened in the relevant XSD available on the BPSim standard website6 . Transformation from the XSD to a set of classes will be described later. Containing data model (see 4.1) is made up of only six classes in order to simplify the overall simulation model. The Element class is the base class and the parent of the other ve classes. It embodies any element of the BPMN model to which simulation properties can be bound and contains the accessor methods for common attributes: String getId() this method is not visible on the class diagram since it is inherited from a common package private class. It returns the id of the element, it should be the same as the id dened in the BPMN model. void setId(String id) setter method for the previous getter. It is not visible in the diagram for the same reason. ElementParameters getElementParameters() ElementParameters is a common class of BPSim model which contains all the simulation properties for the given element. This method returns the ElementParameters of the element. void setElementParameters(ElementParameters e) setter method for the previous getter.

The next class in the hierarchy is the Definition class. It corresponds to the Definitions element of the BPMN model, the uppermost element containing denitions of processes. Besides accessors to the collection of BusinessProcess instances it contains collection of resources as dened in the simulation properties and the scenario by which the simulation will be driven. The Scenario class belongs to the BPSim data model. BusinessProcess class represents the denition of a single process in the model containing accessor methods to the starting node, collection of all nodes and collection of all transitions. Sequence ows inside the process are represented by Transition class. It contains accessor methods to the BPMN representation (SequenceFlow) and source and destination node. Flow objects are reected in the Node class. It contains accessors to the BPMN representation (FlowNode), all the boundary event nodes that are bound to this node, and accessors to the collection of incoming and outgoing transitions. The last class is the SubProcess class. It combines the behavior of Node and BusinessProcess. 4.3.2 REST API

The REST API basically uses two kinds of resources XML les for BPMN and BPSim denitions and results and JSON model for storing hyperlinks to these les. Listing 4.1 shows such JSON object with these properties:
6. http://www.bpsim.org/schemas/1.0/

37

4. Engine extension id id of the resource. definition location of the input BPMN and BPSim XML denition. result location of the result of the simulation, is is an XML le structured like the input document with addition of requested result values.

Listing 4.1 Example of a JSON resource returned by the REST API. { id: 8, definition: http://example.com/simulations/8/definition, result: http://example.com/simulations/8/result } Sequence diagram in the gure 4.2 shows the basic communication sequences within the REST service. The order of the calls does not matter. As the REST is all about resources, there is no standard way of specifying an operation on a resource. That is why the command to run the simulation is wrapped inside the resource creation. In fact we are creating a simulation result resource. The table 4.1 describes the API calls in detail. context stands for the root context of the web service, for example http://bpmn.inqool.cz/simulator/rest.
URL {context}/simulations Method POST Description Create the simulation resource by posting the BPMN and BPSim definition as multipart/form-data Get the JSON resource identied by id structured as the one described in the listing 4.1 Get the BPMN and BPSim denition XML identied by id Get the result XML identied with id Update the simulation resource identied by id by posting the XML Delete the simulation resource and respective les identied by id

{context}/simulations/{id}

GET

{context}/simulations/{id}/definition {context}/simulations/{id}/result {context}/simulations/{id}

GET GET PUT

{context}/simulations/{id}

DELETE

Table 4.1: Detailed description of the REST API calls.

4.3.3

Simulation engine API

The structure of the API can be best seen from the sequence diagrams of the single simulation run. This operation is the core and the most important feature of the simulation engine. It is divided into two views based on how deep the method calls go.

38

4. Engine extension

Figure 4.2: Communication sequences within the REST service.

The top-level view (see gure 4.3) can be interpreted as the REST API calling the engine API. The call begins with the simulator, which is a virtual role and in this case it can be substituted with the REST service. All the other participants in the sequence diagram are actual interfaces and now we will go through them in detail. The BPMNDefinitionReader is an interface that transforms an XML le containing BPMN denition into a structure of objects with Definitions as the parent object. It contains the only method Definitions read(URI uri) which takes a URI of the XML le as a parameter and returns the Definitions when successful. Otherwise it throws a runtime exception BPMNDefinitionParseException. Next interface is the SimulationDataReader and its purpose is to transform an XML le containing BPSim denition into an object structure with BPSimData being the root element. It also contains only a single method BPSimData read(URI uri) which takes a URI of the XML le as a parameter and returns the BPSimData when successful. Otherwise it throws a runtime exception SimulationDataParseException. When both the BPMN and BPSim denitions are ready and a proper scenario is selected, the SimulationDefinitionTransformer comes into play and creates a data model described in the API domain model section (see 4.3.1). This interface contains only

39

4. Engine extension a single method Definition transform(Definitions def, BPSimData s, String scenarioId) which takes three arguments: BPMN denition, BPSim denition and ID of the desired scenario, respectively. It returns a Definition model which is the input for a simulation execution. The most important item from the rst sequence diagram is the SimulationRunner. It is also an imaginary boundary dividing the two levels of abstraction when looking into the simulation engine. Scenario runSimulation(Definition d) is the only method of this interface. It takes a Definition as an argument and returns the resulting scenario of a single simulation run. The last item on the list is the ResultWriter, which serves as a counterpart to the readers it converts the BPMN denition and simulation data with simulation results to a BPMN-compliant XML output.

Figure 4.3: Top-level view of simulation run. The low-level view (see gure 4.4) exposes the internal workings of the SimulationRunners only method runSimulation() in standard implementation. This might seem as an implementation detail, but it is crucial for better understanding of all the API interfaces. The ow begins with the external entity called Simulator and goes through some abstracted communication layers to the SimulationRunner. The method starts with creating the simulation context represented by the SimulationContext interface, which is described later in the text. Next the visitors come into play. There are four kinds of visitors: DefinitionVisitor, ScenarioVisitor, BusinessProcessVisitor and NodeInstanceVisitor. The runner manages collection of instances for each kind of visitor and employs them in various phases of the simulation. Let us walk through these phases. The rst phase begins with the DefinitionVisitor. The runner applies all the instances of the classes that implement this interface at the beginning of the simulation run. The interface contains a single method void visit(Definition definition,

40

4. Engine extension SimulationContext c) which may and should be used to process important data at the start. The outcome is then applied to the simulation context. Then the scenario visitors come into play. The ScenarioVisitor is an interface very similar to the previous one, except its method visit(..) takes Scenario as an argument instead of Definition. The outcome of this method is applied to the simulation context. This concludes the preparation and evaluation of properties that are valid globally for all the process executions in a single simulation run. Every BPSim scenario may dene a replication, which is a number of repeated runs of the whole simulation process. It defaults to one. When no random values and distributions are used in scenario denition, the results of the replications should be the same. The SimulationRunner loops n-times7 and does the following in each loop: 1. For each top-level BusinessProcess in Definition and each BusinessProcessVisitor, the void visit(BusinessProcess process, SimulationContext c) method is executed. It should serve mostly for scheduling the start events of the process. 2. The nodes that are prepared to be executed as a part of single process simulation are wrapped into the NodeInstance interface. The interface provides accessor methods for the actual node Node, parent NodeInstance, a timer boundary event that will be triggered, starting time, duration and id of the run (id of the single process simulation). The scheduled instances are held in the ProcessingQueue and queried in order of their scheduled starting time. While the queue is not empty, the NodeInstanceVisitor is utilized. This interface has two methods, the rst is void visit(NodeInstance n, SimulationContext c), which does the desired processing with the outcome applied to the simulation context and boolean supports(NodeInstance node, Phase p). This method determines, whether the visit(..) method of the visitor should be called on a given NodeInstance and in a given phase. There are three phases of a visit of the single NodeInstance, they are passed in the following order: (a) Prepare the rst phase of the node visits, the visitor should do only basic preparation operations, specically preparation of the context (setting the clock. . . ). (b) Execute the second and the most important phase. This is where the actual execution should happen, for example the expressions evaluation, actual starting time (with the wait time) and duration computation, resource utilization. . . (c) Schedule the last phase. The visitor should examine the transitions and schedule all the valid nodes that follow the visited node in the process. Each visitor, regardless the phase, may operate with the statistics and update the
7. n number of replications

41

4. Engine extension results. It is recommended that a single NodeInstanceVisitor implementation supports only one phase.

Figure 4.4: Low-level view of simulation run.

What happens during the simulation is a matter of SimulationContext (see 4.5). This interface denes the context, which is managed during the simulation and several helper classes that enable easier evaluation of simulation parameters. The SimulationContext provides us with the setter and getter to the identier of the current simulation replication. Moreover it oers getters to these classes: Definition the denition of the simulation, ProcessingQueue, WaitingRoom, ResourceManager, RandomGenerator, ExpressionEngine, ExpressionContext, StatisticsHolder, Clock, ParameterEvaluator and ElementParameterEvaluator.

42

4. Engine extension

Figure 4.5: Simplied SimulationContext diagram 4.3.3.1 ProcessingQueue

This interface was introduced before, let us summarize it. It serves as a container of scheduled NodeInstance instances. The queue in the name might be misleading, as it should not be a FIFO8 container, but more of a priority queue, with starting time of the NodeInstance as a priority indicator the lower starting time means higher priority. It consists of these methods:
8.

void queue(NodeInstance node) adds the node to the queue. boolean hasNext() indicates whether the queue contains at least one node.
FIFO stands for First In, First Out

43

4. Engine extension NodeInstance getNext() returns the node with the highest priority (lowest starting time) and removes it from the queue. WaitingRoom

4.3.3.2

Scheduling nodes is not a trivial process. Sometimes, the nodes can be scheduled only when the source nodes of all the incoming transitions have been processed (a join parallel gateway is an example of such node). These nodes are set aside to the WaitingRoom and they become WaitingNodeInstace instances. A WaitingNodeInstance contains a reference to the node and a counter. The counter indicates how many times has the node been set aside. When we decide that the node waited long enough, we can remove it from the WaitingRoom and put it in the ProcessingQueue. We are provided with these methods: WaitingNodeInstance getWaitingNodeInstance(Long runId, String idNode) returns the WaitingNodeInstance identied by the id of the run and id of the node. WaitingNodeInstance getWaitingNodeInstance(NodeInstance n) similar to the previous method, but the identiers are extracted from the NodeInstance. WaitingNodeInstance createWaitingNodeInstance(NodeInstance ni) creates a WaitingNodeInstance from the given node and increments its counter (from zero to one). void setWaitingNodeInstance(WaitingNodeInstance w) updates the given WaitingNodeInstance. It does not increment the counter. void removeWaitingNodeInstance(Long runId, String idNode) it removes the WaitingNodeInstance identied by the id of the run and it of the node from the WaitingRoom. ResourceManager

4.3.3.3

Managing resources is a task that is performed by a ResourceManager implementation. The interface denes several methods that enable easy manipulation with resources: void add(Resource resource) registers the Resource instance. Resource get(String name) returns the resource with the given name (the name of the resource must be unique). Long requestTime(String resourceName, Long fromTime, Long duration, Integer quantity) requests a closest free time of a quantity instances of a resource identied by the rsrcName, starting at fromTime milliseconds, with a duration of duration milliseconds. It returns null when no such time is available. This method also stores the request for later use.

44

4. Engine extension ResourceRequest getLastResourceRequest() returns the last request made by the previous method. It is convenient when we dont know about the request being made, for example when the resource is requested from the expression in the simulation denition. A ResourceRequest instance contains attributes corresponding to the parameters of the previous method. Collection<? extends ResourceRequest> getResourceRequests() it returns all the requests made with this ResourceManager. Collection<? extends Resource> getAll() returns all the resources registered with this ResourceManager. RandomGenerator

4.3.3.4

Simulation parameters are often fed with random values, usually using some kind of distribution (Poisson, normal. . . ). The user may dene a seed so that independent simulations with random values produce the same results. The RandomGenerator serves as a generator of random numbers with the possibility to set the seed. It should be set during the creation of the simulation context, prior to evaluating any parameter. 4.3.3.5 ExpressionEngine

Expressions are a crucial part of the simulation engine. They may be used for dening the ow, querying resources, etc. The simulation properties contain the expressions in the form of strings, therefore there needs to be a tool for evaluating these strings into some meaningful values. The ExpressionEngine serves just for that. It contains two methods, one being generalization of the other, so we will describe only the more general method: <E> E evaluate(String expression, Long runId, ExpressionContext ctx, Class<? extends E> clazz) evaluates the expression passed as the rst argument. The value bindings are contained in the expression context ctx and the result is dependent on the current run represented by the runId. The return type of the evaluated value is dened by passing an adequate Class clazz argument. ExpressionContext

4.3.3.6

Holding the values necessary for expression evaluation is a task performed by the ExpressionContext. There are two scopes of values: a global scope, which is valid for the whole simulation run and a local scope, which is valid only for a single process execution. The local scope is identied by the id of the process execution run (aforementioned runId). This interface denes these three methods: Map<String, Object> getBindings(Long runId) returns all the bindings for the given process execution run. Global bindings override the local bindings.

45

4. Engine extension void addBinding(Long runId, String nm, Object v) creates a new local binding for the given run id, with the name nm and the value v. If a binding with the same name exists in global context, the new value is put there and not to the local context. void addGlobalBinding(String name, Object value) creates a new global binding with the name name and the value value. StatisticsHolder

4.3.3.7

The evaluated parameters of the simulation properties are collected in the StatisticsHolder and subsequently summarized as the output scenario. There are several types of parameters dened in the BPSim that can be requested for the result. They are represented as the StatisticsParameter enumeration with the values TRANSFER_TIME, QUEUE_TIME, WAIT_TIME, SETUP_TIME, PROCESSING_TIME, VALIDATION_TIME, REWORK_TIME, INTER_TRIGGER_TIMER, TRIGGER_COUNT, SELECTION, FIXED_COST and UNIT_COST. The StatisticsHolder contains two methods: void add(String replicationId, String elId, StatisticsParameter parameter, Object value) adds the value of the given statistics parameter type for the element identied by elId to the container. The replicationId is important as well, since the summary is done for each replication independently. Scenario summarize(Scenario inputScenario) it summarizes the statistics for the inputScenario and returns the resulting scenario. Clock

4.3.3.8

The simulation is driven by a queue of nodes with specic starting time. To keep the current time throughout the execution, the Clock provides us with a couple of methods: Long getTime() returns the current time in milliseconds. void setTime(Long milliseconds) sets the current time in milliseconds. void addTime(Long value, TimeUnit u) sets the current time by adding the given number of given time units to the previous valid value. void addTime(Long milliseconds) similar to the previous methods, except the TimeUnit is xed to milliseconds. ParameterEvaluator

4.3.3.9

Besides evaluating expressions, the simulation scenario parameters are evaluated with the help of ParameterEvaluator. This could be a standalone class with no association to the SimulationContext whatsoever, but it ts right into the provided tools and direct access from the context is an advantage. It contains four methods, two and two being

46

4. Engine extension almost the same one having a RandomGenerator as the parameter, while the other uses its own generator. Since the former approach should be used, only the methods with the generator as the parameter are described: <E> EvaluatedParameter<E> evaluate(ParameterValue value, RandomGenerator randomGenerator, Class<? extends E> clazz) evaluates the ParameterValue, which is a class dened in BPSim that can contain various values (strings, constant numbers, distribution-based random numbers, enumerated values) and returns a single resulting value of the type based on the clazz. Random values are generated by the randomGenerator. <E> Collection<EvaluatedParameter<E>> evaluateCollection(ParameterValue val, RandomGenerator g, Class<? extends E> clazz) it is similar to the previous method, but instead of a single result, it returns a collection of results, for example when we want to return all the values dened in an enumeration.

EvaluatedParameter<E> is a class which holds the evaluated value with some additional information time unit (millisecond, second, minute. . . ) for duration values and currency for costs. 4.3.3.10 ElementParameterEvaluator The ElementParameterEvaluator serves as a top-level facade for the ParameterEvaluator and evaluates the parameters based on their use cases. For example, when we want to nd out the duration of a task, it is appropriate to use a method which returns a number of milliseconds. The class contains these methods, each of which may write statistics into the StatisticsHolder: Long evaluateTriggerCount(ElementParameters elParam, SimulationContext c) returns the trigger count value from the ElementParameters or null, if no such denition exists. Double evaluateInterTriggerTimer(ElementParameters elParam, SimulationContext c) evaluates the length of an interval in milliseconds between two triggers of an element, for example a start event. Returns null if no such denition exists. Double evaluateProcessDuration(SimulationContext ctx) evaluates the duration of the simulation run in milliseconds. The value is just an approximation, it indicates the boundary after which a start event should not be triggered. Returns null if no such denition exists. Double evaluateProbability(ElementParameters elP, SimulationContext c) returns a real value between 0 to 1 indicating the probability of taking a specic transition. If no such denition exists, the method returns null.

47

4. Engine extension Long evaluateStartTime(ElementParameters elP, Long runId, Long duration, SimulationContext ctx) based on the current time, which is stored in the Clock instance in the simulation context and duration in milliseconds, this method evaluates the starting time of an element. The run identier is needed when evaluating resource requests expressions. The returned value is in milliseconds. It returns null only if the resource request was unsuccessful. If no such denition exists, the return value defaults to current time. Long evaluateDuration(ElementParameters e, SimulationContext c) returns the duration of an element in milliseconds. It defaults to zero, if no such denition exists. Boolean evaluateCondition(ElementParameters ep, Long runId, SimulationContext c) evaluates the condition of a transition in a specic run. If no such denition exists, the method returns null. void evaluatePropertyParameters(ElementParameters elPar, Long runId, SimulationContext c) adds the properties dened for the element to the expression context. void evaluateCostParameters(ElementParameters elPar, Long duration, SimulationContext c) evaluates the cost of a task with given duration and adds the result to the StatisticsHolder.

4.4

Implementation

The implementation follows the standards developed with the evolution of the iQ Workow Engine. Although it was not necessary, since the simulation engine is a standalone piece of software, the standards embodied the personal preferences of the author. 4.4.1 Technologies

During the development there was a tendency to use the lowest number of technologies such that there was no limitation on what the resulted software could do. Through careful analysis, we decided to engage the following technologies. 4.4.1.1 Java

Java was the programming language of choice. The introduction is not necessary it is one of the most popular languages we will just state the reasons for its use: Enterprise nature of the language allows for a seamless deployment of the software to the business environments. Clarity and verbosity of the language constructs may slow down the development, but in the end these are the attributes that enable easy code maintenance and refactoring.

48

4. Engine extension There are many more important features (object oriented nature, large community, lots of libraries and frameworks. . . ), but these two stand out in the comparisons with other languages. 4.4.1.2 Spring Framework

Programming to interfaces has lots of advantages, mainly it results in a system consisting of loosely coupled components. On the other hand such system must be assembled together in a way that enables the developer to easily swap the components when necessary. This is where Spring comes in handy. It provides the inversion of control (IoC) container which manages the life cycle of the objects and simplies the dependency injection. Spring employs four key strategies[21]: lightweight and minimally invasive development with plain old Java objects (POJOs), loose coupling through dependency injection and interface orientation, declarative programming through aspects and common conventions, boilerplate reduction through aspects and templates.

All the strategies are applied throughout the project. Declarative and aspect-oriented programming is most visible in the REST service implementation. The Spring MVC, which is a sub-project of the Spring Framework, is used for this purpose. 4.4.1.3 Maven

Java itself oers cumbersome build possibilities and almost non-existent dependency management. Maven was created to smear these deciencies by providing a tool which manages the project build, documentation and reporting from a central piece of information project object model (POM)[22]. Maven project maintains a large repository of libraries. To include an external library, all the developer has to do is to add a dependency consisting of a group id, an artifact id and a desired version. If the dependency is in the repository, it is downloaded and added to the project. Otherwise the developer must download the library manually and install it into the local repository. This is a little more work to do, but most libraries are already present in the central repository and manual installation is necessary in a minority of cases9 . 4.4.1.4 Apache Commons

The Apache Commons project is focused on all aspects of reusable Java components[23]. Specically, it was used for le uploading, IO operations, math-related tasks (random generators, distributions) and as a replacement for some standard Java utilities.
9. All dependencies of this project were present in the central repository.

49

4. Engine extension 4.4.1.5 iCal4j

The BPSim standards uses the iCalendar format to dene applicability of parameters. The iCal4j10 library is the Java implementation of the iCalendar standard and it is used in the project to deserialize and manipulate the calendar denition. Another candidate would be biweekly11 , but its features are more or less the same and the advantage of iCal4j is its longer exposure to the public it has been around since 2004, while biweekly is a rather young project started in 201312 . 4.4.1.6 JSON

JavaScript Object Notation is a lightweight data-interchange format with easy to read, write, parse and generate structure[24]. It competes with XML to become the number one format in the REST-based web services. JSON has other usages as well, but this is the exact domain of use in the project. 4.4.2 Key examples and features

This section is dedicated to the examples of selected components and to the supported features and limitations of the current implementation (it is referred to as the standard implementation further in the text). The complete implementation source code can be found in the attachment. 4.4.2.1 API model implementation

In API domain model section we introduced a data model (see 2.4) consisting of simple interfaces. The decision to build an interface-based model instead of class-based model was driven by the need of capturing the relationship between Node, BusinessProcess and SubProcess. It was required for SubProcess to extend both Node and BusinessProcess and the solution was not elegant when using the classes. In Java it is not possible to create a new instance of an interface directly without implementing it rst. To address this issue, the classes that needed to create new instances of the model interfaces were provided with a ModelFactory. As the name suggests, it serves as a model factory, creating custom implementations of desired interfaces. 4.4.2.2 SimulationRunner

We have already seen the sequence diagram for the standard implementation, now we will manifest how we use Spring to collect custom implementations of visitors. Spring provides several annotations that serve as a demarcation of classes we would like to inject into desired elds. The basic one is the @Component. A class with this annotation
10. http://wiki.modularity.net.au/ical4j/index.php?title=Main_Page 11. http://sourceforge.net/projects/biweekly/ 12. based on the commit logs on SourceForge, http://sourceforge.net/p/biweekly/code/commit_ browser for biweekly and http://sourceforge.net/p/ical4j/ical4j/commit_browser for iCal4j

50

4. Engine extension will be injected into a eld that is properly qualied (for example with the @Autowired annotation) and has the type of the class or its superclass/interface. The code snippet of the standard implementation SimulationRunnerImpl as shown on the listing 4.2 contains such annotations. The crucial point is the use of the Collection of desired elements, which ensures to inject all the desired implementations for example the NodeInstanceVisitor has four standard implementations: GeneralNodeInstanceExecuteVisitor, GeneralNodeInstancePrepareVisitor, GeneralNodeInstanceScheduleVisitor, NodeInstanceTriggerCountVisitor.

The collection is then looped through and the values are appropriately used in this case, the visitors are applied on the current NodeInstance. The integration of a custom NodeInstanceVisitor into the standard SimulationRunner is as easy as implementing the interface and marking the class with the @Component annotation (see listing 4.3). Listing 4.2 The SimulationRunnerImpl snippet. @Component public class SimulationRunnerImpl implements SimulationRunner { @Autowired private Collection<NodeInstanceVisitor> nodeVisitors; @Autowired private Collection<ScenarioVisitor> scenarioVisitors; @Autowired private Collection<DefinitionVisitor> definitionVisitors; @Autowired private Collection<BusinessProcessVisitor> businessProcessVisitors;

Listing 4.3 The example of a custom NodeInstanceVisitor implementation declaration. @Component public class CustomNodeInstanceVisitor implements NodeInstanceVisitor {

51

4. Engine extension 4.4.2.3 ExpressionEngine

The standard expression engine is an implementation based on a standard JavaScript engine found in the javax.script package. This means that the engine supports only JavaScript notation with the exception of simple comparison the single equation sign can be used for equality comparison since the standard use of a single equation sign value assignment is handled dierently13 . On top of that, it provides two functions dened in the BPSim standard: getProperty(propertyName) and getResource(name, quantity). The rst one is simple it retrieves the value bound to the property with the name propertyName. The second one is used for requesting the resource with the given name and quantity. The expression engine achieves this by calling the requestTime(..) method of the ResourceManager. The ResourceManagers implementation is added to the expression context in the initial phase of the simulation execution the standard implementation of the DefinitionVisitor performs this job. 4.4.2.4 Parameter type evaluation

The BPSim standard denes several parameter types. The current ParameterEvaluator supports most of them: Supported: NumericParameter, FloatingParameter, StringParameter, BooleanParameter, DurationParameter, EnumParameter, DateTimeParameter, ExpressionParameter, NormalDistribution, TriangularDistribution, LogNormalDistribution, BetaDistribution, BinomialDistribution, TruncatedNormalDistribution, PoissonDistribution, WeibullDistribution, UniformDistribution and GammaDistribution Not supported: NegativeExponentialDistribution, UserDistribution and ErlangDistribution Supported elements

4.4.2.5

The standard implementation supports only a subset of the BPMN 2.0 elements. Some elements have been ruled out in order to simplify the implementation while preserving the ability to capture common use cases. The palette of supported elements contains: tasks, sub-processes, gateways (parallel, exclusive), sequence ows and events, with the exception of ow objects (gateways, events, tasks. . . ) which have no incoming transition14 . Message ows are not yet supported (as is the case with Bonita BPM Studio or jBPM Web Designer), but this feature is planned for future extensions (along with the support of the events with no incoming transitions).
13. The assignment of simulation properties is handled via property binding dened in the PropertyParameters parameter. 14. The exception does not apply to start events and boundary events.

52

4. Engine extension There are some BPMN types that have no impact on simulation whatsoever, they include swimlanes, data objects, artifacts, data associations and associations. 4.4.2.6 Parameter support

BPSim parameters represent perspectives on common concerns. They evaluate to parameter types, that were described earlier. The standard implementation supports TimeParameters, ControlParameters, CostParameters, PropertyParameters and ResourceParameters. The only kind that is not supported is PriorityParameters, which means that tasks during simulation can not be prioritized (the time of schedule is the priority factor) and can not be interrupted (the time frame of a task must be continuous). The decision to not incorporate the PriorityParameters stems from the fact that the diculty of the implementation exceeds the return value of such investment. Even the simulator in the Bizagi Process Modeler does not support these features.

4.5

Simulation of selected processes

Now we will take a look on how our engine does its job in comparison with the simulation tools from the overview. 4.5.1 Manual invoice delivery

The initial idea to create our own simulation engine arose when we tried to simulate a really simple business process. Imagine a standard administrative workplace that involves handling some invoices. These are being delivered to the customer by following a simple, repetitive sequence of steps that can be transformed to a business process: 1. Print the invoice 2. Put it in an envelope 3. Print the address onto the envelope 4. Put it in the waiting box 5. If the waiting box is full, take all the invoices to the post oce This process is interesting by its use of a global memory the waiting box. The common simulation engines can not deal with this other than by using the probability to indicate the waiting box being full. Let us say that this situation occurs when the box contains exactly ten invoices. The probability-based solution would be to set the probability of the transition going from the exclusive gateway to the Take the invoices to the post oce task to 10 %. But this setting does not guarantee that the transition is taken exactly on the tenth process repetition from the point where the waiting box was empty.

53

4. Engine extension The BPSim comes with the solution based on the expression evaluation and property parameters. We set the global counter to zero in the scenario parameters. Then the counter is incremented every time the invoice is put into the box15 . Then we check whether the counter modulo 10 equals to zero in the exclusive gateway. This is guaranteed to produce the desired results.

Figure 4.6: Manual invoice delivery modeled in jBPM. The diagram can be seen on the gure 4.6. The XML denition is more important as it contains scenario parameters. We will describe every signicant part of the BPSim denition for this process.

4.5.1.1

BPSim denition

First we dene the global simulation properties (see 4.4). We dened single scenario with the id S1 and name My Scenario. Default time unit used throughout the denition is a minute. Seed for the random generator is 100 and we replicate the scenario two times. The start time of the simulation is set to the 1 January 2013 12:13:14. Notice the PropertyParameters with executionCounter set to zero. This will be our global memory representing the waiting box.

15. Or we can simply increment the counter with the start event invocation since the process does not take errors into account and it always ends up putting the invoice into the box.

54

4. Engine extension Listing 4.4 Global simulation properties. <Scenario id="S1" name="My Scenario"> <ScenarioParameters baseTimeUnit="min" replication="2" seed="100"> <Start> <DateTimeParameter value="2013-01-01T12:13:14Z"/> </Start> <PropertyParameters> <Property name="executionCounter"> <NumericParameter value="0"/> </Property> </PropertyParameters> </ScenarioParameters> <!-- content --> </Scenario> The only resource we need is a single accountant who is responsible for the delivery. Its availability is dened in the iCalendar format in the listing 4.5. Listing 4.5 Resources properties. <ElementParameters elementRef="accountants"> <ResourceParameters> <Quantity> <NumericParameter validFor="C1" value="1"/> </Quantity> </ResourceParameters> </ElementParameters> <Calendar id="C1" name="shift-6am-2pm"> BEGIN:VCALENDAR BEGIN:VEVENT DTSTAMP:20121220T202706 UID:1356035226921@localhost DTSTART:20121220T060000 DTEND:20121220T140000 RRULE:FREQ=DAILY END:VEVENT END:VCALENDAR </Calendar> The start event denition follows (see 4.6). We want to trigger our process 100 times with the new execution occurring every 2 to 10 minutes (with mode of 5) according to the triangular distribution. The PropertyParameters denition assures to increment the executionCounter every time the start event is processed. Since this counter is global and may be changed by another process simulation instance, we copy the counter

55

4. Engine extension to our local property waitingBoxCount. Listing 4.6 Start event properties. <ElementParameters elementRef="startEvent"> <ControlParameters> <TriggerCount> <NumericParameter value="100"/> </TriggerCount> <InterTriggerTimer> <TriangularDistribution min="2" max="10" mode="5"/> </InterTriggerTimer> </ControlParameters> <PropertyParameters> <Property name="executionCounter"> <ExpressionParameter value="getProperty(executionCounter) + 1"/> </Property> <Property name="waitingBoxCount"> <ExpressionParameter value="getProperty(executionCounter)"/> </Property> </PropertyParameters> </ElementParameters> The listing 4.7 belongs to the properties of the Print the invoice task. Other tasks dier only in the ProcessingTime value, therefore we will not go through their denitions. The task processing time is dened as a value generated by the given triangular distribution. Since the time unit is not overridden, the default time unit a minute is assumed. The task execution is constrained to the availability of a single accountant. Listing 4.7 Print the invoice task properties. <ElementParameters elementRef="printInvoice"> <TimeParameters> <ProcessingTime> <TriangularDistribution min="2" max="4" mode="2"/> </ProcessingTime> </TimeParameters> <ResourceParameters> <Selection> <ExpressionParameter value="getResource(accountants, 1)"/> </Selection> </ResourceParameters> </ElementParameters>

56

4. Engine extension The exclusive gateway has two outgoing transitions: one going to the join exclusive gateway (isBoxFullSplitToIsBoxFullJoin) and the other going to the Take them to post oce task (isBoxFullSplitToTakeToPostOffice). The decision of taking one of the transitions is made by evaluating the expression from the ExpressionParameter value (see 4.8). The rst transition is taken if the waitingBoxCount is not divisible by ten this happens 90 % of the time. Otherwise if the waitingBoxCount is divisible by ten the second transition is taken and the task of taking the invoices to the post oce can be executed. Listing 4.8 Exclusive gateway transitions properties. <ElementParameters elementRef="isBoxFullSplitToIsBoxFullJoin"> <ControlParameters> <Condition> <ExpressionParameter value="getProperty(waitingBoxCount) % 10 != 0"/> </Condition> </ControlParameters> </ElementParameters> <ElementParameters elementRef="isBoxFullSplitToTakeToPostOffice"> <ControlParameters> <Condition> <ExpressionParameter value="getProperty(waitingBoxCount) % 10 = 0"/> </Condition> </ControlParameters> </ElementParameters> The last interesting part is the request for results. It is shown in the listing 4.9. We specically requested the trigger count of the given task and minimum, average and maximum processing time. The results will be available in the output scenario of the simulation. 4.5.1.2 Result

Now we are ready to employ our simulating engine and see the results. The part of the output is shown in the listing 4.10. The interpretation is clear. Every result request from the denition is represented by its counterpart in the result. Besides the actual value, the output parameter contains the result type (min, mean, max, count. . . ) and an instance identier. There are two dierent identiers 36a319990825 and 1830e9a0d0e816 representing the two individual replications.
16. Typically, they are longer 32-digit GUID plus separating hyphens but they were shortened for brevity.

57

4. Engine extension Listing 4.9 Result request of the Take them to post oce task. <ElementParameters elementRef="takeToPostOffice"> <ControlParameters> <TriggerCount> <ResultRequest>count</ResultRequest> </TriggerCount> </ControlParameters> <TimeParameters> <ProcessingTime> <ResultRequest>min</ResultRequest> <ResultRequest>mean</ResultRequest> <ResultRequest>max</ResultRequest> <TriangularDistribution min="15" max="25" mode="20"/> </ProcessingTime> </TimeParameters> <ResourceParameters> <Selection> <ExpressionParameter value="getResource(accountants, 1)"/> </Selection> </ResourceParameters> </ElementParameters>

The table 4.2 summarizes the results in a more human readable and comprehensive way. Processing time (min) MIN MAX 15:50 15:17 23:06 22:21

Instance 36a319990825 1830e9a0d0e8

Trigger count 10 10

MEAN 19:05 19:25

Table 4.2: Simulation results summary.

4.5.1.3

Conclusion

The engine proved its worth by handling a case which could not be handled by any one of the reviewed tools simulation engines in jBPM and Bizagi Process Modeler do not allow expressions and Bonita BPM Studio supports only process-global expressions, not simulation-global.

58

4. Engine extension Listing 4.10 Resulting scenario of the simulation. <Scenario id="S1_result" result="S1"> <ElementParameters elementRef="takeToPostOffice"> <TimeParameters> <ProcessingTime> <DurationParameter instance="36a319990825" result="min" value="P0Y0M0DT0H15M50.774S"/> <DurationParameter instance="36a319990825" result="mean" value="P0Y0M0DT0H19M5.411S"/> <DurationParameter instance="36a319990825" result="max" value="P0Y0M0DT0H23M6.616S"/> <DurationParameter instance="1830e9a0d0e8" result="min" value="P0Y0M0DT0H15M17.642S"/> <DurationParameter instance="1830e9a0d0e8" result="mean" value="P0Y0M0DT0H19M25.179S"/> <DurationParameter instance="1830e9a0d0e8" result="max" value="P0Y0M0DT0H22M21.022S"/> </ProcessingTime> </TimeParameters> <ControlParameters> <TriggerCount> <NumericParameter instance="1830e9a0d0e8" result="count" value="10"/> <NumericParameter instance="36a319990825" result="count" value="10"/> </TriggerCount> </ControlParameters> </ElementParameters> </Scenario>

4.5.2

Loan request

The second selected process is a representative of a typical business process that handles loan requests. The process manages to employ parallel gateway, exclusive gateway and boundary event: 1. Record new loan application 2. Following tasks can be performed in parallel: Verify employment Request and receive credit report Perform title search and review title report

59

4. Engine extension 3. Review loan application 4. If the application is rejected (a) Send rejection letter (b) Close-out rejection 5. If the application is approved (a) Underwrite loan with terms (b) Close-out approval This process comes from the BPSim implementers guide and the diagram is shown in the gure 4.7 and it should validate the control perspective of the simulation engine. 4.5.2.1 BPSim denition

The initial part of our settings involves the global scenario parameters (see 4.11). We created a scenario with the name Scenario 1 and id default. Default time unit is set to a minute, random generator seed is 100 and we only want one replication of the simulation execution. The duration of the simulation is set to 40 hours, which means that the start events beginning 40 hours after the simulation start will not be taken into account. Listing 4.11 Scenario properties for the loan request process. <Scenario id="default" name="Scenario 1"> <ScenarioParameters baseTimeUnit="min" replication="1" seed="100"> <Duration> <DurationParameter value="PT40H"/> </Duration> </ScenarioParameters> </Scenario> Our next step is to dene the start event properties. We want the process to start every 10 to 30 minutes, the triangular distribution will generate the values in this interval. Regarding the results, we require the trigger count to be included so we know the number of individual process executions. These settings can be found in the listing 4.12. The task properties will be almost the same for all the tasks, so we will include only one example in the listing 4.13. It belongs specically to the Record loan application task and the only thing that it denes is the processing time. We want the task to take 20 minutes on average based on the truncated normal distribution17 . The standard deviation is set to one minute. We dened the result requests for the processing time values as well, particularly the minumum, maximum and average values.
17. The truncated normal distribution is just like any normal distribution, but it also denes the minimum and maximum value.

60

4. Engine extension

Figure 4.7: Loan request process diagram[25].

61

4. Engine extension Listing 4.12 Start event properties. <ElementParameters elementRef="receiveLoanApplication"> <ControlParameters> <InterTriggerTimer> <TriangularDistribution max="30" min="10" mode="16"/> </InterTriggerTimer> <TriggerCount><ResultRequest>count</ResultRequest></TriggerCount> </ControlParameters> </ElementParameters> Listing 4.13 Record loan application task properties. <ElementParameters elementRef="recordLoanApplication"> <TimeParameters> <ProcessingTime> <ResultRequest>min</ResultRequest> <ResultRequest>max</ResultRequest> <ResultRequest>mean</ResultRequest> <TruncatedNormalDistribution max="1000" mean="20" min="0" standardDeviation="1"/> </ProcessingTime> </TimeParameters> </ElementParameters>

A rejection or an approval of the loan request in our simulation is based on the probability of the transitions going from the exclusive gateway. As we can see in the listing 4.14, the transition going to the Send approval letter task has the probability of 27 % and the other (going to the Send rejection letter task) has the probability of 73 %. The trigger count of those tasks should correspond to this percentage. The last interesting part of the denition involves the boundary event bound to the Underwrite Loan with Terms task. It is a timer event that is triggered when the task takes too long. In that case, the default loan terms apply. The listing 4.15 contains the InterTriggerTimer set to 60 minutes. After this time, the processing of the task is stopped and the process ow goes to the Set with Default Terms task. 4.5.2.2 Result

From the three simulation tools presented, only Bizagi Process Modeler was able to simulate the process to a similar extent as our simulation engine. Bonita BPM Studio could not handle the boundary event condition and jBPM Web Designer even failed to start the simulation. The table 4.3 contains the results from both successful simulation engines. The differences are not substantial, except for one case the maximum processing time of

62

4. Engine extension Listing 4.14 Exclusive gateway transitions properties. <ElementParameters elementRef="exclusiveSplitToSendApprovalLetter"> <ControlParameters> <Probability><FloatingParameter value="0.27"/></Probability> </ControlParameters> </ElementParameters> <ElementParameters elementRef="exclusiveSplitToSendRejectionLetter"> <ControlParameters> <Probability><FloatingParameter value="0.73"/></Probability> </ControlParameters> </ElementParameters> Listing 4.15 Boundary event on the Underwrite Loan with Terms task. <ElementParameters elementRef="oneHourTimeLimit"> <ControlParameters> <InterTriggerTimer> <DurationParameter value="PT60M"/> </InterTriggerTimer> <TriggerCount><ResultRequest>count</ResultRequest></TriggerCount> </ControlParameters> </ElementParameters> Underwrite loan with terms. Our engine processed the duration regardless the boundary timer. It does not make much sense, since the boundary event interrupts the task execution and we cannot say, how much time it would really take, but on the other hand, it gives us the insight into how it would behave without the boundary event. We know that the task would be interrupted after 60 minutes, therefore we are not deprived of any useful information, on the contrary, we got additional data. 4.5.2.3 Conclusion

The tested process was a typical representative of a moderately complex business process. Our engine succeeded in its simulation side by side with Bizagi Process Modeler. The other two engines did not compete as the Bonita BPM Studio could not incorporate the boundary event into simulation and jBPM was not able to determine the process paths due to the Receive credit report event, and even after the event was discarded, the simulation engine failed with the Simulation did not return any results message. Other than that, the runtime did not provide any additional error message and all the attempts to recongure the simulation were unsuccessful.

63

Element Receive loan application Loan request rejected Loan request approved One hour time limit Record loan application Verify employment Review title report Review loan application Close-out rejection Close-out approval Underwrite loan with terms

Bizagi Process Modeler Processing time (min) Trigger count MIN MAX MEAN 125 90 35 6 17:43 17:28 14:48 22:21 4:02 9:29 27:00 22:25 41:56 24:34 41:04 5:32 10:28 60:00 20:04 29:55 20:03 30:09 4:58 9:58 49:34

Our simulation engine Processing time (min) Trigger count MIN MAX MEAN 129 88 41 6 17:12 17:47 14:52 19:31 4:20 9:19 29:45 22:54 40:45 28:12 40:17 5:43 10:28 73:17 20:01 29:46 20:10 30:01 5:01 9:55 49:35 4. Engine extension

Table 4.3: Result summary from both the Bizagi Process Modeler and our simulation engine.

64

Chapter 5

Conclusion
The goal of this thesis was to propose a new extension to the iQ Workow Engine in the form of an innovative simulation engine. Based on the ndings from the chapter 3, we were able to compile a list of requirements for such system and to grasp the concepts behind a simulation engine. With the introduction of the BPSim specication early in the 2013, the simulation properties denition became more or less standardized and brought a variety of useful settings that were not present in the tested tools. As a result of our eort, we produced a solution analyzed in the chapter 4. In the last part of the chapter, we showed some interesting examples of business processes and simulated them with our engine. Even though it succeeded in this task and proved its dominance in some cases, we cannot forget the limitations it has. For example, Bonita BPM Studio provides better options in task priority and continuity settings and has a more powerful resource availability denition. However, the engine provides a solid basis and can be improved in the future. This is allowed by the architecture that consists of loosely coupled components backed by the dependency injection framework Spring. The REST service oers an entry point for separate services or for a graphical user interface front end. To summarize the future of the engine, the work to support these features is advised: Security of the REST interface Graphical user interface for simulation properties denition Simulation results reporting and visualization Multiple resources per task Task priority and interruptibility Message ows and intermediate events with no incoming transition

Even though business process management has been around for a couple of years, there are still many companies that either do not consider BPM to be a viable option for their business or are only beginning to acquire this approach. With simulation and optimization tools they are able to predict the behavior of processes to some extent and reduce risks of change. The standards like BPSim facilitate the acceptance of the concept and our engine is one of the rst to adopt the standard.

65

Bibliography
[1] M. Hammer and J. Champy. Reengineering the Corporation: A Manifesto for Business Revolution. HarperCollins Publishers, 1993. [2] Henry J. Johansson et al. Business Process Rengineering: BreakPoint Strategies for Market Dominance. John Wiley & Sons, 1993. [3] Thomas H. Davenport. Process innovation: reengineering work through information technology. Harvard Business School Press, Boston, MA, USA, 1993. [4] Jaroslav Rek. Study materials for the course PV165. https://is.muni.cz/ auth/el/1433/jaro2013/PV165/um/, 2013. [Online; 2013-06-28]. [5] J. B. et al. Hill. Findings: Confusion remains regarding BPM terminologies, 2008. [6] M. Salatino. jBPM 5 Developer Guide. Packt Publishing, Limited, 2012. [7] Wil M. P. Van Der Aalst, Arthur H. M. Ter Hofstede, and Mathias Weske. Business process management: a survey. In Proceedings of the 2003 international conference on Business process management, BPM03, pages 112, Berlin, Heidelberg, 2003. Springer-Verlag. [8] PNMsoft Ltd. Business Process Management Life Cycle. http://www.pnmsoft. com/resources/bpm-tutorial/bpm-lifecycle/, 2013. [Online; 2013-11-09]. [9] Tijs Rademakers. Activiti in Action: Executable business processes in BPMN 2.0. Manning Publications Co., Greenwich, CT, USA, 2012. [10] Ryan K. L. Ko. A computer scientists introductory guide to business process management (BPM). Crossroads, 15(4):4:114:18, jun 2009. [11] Object Management Group. Business Process Model and Notation (BPMN). http: //www.omg.org/spec/BPMN/2.0/PDF, January 2011. [Online; 2013-06-28]. [12] Robert Shapiro. Update on BPMN Release 2.0. http://www.wfmc.org/ Download-document/BPMN-2.0-Industry-Update-Presentation.html, February 2010. [Online; 2013-06-28]. [13] Kerim Tumay. Business process simulation. In Proceedings of the 28th conference on Winter simulation, WSC 96, pages 9398, Washington, DC, USA, 1996. IEEE Computer Society.

66

5. Conclusion [14] Tihomir Surdilovic. jBPM web designer: Can I create collaboration diagram? https://community.jboss.org/message/778713#778713, 2012. [Online; 2013-0923]. [15] Red Hat. jBPM Roadmap. http://www.jboss.org/jbpm/roadmap, 2012. [Online; 2013-09-23]. [16] BPSim.org. BPSim.org. http://www.bpsim.org/, 2013. [Online; 2013-09-23]. [17] Tijs Rademakers. Activiti Modeler. http://activiti.org/slides/Activiti_ Modeler.pdf, 2012. [Online; 2013-11-09]. [18] WfMC. BPSim Specication. http://www.bpsim.org/specifications/1.0/ WFMC-BPSWG-2012-01.pdf, 2013. [Online; 2013-11-09]. [19] Internet Engineering Task Force. Internet Calendaring and Scheduling Core Object Specication (iCalendar). http://tools.ietf.org/html/rfc5545, 2009. [Online; 2013-11-09]. [20] Alex Rodriguez. RESTful Web services: The basics. https://www.ibm.com/ developerworks/webservices/library/ws-restful/, 2008. [Online; 2013-11-09]. [21] C. Walls. Spring in Action. Manning Pubs Co Series. Manning Publications Company, 2011. [22] The Apache Software Foundation. Maven What is Maven? http://maven. apache.org/what-is-maven.html, 2013. [Online; 2013-11-23]. [23] The Apache Software Foundation. Apache Commons Apache Commons. http: //commons.apache.org/index.html, 2013. [Online; 2013-11-23]. [24] http://www.json.org/. Introducing JSON. http://www.json.org/, 2013. [Online; 2013-11-23]. [25] WfMC. BPSim Implementers Guide v1.0. http://www.bpsim.org/ implementers/1.0/BPSim%20Implementers%20Guide%20v1.0.zip, 2013. [Online; 2013-11-09].

67

Appendix A

CD content
Attached CD contains the following directory structure: doc/ img/ . . . . . . . . . . . . . . . . . . . . . . . . . . directory with the images used in thesis bib-db.bib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . bibliography source
A thesis_svancara.tex . . . . . . . . . . . . . . . . . . . . . . . . . thesis in the L TEXformat thesis_svancara.pdf . . . . . . . . . . . . . . . . . . . . . . . . . thesis in the PDF format

processes/ lr.bpmn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loan request denition lrResult.bpmn . . . . . . . . . . . . . . . . . . . . . . . . . Loan request simulation result mid.bpmn . . . . . . . . . . . . . . . . . . . . . . . . . . Manual invoice delivery denition midResult.bpmn . . . . . . . . . . . . Manual invoice delivery simulation result

simulator/ simulator-api/ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Simulator API source code simulator-impl/ . . . . . . . . . . . . . . . . Simulator implementation source code simulator-rest/ . . . . . . . . . . . . . . . . . . . . . . Simulator REST API source code install.txt . . . . . . . . . . . . . . . . . . . . . . . . . . .Simulator installation instructions pom.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maven build le

68