Monitoring of Business Processes with Complex Event Processing

Monitoring of Business Processes with Complex Event Processing Susanne Bülow, Michael Backmann, Nico Herzberg, Thomas Hille, Andreas Meyer, Benjamin Ulm, Tsun Yin Wong, Mathias Weske Hasso Plattner Institute at the University of Potsdam Prof.-Dr.-Helmert-Str. 2-3, 14482 Potsdam, Germany {nico.herzberg,andreas.meyer,mathias.weske}@hpi.uni-potsdam.de Summary. Business process monitoring enables a fast and specific overview of the process executions in an enterprise. Traditionally, this kind of monitoring requires a coherent event log. Yet, in reality, execution information is often heterogeneous and distributed. In this paper, we present an approach that enables monitoring of business processes with execution data, independently of the structure and source of the event information. We achieve this by implementing an open source event processing platform combining existing techniques from complex event processing and business process management. Event processing includes transformation for abstraction as well as correlation to process instances and BPMN elements. Monitoring rules are automatically created from BPMN models and executed by the platform. Key words: Business Process Intelligence, Complex Event Processing, BPMN, Event Transformation, Event Correlation 1 Introduction The efficient and correct execution of business processes is essential for the success of an enterprise. Therefore, it is important to model and improve business processes as well as to monitor their executions [1]. Business process management systems (BPMS) control business processes and log the execution of process instances. These execution logs contain complete and structured information required for analysis and optimization of business processes. The information can be evaluated in the context of Business Activity Monitoring, for instance with process mining tools. Yet in some cases, the use of a BPMS is not possible. Enterprises without a BPMS might still have large, complex processes that are executed distributed over several locations and are highly interesting to monitor. During process execution, there arises a lot of information in form of events. An event is the technical representation of a real world happening. In contrast to traditional execution logs, events cannot be analyzed as they are, since they might not be structured nor related to a process instance. The goal of this paper is to enable business process monitoring with execution data, regardless of whether there are complete event logs or unstructured events. Therefore, we designed and implemented an open source event processing platform (EPP) combining existing techniques from complex event processing and business process man-

2 S. Bülow et al. needs to be cooled store chilled reload to other truck technical defect ship arrival store unchilled truck available load to truck transport discharge truck Fig. 1: Business process model of transport process from harbor to destination in BPMN. agement. The platform imports events from different sources, e.g., Excel lists or XML messages, and enriches them with information concerning the process, process instance, activity, and activity instance. In this approach, the methods of complex event processing are not only used for the actual monitoring but for the event enrichment as well. The system provides a high degree of flexibility and adaptability of those enrichment rules in order to make it configurable for different use cases. The EPP presented in this paper builds upon a framework describing how to enrich raw events with context and process data via normalized and business events to process events [2]. There, raw events are the representation of real world happenings in information systems, normalized events have been put into a predefined structure based on the event type, business events contain contextual information existing orthogonally to business processes, and process events are correlated to specific process information, e.g., process instances. To allow monitoring of processes, we adapt the technique of event monitoring points [3], which are attached to specific state transitions of the life cycle of an activity [1] to signal the occurring of a specific event for a specific process instance. The paper is structured as follows. Section 2 introduces a scenario that will be taken as a running example throughout the paper. Section 3 explains the developed techniques to enable monitoring without the existence of a BPMS. This includes transformation, correlation, and monitoring aspects as well as the architecture and implementation of the underlying platform realizing our concepts. Section 4 discusses related work before Section 5 concludes the paper. 2 Scenario The scenario used as a running example in this paper addresses processes in logistics. Specifically, we want to examine a transport process of a as it can be seen in Fig. 1 modeled in BPMN [4]. The arrives on a ship at the harbor and is then stored at a warehouse. The storage is either chilled or unchilled depending on the goods stored in the. As soon as a truck is available, the is loaded to the truck and transported to the customer, where it is discharged. During the transport a technical defect might occur that turns it inevitable to reload the to another truck. There are a lot of events that occur during process execution. Some of these events can be seen in Fig. 2. A ShipEvent is sent from the ship containing information about

