مشاوره استثنائات گذشته به منظور تسهیل رسیدگی استثنا جریان کار

In this paper, we propose an architecture model that deals with both expected and unexpected exceptions in the context of workflow management. Expected exceptions and their handling approaches are specified by ECA rules, while cases of unexpected exceptions are characterized by their features and resolution approaches. The handling of unexpected exceptions is then assisted by the system providing information about how recent similar cases were resolved. The ways in which the previous exception cases were handled provides useful information in determining how to handle the current one. Quantifying the similarity of exception cases is described, and three algorithms for efficiently searching for similar exception cases are proposed and evaluated both theoretically and by experimenting with synthetic data sets

Workflow management systems (WFMSs) support the execution of business processes. A business process has a market-centred aim of fulfilling a business contract or satisfying a customer's needs [13], and typically, it is controlled by many factors, including the description of the constituent activities, their control/data flow, the potential participants, the organization model and the referenced data [31]. A WFMS separates the specification of business processes, or so-called workflow types, from their execution and provides a convenient and powerful means of specifying a business process and controlling its executions. However, it is well recognized that defining a workflow that represents all properties of the underlying business process is difficult [10]. Moreover, since the formulation of business processes occurs at a high conceptual level, workflows have to adapt rapidly to a changing environment, resulting in executions that deviate from the predefined plan. The process model defined at specification simply represents a standard case, and WFMSs should provide the flexibility to support run-time modification to the defined workflows so as to handle non-standard cases, or so-called exceptions. Some types of exceptions are expected because they are known to occur occasionally or periodically, and their character and the associated way of handling them can be completely decided at build-time. Other exceptions are unexpected since they result from unpredictable changes in the environment, being unable to decide how to handle the exception, or from some other factor that simply cannot be predicted at design-time. It has been observed that exceptions occur rather frequently in real working environments [11] and [27]. This highlights the importance of exception handling in the context of workflow management.

Handling the unexpected exceptions from workflows is a practical but difficult problem. In this paper, we have proposed an architecture model for handling such workflow exceptions. When an exception occurs, the exception handler first searches for a suitable ECA rule that can be triggered. If no such rule can be found, it then searches the previous exception cases and identifies a small subset that resembles the current exception. We characterized an exception by a set of attributes and allowed users to specify a criterion for retrieving matching records. This criterion includes a set of predicates on some attributes and a set of importance weights on candidate attributes. Exception records that satisfy these predicates are ranked according to a similarity measure defined by considering candidate attribute values and their importance weights. Three algorithms, namely, SEQ-E, SEQ-C, and BIN-C, have been derived for finding past exceptions that are similar to the current one. Their relative performance has been compared both theoretically and by experimenting with synthetic data sets. We concluded that BIN-C is an attractive approach, especially when the number of past exception records is huge. BIN-C provides considerable benefits in terms of the execution time, and sacrifices very little in terms of the quality of the returned exception record(s). As we described earlier in this paper, unexpected exceptions can be handled through a two-step procedure in the real world. Firstly, the approaches proposed in this paper are employed in order to obtain a set of similar past exceptions. Secondly, these exceptions are reviewed and an appropriate approach is decided upon for handling the new exception. The focus of this paper has been on the first step. However, the second step is at least as important as the first one, since it usually involves a great deal of human input. Our future work includes the development of a structured way for performing this step. The preliminary idea is to first derive a naı̈ve exception handler from these similar exceptions and then adopt case-based reasoning to adapt this naı̈ve handler to handle the current exception.