Exploring WebSphere Process Server transactionality

WebSphere® Process Server supports both short-running microflow processes that run as a transaction in memory, and long-running processes where the state is maintained in the database. This article examines the transactional aspect of each type of flow, including advanced settings that govern the behavior of transactions within a business process.

Marc Fasbinder, Consulting I/T Specialist, IBM

Photo of Marc FasbinderMarc Fasbinder is an I/T Specialist at IBM with the WebSphere Technical Sales team in Southfield, Michigan.


developerWorks Contributing author
        level

17 June 2009

Also available in Chinese Spanish

Introduction

IBM® WebSphere Process Server (hereafter called Process Server) supports different classes of business processes. These are defined by using the WS-BPEL, which is a short-running "microflow" style of process that runs entirely in memory. In a short-running process, the services invoked are committed together as one unit of work; in the case of a failure, transactional services can roll-back. Short-running processes are stateless and normally have subsecond performance. All of the tasks in a short-running process are synchronous, with no human tasks. If you had thousands of process instances running, waiting for days or weeks to complete before they could commit their work, you run into problems with deadlocks.

To solve this problem, another class of business processes, which are long-running, can be used. These processes take some amount of time to complete, from minutes to hours to days or even months. The state is maintained in a database, which means that even if the server was to be stopped, the process resumes where it left off. Processes with human tasks must always be long-running. As a default, each step in a long-running process is a transaction in and of itself. However, there are parameters to control the behavior, which this article will explore.

WebSphere Integration Developer version 6.2.0.1 and WebSphere Process Server version 6.2.0.1 were used for this article. It is assumed that the reader has intermediate knowledge of those two products.


The sample project

To explore the transactional concepts in Process Server, a simple three-step process will be used as an example. You can import the project interchange file that is provided with this article, ShortRunningProcess_PI.zip, into your workspace to follow along. The process is short-running with three steps, each invoking a service. Each service is located in its own module:

  • A Java™ component that displays a message in the console.
  • An import with WebSphere MQ binding, which writes a message to a queue.
  • The WebSphere Flat File Adapter, which writes out a message to a text file.

The process invokes each of these three modules using service component architecture (SCA) binding. The integration solution diagram is shown in Figure 1.

Figure 1. The solution diagram
The solution diagram

For simplicity, each service uses the same interface, txnDemoInterface. The process will run the simple Java component, put a message onto an MQ queue, then write to a flat file.

After importing the project interchange file, deploy all four modules to your server.

Java module

The Java module consists of an SCA export, along with a Java component. The generated Java was updated to write a message out to the console as shown in Listing 1.

Listing 1. Java component
public DataObject runService(DataObject input) {
	System.out.println("Running simple Java...");
	return input;
}

MQ module

The MQ module consists of an SCA export, along with an Import using a WebSphere MQ binding. The Import was configured for the local queue manager and a local queue, as shown in Figure 2.

Figure 2. MQ import settings
MQ import settings

Short-running processes can only invoke synchronous services. Therefore, the ToMQ import uses a one-way interface, which will only put a message. A two-way interface waits for a reply. Since there is a mismatch in the interfaces, a mediation component is used between the export and import.

Update the values on the "End-point configuration" tab to point to your own queue manager. If the postcard queue does not exist on your system, you can either create it or change the destination queue to one that already exists.

File module

The file module (Figure 3) consists of an SCA export, an outgoing WebSphere Adapter import, using the WebSphere Adapter for Flat Files, as well as a mediation flow. The adapter import has a different interface than the other artifacts, which means a mediation is needed for it to be invoked.

Figure 3. File module
File module

The mediation maps the operations, sending the input data through to the adapter. Any response or fault message is mapped out to the status field in the return message. Figure 4 shows the return mapping.

Figure 4. Mediation response mapping
Mediation response mapping

The WebSphere Flat File Adapter is configured to write the output to a file in the C:\FileOutput directory. Before running the process, create a directory to match this name, or update the configuration of FlatFileImport to point to an existing directory on your hard drive.