Monitoring of Business Processes with Complex Event Processing 3 ShipEvent Type:-Edifact Sender:-Ship WarehouseEvent Type:-Excel Sender:-Warehouse TruckReadyEvent Type:-XML Sender:-In-house parking-area DriverReadyEvent Type:-XML Sender:-Driver DefectEvent Type:-XML Sender:-Driver DeliveryEvent Type:-XML Sender:-Driver Fig. 2: Occuring events in transport process the loaded s, e.g., id and storage hints, as well as arrival time. This event is in the EDIFACT format, which is the standard in technical business communication. The warehouse regularly sends Excel lists about the arrival of new goods or the sending of goods, which represents a WarehouseEvent. A TruckReadyEvent occurs when an empty truck is handed in at an in-house parking area. In our example, truck drivers are equipped with a mobile device that can send XML messages to the logistics headquarter. In this way a driver is able to send a message (DriverReadyEvent), when she is available for a new delivery. If a TruckReadyEvent and a DriverReadyEvent occur in the same area, driver and truck are available and can be used to transport the to the customer. DefectEvents and DeliveryEvents are sent by the driver equally to a DriverReadyEvent informing the headquarter about a technical defect or updating the status of the delivery. Note that a DefectEvent is an unexpected event that does not need to occur for a successful process execution indicated by the dashed lines. Each type of event consists of different key-value pairs. Some example events can be seen in Fig. 3. The described process is not easy to monitor without software support, because these events are neither on the same abstraction hierarchy nor are they by content directly related to the process execution. However, with the approach described in this paper, it is possible to connect those events with the corresponding business process instances. Then, using the process model and some configuration rules, monitoring of the process execution is enabled. 3 Processing of Events and Monitoring This chapter provides an overview of the platform s architecture and illustrates how correlation and transformation are used to enable the monitoring of process instances. Event(1): WarehouseEvent Timestamp: 17/04/2013 14:40 Container ID: AX23 Type: incoming Event(2):TruckReadyEvent Timestamp: 17/04/2013 15:10 Truck Number: 345 Event(3): DriverReadyEvent Timestamp: 17/04/2013 15:00 Driver Number: 987 Fig. 3: Examples for a WarehouseEvent, a TruckReadyEvent, and a DriverReadyEvent

4 S. Bülow et al. EventType 1 * * * Process -eventtypes[] : EventType -processinstances[] : ProcessInstance 1 * Event -eventtype : EventType -processinstances[] : ProcessInstance * * ProcessInstance -events[] : Event -timerevent : Event Fig. 4: Class diagram of the logical core classes for event processing. It demonstrates the transformation from unstructured raw events to process events. As you can see in Fig. 4, process events are associated to one event type and a set of process instances. An event type describes a schema composed of attribute names and attribute types for events. Events have to comply with this schema. The attributes specified in the event type are filled with concrete values matching the attribute type in the event. A process instance is a concrete execution of a process. 3.1 Architecture This section gives an overview of the architecture of the platform presented in Fig. 5 by providing a high level description of important parts. The Event Producers provide events to the Event Receiver, which forwards them to the Correlation Processor. Afterwards they are sent to the Broker that saves them via the Persistence Layer and passes them on to the Query Processor where the events are matched with the previously by the Transformation Processor and Monitoring Processor registered queries. The aforementioned important modules of the architecture are described in detail below. Event Receiver. The Event Receiver is responsible for the import and normalization of events. It receives raw events from different external sources like Excel (.xls/.xlsx), XML or EDIFACT files, and internally created events from transformation. The structure of raw events is undefined. Raw events and normalized events can be flat or hierarchical depending on the input. Based on the incoming events, the Event Receiver produces a normalized event stream. Normalized events are associated to an event type and contain at least a generated ID and a timestamp which can either be the import time or part of the incoming raw event. The remaining information is stored in the payload. Correlation Processor. The Correlation Processor needs user defined rules to correlate events to process instances. Each event can be correlated to multiple process instances and each process instance contains a reference to one process. If there is no existing process instance representation in the EPP that fits to the incoming event, a new one is created. The correlation is executed on the normalized events from the event receiver and creates process events as output. Events which have no relation to any Correlation Rule are forwarded without modification. Broker. The Broker receives the process events from the Correlation Processor. It forwards them simultaneously to the database for permanent storage and to the Query Processor for event stream processing. The Broker enables data integrity and consistency implemented with the concept of mutual exclusion in a multi-threaded environment.

