Workflow management with BPEL

All Together

By Michael Kleinhenz

An employee who is going on a business trip mails the dates and target location to a service center; somebody in the back office copies these details to various online booking portals and issues a confirmation memo. The employee then returns from the trip and enters the same data again for an expenses claim. Some clever employee might use scripting to automate this process, thereby removing the need for entering redundant information, but what happens if the company modifies the process? Will anyone take the time to rewrite all the custom scripts?

Developers often need a way to modify business processes without reinventing the underlying infrastructure. The processes are thus the interface between the productive departments and IT. At the same time, developers and administrators need to keep track of the whole system and its internal processes - a challenge for both modelers and architects.

The purpose of workflow management systems (WFMS) is to model operations independently of their implementation. The idea is to give users basic tools that map procedures to business functions, such as mail, credit card transactions, or inventory systems, without the need for legacy programming.

XML lends itself to this kind of task, but because an XML description is difficult to manage with just an editor, a range of graphical tools are available to handle the job. The WFMS reads the process definition encoded in the XML and refers to it to coordinate and check the tangible instance of the modeled process.

Workflow engines provide a means for addressing the chain of activities and its sequence. To integrate individual services, most engines use Service-Oriented Architecture (SOA), an XML-based function description. SOA lets a company glue together components from different frameworks. For instance, you can deploy SAP systems in Accounting and still use an in-house component based on JEE or Dotnet in Engineering.

If all the applications have direct SOA interfaces, WFMS can link their functions across applications and control workflows between the components. The individual web services are like the instruments in an orchestra: The workflow directs and integrates the individual parts to create a harmonious whole. Experts in the field refer to this as "programming in the large."

Business Process Execution Language (BPEL) is a standard for SOA workflow management. IBM, BEA, Microsoft, SAP, and others drafted the BPEL OASIS standard, which has now reached version 2.0 [1]. BPEL uses XML to describe processes and relies on the web service standards WSDL and SOAP.

Designing Sample Processes

The process designer starts by drafting planned workflows in a mainly non-technical form, such as event-driven process chains or sketches. Then the designer uses one of the various editing tools to create a BPEL environment - that is, to formulate a plan in the formal description language. The Eclipse environment, for instance, offers BPEL programmers action pallets that support point-and-click-based process building (see Figure 1).

Figure 1: Instead of manually editing the XML code, the BPEL Designer lets users model processes by drag and drop.

BPEL models a process as a sequence of atomic processing steps, or activities. These activities are typically provided directly by web services as invoke elements, or they are available as manipulable variables. Developers organize individual activities as nodes in a graph. Each node contains exactly one control element - for example, conditions that trigger other activities or flows that execute other activities in parallel. Elements such as sequences or loops also manage the control flow.

When stored in an XML document, these structures represent a BPEL process definition. The definition additionally contains meta information and interface descriptions. The modeler formulates the definition in WSDL and as PartnerLinks elements. These elements create a further abstraction layer - between invoke activities below a process on the one hand and tangible web services on the other.

BPEL uses the default XML schema to pass in values; the variables can thus accept complex structures. Fault handlers catch process execution errors and respond by, say, shutting down the database connection. In contrast to this, event handlers provide additional services besides the normal process logic.

Controlling Sequences

The pattern the planner uses to organize sequences is, in effect, the process. Not until a run-time environment, the BPEL engine, parses this description are process instances created from it. Each instance has its own states. The instance links the individual IT systems with the stakeholding employees (see the "Integrating Workflow with Structures" box). Stakeholders are given their own web service connections: To allow this to happen, the engine delivers an email message to the stakeholder or adds a task to the enterprise groupware.

Business processes can take multiple days or even longer depending on the application. Legacy methods such as rolling back an SQL database cannot fully guarantee data integrity in this kind of environment: for example, it is impossible for the sender to recall a letter they have sent. Instead, workflow systems rely on compensation, such as a second letter that cancels a hotel reservation. A compensation is defined like a separate process in a BPEL context; developers can use all of BPEL's design options within the compensation.

