Paper: Nondeterministic Events in Business Processes


Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Paper: Nondeterministic Events in Business Processes

  1. 1. Nondeterministic Events in Business Processes Albert Fleischmann1, Werner Schmidt2, Christian Stary3, Florian Strecker1 1 Metasonic AG, Münchner Str. 29, 85276 Hettenshausen, Germany Albert.Fleischmann | 2 Ingolstadt University of Applied Sciences, Esplanade 10, 85049 Ingolstadt, Germany 3 Johannes Kepler University Linz, Freistädterstraße 315, 4040 Linz, Austria 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-BPM1 IntroductionIn this paper we describe how the specification of business processes and eventprocessing can be combined in order to handle deterministic and non deterministicbusiness situations. Additionally we will show how such specifications with nondeterministic events can be implemented in a straight forward way.Business processes are the behavioral parts of organizations. Business processspecifications describe which event causes the instantiation of a business process,which parties in a process execute which activities, using which tools and whichcommunication acts they perform in order to synchronize work in a world with a highdegree of division of work. Business processes can be instantiated for various reasonsand must be able to handle deterministic and nondeterministic events during itsexecution. Deterministic events are those which occurrence in time can be specifiedaccurately, i.e. it is known that they will occur and when they will occur. In case ofnondeterministic events it is not known whether they occur at all and in case ofoccurrence 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 BusinessProcess Management (BPM) we distinguish between events which cause the creationof a process instance and events which are created during the execution of a processinstance.
  2. 2. 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 wedistinguish 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 processspecification. During process execution several deterministic and nondeterministiccommunications (events) can occur. For deterministic communication it is definedwhen and by whom they are sent and how the receiver reacts. Non deterministicevents are messages randomly sent from parties in a process. We call these types ofmessages process instance execution events or, for short, internal process events. Anexample of such an internal event can be a cancelation message. A customer informsthe service center that he could solve the problem by his own and the incident ticketcan be closed. During the execution for those events it is unclear whether they occur at all, and ifso, when they occur. Reactions differ depending on the state the process instance is inby the time the event occurs. Process models are templates for creating and executing process instances. Thus amodel not only needs to describe the sequence of activities being executed and themessages being sent and received with regard to deterministic events. The challengeis 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 onrelated work regarding event handling in business process management. After that webriefly introduce Subject-oriented Business Process Management (S-BPM) anddiscuss the integration of Complex Event Processing (CEP) into S-BPM. Complexevents are built out of lots of simple events which as a group serve as an element in aspecific situation for a particular purpose [17]. We will show how complex event
  3. 3. Nondeterministic Events in Business Processes 3processing units can be integrated into subject-oriented process specifications. Ourgoal is to integrate complex event processing at process instance execution rather thanon the process instance creation level. This approach better matches actual businessoperation which is characterized by nondeterministic events, e.g. the change of anorder or purchases stocks if certain prices are reached. Chapter 4 presents the conceptand a prototype implementation of the message guard concept in S-BPM, suitable tohandle process instance execution events. We end with the conclusion in chapter 5.2 Challenges to Capture Nondeterministic Events in BPMBeing able to flexibly react on unforeseen events when executing business processesis both a constraint and a valuable asset for an agile organization. We look at the wayhow state-of-the-art approaches to business process modeling and execution copewith 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 ARISmethodology of business process modeling. Per definition, events drive the controlflow, but the possibility to model events is limited to deterministic ones. The methoddoes not offer concepts to handle asynchronous, nondeterministic events as mentionedin section 1. As a consequence those events are not considered when EPCs aretransferred 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’ (eventfires) as flow elements in the description of a process. Those events can be of varioustype (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 usedto interrupt a running sub process. The overall process is then continued on the higherlevel of the calling process. It is not clearly defined who can be the source of such anexception and it is difficult to describe the way back to the interrupted process afterthe 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 theseller side of the order process. This means the seller must be able to react to it atmany different points in a suitable way. If the message arrives before picking andpacking the goods the reaction can just be changing the number and continuing theprocess instance in the state where the change request had arrived. In case deliveryhas already been started the reaction might be to create a new instance with themissing number of goods causing a second delivery. BPMN 2.0 falls short in clearsemantics to precisely express such situations as well as the message exchange [18]. Itis limited in its expressiveness for conditional event-driven reaction logic [20] anddoes not offer possibilities to integrate facilities which are able to handle processexternal event patterns (see p. 376 in [4]). In order to generally tackle BPMN 2.0shortcomings, some additional definitions beyond the standard are necessary, likeproposed by Silver [19].
  4. 4. 4 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.2.3 Event-driven Business Process Management (ED-BPM) Event-Driven Business Process Management (ED-BPM) combines two differentdisciplines: Business Process Management (BPM) and Complex Event Processing(CEP) [4, 5, 17]. Basic idea is that single events occurring in an event cloud areprocessed (mainly filtered) by an event processing platform and thus aggregated intoa complex event [14, 15], which can be modeled in a process execution language of aBPMS triggering changes in the runtime behavior of a process. This view bringstogether 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 howbusiness process execution can be enhanced on the basis of ED-BPM, e.g. byenhancing WS-BPEL, which in its “standard form cannot execute event-drivenprocesses” [4]. Paschke also mentions the limits of pure syntactic BPM languages like BPEL andBPMN in the context of ‘complex decision logic and conditional event-drivenreaction logic’ [20]. For orchestration of business processes he proposes a declarativemiddleware based on rules and events and combining CEP technologies with thosefor 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 extensionto BPEL (AO4BPEL). The first allows to translate process information to differentCEP engines, the ladder makes it possible to adapt the process behavior at runtimewithout redeploying the whole model before.3 Subject-oriented Business Process Management3.1 FundamentalsThe S-BPM approach roots in the observation that humans usually use standardsemantics of natural language with subject, predicate, and object when they describewhat they are doing in a business process. Consequently the S-BPM modelinglanguage allows for representing these building blocks of a complete sentence innatural language, where the subject is the starting point for describing a situation or asequence of events, the activities are denoted by predicates and an object is the targetof an activity. Resulting models describe structural properties and behavioralalternatives, including the message-based interaction occurring in the technical and/ororganizational environment. Thus S-BPM enriches flow concepts of function-drivenBPM approaches by active entities sending and receiving messages [1, 6, 8]. Theseactive entities are called subjects. In order to keep a process specification independentfrom a special organizational and technical environment subjects are a more abstractview on active entities than actors or agents. A subject abstractly models anagent which executes some specified behavior; for example a subject can stand for aperson acting in a given situation (process) or for a thread in an IT system (softwareagent). A concrete agent (when acting) instantiates (the behavior of) a subject. Thusone agent may be able to execute the behavior of different subjects and vice versadifferent agents may execute the same behavior, as defined by one subject. Thesedifferent executions are independent of each other. Assigning an actor or agent to asubject is part of the implementation of a subject. The graphical notation of the S-BPM modeling language with only a few symbolsis based on process algebra with a clear formal semantic allowing automated codegeneration. This makes subject-oriented process descriptions executable and supportsseamless round-trip engineering [1, 8].
  5. 5. Nondeterministic Events in Business Processes 5 Using the Abstract State Machine (ASM) method Egon Börger [16] developed aprecise formulation for the semantics of the S-BPM constructs in form of a high-levelsubject-oriented interpreter model and gave proof both of ground model andrefinement correctness of the interpreter (for details see [2] and pp. 346-395 in [1]).3.2 ModelingIn 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. Figure1 shows the natural language description of this process. An employee applies for a business trip. His manager checks the request andinforms the employee whether he approves or rejects the request. The approvedrequest 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 ofprocess-specific roles involved in the process, the subjects, and the messagesexchanged between them. When sending messages, the required data is transmittedfrom the sender to the receiver via simple parameters or more complex businessobjects if necessary. Thus, with the message ‘business trip request’ sent by theemployee 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 SubjectInteraction 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 interactionsthe 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 theemployee sends and receives messages, or executes internal actions, and the states heis in during his business trip application.
  6. 6. 6 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F. 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 statein which the employees complete their business trip request. The state transitionfilled out Bt-request leads to a send state in which they send the application to themanager, before entering the receive state, in which an answer is received from themanager. Here, the applicants wait for the response of the manager. In case theyreceive a rejection message from the manager, the process comes to an end. In casethe employees receive the approval message from the manager, they go on the trip onthe agreed date and the business trip application process is completed. The behavior of the manager is complementary to that of the employee (see figure4). Messages sent by the employee are received by the manager, and vice versa. Themanager therefore first waits in a receiving state for a business trip request from theemployee. After receiving the application, he goes to a state of checking which leadseither to the approval or rejection of the request. In the second case, a send statefollows to send the refusal to the employee. In the first case, the manager first movesto a send state for transmitting the approval to the applicant, and then proceeds to astate 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 exampleillustrates the essential elements of a subject-oriented model as there are: The subjects involved in the process, The interactions taking place between them,
  7. 7. Nondeterministic Events in Business Processes 7 The messages they send or receive during each interaction, and The behavior of the individual subjects3.3 Integrating Complex Event Processing (CEP) in S-BPMIn the CEP context an event processing agent (EPA) denotes a unit processingcomplex events [15, 17]. As in S-BPM we distinguish between abstract subjects andactors/agents (see section 3.1) we need a term for a more abstract view on complexevent processing in the subject-oriented context. We introduce the event processingfunctionality (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 toperform them. This means we want to consider event processing functionalityindependent 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 incomingevents in the event cloud. When it discovers a defined constellation a correspondingbusiness process instance is created to handle that constellation.Complex event processing is part of processes. Event processing functionality canbe considered as functions in the behavior of a subject and if the subject is assigned toan agent we have an EPA. As soon as a process is instantiated this agent is alsoinstantiated and can start working. When a predefined event pattern is discovered theinternal function of the related exit transition is executed. Due to the fact that themodeler can define several exits for each internal function, this function can searchfor different patterns. The following figure shows a subject with event processingfunctionality. Fig. 5. A subject with event processing functionality The subject receives a message ‘start_watching_stocks’. After accepting thatmessage the subject is in state ‘watch_stock_exchange’. If ‘Stock price low’ isdiscovered the corresponding transition is executed and in the following send state themessage ‘buy_stocks’ is sent to the subject ‘trader’. If the result ‘stock price high’ isdiscovered the corresponding message is sent. With these messages the correspondingbuy or sell processes are started. After that the subject can do some other workdepending on the behavior specification. As the function discovers events it passes the information on to other subjects inthe process which handle the activities to be accomplished because of an event. Thistype of events (i.e. messages) is nondeterministic. It is unclear whether the message issent and when it will be sent. Other subjects can also send messages to the event
  8. 8. 8 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.processor subject containing information which constellations should be observed (inour example in the message ‘start event processing’) in order to make the complexevent function change its observation conditions. This means subjects must be able tohandle nondeterministic messages. In the following chapter we present the Message Guard concept which details theaforementioned possibilities S-BPM provides to handle asynchronous, nondeter-ministic events.4 Message Guard Concept in S-BPM4.1 Specification We use the term Message Guard as a synonym for handling an exception. It is abehavioral description for a subject that is relevant when a specific, exceptionalsituation occurs along executing a subject behavior specification. It is activated whena corresponding message is received, and the subject is in a state being able torespond to exception handling (see p. 147 ff. in [1]). In such a case, the transition toexception handling has the highest priority and will be enforced. Exception handling can occur in a process in many behavior states of subjects. Thereceipt of certain messages, e.g., to abort the process, always results in the sameprocessing pattern. This pattern should also be modeled for each state in which it isrelevant. Exception handlings cause high modeling effort and lead to complex processmodels, 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 handlingin programming languages or interrupt handling in operating systems. To illustrate the compact description of exception handlings, we enhance ourbusiness trip example by introducing an additional subject ‘Service desk’. Thissubject identifies a need for a business trip in the context of solving a customerproblem - 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 triprequest. The service order may be canceled up to its completion in principle at eachstage of processing. The cancelation message is passed on to all affected subjects tobring 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 withoutapplying the message guard concept of exception handling. A cancelation messagecan be received by the employee either while filling in the application, or whilewaiting for the approval or rejection message from the manager. With respect to thebehavior of the subject ‘employee’, the state ‘response received from manager’ needsto be enriched with the possible input message containing the cancelation and theassociated consequences, too. The verification whether filling in the request isfollowed by a cancelation is modeled through a receive state with a timeout. In casethe timeout is zero, there is no cancelation message in the input pool and the businesstrip request is sent to the manager (for details of the input pool and timeout concept
  9. 9. Nondeterministic Events in Business Processes 9(see p. 96 ff. in [1]). In the other case, the manager is informed of the cancelation andthe process terminates for the subject ‘employee’. A corresponding adjustment of thebehavior 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 suchexception messages can quickly make behavior descriptions extensive and confusingto understand. The concept of exception handling, therefore, should enable supple-menting exceptions to the default behavior of subjects in a structured and compactform. 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 statetransitions, the behavioral description is enriched with the exception handling ‘servicecancelation’. Its initial state is labeled with the states from which is branched to, oncethe message ‘service cancelation’ is received. In the example, these are the states‘business trip application complete’ and ‘receive answer from manager’. Each ofthem is marked by a triangle on the right edge of the state symbol. The exceptionbehavior leads to an exit of the subject, after the message ‘service cancelation’ hasbeen sent to the subject ‘manager’. Basically, a subject behavior does not need to stop here; it may be continued fromthere as specified in some default behavior. Exception handling behavior in a subjectmay 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 exceptionhandling can be a receive state or a function state. Messages that, like ‘service cancelation’, lead to exception handling always havehigher priority than other messages. Thus, modelers express that specific messagesare read in a preferred way. For instance, when the approval message from themanager and shortly thereafter the cancelation message are received in the input poolof the employee, the latter is read first. It causes corresponding abort consequences.4.2 ImplementationSections 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
  10. 10. 10 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.concepts available in a Business Process Management System (BPMS), extensionsare necessary in the design part and in the execution part of a tool suite supporting theS-BPM approach. Strecker presents a prototype solution enhancing the Metasonic Suite as a BPMSby functionality allowing to model exception handling according to the messageguard concept and to perform the modeled behavior at runtime [3].4.2.1 Extension for Modeling and ExecutionAlthough Metasonic’s modeling environment ‘Metasonic Build’ is Eclipse-based andcan therefore easily being adapted or extended, Strecker did not alter the core of theBPMS, but used out-of-the-box possibilities like modeling conventions (e.g. different,multi-colored symbols) and existing custom modeling parameters [10] for his quickand easy prototype implementation. Figure 8 depicts how a message guard behavior is modeled with the mentionedmeans: 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 customextensions to enhance the runtime environment via so-called engine add-ons [10].These extensions can react to certain, well-defined events, and are implemented usingthe so-called observer pattern [11]. As we defined events as incoming messages an InputpoolObserver is needed toreact to message entries in the subject’s input pool. The StateChangeObserver isapplied for handling the message guard behavior. It checks the process model for
  11. 11. Nondeterministic Events in Business Processes 11custom modeling parameters described in the previous section and reacts on theparameter values as events. A certain parameter constellation for example can makethe 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 WorkBusiness Process Management (BPM) recognizing complex events requirescorresponding representation and execution schemes, as those events reflect in situbusiness settings and organizational behavior patterns. In particular, events that areuncertain with respect to their occurrence and their time of occurrence, so callednondeterministic events, require proper management at runtime. Approaches toembed Complex Event Processing (CEP) into BPM neither support specification ofhandling nondeterministic events, e.g., BPMN, nor reflect dynamic handling of thoseevents, 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 functionalapproaches it is grounded on communication patterns between acting systems (i.e.subjects). We started integration by considering CEP units as one way to instantiate aprocess, i.e. creating a process instance. CEP units can then be integrated into subjectsas internal functions. At run time (process instance execution), based on evaluatingvarious data patterns the subject containing the CEP function can inform othersubjects by sending corresponding messages. This represents the basic concept for thehandling of nondeterministic events. The informed subjects may then delegate further observation tasks to the subjectcontaining the CEP unit. In this way they dynamically influence the system behavior.The prototype implementation provides the proof of concept. We have used themessage guard concept for straightforward implementation. Future work should include detailing and evaluating the concept as well as theprototype implementation, e.g. in terms of relating it to the standard event processingarchitecture introduced by [17] or in terms of interaction with existing CEP solutions.Questions still to be answered also refer to performance, limitations and a comparisonwith existing approaches like mentioned in section 2.3.References1. 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 20122. 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)
  12. 12. 12 Fleischmann, A., Schmidt, W., Stary, C., Strecker, F.5. von Ammon, R., Etzion, O., Paschke, A., Stojanovic, N., Event-Driven Business Process Management, in: ED-BPM Workshop, ServiceWave 2008, Madrid, 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., Pfaffenhofen (2011)11. Metasonic AG: ExecutionOrderWithinRefinementsAndObservers (com.jcom1. documentation.refinements.ExecutionOrderWithinRefinementsAndObservers). In: Metasonic AG: Metasonic Suite Developer Documentation 4.4. http://www., Pfaffenhofen (2011)12. Strecker, Florian: OMG, Business Process Management Initiative, BPMN, 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, event-processing-glossary-version-2-0/, last access 2012-05-3016. 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 Implementers 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)