Monitoring of Business Processes with Complex Event Processing 5 Event Producer 1 Event Producer n EventCReceiver EventCTypes Events Transformation Processor MonitoringC Processor CorrelationC Processor Queries R Processes R UserC Interface Process Instances R QueryC Processor Broker R MonitoringC Points AggregationC Rules PersistenceCLayer EventCProcessingCPlatform BPMN Models Database Fig. 5: Architectural overview of our event processing platform. Transformation Processor. The Transformation Processor creates new events by the usage of Transformation Rules which are registered queries. These Transformation Rules are defined by the user. The platform provides a user interface for these definitions. The Transformation Processor registers listeners for these rules at the Query Processor. If a rule matches, the corresponding listener is invoked and the Transformation Processor creates a new event as defined in the rule. The new events are sent to the Event Receiver. Monitoring Processor. To monitor processes, additional information about the relationship between events and processes respectively activities is required. The user can use BPMN process models which are extended by event monitoring points to achieve this connection. With this information, the Monitoring Processor can keep track of running process instances and their progress. Query Processor. The Query Processor works with the stream of typed events and tries to detect the query patterns that have been registered by the Transformation Processor or Monitoring Processor. The Query Processor holds these queries for monitoring and transformation. As soon as a query pattern matches, the Query Processor triggers the corresponding listener. The component that registered the query at the Query Processor can then react to the invoked listener. The Query Processor utilizes an event processing language (EPL), in our case the Esper Query Language [5].

6 S. Bülow et al. Persistence Layer and Database. The Persistence Layer enables the connection of the platform to the Database. The database stores all relevant entities (processes, events, process instances, event types, etc.) and provides access to them. In our case, the database is realized with MySQL and the persistence layer connects the database to the platform implemented in Java via JPA, the Java persistence API. In the following, we refer to the Transformation Processor in Section 3.2, the Correlation Processor in Section 3.3 and the Monitoring Processor in Section 3.4. 3.2 Transformation Normalized events differ in quality since they originate from various business processes where events are captured with different techniques reaching from manual to fullyautomated. Following the approach in [2], our Transformation Processor enables the creation of business events from normalized events and other business events by supporting the functionalities of transformation event processing agents described in [6] such as translation, aggregation, composition, enrichment and projection of events and the usage of context data that exists orthogonally to the business processes. A Transformation Rule consists of a pattern that triggers the creation of a new event and the definition of the event that shall be created. The user has to define the pattern specifying conditions such as the execution order and filtering of events from different event streams. A Transformation Rule Editor abstracting from the Esper Query Language is provided to facilitate the creation of these patterns. The user can build a pattern by the usage of visual elements and suggestions with a preview illustrating the structure of the created pattern. Due to the graphical presentation and the input suggestions of the editor syntactical errors by the user can be avoided. To define the resulting business event, the attribute values have to be determined based on the selection of the event type for the event. These values are mapped by events included in the pattern definition or by context data pulled from the database. For unified access to the database, the context data is stored in an event structure. A query is derived from the Transformation Rule and registered at the Transformation Processor, which creates and activates a statement for the query. In the next step, the Transformation Processor registers a listener for the statement at the Query Processor. Once the events received from the Query Processor fulfill the defined pattern, the listener is invoked and the business event is created. If the type of this business event is referenced in another Transformation Rule, the creation of business events will cascade. In the running example, events of the types WarehouseEvent, TruckReadyEvent, and DriverReadyEvent, e.g., Event(1), (2) and (3), as stated in Section 2 can be aggregated to a business event representing the information of an available driver with a truck assigned for the transport of a certain. A WarehouseEvent expresses the arrival of a in a warehouse and concurrently alerts the need for a transport via truck. Hence, a truck and a driver have to be available in the same region. This information is provided by events of the types TruckReadyEvent and DriverReadyEvent. The Transformation Rule defines a pattern matching on a WarehouseEvent, a TruckEvent, and a DriverEvent that occurred on the same location. If the events matching the pattern are received by the platform, the Transformation Rule is triggered, and the aggregated