Figure 2: The BPEL engine executes individual activities in a sequence provided by users as specified through data created in a browser-based worklist manager.

Long-Winded

Another problem occurs with lengthy processes: The typical HTTP request/response approach is insufficient if the response takes too long to arrive. A request to a synchronous service like this would time out before the web service could respond. For this reason, BPEL defines techniques for asynchronous web service communications between the client and server. The client interrupts the connection when a confirmation of receipt reaches it. The request uses a replyTo header field to define a URL for the response. Once the task is complete, the two partners swap roles, and the former server sends the response to the specified address so that the BPEL engine at this address can continue the process. If it is impossible for the process engine to accept responses, the task falls to a middleware component, such as an enterprise service bus.

Creating Structure

The process engine has the task of allocating a success message to a process instance long after the corresponding request has been issued, and in some cases, many instances are active at the same time in the engine. For example, some instances of "Approve trip" could be running simultaneously in the process engine because several members of staff are planning to visit a trade fair. If it is impossible to add a transaction ID to the request because the interface is defined externally, the WFMS attempts to identify the process instance by reference to the parameters. In the case of a business trip, the name and departure date would probably suffice. Attributes comparable to primary keys are referred to as correlation sets in BPEL.

Scopes in modeling are similar to blocks in C++ or Java. A scope is an area with local variables, process sequences, and fault handlers that allow a developer to keep a process definition tidy, in that local structures and local variables are available just in the local scope.

A delivery example modeled with the use of scopes will help to illustrate: A company charges an amount to a credit card (subscope invoice), but can't deliver the goods because the address is wrong (subscope delivery). The corresponding fault handler passes the error on to the surrounding scope, which also has a fault handler. The fault handler notifies the order processing clerk and compensates the activities after having done so by crediting the amount to the credit card account. The advantage is that the process designer can assign error handling and countermeasures locally for each step.

Example: Booking a Business Trip

Using the travel example described at the beginning of this article, I can now model and later start a simple process. Once the application server and the BPEL are downloaded and installed, the designer models part of the business trip reservation. This simple example does without compensation and asynchronous calls. The result is a collection of XML files that the designer can bundle into an archive and transfer to the engine.

The input for the process comprises four records: the username of the person going on the trip, the starting and finishing points of the trip, and the date and time. The process starts by selecting a method of transport. To allow this to happen, a web service refers to the duration of the trip and the identity of the person traveling to decide whether to book a train or a plane ticket. CEOs and service engineers could have a higher flight priority, for example. After making this decision, the process engine books the tickets. The schedule for the trip is then sent to the traveler (see Figure 3).

Figure 3: When a business trip is booked, a web service decides which method of transport to use, after which the workflow engine triggers a rail or flight reservation.

Point and Click

The graphical ActiveBPEL Designer [5] helps convert the individual modeling steps to XML files. BPEL strictly separates interface information from web services. The languages uses operations, parameter descriptions, and partner links (abstract representations of the actual service addresses). The model itself defines the structure, sequence, and exception handling. The files are available at the Linux Magazine website [6].

To follow this example, BPEL newcomers can download the ActiveBPEL Designer, unpack it, then launch it as follows:

./ActiveVOS_Designer_unix_6_0_2.sh

Once the license file has been mailed to you, there is nothing to stop you from installing. If you prefer not to use the test version, you can use any other BPEL designer. A wizard installs a full version of the engine, allowing users to test the engine directly from the editor.

After installing, users can fix the encoding problem with version 6.0.2 for Linux and recode the file:

cd ./Designer/designer
recode ibmpc..latin1 jre/lib/i386/jvm.cfg

Then type ./designer to launch the designer and accept the path suggested for the workspace. Closing the tab closes the welcome page. Eclipse users will soon feel at home. In the designer's default workspace, you can select File | New | Orchestration Project to create a new project.

