Workflow as persistent objects with persistent exceptions: a framework for flexibility

It is of significant value for an organization to be able to analyze and assist business processes by capturing them in a process modeling language. It describes the tasks to be performed in steps and their coordination in a schema, whose enactment is a specific instance (workcase) that unfolds over time. In such an environment, a process support system (PSS) is introduced to ensure that the enactment conforms to the schema. But, in a realistic workflow/process model, it is impractical to anticipate every deviation from the norm that may appear during some enactment. Since the objective of a PSS is to support human-centered activities as coherently as possible, we must face the issue of permitting, in a flexible manner, these unanticipated deviations, and to cope with their consequences.Although, in fact, many workflow products attempt to cater to deviations from the norm, it appears that most mechanisms so far tend to allow overly powerful ad-hoc actions (e.g., arbitrary schema changes), with insufficient attention to the consequences of continuing after the treatment. More significantly, type constraints on the objects that a PSS operates on are equally subject to unanticipated deviations. We offer a mechanism that integrates data and process deviations, mainly by (i) reifying workflows/workcases as classes/objects, and (ii) applying to them a principled method, developed earlier, for handling persistent exceptional data.After adopting Ellis' ICN as the process formalism (for specificity), we reify key aspects of workcases as persistent objects in classes. Besides data-centric attributes for activities (e.g., one for the responsible agent) with the usual type constraints, we introduce assertion attributes of various kinds to model the conditions that are supposed to hold during enactment. These are largely of two kinds: ones checked at run-time, and others assumed to hold under normal circumstances. The coordination aspects of a workflow are captured by making the steps be attributes, whose type constraints define the kind of step, the activities undertaken for them, and the step(s) following it. For example, a purchasing workflow might include steps for 1) preparing the purchase order, 2) getting the approval of the manager, and 3) submitting the PO to the purchasing dept. The nature of step 1 and its successor is encoded as step1:Prepare_PO and …[next=self.step2]. An enactment is carried out by creating value instances for these step attributes, and moving them from one state to another. (These are also represented as class extents.)We use an exception handling mechanism to detect violations of constraints at an update, suspend the operation, and signal an exception to the invoker. An exception handler is then searched for, which could be pre-programmed, or most significantly, provided on-line by an agent in a role. The exception handler indicates at its completion how to continue with the suspended operation. Resumption allows the constraint violation to persist as a deviation from the norm, and this requires an adequate excuse to record who, why, and when the exceptional property has been admitted, providing administrative control over deviations. At the same time, the involved attribute is marked exceptional with a "pollution marker", which is raised as an exception when accessing the value later -- an alert that it needs to be dealt with circumspectly. Such exceptions are handled using the usual mechanism for any other exception.The reified workflows and the exception handling mechanism, when combined, provide means for end-users to modify on-line the state of activities, their successor, and add extra ones, all in an accountable manner. For the above example, an agent may choose to update wf1.step1.next=wf1.step3, skipping the approval step because the manager is away, but having to provide an excuse (for which she has an authorization). Extensible taxonomies of exceptions can also play an important role in organizing and selecting appropriate handlers.When resuming with violations that persist, our safety policies start checking assumptions at run-time, to deal with, e.g., changes in control flow. In the above example, suppose there is a step later on to debit the purchase amount from the client department's budget, where an assumption says: self.step2 in ENDED, meaning the approval step is completed. Due to the skipping above, the assumption checking is activated, resulting later in an exception that prevents this non-standard workcase from escaping the intended regulations.The generality of our approach is shown by applying it to a second process model -- the Workflow Net Model of Agostini and De Michelis. The result is illustrated by an example that accommodates a coordination deviation in a generic "review-process".Our approach supports flexibility during process enactment by allowing changes to the data values used by the PSS as part of on-line exception handling. By treating process objects as ordinary ones, and by equating exceptional occurrences with violations of constraints, we have achieved uniformity and frugality in terms of new notions to be introduced. Significantly, through the mechanism of exceptional attributes and safety policies, we have put into place controls over persistent deviations.