Monitoring of Business Processes with Complex Event Processing 7 Event(1): WarehouseEvent Timestamp: 17/04/2013 14:40 Container ID: AX23 Type: incoming Event(2):TruckReadyEvent Timestamp: 17/04/2013 15:10 Truck Number: 345 Event(3): DriverReadyEvent Timestamp: 17/04/2013 15:00 Driver Number: 987 Pattern: WarehouseEvent TruckReadyEvent DriverReadyEvent Condition: (WarehouseEvent.Location = TruckReadyEvent.Location = DriverReadyEvent.Location) WarehouseEvent.Type = incoming Event(4) : Aggregated Event Timestamp: 17/04/2013 15:10 Container ID: AX23 Truck Number: 345 Driver Number: 987 Fig. 6: Example of an event Transformation Rule creating a business event from normalized events. event is created as shown in Fig. 6. The transport planner can thus react to the aggregated event by assigning the driver to the truck and sending it on the road. In order to improve the location condition, a usage of context data referencing cities and hubs to geospatial coordinates can be defined. By this means, the condition could be stated by defining a maximum distance of the locations and thereby enabling a more tolerant matching. 3.3 Process Correlation Every incoming event has to be assigned to a process instance to enable monitoring of processes. As already shown in Fig. 4, our events contain a list of process instances, where each process instance belongs to a process. Correlation is defined as the relationship between two events and defines a collection of semantic rules to specify how certain events are related to each other [7]. In our case, events are related to each other, if they contain equal values for certain attributes. These identifying correlation attributes define the relation of events to process instances as well. Thus, the Correlation Processor tries to correlate the events to a set of process instances. In our approach, the Correlation Rules are defined by the user with suggestions from the Correlation Processor. The user has to determine a process for the Correlation Rule. Then he assigns a set of event types to the Correlation Rule. Every event type specifies a set of attributes. Out of these attributes, the user determines the identifying attributes for the Correlation Rule, the so called correlation attributes. The Correlation Processor uses the defined Correlation Rules during runtime in order to group matching events to process instances. The Correlation Processor groups all events from the database and new incoming events from external event sources that have an event type according to a Correlation Rule. Events belong to the same process instance, if they have the same value in the correlation attributes. Correspondingly, one process instance is created for every distinct value set of the correlation attributes. In our example all events have an attribute which contains the identification number of the transported (Container ID) (see Section 2). The Correlation Processor creates a process instance for every distinct identification number. This single attribute correlation is not sufficient for our use case as the process is intended to monitor a from the arrival in the harbor until the discharge from the truck. Furthermore,

