paper: nondeterministic events in business processes

Nondeterministic Events in Business Processes

Albert Fleischmann1, Werner Schmidt

2, Christian Stary

3, Florian Strecker

1

1 Metasonic AG, Münchner Str. 29, 85276 Hettenshausen, Germany

Albert.Fleischmann | [email protected]

2 Ingolstadt University of Applied Sciences, Esplanade 10, 85049 Ingolstadt, Germany

[email protected]

3 Johannes Kepler University Linz, Freistädterstraße 315, 4040 Linz, Austria

[email protected]

Abstract. In this article we describe how Complex Event Processing (CEP) can

be smoothly integrated into Subject-oriented Business Process Management (S-

BPM). This approach is grounded on communication patterns between acting

systems (i.e. subjects), such as people and software systems. The integration is

done twofold. Firstly, complex event processing units can be seen as one way to

instantiate a process. Secondly, CEP units can be integrated into subjects as

internal functions. Based on evaluating various data patterns the subject

containing the CEP function can inform other subjects by sending

corresponding messages. In this way, nondeterministic (since not predictable)

events can be dealt with at runtime. An informed subject may actively influence

further system behavior by delegating further observation tasks to the subject

containing the complex event processing unit. Based on the introduced concepts

and their straightforward implementation actual business operations can not

only be represented, but also processed more accurately.

Keywords: events, message guard, implementation, CEP, S-BPM

1 Introduction

In this paper we describe how the specification of business processes and event

processing can be combined in order to handle deterministic and non deterministic

business situations. Additionally we will show how such specifications with non

deterministic events can be implemented in a straight forward way.

Business processes are the behavioral parts of organizations. Business process

specifications describe which event causes the instantiation of a business process,

which parties in a process execute which activities, using which tools and which

communication acts they perform in order to synchronize work in a world with a high

degree of division of work. Business processes can be instantiated for various reasons

and must be able to handle deterministic and nondeterministic events during its

execution. Deterministic events are those which occurrence in time can be specified

accurately, i.e. it is known that they will occur and when they will occur. In case of

nondeterministic events it is not known whether they occur at all and in case of

occurrence when they actually occur.

In this paper events are considered to be messages sent from a sender to a receiver.

Messages may transport some data from the sender to the receiver. In Business

Process Management (BPM) we distinguish between events which cause the creation

of a process instance and events which are created during the execution of a process

instance.

mailto:[email protected]

2 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.

Events which cause process instances

Depending on the source of an event which causes a new process instance we

distinguish we four types:

Human actor interference

A human initiates the execution of a process. For example somebody calls a

service center because he/she has problems with a certain device. The service

center creates a process instance of a process which handles such incident

calls.

Time

An instance of a process must be created regularly in order to produce certain

results which are required by various people. Every day in the evening a

process is executed which collects data from several service organizations,

creates a report and distributes that report to several employees interested in

that report.

Other business processes

An instance of a business processes triggers the instantiation of another

business process. A sales process causes the instantiation of a corresponding

production process if a customer accepts an order.

Data state

If certain conditions become valid in some data storage a process instance is

instantiated. An observer realizes that a defined condition becomes true and

creates an instance of a process which handles that situation. Data changes

can be caused by human interactions or software programs like complex event

filters. A complex event processing unit discovers a certain constellation in the

external event stream which has to be handled by a business process. The filter

triggers the instantiation of the corresponding business process (see [4]).

Events which are created during process instance execution

Process instances created for certain reasons are executed according to the process

specification. During process execution several deterministic and nondeterministic

communications (events) can occur. For deterministic communication it is defined

when and by whom they are sent and how the receiver reacts. Non deterministic

events are messages randomly sent from parties in a process. We call these types of

messages process instance execution events or, for short, internal process events. An

example of such an internal event can be a cancelation message. A customer informs

the service center that he could solve the problem by his own and the incident ticket

can be closed.

During the execution for those events it is unclear whether they occur at all, and if

so, when they occur. Reactions differ depending on the state the process instance is in

by the time the event occurs.

Process models are templates for creating and executing process instances. Thus a

model not only needs to describe the sequence of activities being executed and the

