Abstract
The ability to continuously revise business practices is limited when referring to traditional approaches in business process management systems. However, it is essential to organizations aiming at reducing their costs and increasing their revenues. In turbulent environments, the requirement for rapid and continuous changes to business processes, result in less control over the executed activities. As a consequence, process designers are limited in producing solid, well-validated workflow models. This chapter, reviews common approaches to exception handling, focusing especially on adaptive exception handling and introduces a mechanism that allows a flexible ad-hoc generated exception handling using backtracking and forward stepping at a process instance level. A dynamic approach in this domain is required, and can bolster the ability of a business process management system to deal with unexpected situations and to resolve, in runtime, scenarios in which such resolution both is called for and does not violate any business process constraints.
TopIntroduction
Turbulent environments require organizations to continuously revise their business practices, seeking better business opportunities and continuously optimizing their processes. In the last decade, businesses have turned to technological solutions to assist them in this task. The use of electronic means to commerce, data mining, SLA's, and customer profiling are all recent technological developments that penetrate business activities. One of the most recent technological developments is the use of Web services, components with a well-defined interface that are embedded in cross-organizational business processes. Using Web services, the functional aspects of business applications are encapsulated (Aalst, 2003), with interfaces defined using standards such as BPEL4WS (BPEL4WS), and invocation controlled using approaches such as Service Oriented Architecture (SOA). Web services promise to deliver greater choice and flexibility to business processes.
Frequent and continuous changes to business processes carry with it risks, due to shorter (or even nonexistent) design time and less control over the executed activities. As a result, the ability of process designers to produce solid, well-validated workflow models is limited. Workflow management systems (WfMSs), serving as the main vehicle of business process execution, should recognize these risks and become more dynamic to allow the required business flexibility. To illustrate this point, two examples, involving Web services, will be used. First, an observation that the development of Web services is an ongoing task and new and improved services are continuously replacing existing ones. Currently, WfMSs provide little support to the re-execution of successfully processed tasks for running instances, even if the gains from such re-execution outweigh the costs. As another example, observe that Web services merely provide syntactic information regarding their input, output and processing logic, through standards such as WSDL. In most cases, such descriptions fail to convey all necessary constraints and restrictions. Modeling using Web services, therefore, is likely to make the validation of workflow models more difficult (Gaaloul, 2004), and more exceptions at run-time are to be expected. Efficient exception handling is a fundamental component of WfMSs and is critical to their successful implementation in real-world scenarios (Agostini, 2000).
The motivation for this work, lies in the need for flexible and dynamic WfMSs to support the growing number of exceptions that cannot be designed a priori, due to poor design or the lack of sufficient information regarding the internal logic of Web services. In particular, the introduction of a new and more beneficial Web service may trigger backtracking of a process for a re-execution to an activity in which the new Web service is performed, and then continue the regular execution while utilizing, to the extent possible, previously executed activities. In the case of an exception, the proposed algorithm identifies a feasible alternative that avoids the failing activity or communication channel. In this scenario, again, we backtrack to an activity from which it is considered safe to step forward. This is an elaboration of the work presented in (Golani 2005).
This chapter introduces the following:
Key Terms in this Chapter
Process Model: a structure (one among petri net, BP graph, ADEPT WSM net) that describes the precedence of activities, roles, synchronization conditions etc.
Semantic Execution: execution on the workflow level only, meaning that the workflow engine is reported that task ’a’ is completed while the underlying application for this task was not executed.
Adaptivity: the ability to change the definition or routings of a running process
Back-Tracking: undoing/compensating already completed tasks in order to arrive to an earlier step in the business process.
Forward Stepping: a section of the dynamic exception handler, in which the process advances forward (some of the underlying applications could actually not be invoked. See: semantic execution)
Meta Process: a process that models and manages other process models
Exception Handler: a mechanism that enables a business process to manage and heal from occurred and detected exception.
Flexibility: the ability to reconfigure a process given new demands and constraints. This is done by a designer/expert
Alternative Path: an execution plan of a business process that overtakes an activity on another path.
Full Blocked Workflow: For each JOIN (or respectively SPLIT) there is exactly one corresponding SPLIT (or respectively JOIN) of the same kind, and the Activity of the SPLIT and the corresponding JOIN are also the pairing BEGIN and END activities of an INLINE_BLOCK.