8 S. Bülow et al. one should consider that a can be used several times. So if the would arrive again some month later in the harbor, the event would be correlated to the same process instance as before. Therefore, it is possible to additionally correlate the events depending on their timestamp. One of the selected event types has to be determined as a timer and the user has to define a period of time starting or ending with the timer event. The timer can be seen as an additional Correlation Rule and if both rules (the single attribute and the timer rule) match, the event will be correlated to the process instance. In reference to the running example, the user determines the ShipEvent that indicates the arrival of the in the harbor as timer event and defines the period of time as one week for the consecutive events. Therefore, the occurrence of an event of the type ShipEvent with the ID AX23 triggers the creation of a representation of the process instance in the platform. Event(2) as well as Event(4) from Section 3.2 are assigned to the same process instance. Events of the types DefectEvent and DeliveryEvent are treated the same way, if containing the same ID and time frame. In consequence of enriching the Correlation Rule with the timer, a re-arrival of the AX23 several months later, would result in an assignment of the new events to a second process instance. 3.4 Automatic Generation of Monitoring Queries With complex event processing, it is possible to monitor the execution of processes and the analysis of finished process instances. Many users of process monitoring are more familiar with business process modeling languages than with an EPL like Esper Query Language in our case. Therefore, we decided to give the user the possibility to model a BPMN process and to upload it into the EPP. Afterwards, the Monitoring Processor derives queries from the BPMN process for the Query Processor. For automatic query generation, we assume, utilized BPMN process models are block-structured. In order to create modular and independent queries, it is necessary to decompose the BPMN process in smaller components. We use the refined process structure tree (RPST) described in [8]. The RPST is an algorithm to decompose a workflow graph into smaller parts in a hierarchical structure. The elements of the RPST are canonical blocks with a single entry and a single exit. One advantage of a decomposition with the RPST is that the canonical blocks do not overlap, hence every edge of the model s graph is only considered in one query. In the next step, we map every block of the tree to a specific pattern type which afterwards is used for the query creation. Possible pattern types for a block are: Sequence: all elements belong to a polygon of the RPST which indicates that they are in a sequential execution order. Or: the elements are located in a bond of the RPST on several paths (polygons), where only the elements of one path are executed. And: the elements are located in a bond of the RPST on several paths (polygons), where the elements of all paths are executed. Loop: the elements are located in a bond of the RPST and they belong to a loop. Timer: the polygon contains a sequence of elements that includes a boundary timer element which indicates the continuation of the process execution and interrupts the execution of the element with the attached timer after a specified time duration.

Monitoring of Business Processes with Complex Event Processing 9 We generate a different query for each pattern type mentioned above. Additionally, there is a state transition query for each monitorable BPMN element. This state transition query represents the life cycle of a single element, therefore it is possible to monitor the different state transitions which an element passes through during its life cycle. Figure 7a illustrates the three important canonical blocks for our scenario process. Due to the increased clarity, four smaller sequential blocks in the loop- and in the orblock are omitted. The canonical blocks have been enriched by their pattern types. Besides, occurring events in the EPP need to be bound to the elements of the BPMN process. We enrich the BPMN process elements with event monitoring points as explained in [3]. A event monitoring point stores information concerning the different states of the element s life cycle. The state transitions within the event monitoring point can be bound to an event type via matching algorithms, e.g. string pattern matching or stemming. The matching is applied to the event type name and a certain value of the event monitoring point. Thus, it is possible to generate a query for every canonical block containing elements with event monitoring points. Only the elements with event monitoring points are monitorable and have to be considered whereas the remaining elements are ignored. In Fig. 7b the three generated pattern queries for the canonical blocks from Fig. 7a are depicted. As mentioned above, the queries are written in the Esper Query Language [5]. This language provides patterns in order to query event streams. Every query is registered at the Query Processor, which provides a listener that then gives information about the query completion. The queries can be nested and also depend on the completion of other queries. The structure of the nested queries is closely related to the RPST-structure. In our case, the Monitoring Processor is registered as a listener that collects the information about the execution status for every query. Through the assembly of the queries, it is possible to deduce the status of a process instance. The Monitoring Processor facilitates the monitoring of the running process instances and the detection of violations in the execution order. Furthermore, it gives possibilities to analyze finished process instances, e.g., the execution time or the frequency of execution paths. In our scenario, the advancement and the status of s can be pursued by means of this approach. Fig. 7a illustrates how the event types introduced in Section 2 are bound to elements of the process model. If during process execution an event of the event type ShipEvent enters the Monitoring Processor, it is already correlated to a process instance. Then, the event is bound to the message start event of this process instance. The occurrence of an event of the type WarehouseEvent correlated to the same process instance will then indicate that the process instance is progressed to the waiting for a truck. Hence, through the binding of event types to process elements, e.g., activities, the progress of a process instance can be monitored in real-time with the arrival of the events. 3.5 Implementation Our approach was implemented in a platform using the underlying EPL Esper and can be downloaded with test data and a screencast at http://bpt.hpi.uni-potsdam. de/public/epp. In the platform, event producers can be connected to the event receiver, who creates normalized events out of raw events. For event processing, trans-