messages being sent and received with regard to deterministic events. The challenge

is to also include internal events into the model and have them handled at runtime.

In this article we show how internal events can be easily integrated in subject-

oriented business process models. After this introduction we shed some light on

related work regarding event handling in business process management. After that we

briefly introduce Subject-oriented Business Process Management (S-BPM) and

discuss the integration of Complex Event Processing (CEP) into S-BPM. Complex

events are built out of lots of simple events which as a group serve as an element in a

specific situation for a particular purpose [17]. We will show how complex event

Nondeterministic Events in Business Processes 3

processing units can be integrated into subject-oriented process specifications. Our

goal is to integrate complex event processing at process instance execution rather than

on the process instance creation level. This approach better matches actual business

operation which is characterized by nondeterministic events, e.g. the change of an

order or purchases stocks if certain prices are reached. Chapter 4 presents the concept

and a prototype implementation of the message guard concept in S-BPM, suitable to

handle process instance execution events. We end with the conclusion in chapter 5.

2 Challenges to Capture Nondeterministic Events in BPM

Being able to flexibly react on unforeseen events when executing business processes

is both a constraint and a valuable asset for an agile organization. We look at the way

how state-of-the-art approaches to business process modeling and execution cope

with the representation and execution of event-driven actions.

2.1 Event-driven Process Chains (EPC)

The flow-oriented EPCs are the major model type of the control view in the ARIS

methodology of business process modeling. Per definition, events drive the control

flow, but the possibility to model events is limited to deterministic ones. The method

does not offer concepts to handle asynchronous, nondeterministic events as mentioned

in section 1. As a consequence those events are not considered when EPCs are

transferred to executable code during IT implementation.

2.2 Business Process Model and Notation (BPMN)

BPMN 2.0 includes ‘catching events’ (trigger has fired) and ‘throwing events’ (event

fires) as flow elements in the description of a process. Those events can be of various

type (e.g. message event, timer event, signal event, terminate event, cancel event),

each represented by a dedicated symbol [13, 14, 19].

Nondeterministic events can be modeled as so-called exceptions. They can be used

to interrupt a running sub process. The overall process is then continued on the higher

level of the calling process. It is not clearly defined who can be the source of such an

exception and it is difficult to describe the way back to the interrupted process after

the exception was handled.

If, for example, a customer changes an order the change request message (e.g.

increasing the number of products ordered) can arrive in any execution state on the

seller side of the order process. This means the seller must be able to react to it at

many different points in a suitable way. If the message arrives before picking and

packing the goods the reaction can just be changing the number and continuing the

process instance in the state where the change request had arrived. In case delivery

has already been started the reaction might be to create a new instance with the

missing number of goods causing a second delivery. BPMN 2.0 falls short in clear

semantics to precisely express such situations as well as the message exchange [18]. It

is limited in its expressiveness for conditional event-driven reaction logic [20] and

does not offer possibilities to integrate facilities which are able to handle process

external event patterns (see p. 376 in [4]). In order to generally tackle BPMN 2.0

shortcomings, some additional definitions beyond the standard are necessary, like

proposed by Silver [19].


2.3 Event-driven Business Process Management (ED-BPM)

Event-Driven Business Process Management (ED-BPM) combines two different

disciplines: Business Process Management (BPM) and Complex Event Processing

(CEP) [4, 5, 17]. Basic idea is that single events occurring in an event cloud are

processed (mainly filtered) by an event processing platform and thus aggregated into

a complex event [14, 15], which can be modeled in a process execution language of a

BPMS triggering changes in the runtime behavior of a process. This view brings

together the abstract description of processes at design time with unforeseen events

(i.e. nondeterministic) affecting the execution of process instances during runtime.

Von Ammon et al. suggest a general framework for ED-BPM and discuss how

business process execution can be enhanced on the basis of ED-BPM, e.g. by

enhancing WS-BPEL, which in its “standard form cannot execute event-driven

processes” [4].

Paschke also mentions the limits of pure syntactic BPM languages like BPEL and

BPMN in the context of ‘complex decision logic and conditional event-driven

