Process-aware information systems will be not accepted by users if rigidity or idleness due to failures comes with them. When implementing business processes based on process management technology one fundamental goal is to ensure robustness of the realized process-aware information system. Meeting this goal becomes extremely complicated if high exibility demands need to be ful lled. This software demonstration shows how the AristaFlow BPM Suite assists process participants in coping with errors and exceptional situations. In particular, we focus on new error handling procedures and capabilities using the exibility provided by ad-hoc changes not shown in other context so far.
During the last decade we developed the ADEPT2 next generation process
management technology [
Our tool demo complements previous demos of ADEPT2 and focuses on a fundamental pillar of robust process implementations: error handling. One important aspect in this context is error prevention. We achieve the latter by applying a \correctness by construction" principle during process composition and by guaranteeing correctness and robustness in connection with dynamic process changes. This was probably the most in uential challenge for our research activities. It also had signi cant impact on the development of the AristaFlow BPM Suite. In particular we try to detect as many potential errors as possible during buildtime (e.g. incomplete data ow speci cations or deadlocks) to prevent them from happening during runtime. As we will show, however, errors cannot always be prevented. Therefore another important aspect of PAIS robustness concerns is exception handling. Our demo will show that the AristaFlow BPM Suite provides an easy but yet powerful way to handle exceptions during runtime. In this context ad-hoc process changes are extremely helpful. By utilizing them it becomes possible to even cope with severe process failures and to continue and complete respective processes.
The paper is structured as follows: In Section 2 we introduce a simple application scenario which we use as running example. Section 3 introduces the AristaFlow BPM Suite. In Section 4 we demonstrate how AristaFlow copes with errors that are encountered during process life and how to do this in a exible way. Section 5 discusses related work and Section 6 concludes with a summary and outlook. 2
We will use a simple example to demonstrate how errors can be handled in the AristaFlow BPM Suite. Consider Fig. 1, which shows a simple process of an online book store. In the rst step a customer request is entered and required data is collected. Next the bookseller requests pricing o ers from his suppliers. In this example he will request an o er from Amazon using a web service and another o er from a second company using e-mail. After he has received the pricing o ers from both suppliers the bookseller checks whether he can nd a special o er for the requested books in the Internet. Finally he makes an o er to his customer for the requested books. As we will show, this scenario contains several sources of potential errors. Some of them can be detected and prevented at buildtime while others cannot. Assume, for example, that the process implementer does not foresee a way to enter the o er from SnailMailSeller into the system. In this case the nal activity might fail or produce an invalid output since its input parameters are not provided as expected. Another source of errors might be the Amazon web service; e.g. it might be not available when making the request and therefore the Get Amazon o er activity might fail during runtime. Respective errors can be foreseen and hence considered at buildtime. However non-expected errors might occur as well; e.g., activity Check Special o ers might fail due to troubles with the user's Internet connection.
In summary the following requirements for error-safe and robust process execution exist: On the one hand errors should be avoided during buildtime, on the other hand PAIS must enable users to e ectively deal with expected and unexpected errors during runtime. In the following we show how AristaFlow BPM Suite meets these requirements.
As aforementioned AristaFlow BPM Suite1 is based on the results of the ADEPT2
project. In this research project we targeted at a process management
technology which enables ease of use for process implementers, application developers
and end users. Furthermore, robustness of process implementations, and support
of dynamic process changes were fundamental project goals. To achieve this we
realized a \correctness by construction" principle and guarantee correctness in
the context of ad-hoc changes at the process instance level. Another important
aspect in the context of robustness is error handling. Any PAIS will not be
accepted by users if rigidity comes with it or if its use in error situations is more
expensive than just handling the error by calling the right people by phone.
These challenges were probably the most in uential one for the whole ADEPT2
project [
In the following we consider the scenario from Section 2 from the perspectives of the process implementer, the system, the end user, and the system supervisor. We demonstrate how each of these parties can contribute to the handling of errors.
Process implementer perspective: Fig. 2 shows a part of the process from Fig. 1 as it can be modeled using the AristaFlow Process Template Editor. For implementing work ows, we pursue the idea of process composition in a \plug & play" style supported by correctness checks. The latter contributes to exclude certain errors during process execution. As prerequisite, for example, implicit data ow dependencies among application services have to be made explicit to the process engine. AristaFlow provides an intuitive graphical editor and composition tool to process implementers (cf. Fig. 2), and it applies a correctness by construction principle by providing at any time only those operations to the user which allow to transform a structurally sound process schema into another one; i.e., change operations are enabled or disabled according to which region in the process graph is marked for applying an operation. De ciencies not prohibited by this approach (e.g., concerning data ow) are checked on-the- y and are reported continuously in the problem window of the Process Template Editor. An example can be seen in Fig. 2, where AristaFlow detects that data element Customer price per unit is read by activity Write Customer o er but not written by any preceding activity.
Generally, we should not require from process implementers that they have detailed knowledge about the internals of the application functions they can assign to process activities. However, this should not be achieved by undermining 1 The AristaFlow BPM Suite is provided free of charge to universities for research and educational purposes. Please visit www.AristaFlow-Forum.de for more information on this topic. For commercial usage please visit www.AristaFlow.com.
Data element not supplied
at read access Problems View the correctness by construction principle. In AristaFlow, all kinds of executables that may be associated with process activities are rst registered in the Activity Repository as activity templates. An activity template provides all information to the Process Template Editor; e.g., about mandatory and optional input/output parameters or data dependencies to other activity templates. The process implementer just drags and drops an activity template from the Activity Repository Browser window of the Process Template Editor onto the desired location in the process graph.
One major advantage of this approach is that common errors, e.g. missing data bindings, can be completely prevented at buildtime. Therefore the time needed for testing and debugging can be signi cantly reduced; i.e., AristaFlow guarantees that process models without any detected de ciencies are sound and complete with respect to the activity templates used.
System perspective: The approach described above ensures that in principle the process model is executable by the system in an error-safe way. As always, this might not hold in practice. Again, consider the scenario from Fig. 1: the web service involved by activity Get Amazon o er might not be available when the process is executed, leading to an exception during runtime. Such errors can neither be detected in advance nor completely be prevented by the system.
Failures of the Amazon web service might be anticipated by the process implementer. Thus he can assign speci c error handling procedures to the respective activity. Following the work ow paradigm, AristaFlow uses processes to handle exceptions, i.e., AristaFlow provides a re ective approach in which error handling is accomplished using a work ow being executed by AristaFlow. A simple error handling process is shown in Fig. 3. Depending on whether or not the failure of the process activity was triggered by the user (e.g. through an abort button) either the system supervisor is noti ed about the failure or the process silently terminates. Generally, error handling processes can be arbitrarily complex, long running processes. It is important to note that AristaFlow treats error handling processes the same way as any other process. Thus they can contain any activity available in the repository. Note that this enables error handling of higher semantical level, involving users where required. If an activity fails, the respective error handling process is initiated and provided with all the data necessary to identify and handle the error, e.g. the ID of the failed activity instance, the agents responsible for the activity and the process, the cause of the error, etc. (cf. Fig. 3).
Input parameters of the
process template Properties of the selected activity
User assigned to the selected activity
After an error handling process has been created and deployed to the AristaFlow Server it can be assigned to an activity or process by simply selecting it from a list of processes. Whether or not a process is suitable as error handling process is decided based on its signature, i.e. the input and output parameters of the process.
It is also possible to assign an error handling process to a complete process instead of an activity. In this case this general error handling process will be used if no other error handling process is associated with the failing activity. In case there is no error handling process assign to either the activity or the process a system default error handling process will be used.
One of the advantages of using processes for error handling is that standard process modeling tools and techniques can be used for designing error handling strategies as well. Therefore process implementers do not need to learn any new concept to provide error handing. Another important advantage is that error handling at a higher semantical level can be easily achieved. For example, it is also possible to use more complex error handling strategies like compensation or to apply ad-hoc changes to replace parts of the failed process.
End user perspective: In certain cases the simple error handling process from Fig. 3 might be not appropriate since it increases the workload of the system supervisor. Most standard errors can also be handled in a (semi-)automatic way by the agent executing the activity. Upon failure of the respective activity the agent responsible for executing this activity could be provided with a set of possible error handling strategies he can choose from. An example for such more complex error handling process is shown in Fig. 4. Here the user can choose between a variety of ways to handle the respective error: retrying the failed process step, aborting the whole process instance or applying prede ned ad-hoc changes to x or compensate the error.
Additionally, suggested error handling strategies may depend on the background of the respective user, i.e. his knowledge and position in the organizational model and various other factors. Based on the selection of the user the respective strategy is then applied to handle the error.
Such a semi-automatic, user-centered approach o ers many advantages. Since for each process activity a prede ned set of possible strategies can be provided to users, they do not need to have deep insights into the process to handle errors appropriately. This allows to signi cantly reduce waiting times for failed instances since users can handle errors immediately by their own and do not have to wait for a probably busy helpdesk to handle errors for them. This in turn allows to relieve the helpdesk from the tedious task of handling simple process errors.
System supervisor perspective: Certain errors cannot be handled by the user. For example they might not have been foreseen at buildtime, i.e., no appropriate error handling process exists; or it might be simply not possible to handle errors in an easy and generic way. In such cases the system supervisor can use the AristaFlow Process Monitor shown in Fig. 5 to take a look at this process instance, to analyze its execution log, and decide for an appropriate error handling. Additionally the system supervisor can use the AristaFlow Process Monitor to keep track of failed instances; e.g., he may intervene if a web service becomes unavailable permanently.
Consider again our bookseller example from Fig. 1. Assume that a process instance wants to issue a request for a book using Amazon's web service facilities, Finding Instances with failed activities
Execution log but then fails in doing so. The system administrator detects that the process is in trouble and uses the AristaFlow Process Monitor to take a look at this process instance (cf. Fig. 5). Analyzing 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 a temporary problem and just resets the 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 dependencies, and sees that the result of this and the subsequent activity is only needed when executing the Choose o er activity. Therefore, he moves these two activities after activity Check Special O ers ; i.e., the user can continue to work on this process instance before the PAIS tries to re-connect to Amazon (cf. Fig. 6). To accomplish this change he would switch to the Instance Change Perspective of the Process Monitor which provides the same set of change operations as the Process Template Editor. In fact, it is the Process Template Editor, but it is aware that a process instance has been loaded and, therefore, all instance-related state information is taken additionally into account when enabling/disabling change operations and applying correctness checks. The system administrator would now move the two nodes to their new position by using the respective standard change operation. The resulting process is depicted in Fig. 6. Assume now that the web service problem lasts longer than expected and, therefore, the user wants to call Amazon by phone to get the price that way. In this case he would ask the system administrator to delete the activities in trouble and to replace them with a form-based activity which allows to enter the price manually.
Besides ADEPT, YAWL [
Due to its \correctness by construction" principle and its comprehensive support of ad-hoc changes during runtime, as well as the possibility to de ne arbitrary error handling processes, AristaFlow is well suited to enable robust process implementations while preserving the possibility to exibly react to exceptional situations during runtime. Currently, we investigate the handling of other kinds of errors (e.g. time related errors).