The process

The initial version of the process is short-running. The process attributes let you set how the process will run. As shown in Figure 5, the process is a long-running flag that specifies which style of process to use. Process Server uses the transaction manager in WebSphere Application Server as the basis for its transactions. For the short-running process, the transactional boundary is the entire process.

Figure 5. Process attributes
Process attributes

Running the process

As a short-running process, the expected behavior is to invoke all three services and to commit the transaction. For the initial test, start the server then deploy all four modules.

  1. Select the servers tab, then right-click the server. Select Add and Remove Projects ..., then click Add All >> to add the four projects to your server. Click Finish. The projects will publish. This may take some time, depending on the speed of your system.
  2. Right-click the server and select Launch - Business Process Choreographer Explorer. Log on with the user ID of admin and a password of admin. If prompted about a security exception, select Yes to continue.
  3. Click Process Templates. If the modules are all deployed, you see TxnProcess in the list. Notice that the Long Running flag is set to "no".
  4. Select the checkbox for TxnProcess and click Start Instance, as shown in Figure 6. This displays a form for input to the process.
    Figure 6. Starting the process
    Starting the process
  5. Enter your name, an amount, and a status of new. Click Submit to start the process.
  6. Look at the console. The message displays "Running simple Java". This shows that the Java component was invoked.
  7. Use a tool, such as RFHUtil from WebSphere MQ Support Pac IH03, to look for messages on the queue named postcard. The data looks similar to Figure 7.
    Figure 7. Message displayed in RFHUtil
    Message displayed in RFHUtil
  8. Look in the directory C:\FileOutput. You see two files. DemoData.seq is the sequence file used to index the file names. DemoData.1.txt contains the data. Edit the file. You see output that is similar to Listing 2.
    Listing 2. File output
    <?xml version="1.0" encoding="UTF-8"?>
    <p:DemoData xsi:type="p:DemoData" xmlns:xsi="http://www.w3.org/2001/
     XMLSchema-instance" xmlns:p="http://TransactionLibrary">
    	<Name>Marc</Name>
    	<Amount>123</Amount>
    	<Status>New</Status>
    </p:DemoData>

    The process output message is displayed in the Business Process Choreographer Explorer. The return code from the Flat File Adapter is displayed in the status, as shown in Figure 8. If the message is successfully written, the file message is set to the name of the file that was created.
    Figure 8. Process output message
    Process output message

The process has run successfully. You can delete the files and remove the message from the queue to prepare for the next test.

Running the process with a fault

Now that the process is running, the next step is to test how the transactions work. One easy way to do this is to intentionally cause a problem for the Flat File Adapter, which results in a fault.

  1. Use Windows® Explorer to delete the C:\FileOutput directory.
  2. Follow Steps 1 to 5 above to start a new process instance.
  3. The process invokes the Java component to display the message.
  4. The process writes a message into the WebSphere MQ queue.
  5. The process invokes the Flat File Adapter, which causes a fault. You see a number of messages that appear in the console.
  6. Examine the postcard queue. No messages are in the queue.

Why did this happen? When the short-running process started, a transaction was opened. The first two service invocations were successful, but when the third returned a fault, the transaction was rolled back. Since you cannot undo writing a message to the console, nothing was done for the first service. For the MQ service, when the transaction was rolled back, the message was not committed to the queue.

This shows that when a fault occurs in a short-running process, the transaction is rolled back. Click the Servers tab. Right-click the server and select Add and Remove Projects. Select ProcessModuleApp and click Remove <. Click Finish. The short-running version of the process is removed from the server.


Long running process