reaction logic’ [20]. For orchestration of business processes he proposes a declarative

middleware based on rules and events and combining CEP technologies with those

for declarative rule-based programming [22].

The CEVICHE framework presented by Hermosillo et al. [23] combines an XML-

based Standard Business Process Language (SBPL) with an aspect-oriented extension

to BPEL (AO4BPEL). The first allows to translate process information to different

CEP engines, the ladder makes it possible to adapt the process behavior at runtime

without redeploying the whole model before.

3 Subject-oriented Business Process Management

3.1 Fundamentals

The S-BPM approach roots in the observation that humans usually use standard

semantics of natural language with subject, predicate, and object when they describe

what they are doing in a business process. Consequently the S-BPM modeling

language allows for representing these building blocks of a complete sentence in

natural language, where the subject is the starting point for describing a situation or a

sequence of events, the activities are denoted by predicates and an object is the target

of an activity. Resulting models describe structural properties and behavioral

alternatives, including the message-based interaction occurring in the technical and/or

organizational environment. Thus S-BPM enriches flow concepts of function-driven

BPM approaches by active entities sending and receiving messages [1, 6, 8]. These

active entities are called subjects. In order to keep a process specification independent

from a special organizational and technical environment subjects are a more abstract

view on active entities than actors or agents. A subject abstractly models an

agent which executes some specified behavior; for example a subject can stand for a

person acting in a given situation (process) or for a thread in an IT system (software

agent). A concrete agent (when acting) instantiates (the behavior of) a subject. Thus

one agent may be able to execute the behavior of different subjects and vice versa

different agents may execute the same behavior, as defined by one subject. These

different executions are independent of each other. Assigning an actor or agent to a

subject is part of the implementation of a subject.

The graphical notation of the S-BPM modeling language with only a few symbols

is based on process algebra with a clear formal semantic allowing automated code

generation. This makes subject-oriented process descriptions executable and supports

seamless round-trip engineering [1, 8].


Using the Abstract State Machine (ASM) method Egon Börger [16] developed a

precise formulation for the semantics of the S-BPM constructs in form of a high-level

subject-oriented interpreter model and gave proof both of ground model and

refinement correctness of the interpreter (for details see [2] and pp. 346-395 in [1]).

3.2 Modeling

In order to demonstrate the mapping of a language-based representation to a subject-

oriented model we use the application for a business trip as a simple example. Figure

1 shows the natural language description of this process.

An employee applies for a business trip. His manager checks the request and

informs the employee whether he approves or rejects the request. The approved

request is forwarded to the travel office which does all the travel arrangements.

Fig. 1. Natural language description of the business trip application process

The subject-oriented description of the process starts with the identification of

process-specific roles involved in the process, the subjects, and the messages

exchanged between them. When sending messages, the required data is transmitted

from the sender to the receiver via simple parameters or more complex business

objects if necessary. Thus, with the message ‘business trip request’ sent by the

employee to the supervisor, among other things, the start and end date are transmitted.

Figure 2 depicts the interaction structure of the process, the so-called Subject

Interaction Diagram.

Fig. 2 The business trip application process with the involved subjects and their interactions

In a further refinement step, the modeler describes which activities and interactions

the subjects have to perform in which order during the execution of the process, i.e.,

he defines the behavior of individual subjects.

The so-called Subject Behavior Diagram in figure 3 shows the order in which the

employee sends and receives messages, or executes internal actions, and the states he

is in during his business trip application.


Fig. 3 Graphical representation of employee behavior when applying for a business trip

The initial state is marked by a triangle in the upper left corner. It is a function state

in which the employees complete their business trip request. The state transition

'filled out Bt-request' leads to a send state in which they send the application to the

manager, before entering the receive state, in which an answer is received from the

manager. Here, the applicants wait for the response of the manager. In case they

receive a rejection message from the manager, the process comes to an end. In case

the employees receive the approval message from the manager, they go on the trip on

the agreed date and the business trip application process is completed.

The behavior of the manager is complementary to that of the employee (see figure

4). Messages sent by the employee are received by the manager, and vice versa. The

manager therefore first waits in a receiving state for a business trip request from the