The WSDL file, services.wsdl describes all the interfaces. First store the file in the project tree below wsdl; the same applies to the BPEL process description, travelbooking.bpel, below bpel. The deployment descriptor contains the address details for the services. The important thing is that all the definitions find each other; if the designer makes a mistake, you need to check the WSDL references in the BPEL and PDD files.

export CATALINA_HOME=$(pwd)/apachetomcat
cd activebpel5.0.2
./install.sh

cd ../apachetomcat/bin
./startup.sh

Trial and Error

After creating the process, you can test it in the simulator. To do so, run the process by selecting Run | Simulate Process on the internal engine. This command manually sets parameter data via the Process Variables tab to simulate the values passed in by another web service in production use.

If the process works as designed, the BPEL user then creates a deployment archive (see Figure 4). This BPR file is a JAR archive that contains all the files required for the process to run on the open source engine. The file is created by selecting File | Export | Orchestration | Business Process Archive File and choosing File as the deployment type. This step writes the BPR file to disk initially. Optionally, you can pass the deployment directly to a running engine via a web service.

Figure 4: The designer helps compile a business process archive from the various modeling files. The file is executed by a servlet container like Tomcat.

If you prefer to work with Ant and without the designer later on, you can create a BPRD file. A deployment descriptor describes how a process definition finds its way into a workflow engine and configures what were previously abstract parameters. These details are compiled in travelbooking.pdd.

The developer now needs to stop the designer and start Tomcat with the ActiveBPEL engine in it. To introduce the new process to the engine, you just need to copy the BPR archive to the bpr deployment directory below the Tomcat installation. After a couple of seconds, the servlet container identifies the archive. You can monitor this process in http://localhost:8080/BpelAdmin/deployment_log_detail.jsp, the administration interface deployment log.

The log lists the installed processes below Deployed Processes. If a user launches a travelbooking type process via a SOAP request, the admin front end shows its state and variable content in [.../BpelAdmin/active_processes.jsp]. The process visualization in the web front end is similar to the display in the designer.

Good Connections

Any SOAP client can issue a SOAP request; SoapUI is a good choice for quick tests [7]. The WSDL definition for travelbooking() can thus be loaded directly with the running engine: [.../activebpel/services/TravelbookingPartnerLinkService?-wsdl]. If you import the definitions in this way, and set the real HTTP service address for the engine, you can jump right in and integrate the process with your own applications.

Because of the many abstraction layers, workflow management with BPEL is non-trivial. Multiple approaches to process modeling on a business level, different notations, permitted variants in implementation of the standard, the many layers of an SOA, and the variety of software products make it hard for architects to keep track of the solution. Specialist literature on the subject would fill a small library; The Packt Press book Business Process Execution Language for Web Services provides a pragmatic approach [8]. None of the examples require the BPEL Designer because the authors work directly in XML.

Developers Still Have Work To Do

BPEL's answer to the many competing methods of process modeling is to provide a universal approach. BPEL is so universal that it can handle the lion's share of business workflows. This outlook keeps developers flexible and means they can support several modeling methods. But you should not underestimate the complexity: A WFMS based on BPEL requires sound working knowledge of SOA technology by the developer and an unequivocal "yes" to process technology from the business divisions.

Despite all this standardization, BPEL has a couple of pitfalls. For example, the standard is unclear in some areas, or it leaves loopholes that many BPEL engine vendors exploit for proprietary extensions. Although it requires XPath as the language for variable and value manipulation, for instance, it allows for extensions such as XQuery or JavaScript. Although this approach might facilitate modeling, it means that the process definitions are not intelligible to every workflow engine.

The description language is not suitable as a tool for the marketing department or management team to define business workflows on their own. On the contrary: A process designer has to understand the technical underpinnings of the underlying SOA. SOAP skills and a sound understanding of the WSDL standard are useful.

The vision of letting the boss do all the work turns out to be an illusion. But end-user friendliness was never the purpose of this technology: BPEL is a technical integration platform for any kind of business process definition. If you have the perseverance to create a structure with BPEL, you can relax and watch your business workflows perform later as your business processes evolve.