For the next test, the process needs to be changed from short-running to long-running. You can make these updates, or import the project interchange provided in the LongRunningProcess_PI.zip file.

  1. Expand ProcessModule - Integration Logic - Processes and double-click TxnProcess. The process editor opens.
  2. Click the Properties tab. Click the whitespace in the process editor to select the process properties.
  3. Select the checkbox Process is Long Running.
  4. Save the process. You see two errors appear in the Problems view. The Join Transaction qualifier for the process interface needs to be set to "False". You can perform this step in the assembly editor.
  5. The preferred interaction style for the process interface needs to be set to "Async". Unfortunately, you cannot change this in the editor. The best solution is to delete the process component from the assembly diagram, drag and drop in the updated process, and rewire it to the three imports.
  6. Double-click Assembly Diagram in ProcessModule to open the assembly editor.
  7. Right-click the TxnProcess component and select Delete.
  8. Drag and drop TxnProcess from the ProcessModule onto the canvas.
  9. Wire each of the three references from the process to the corresponding import. If you hover over a reference, a pop-up appears with information, as shown in Figure 9.
    Figure 9. Wiring the process
    Wiring the process
  10. Save the updated assembly diagram.
  11. After the workspace is rebuilt, right-click the server and select Add and Remove Projects. Add ProccessModuleApp to the server and click Finish.
  12. The updated process is deployed to the server.

Running the process

Now that the process is deployed, you can try to run it. For the first iteration, create the C:\FileOutput directory, so that the Flat File Adapter will succeed in writing the file.

  1. Launch the Business Process Choreographer Explorer, or log back on if it is still running from before.
  2. Click Process Templates. TxnProcess now shows the Long-Running flat set to yes.
  3. Select the checkbox for TxnProcess and click Start Instance.
  4. Enter a name, amount, and status and click Submit.
  5. The message Running Simple Java... appears in the console.
  6. A message appears on the WebSphere MQ queue named "postcard".
  7. A file is created in the C:\FileOutput directory.

The long-running process worked similarly to the short-running process.

Running the process with a fault

To test the transactional behavior of a long-running process, perform the same steps as before to delete the c:\FileOutput directory, causing a fault with the Flat File Adapter.

  1. With the directory removed, start another process instance.
  2. The message appears in the console, followed by the error messages.
  3. Examine the WebSphere MQ queue named postcard. A message appears on the queue, even though a fault occurred.

What happened? Each step in a long-running process is a transaction in and of itself. After the message was written to the queue, it was committed. The file output step occurred in its own transaction. When that transaction failed, the previous steps were already committed.

  1. In the Business Process Choreographer Explorer, click Started By Me under Process Instances.
  2. You see your process in a "failed" state, as shown in Figure 10.
    Figure 10. Failed process instance
    Failed process instance
  3. Recreate the directory C:\FileOutput.
  4. Click the checkbox for your process instance, then click Activities, as shown in Figure 11.
    Figure 11. Selecting process instance activities
    Selecting process instance activities
  5. You see all of the activities for the process, and that WriteFile is in a failed state.
  6. Select the checkbox for WriteFile and click Restart (Figure 12). The process restarts and runs from end-to-end.
    Figure 12. Restarting the failed activity
    Restarting the failed activity
  7. Remove any messages from the queue to clean up for the next section.

Why did the process have to be restarted? There are no fault handlers in the process, so the fault made the process go into a state called "Failed", as shown in Figure 11. It is possible to modify the process so that you can redo the failing step, without having to restart from the beginning. The key is an attribute called "Continue on Error", which defaults to "Yes" for each activity in the process (Figure 13).

Figure 13. Continue on error
Continue on error
  1. Edit TxnProcess. Click the Properties tab and click the task Write File.
  2. On the Details tab, change Continue On Error to No.
  3. Save the process and then publish ProcessModuleApp to the server.
  4. Verify that the directory c:\FileOutput does not exist.
  5. From the Business Process Choreographer Explorer, go to the Process Templates view and start an instance of the process.
  6. The process runs until the fault occurs in the Write File step.
  7. Click Process Instances - Started By Me. Note that instead of "Failed", this process instance is in the "Running" state.
  8. Select the checkbox for your process instance, then click Activities. The list of activities for your process is shown. Instead of Failed, the WriteFile step is in the Stopped state this time, which enables you to perform actions that are not valid for Failed activities.
  9. Create the c:\FileOutput directory again, so that the activity can succeed.
  10. In the Business Process Choreographer Explorer, select the checkbox for WriteFile and click Restart as shown in Figure 14.
    Figure 14. Restarting WriteFile
    Restarting WriteFile
  11. The Activity Restart screen appears, showing the process data. Click the Restart button. The WriteFile activity succeeds this time. Verify that the file was created.
  12. Remove the message from the queue and remove the c:\FileOutput directory to prepare for the next section.