employee. After receiving the application, he goes to a state of checking which leads

either to the approval or rejection of the request. In the second case, a send state

follows to send the refusal to the employee. In the first case, the manager first moves

to a send state for transmitting the approval to the applicant, and then proceeds to a

state of informing the travel office about the approved business trip request.

Fig. 4. Graphical representation of the manager’s behavior when handling a business trip request

The behavior of the travel office can be described analogous. This short example

illustrates the essential elements of a subject-oriented model as there are:

The subjects involved in the process,

The interactions taking place between them,


The messages they send or receive during each interaction, and

The behavior of the individual subjects

3.3 Integrating Complex Event Processing (CEP) in S-BPM

In the CEP context an event processing agent (EPA) denotes a unit processing

complex events [15, 17]. As in S-BPM we distinguish between abstract subjects and

actors/agents (see section 3.1) we need a term for a more abstract view on complex

event processing in the subject-oriented context. We introduce the event processing

functionality (EPF), which becomes an event processing agent as defined in [15] and

[17] once the functions are assigned to an entity (software, people etc.) able to

perform them. This means we want to consider event processing functionality

independent from the executing ‘technology’.

Complex Event Processing can be easily integrated in S-BPM in a twofold manner:

Complex event functionality triggers process instances. It observes the incoming

events in the event cloud. When it discovers a defined constellation a corresponding

business process instance is created to handle that constellation.

Complex event processing is part of processes. Event processing functionality can

be considered as functions in the behavior of a subject and if the subject is assigned to

an agent we have an EPA. As soon as a process is instantiated this agent is also

instantiated and can start working. When a predefined event pattern is discovered the

internal function of the related exit transition is executed. Due to the fact that the

modeler can define several exits for each internal function, this function can search

for different patterns. The following figure shows a subject with event processing

functionality.

Fig. 5. A subject with event processing functionality

The subject receives a message ‘start_watching_stocks’. After accepting that

message the subject is in state ‘watch_stock_exchange’. If ‘Stock price low’ is

discovered the corresponding transition is executed and in the following send state the

message ‘buy_stocks’ is sent to the subject ‘trader’. If the result ‘stock price high’ is

discovered the corresponding message is sent. With these messages the corresponding

buy or sell processes are started. After that the subject can do some other work

depending on the behavior specification.

As the function discovers events it passes the information on to other subjects in

the process which handle the activities to be accomplished because of an event. This

type of events (i.e. messages) is nondeterministic. It is unclear whether the message is

sent and when it will be sent. Other subjects can also send messages to the event


processor subject containing information which constellations should be observed (in

our example in the message ‘start event processing’) in order to make the complex

event function change its observation conditions. This means subjects must be able to

handle nondeterministic messages.

In the following chapter we present the Message Guard concept which details the

aforementioned possibilities S-BPM provides to handle asynchronous, nondeter-

ministic events.

4 Message Guard Concept in S-BPM

4.1 Specification

We use the term Message Guard as a synonym for handling an exception. It is a

behavioral description for a subject that is relevant when a specific, exceptional

situation occurs along executing a subject behavior specification. It is activated when

a corresponding message is received, and the subject is in a state being able to

respond to exception handling (see p. 147 ff. in [1]). In such a case, the transition to

exception handling has the highest priority and will be enforced.

Exception handling can occur in a process in many behavior states of subjects. The

receipt of certain messages, e.g., to abort the process, always results in the same

processing pattern. This pattern should also be modeled for each state in which it is

relevant. Exception handlings cause high modeling effort and lead to complex process

models, since from each affected state a corresponding transition has to be specified.

In order to prevent this situation, we introduce a concept similar to exception handling

in programming languages or interrupt handling in operating systems.

To illustrate the compact description of exception handlings, we enhance our

business trip example by introducing an additional subject ‘Service desk’. This

subject identifies a need for a business trip in the context of solving a customer

problem - an employee needs to visit the customer to provide a service locally.

According to the subject interaction diagram in figure 6 the subject ‘Service desk’

passes on a service order to an employee. Hence, the employee issues a business trip

request. The service order may be canceled up to its completion in principle at each

