BPM engines are designed to follow a coarse-grained processing methodology, which is not enough to manage long-running activities. To cope with this, Complex Event Processing (CEP) is exploited. However, the integration of the two elds had always been intricate. This paper demonstrates an easy tool to work out this integration.
Existing BPM engines [
To compensate for this shortcoming, many research initiatives integrate the CEP technology within BPM engines [1{3]. Even though these initiatives proposed various conceptual and practical solutions to the BPM/CEP integration, they have mainly focused on design-time integration. In other words, they annotate process models with all-purpose events at design-time. This practice does not support predictions while tasks are executing.
Up to this day, no real attempt was made to integrate predictive CEP capabilities inside executing long activities. We argue that the explicit reason for this is the overwhelming complexity that this integration could yield. Since in the CEP world rules are written manually, an easy-to-use solution of integrating on-th- y such rules is not evident. And BPM tech users would nd themselves in urge to master yet another complex domain with intricate jargons.
This paper demonstrates an easy-to-use tool to ful ll a BPM/CEP integration. This integration predicts in-activities violations, and therefore it helps to realize a proactive BPM. Apart from its predictive capabilities, our approach is also generic, in a sense that it works whenever classi ed time series data sets exist, regardless of the application domain. This data set contains the history of executions of monitorable activities, and it constitutes the training data to learn complex and predictive CEP rules.
In this work, we make use of the concept of contextual templates to tackle
context-dependent monitorable tasks, and we demonstrate how autoCEP [
In the manufacturing of semiconductor microelectronics, several sensors to capture important measurements are deployed on the machines that etch the wafers. After the creation of one silicon wafer, it is manually checked if it is normal or abnormal, and then the sensor data related to this speci c wafer are classi ed accordingly. Such work ow is simpli ed in Figure. 1. The manufacture wafer task is long-running and beyond the reach of the BPM engine.
Currently, one could have the (un)interrupting error event that is attached to the manufacture task. Thanks to this, reactive procedures could be later executed (React to Violation sub-process in gure 1). In contrast, what could be achieved using our approach is a proactive management. The manufacture wafer task could have another (un)interrupting event, however this time for a predicted situation. Therefore, the management of the process could be carried out proactively (Proact to Violation sub-process in gure 1).
The strong point to emphasize is that this is not going to be achieved through an ad-hoc support, but it could be done easily in many domains and for any number of situations. The CEP engine will work automatically and signal any violation that it is trained to predict. 3
A main concept that paves the way for a better management of monitorable and long-running activities is contextual templates. Templates are supposed to wrap such activities in order for the CEP engine to infer what should predicted for this speci c instance. This practice constitutes a way of specializing the management of processes on the instance level).
Templates comprise two types of attributes in addition to a prediction section. The rst type is instance-based attributes. These are static data that are useful to con gure the engine. The second type is run-time attributes. They constitute the attributes that the CEP engine should monitor in real-time.
The other part of a template is the prediction section where checkboxes for each situation (class) need to be provided. The user can select what situations he/she is interested in predicting for this speci c instance, and later on the CEP engine will make sure to predict and signal them. Figure 2 shows an example template for manufacturing activities. It is obvious that there are six sensors deployed on the machine. The CEP engine will seek to provide real-time values from each sensor during the execution of the manufacture task. Regarding the predictions, there are two situations or classes in this case because historical wafer manufacturing scenarios are classi ed as normal or abnormal. Selecting some of these classes will notify the CEP engine that users are interested in predicting. Afterwards, the CEP engine will work its magic to predict these classes in an automatic way and without any manually written CEP code.
Templates are extensible, exible, and can be easily created using current BPM engines. All typical engines provide an easy way (usually HTML forms) in order to create templates to assign values to process variables.
The learning part of autoCEP runs over historical scenarios and produces predictive patterns. The learned patterns are saved to a local repository. Afterwards, when the process starts executing, users can check from the template the classes they are interested to predict. For instance, in the manufacturing scenario, it makes sense to predict abnormality. When the execution ow reaches the monitorable activity, e.g. manufacture, whose behavior we aim to predict, the BPM engine will trigger autoCEP while pointing it to the location where the temporal patterns are saved. Such a pointing could be done through the instance-based attributes of the template, or easily through the autoCEP API. AutoCEP then transforms on-the- y the di erent patterns into predictive CEP rules, it con gures the CEP engine to predict for the checked classes in the template, it runs the engine, and starts real-time monitoring and analysis. Subsequently, whenever one of the checked classes (in the template) is predicted, autoCEP will signal an event to the BPM engine (e.g., throw a BPM error with the code equals to the name of the class). Finally, attached events to the monitorable tasks (as shown in the scenario section, g. 1) with the same code as the class will catch the error event dispatched by autoCEP, and the management could be carried out proactively.
BPM users are not responsible of writing CEP rules. They are rather left to focus on the design of their business processes. The only requirement is to name the process variables of the checkboxes in the prediction section of the template and the codes of the attached events, the same as the existing classes from the historical scenarios. Given this simple setup, the interaction between the BPM and the CEP engines will be done behind the scenes. 5
A video that presents our demonstration and puts the whole system into action (with the manufacturing scenario) could be found on our website 3. Moreover, the website contains the source code, links to the data sets, and more experiments to assess the tool from data mining perspectives.
What we have proposed so far could be done in di erent existing BPM engines. In our implementation we exploited the open-source Camunda engine4 to this end. After deploying and con guring the process (in BPMN format), executing it will trigger autoCEP. Then autoCEP will go side by side with Camunda to provide real-time analysis and prediction for the manufacturing task.
Figure 3 presents two portions of two running instances of the manufacturing process. On the left side of the gure, a normal test instance was streamed through autoCEP, correctly no abnormality was predicted, and the ow of the process continued normally. This is shown with the execution token inside the Camunda engine cockpit on the No Predicted Abnormality task. On the right side 3 https://goo.gl/2aDHyu 4 https://camunda.org/ of gure 3, an abnormal test instance was streamed, and as shown the execution of the process was interrupted by the attached error event - the execution token on the Abnormality Predicted task. Thanks to this easy integration with CEP, proactive measures could now be designed and triggered. 6
In this paper, we presented a new technique to put autoCEP in service of the BPM domain in order to allow for more ne-grained management, and prediction when dealing with long-running activities. The overall tool could be considered as an easy way to integrate BPM and CEP, a problem that is lately storming the research area of BPM.
Predicting situations was discussed in this demo, however proposing adaptation countermeasures is still out of its reach. Therefore, further researches are to be continued in this direction.