The AristaFlow Monitor shall support process administrators as well as system experts. Amongst others it enables the monitoring of in-progress process instances. For example, authorized users may view the current state of a selected process instance as well as its execution log (cf. Fig. 1).

 

Fig. 1: Process Monitor: Monitoring Perspective

Furthermore, the AristaFlow Monitor enables process administrators to cope with exceptions that may occur during process execution (e.g., failed activities). In particular, they may dynamically change a process instance in order to deal with such failures. When defining such ad-hoc changes for a particular process instance, users may apply the complete spectrum of change operations as provided to process designers at buildtime.
Fig. 1 and Fig. 2 illustrate how an ad hoc change could look like. As example assume that a process instance wants to issue a request for a book quote using Amazon’s web service facilities, but then fails in doing so. The user detects that his process instance is in trouble and calls the process administrator for help. The process administrator then invokes the AristaFlow Process Monitor to take a look at this process instance (cf. Fig. 1). Looking into the execution log of the failed activity he detects that its execution failed because the connection to Amazon could not be established. Let us assume that he considers this as a temporary problem and offers the user to reset this activity so that it can be repeated once again. Being a friendly guy, he takes a short look at the process instance and its data flow dependencies, and sees that the result of this and the subsequent activity is only needed when executing the “Choose offer” activity. Therefore, he offers the user to move these two activities after activity “CheckSpecialOffers”; i.e., the user may continue working on this process instance before the process-aware information system once again tries to connect to Amazon.

In order to accomplish this change he would switch to the Instance Change Perspective of the AristaFlow Process Monitor which provides the same set of change operations as the Process
Template Editor. In fact, it is the Process Template Editor, but is aware that a process instance has been loaded and, therefore, all instance-related state information is taken additionally into account when enabling or disabling change operations and when performing correctness checks. The process administrator would now mark the two nodes “Get Amazon offer” and “Get Amazon price” as source area and the nodes “CheckSpecial Offer” and “Choose offer” as target area, and then perform the operation Move nodes. The resulting process graph is depicted in Fig. 2. Another option would be to move node “RetrieveSnailOffer” (where we are waiting for an E-Mail response) after “CheckSpecialOffer” as well. Then “CheckSpecialOffer” would become immediately selectable and thus executable.

 

Fig. 2: Process Monitor: Instance Change Perspective

Assume now that the web service problem lasts longer than expected and, therefore, the user may want to call Amazon by phone to get the price that way. In this case we would ask the process  administrator to delete the two activities in trouble and to replace them with a form-based activity
(which allows to enter the price manually and thus provides the value for the data element previously written by activity “Get Amazon price”).

In order to realize application-specific clients for monitoring and changing in-progress process instances the AristaFlow Open API can be used.