10 S. Bülow et al. Sequence Or Aneeds toabeacooled storea chilled reload toaother truck Loop technical defect shipaarrival storea unchilled truck available load toatruck transport discharge truck ShipEvent StateATransition:Aexecute WareHouseEvent StateATransition:Aterminate AggregatedEvent StateATransition:Aexecute TruckReadyEvent DriverReadyEvent DefectEvent StateATransition:Aexecute DeliveryEvent StateATransition:Aterminate (a) BPMN process with canonical blocks and event types bound to process elements Sequence: ShipEventT=>TOrT=>TAggregatedEventT=>TLoopT=>TDeliveryEvent Or: WareHouseEventTTORTTWareHouseEvent Loop: DefectEventTUNTILTDeliveryEvent (b) Generated patterns for the BPMN process Fig. 7: BPMN scenario process (a) with associated pattern queries (b) formation, and correlation rules can be configured. For monitoring, BPMN models annotated with event monitoring points can be uploaded to the platform and connected to business processes. A graphical Web interface is provided for usage of the system. Summarizing, the users can configure and adapt the platform to monitor their processes with different event sources. Previously, process mining was not possible with heterogeneous and distributed raw events of process executions. With our platform, it is possible to deduce enough information to enable process mining and monitoring. 4 Related Work The event processing platform (EPP) presented in this paper targets on an high-quality event basis for business process intelligence (BPI) by processing raw events with techniques known from the field is complex event processing (CEP). BPI aims to manage the quality of process executions by utilizing monitoring and analysis, prediction, control, and optimization [9, 10]. [10 12] concerns the capturing and storing of business process execution data, however, they assume that every process step is recorded and thus, the resulting event log is complete. [9] describes a reference architecture for BPI, containing an integration, a functional, and a visualization layer. The presented approach targets on the integration and functional layer by integrating and combining process execution data, process knowledge, and context data. Process mining [13] is one application of business process intelligence [14] and profits from the EPP. The created process events could be exported from the EPP to an event log to allow the extraction of all kinds of process information, e.g., execution times and conformance information to given process models. The presented EPP could

Monitoring of Business Processes with Complex Event Processing 11 be used as pre-processing step for the existing process mining techniques [13] to bridge the gap of the assumption that an event log needs to be complete. [15] presents an overview of business activity monitoring (BAM) and gives a four class-categorization of BAM systems: pure BAM, discovery-oriented BAM, simulationoriented BAM, and reporting-oriented BAM. As all of these classes base on events with high information content, the presented approach could be applied to enable BAM techniques and methods to provide valuable monitoring results by using the produced process events as input. Del-Río-Ortega et al. [16] presents the concept of process performance indicators (PPI), the process related form of key performance indicators, to enable process evaluation. The presented EPP could provide the input for the so-called process measurements, e.g., time, costs, and occurrences and the concept of PPIs could be applied on top. Therewith, measurements can already be provided while process instance is still running. This enables that violations of tolerance thresholds can be mitigated before the process instance failed a PPI, for instance. The first emphasis of the presented platform is set on the preparation of events for BPI. [17] explains an example of event preparation that creates structured event logs from static data tables. This is done without CEP context and therefore without hierarchical abstraction. In our approach, we use transformation as defined in [6] to abstract from low level events and create business events. Several works concentrate on the correlation of events to process instances. In [7], Correlation Rules are generated semiautomatically for various data sources. The Correlation Rules, we use, are determined by the user in our platform (with the guidance of the platform) and the corresponding procedure is manually configurable. Furthermore, our correlation is more flexible since it is not only dependable on correlation attributes but can be extended on time periods. Secondly, we focused on automated BPI with the help of CEP. [18] introduces techniques to automatically generate Esper queries by taking a choreography model as a formalization of the process. We follow the same approach but with BPMN. In [19], BPMN models are taken as a basis to create EPL statements to monitor process violations but not to monitor the execution as it is our goal. [18] as well as [19] assume complete, structured event logs. Since we do not make the same precondition, the model in our approach must first be annotated with event monitoring points that bind events to states of the life cycle of BPMN elements as described in [3]. Our work supports and implements the framework introduced in [2]. We combine approaches to create queries from models with approaches concerning event preparation including normalization, transformation, and correlation to process instances and activity instances. Important terms related to CEP used in this paper are taken from [20]. 5 Conclusion In this paper, we have proposed an architecture for the approach to enable monitoring of business processes with execution data, independently of the structure and source of the obtainable events. We achieved this by using CEP with rules configurable by the user. Our approach supports business process models in BPMN, which is a well-known standard in process modeling. Furthermore, a graphical interface facilitates the usage of