stage of processing. The cancelation message is passed on to all affected subjects to

bring the process towards a defined end.

Fig. 6. Subject interaction diagram of the business trip application process including

cancelation messages

As for the behavior we first describe what the model would look like without

applying the message guard concept of exception handling. A cancelation message

can be received by the employee either while filling in the application, or while

waiting for the approval or rejection message from the manager. With respect to the

behavior of the subject ‘employee’, the state ‘response received from manager’ needs

to be enriched with the possible input message containing the cancelation and the

associated consequences, too. The verification whether filling in the request is

followed by a cancelation is modeled through a receive state with a timeout. In case

the timeout is zero, there is no cancelation message in the input pool and the business

trip request is sent to the manager (for details of the input pool and timeout concept


(see p. 96 ff. in [1]). In the other case, the manager is informed of the cancelation and

the process terminates for the subject ‘employee’. A corresponding adjustment of the

behavior needs to be made for each subject, which can receive a cancelation message,

including the manager and the travel office.

This relatively simple example already shows that paying attention to such

exception messages can quickly make behavior descriptions extensive and confusing

to understand. The concept of exception handling, therefore, should enable supple-

menting exceptions to the default behavior of subjects in a structured and compact

form. Figure 7 shows how such a concept affects the behavior of the employee.

Fig. 7. Behavior of subject ‘employee’ with exception handling

Instead of modeling receive states with a time-out zero and corresponding state

transitions, the behavioral description is enriched with the exception handling ‘service

cancelation’. Its initial state is labeled with the states from which is branched to, once

the message ‘service cancelation’ is received. In the example, these are the states

‘business trip application complete’ and ‘receive answer from manager’. Each of

them is marked by a triangle on the right edge of the state symbol. The exception

behavior leads to an exit of the subject, after the message ‘service cancelation’ has

been sent to the subject ‘manager’.

Basically, a subject behavior does not need to stop here; it may be continued from

there as specified in some default behavior. Exception handling behavior in a subject

may vary, depending from which state or by what type of message (cancelation,

temporary stopping of the process, etc.) it is called. The initial state of exception

handling can be a receive state or a function state.

Messages that, like ‘service cancelation’, lead to exception handling always have

higher priority than other messages. Thus, modelers express that specific messages

are read in a preferred way. For instance, when the approval message from the

manager and shortly thereafter the cancelation message are received in the input pool

of the employee, the latter is read first. It causes corresponding abort consequences.

4.2 Implementation

Sections 3.2 and 4.1 demonstrated the concepts S-BPM offers to model nondeter-

ministic events in a transparent and efficient way. To have functions based on these


concepts available in a Business Process Management System (BPMS), extensions

are necessary in the design part and in the execution part of a tool suite supporting the

S-BPM approach.

Strecker presents a prototype solution enhancing the Metasonic Suite as a BPMS

by functionality allowing to model exception handling according to the message

guard concept and to perform the modeled behavior at runtime [3].

4.2.1 Extension for Modeling and Execution

Although Metasonic’s modeling environment ‘Metasonic Build’ is Eclipse-based and

can therefore easily being adapted or extended, Strecker did not alter the core of the

BPMS, but used out-of-the-box possibilities like modeling conventions (e.g. different,

multi-colored symbols) and existing custom modeling parameters [10] for his quick

and easy prototype implementation.

Figure 8 depicts how a message guard behavior is modeled with the mentioned

means:

The message guard behavior is placed to the right of the standard behavior.

The complete message guard behavior is shimmed with a light-blue box and

marked as “message guard behavior” with a text box.

The start of the message guard behavior is a receive state; therefore, it is possible

to distinguish different messages there.

The start of the message guard behavior is marked with a blue triangle on its top.

In the standard behavior, all states which can be left to access the message guard

behavior, are marked with a dark-blue triangle on their upper right corner.

Fig. 8. A subject behavior employing a message guard behavior

The process engine ‘Flow’ as a part of the Metasonic Suite allows creating custom

extensions to enhance the runtime environment via so-called engine add-ons [10].

These extensions can react to certain, well-defined events, and are implemented using

the so-called observer pattern [11].

As we defined events as incoming messages an InputpoolObserver is needed to

react to message entries in the subject’s input pool. The StateChangeObserver is

applied for handling the message guard behavior. It checks the process model for


custom modeling parameters described in the previous section and reacts on the

parameter values as events. A certain parameter constellation for example can make

the observer switch a subject state and thus altering the subject behavior at runtime.

The implementation including some examples can be downloaded at [12].

5 Conclusion and Future Work

Business Process Management (BPM) recognizing complex events requires

corresponding representation and execution schemes, as those events reflect in situ

business settings and organizational behavior patterns. In particular, events that are

uncertain with respect to their occurrence and their time of occurrence, so called

nondeterministic events, require proper management at runtime. Approaches to

embed Complex Event Processing (CEP) into BPM neither support specification of

handling nondeterministic events, e.g., BPMN, nor reflect dynamic handling of those

events, e.g., EPC.

In this contribution we have introduced how CEP can be integrated into Subject-

oriented Business Process Management (S-BPM). In contrast to existing functional

approaches it is grounded on communication patterns between acting systems (i.e.

subjects). We started integration by considering CEP units as one way to instantiate a

process, i.e. creating a process instance. CEP units can then be integrated into subjects

as internal functions. At run time (process instance execution), based on evaluating

various data patterns the subject containing the CEP function can inform other

subjects by sending corresponding messages. This represents the basic concept for the

handling of nondeterministic events.

The informed subjects may then delegate further observation tasks to the subject

containing the CEP unit. In this way they dynamically influence the system behavior.

The prototype implementation provides the proof of concept. We have used the

message guard concept for straightforward implementation.

Future work should include detailing and evaluating the concept as well as the

prototype implementation, e.g. in terms of relating it to the standard event processing

architecture introduced by [17] or in terms of interaction with existing CEP solutions.

Questions still to be answered also refer to performance, limitations and a comparison

with existing approaches like mentioned in section 2.3.

References

1. Fleischmann, A., Schmidt, W., Stary, C., Obermeier, S., Börger, E.: Subjektorien-

tiertes Prozessmanagement, Hanser, München (2011), to appear in English at

Springer, Berlin Heidelberg in October 2012

2. Börger, E., The Subject-Oriented Approach to Software Design and the Abstract

State Machines Method, in: Düsterhöft, A., Klettke, M., Schewe, K.-D. (eds.),

Conceptual Modeling and its Theoretical Foundations, LNCS 7260, pp. 52-72,

Springer, Berlin Heidelberg (2012)

3. Strecker F.: New Modeling Concepts in S-BPM: The First Implementation of the

‘Message Guard’ and ‘Macro’ Behaviour Extensions in: Oppl, S. and

Fleischmann, A. (eds.), S-BPM ONE 2012, CCIS 284, pp. 121-134, Springer,

Berlin Heidelberg (2012)

4. von Ammon, R. Ertlmaier, T., Etzion, O., Kofman, A., Paulus, T.: Integrating

Complex Events for Collaborating and Dynamically Changing Business

Processes in: Dan, A., Gittler, F. and Toumani, F. (Eds.): ICSOC/ServiceWave

2009, LNCS 6275, pp. 370–384, Springer, Berlin Heidelberg (2010)


5. von Ammon, R., Etzion, O., Paschke, A., Stojanovic, N., Event-Driven Business

Process Management, in: ED-BPM Workshop, ServiceWave 2008, Madrid,

http://www.nessi-europe.com/Nessi/adminP/ArchivedPages/ServiceWave

2008Workshop BPM/tabid/468/Default.aspx, last access 2011-04-16 (2008)

6. Fleischmann, A., Stary, C.: Whom to talk to? A stakeholder perspective on

business process development, Universal Access in the Information Society, DOI

10.1007/s10209-011-0236-x (2011)

7. Weber, J., Schmidt, W., Weber, P., Using Social Network Analysis and

Derivatives to Develop the S-BPM Approach and Community of Practice, in:

Stary, C. (Ed.), S-BPM ONE 2012, LNBIP 104, pp. 205-217, Springer, Berlin

Heidelberg (2012)

8. Fleischmann, A., Schmidt, W., Stary, C., A Primer to Subject-oriented Business

Process Modeling, in: Stary, C. (Ed.), S-BPM ONE 2012, LNBIP 104, pp. 218-

239, Springer-Verlag, Berlin Heidelberg (2012)

9. Stary, C., Fleischmann, A.: Key Features of Subject-Oriented Modeling and

Organizational Deployment Tools, in: Stephanidis, C. (Ed.), HCII 2011, LNCS

6768, pp. 205–214, Springer, Berlin Heidelberg (2011)

10. Metasonic AG: Metasonic Suite Developer Documentation 4.4. http://www.

metasonic.de, Pfaffenhofen (2011)

11. Metasonic AG: ExecutionOrderWithinRefinementsAndObservers (com.jcom1.

documentation.refinements.ExecutionOrderWithinRefinementsAndObservers).

In: Metasonic AG: Metasonic Suite Developer Documentation 4.4. http://www.

metasonic.de, Pfaffenhofen (2011)

12. Strecker, Florian: http://www.floooooo.de/s-bpm/#sbpmone2012.

13. OMG, Business Process Management Initiative, BPMN, http://www.omg.org/

spec/BPMN/2.0/PDF/, last access 2012-05-26.

14. Freund, J., Rücker, B.: Praxishandbuch BPMN 2.0, Hanser, München (2010)

15. Luckham, D., Schulte, R. (Hrsg.), Event Processing Glossary Version 2.0/2011,

Event Processing Technical Society, http://www.complexevents.com/2011/08/23/

event-processing-glossary-version-2-0/, last access 2012-05-30

16. Börger E., Stärk R., Abstract State Machines: A Method for High-Level System

Design and Analysis, Springer Berlin Heidelberg (2003)

17. Etzion O., Niblett P., Event Processing in Action, Manning Publications,

Stamford (2011)

18. Börger E., Approaches to Modeling Business Processes. A Critical Analysis of

BPMN, Workflow Patterns and YAWL, Software & Systems Modeling 11

(2012) 3, pp. 305-318.

19. Silver B., BPMN Method and Style, 2nd Edition, with BPMN Implementer's

Guide: A Structured Approach for Business Process Modeling and

Implementation Using BPMN 2, Cody-Cassidy Press (2011)

20. Paschke, A., A Semantic Rule and Event Driven Approach for Agile Decision-

Centric Business Process Management, in: Abramowicz, W., et al. (Eds.),

ServiceWave 2011, LNCS 6994, pp. 254-267, Springer, Berlin Heidelberg (2011)

21. Janiesch, C., Matzner, M., Müller, O., A Blueprint for Event-driven Business

Activity Management, in: Rinderle, S., Toumani, F., and Wolf, K. (Eds.), 9th

International Conference on Business Process Management (BPM). LNCS 6896,

pp. 17-28, Springer, Berlin Heidelberg (2011)

22. Paschke, A., Kozlenkov, A., A Rule-based Middleware for Business Process

Execution, in: Bichler, M., Hess, T. et al. (Eds.), Proceedings of Multikonferenz

Wirtschaftsinformatik (MKWI) 2008, pp. 1409-1420, GITO, Berlin (2008)

23. Hermosillo, G., Seinturier, L., Duchien, L., Using Complex Event Processing for

Dynamic Business Process Adaptation, in: Proceedings of the 7th IEEE Inter-

national Conference on Service Computing (SCC), pp. 466-473, Miami (2010)

http://www.amazon.de/Abstract-State-Machines-High-Level-Analysis/dp/3540007024/ref=sr_1_4?ie=UTF8&qid=1342608512&sr=8-4

http://www.amazon.de/Abstract-State-Machines-High-Level-Analysis/dp/3540007024/ref=sr_1_4?ie=UTF8&qid=1342608512&sr=8-4

http://www.amazon.de/Method-Style-Edition-Implementers-Guide/dp/0982368119/ref=sr_1_1?ie=UTF8&qid=1342617723&sr=8-1



paper: nondeterministic events in business processes

Technology