If you are not going to handle faults in your process, you can use the "Continue On Error" attribute to enable authorized process administrators to repair failed processes, rather than having to restart from the beginning. You can also perform a Force Complete, which enables you to enter the output data manually, complete the task, and have the process resume.

Advanced transactional settings

In a long-running process, the default behavior is to have each activity run as its own transaction. You can also specify transactional behavior for steps within a long-running business process. For each process activity, you can select an attribute to set the transaction, as shown in Figure 15.

Figure 15. Transactional behavior
Transactional behavior

Using these settings, you can enable multiple activities in a long-running process to run within a single transaction. For example, if you had a human task followed by two service invocations, you can use a single transaction for the two services.

In addition to this setting, it is important to take SCA qualifiers into account as well. An SCA qualifier overrides the process setting. If a component you are invoking cannot participate in a global transaction, it forces a commit before the component can run. To explore this behavior, edit the assembly diagram for ProcessModule.

  1. Edit TxnProcess. For Call MQ and Write File, click the Server tab and set Transactional Behavior to Participates. Now all three steps are marked to run within a single transaction. Save the process.
  2. Expand ProcessModule and double-click Assembly Diagram. The assembly diagram editor opens.
  3. Right-click TxnProcess and select Show Transaction from Here. You see a screen similar to Figure 16.
    Figure 16. Transaction boundary
    Transaction boundary
    What happened here? Two activities in the process are set to participate in a transaction, yet only SendToMQ is shown in a transaction. The answer is the SCA qualifiers.
  4. Expand FileModule and double-click Assembly Diagram.
  5. In the Properties tab, click Qualifiers. The SCA qualifiers for the module are displayed, as shown in Figure 17.
    Figure 17. SCA qualifiers for FileModule
    SCA qualifiers for FileModule

The Join transaction qualifier for FlatFileImport is set to "False". This overrides the setting in the process, which is why the transaction shown in Figure 16 only includes SendToMQ. To set this qualifier to "True", you must call the service through a synchronous interface.

Compensation

What happens when you want to use a service in a transaction, but the service is non-transactional? In txnProcess, the service being invoked was asynchronous, which meant it could not participate in the transaction. The answer is a concept called compensation.

Compensation enables a long-running business process to have the same quality of service as a short-running process. Services, which have already been invoked and committed, are "undone" with the compensation handler.

  • If a service adds a record, the compensation removes the record.
  • If a service updates a record, the compensation restores the original value.
  • If the service deletes a record, the compensation restores the record.

Not every step in the process needs to be undone. You cannot "unprint" a document. A person does not have to "unapprove" a request that they previously approved. Typically, compensation will undo a subset of the automatic services, which were invoked by the process. Compensation is also available in short-running processes for cases where the invoked services cannot participate in a transaction.

For a detailed article on compensation, see Using compensation in business processes with Business Process Choreographer.


Conclusion

This article described transactional concepts in WebSphere Process Server. You learned how:

  • Short-running processes run within a single transaction.
  • Each step in a long-running process runs within its own transaction as a default and how you can override the behavior.
  • To repair a process and how you can use compensation to give a long-running process the same quality of service as a short-running process.

Downloads

DescriptionNameSize
Code sampleShortRunningProcess_PI.zip2,608 KB
Code sampleLongRunningProcess_PI.zip2,608 KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=397709
ArticleTitle=Exploring WebSphere Process Server transactionality
publish-date=06172009