[Bernstein09] Section 5.3. Business Process Execution

5.3. Business Process Execution
Manysystems that support the execution of business processes offer aspecial-purpose runtime system. This section summarizes the maincapabilities one would expect from such a runtime system.
First,the system needs to offer a way of installing business processdefinitions so they can subsequently be invoked. For the most part,this is no different than installing any service. One needs to storethe executable, make its interface definition known to programs thatwill call it, and add its name to a registry so that a caller can findthe service to invoke it.
Routinga request to create a business process is easy enough, since it can beguided by a registry entry. Messages that arrive for running businessprocesses are more challenging. Each message, which corresponds to anevent, needs to be routed to the proper instance of the businessprocess. For example, when a message arrives that says a particularcomputer has left manufacturing, the message needs to be routed to thebusiness process instance that is responsible for that order. Thisinvolves matching parameters in the message with process state. Thismatching needs to be fast, even when there is a large number of activebusiness processes.
Manybusiness processes that include steps performed by people need to allowpeople to modify the process dynamically. That is, a person performinga step might want to add a new step, skip a certain step, or reordersome steps. For example, in a mortgage application process, if anunderwriter finds the customer has an unusual credit history, she mayadd another step for a second opinion by a more experienced loanofficer. Like other process behavior, these modifications of theprocess should be logged so they are made available to later queries.
State Management
Theruntime system needs to manage the state of a running process. For eachprocess, it needs to know which steps have executed, the step(s) thatshould execute next, the business process’s local variables, and othercontext informationneeded for it to run. Much of the work in managing business processexecution involves managing the business process state.
Theruntime system should make process state available to applications.Applications need this capability so they can tell the user about thestate of his or her partially executed business process, which isimportant because business processes may take a long time to execute.For example, if a user places an order and doesn’t receive anacknowledgment within a few days, then the user wants to be able toinvestigate the state of the order. A general-purpose mechanism to savethe state of a business process and to query that state makes it easierfor applications to offer this kind of functionality.
Tomaintain the state of a running process, the runtime needs to log allthe interesting events that occur in a process, since the fact thatthose events occurred is part of the process’s state. For example, foreach active process, it should log when the process starts, who invokedit, and when it ends. Also, the runtime should log when each stepstarts and ends, perhaps including its input parameters and otherinformation about the context in which it runs. This information shouldbe stored in a form that makes it easy to process queries about anindividual process or a large number of processes. The former is neededfor answering customer questions, such as the question earlier, toinvestigate the state of an order. The latter is needed by systemmanagers to monitor performance and identify slow or otherwiseunhealthy processes that need attention. Aggregate information may alsobe useful to business process analysts, to determine the averageperformance of business processes (e.g., response time for certainkinds of orders), to optimize processes (e.g., certain kinds ofprocesses that are taking too long), and to identify poorly automatedprocesses (e.g., ones that require too many manual steps for exceptionhandling).
A businessprocess may execute over a long period, such as days or even months.Although a business process is long-running, it spends most of its timein an inactive state, waiting for an event to arrive to wake it up. Itwould be inefficient and unreliable for the process to reside in mainmemory throughout its execution. It would be inefficient because theprocess has long periods of inactivity during which its state might aswell reside on less expensive persistent storage. It would beunreliable because main memory is volatile, so the business process’sstate would be lost in a system failure. This is a much more seriousproblem than the loss of a short transaction, which can simply abortand re-execute. Therefore, for safety’s sake, the business processshould save its state at the end of each step, as we saw inFigure 2.15.
There are two styles of process execution that relate to process state management, document-oriented and message-oriented.A document-oriented application takes a document as input, associatesit with a business process, and passes the document along from one stepof the business process to the next. Each step knows where to look inthe document for the information that it needs for that step. Each stepupdates the state of the process in the document itself and saves itpersistently before passing it on to the next step. Applications thatevolved from the Electronic Data Interchange (EDI) standard typicallywork this way, as are many newer ones that use XML documents forbusiness-to-business e-commerce.
Bycontrast, a message-oriented application looks more like a sequence ofevents, where each event arrives as a message with explicit parametersthat tell the next step what to do, rather than relying on the step tofind its input in a document. The state of the business process isstored in one or more databases, not in the message like in adocument-oriented application.
Althoughmost applications follow one of these two styles, there are hybridcases that don’t fall neatly into one style or the other. That is, someprocess state information may be retained in messages that are passedbetween steps, while other state information resides in databases. Anddocument-oriented processing often invokes RPCs to execute one or moreof the steps.
Thesystem needs to offer functions for saving and restoring the state of abusiness process. The functions for saving a business process’s statemight be invoked by the business process itself or by an agent thatlooks for business processes that have been idle for a long time andshould be moved out of main memory. The function for restoring thestate of a business process could be invoked by the runtime environmentwhen a step of theprocess is ready to execute. We will see other uses for statemanagement in the next section for handling system failure and recovery.
Businessprocess state can be used to help understand the relationships betweendifferent types of enterprise information. It is often the only placewhere related data entities are correlated and managed. For instance,the relationship between a sales opportunity, a sales quote, a salesorder, and a contract for sales is hard to maintain. If theseactivities were reflected as entities and were coordinated by a singleopportunity-to-contract process, then each instance of the processwould have an ID that would correlate the IDs of these related activityentities as part of the business process state. In this sense businessprocess state is central to creating integrated views of business data.
Giventhe importance of business process state, tools to analyze this statehave become a recognized business process management capability, calledbusiness activity monitoring.This involves emitting business process state, such as event streamsthat populate a database. The database can be used by data mining andother business intelligence tools to provide visibility into everyaspect of the workings of real business processes, includinghuman-driven ones.