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

It is of significant value for an organization to be able toanalyze and assist business processes by capturing them in aprocess modeling language. It describes the tasks to beperformed in steps and their coordination in a schema, whoseenactment is a specific instance (workcase) thatunfolds over time. In such an environment, a process supportsystem (PSS) is introduced to ensure that the enactmentconforms to the schema. But, in a realistic workflow/process model,it is impractical to anticipate every deviation from the norm thatmay appear during some enactment. Since the objective of a PSS isto support human-centered activities as coherently as possible, wemust face the issue of permitting, in a flexible manner, theseunanticipated deviations, and to cope with their consequences.Although, in fact, many workflow products attempt to cater todeviations from the norm, it appears that most mechanisms so fartend to allow overly powerful ad-hoc actions (e.g., arbitraryschema changes), with insufficient attention to the consequences ofcontinuing after the treatment. More significantly, typeconstraints on the objects that a PSS operates on are equallysubject to unanticipated deviations. We offer a mechanism thatintegrates data and process deviations, mainlyby (i) reifying workflows/workcases as classes/objects, and (ii)applying to them a principled method, developed earlier, forhandling persistent exceptional data. After adopting Ellis' ICN as the process formalism (forspecificity), we reify key aspects of workcases as persistentobjects in classes. Besides data-centric attributes for activities(e.g., one for the responsible agent) with the usual typeconstraints, we introduce assertion attributes of various kinds tomodel the conditions that are supposed to hold during enactment.These are largely of two kinds: ones checked at run-time, andothers assumed to hold under normalcircumstances. The coordination aspects of a workflow are capturedby making the steps be attributes, whose type constraints definethe kind of step, the activities undertaken for them, and thestep(s) following it. For example, a purchasing workflow mightinclude steps for 1) preparing the purchase order, 2) getting theapproval of the manager, and 3) submitting the PO to the purchasingdept. The nature of step 1 and its successor is encoded asstep1:Prepare_PO and …[next=self.step2]. An enactment iscarried out by creating value instances for these step attributes,and moving them from one state to another. (These are alsorepresented as class extents.) We use an exception handling mechanism todetect violations of constraints at an update, suspend theoperation, and signal an exception to theinvoker. An exception handler is then searchedfor, which could be pre-programmed, or most significantly, providedon-line by an agent in a role. The exception handler indicates atits completion how to continue with the suspended operation.Resumption allows the constraint violation topersist as a deviation from the norm, and this requires an adequateexcuse to record who, why, and when theexceptional property has been admitted, providing administrativecontrol over deviations. At the same time, the involved attributeis marked exceptional with a "pollution marker", which is raised asan exception when accessing the value later -- an alert that itneeds to be dealt with circumspectly. Such exceptions are handledusing the usual mechanism for any other exception. The reified workflows and the exception handling mechanism, whencombined, provide means for end-users to modify on-line the stateof activities, their successor, and add extra ones, all in anaccountable manner. For the above example, an agent may choose toupdate wf1.step1.next=wf1.step3, skipping the approval step becausethe manager is away, but having to provide an excuse (for which shehas an authorization). Extensible taxonomies of exceptions can alsoplay an important role in organizing and selecting appropriatehandlers. When resuming with violations that persist, our safetypolicies start checking assumptions at run-time, to dealwith, e.g., changes in control flow. In the above example, supposethere is a step later on to debit the purchase amount from theclient department's budget, where an assumption says: self.step2 inENDED, meaning the approval step is completed. Due to the skippingabove, the assumption checking is activated, resulting later in anexception that prevents this non-standard workcase from escapingthe intended regulations. The generality of our approach is shown by applying it to asecond process model -- the Workflow Net Model of Agostini and DeMichelis. The result is illustrated by an example that accommodatesa coordination deviation in a generic "review-process". Our approach supports flexibility during process enactment byallowing changes to the data values used by the PSS as part ofon-line exception handling. By treating processobjects as ordinary ones, and by equating exceptional occurrenceswith violations of constraints, we have achieved uniformity andfrugality in terms of new notions to be introduced. Significantly,through the mechanism of exceptional attributes and safetypolicies, we have put into place controls over persistentdeviations.