12 S. Bülow et al. the system. Consequently, it can be used directly by managers without IT background. The developed platform can be easily configured for the user s own needs. In future work, we intend to enhance our system to monitor process execution violations besides the actual instance monitoring. Beyond, the scalability and performance of our system has to be examined. References 1. Weske, M.: Business Process Management: Concepts, Languages, Architectures. Second Edition. Springer (2012) 2. Herzberg, N., Weske, M.: Enriching raw events to enable process intelligence research challenges. Technical Report 73, Hasso Plattner Institute at the University of Potsdam (2013) 3. Herzberg, N., Kunze, M., Rogge-Solti, A.: Towards Process Evaluation in Non-automated Process Execution Environments. In: ZEUS, CEUR-WS (2012) 97 103 4. OMG: Business Process Model and Notation (BPMN), Version 2.0 (2011) 5. Bernhardt, T., Vasseur, A.: Esper: Event Stream Processing and Correlation. Online: http://onjava.com/pub/a/onjava/2007/03/07/ esper-event-stream-processing-and-correlation.html (March 2007) 6. Etzion, O., Niblett, P.: Event Processing in Action. Manning Publications Co. (2010) 7. Rozsnyai, S., Slominski, A., Lakshmanan, G.T.: Discovering event correlation rules for semi-structured business processes. In: Distributed event-based system, ACM (2011) 75 86 8. Vanhatalo, J., Völzer, H., Koehler, J.: The refined process structure tree. Data & Knowledge Engineering 68(9) (2009) 793 818 9. Mutschler, B., Reichert, M.: Aktuelles Schlagwort: Business Process Intelligence. EMISA Forum 26(1) (January 2006) 27 31 10. Grigori, D., Casati, F., Castellanos, M., Dayal, U., Sayal, M., Shan, M.: Business Process Intelligence. Computers in Industry 53(3) (April 2004) 321 343 11. Azvine, B., Cui, Z., Nauck, D., Majeed, B.: Real Time Business Intelligence for the Adaptive Enterprise. In: CEC/EEE, IEEE (2006) 29 12. Melchert, F., Winter, R., Klesse, M.: Aligning Process Automation and Business Intelligence to Support Corporate Performance Management. In: AMCIS, Association for Information Systems (2004) 4053 4063 13. van der Aalst, W.M.P.: Process Mining: Overview and Opportunities. ACM Trans. Manage. Inf. Syst. 3(2) (2012) 7:1-7:17 14. van der Aalst, W.M.P., et al.: Process Mining Manifesto. In: BPM Workshops, Springer (2012) 169 194 15. Dahanayake, A., Welke, R., Cavalheiro, G.: Improving the Understanding of BAM Technology for Real-time Decision Support. IJBIS 7(1) (December 2011) 1 26 16. Del-Río-Ortega, A., Resinas, M., Ruiz-Cortés, A.: Defining Process Performance Indicators: An Ontological Approach. In: OTM. Springer (2010) 555 572 17. Rodríguez, C., Engel, R., Kostoska, G., Daniel, F., Casati, F., Aimar, M.: Eventifier: Extracting process execution logs from operational databases. In: Demonstration Track of BPM Conference, CEUR-WS (2012) 17 22 18. Baouab, A., Perrin, O., Godart, C.: An Optimized Derivation of Event Queries to Monitor Choreography Violations. In: ICSOC, Springer (2012) 222 236 19. Weidlich, M., Ziekow, H., Mendling, J., Günther, O., Weske, M., Desai, N.: Event-based monitoring of process execution violations. In: BPM, Springer (2011) 182 198 20. Luckham, D., Schulte, R.: Event Processing Glossary. Online: http://www.complexevents.com/2011/08/23/ event-processing-glossary-version-2-0/ (2011)