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

All information submitted is secure.

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.

All information submitted is secure.

My developerWorks:

My notifications:

Sign out

Select a language:

Implementing web services transactions in WebSphere Process Server V7

Learn how to implement a Web Services Atomic Transaction scenario with a business process and external web service

Rajiv Madassery (rajiv.madassery@in.ibm.com), Principal Software Engineer, IBM

Rajiv Madassery is a Principal Software Engineer at IBM and works for the WebSphere Process Server Level 2 Support Team. Rajiv came to IBM in 2003 and has worked with the WebSphere Business Integration Adapters Functional Verification Test team and WebSphere Application Server Level 2 Support team. Rajiv is a developerWorks Contributing Author in the WebSphere Process Server space.

Summary: This tutorial provides instructions to implement a transaction between an IBM® WebSphere® Process Server V7 business process and an external web service running on WebSphere Application Server V7. The tutorial will provide steps to be carried out in IBM WebSphere Integration Developer V7 while developing the business process module and the web service, followed by instructions to configure WebSphere Process Server and WebSphere Application Server to enable Web Services Atomic Transaction. The latter part demonstrates the transaction commit and rollback scenarios to complete the tutorial.

Date: 24 Nov 2010
Level: Intermediate
PDF: A4 and Letter (1043 KB | 29 pages)Get Adobe® Reader®

Activity: 28686 views
Comments:

Testing the transactional behavior

You can now test the transactional behavior as all the required configurations are complete.

Scenario: Transaction commit

Go to Integration Developer and open ABCBPEL module.
Right-click on the Component1 in the assembly diagram and select Test Component.
Navigate to Initial request parameters enter a value of success and invoke the request.
The business process invokes the web service (Figure 31). The transaction context is propagated to the web service, but because of the transactional qualifiers set, the web service transaction will execute in the same context as the client transaction.
The web service reads the input parameter and subsequently adds a row to the database. This database transaction will also run in the client context.

Figure 31. Test Component run 1
Verify the database that the record is entered into the database table (Figure 32).

Figure 32. Verifying the database table
The transaction will commit after calling Snippet1.

In this scenario, the transaction context is propagated from Process Server and the web service. The database transactions all participate in a global transaction context.

Scenario: Transaction rollback

Go to Integration Developer and open the ABCBPEL module.
Right-click on the Component1 in the assembly diagram and select Test Component.
Navigate to Initial request parameters enter a value of fail and invoke the request.
The business process invokes the web service.
The web service reads the parameter and writes the record to the database.
At this stage, the transaction is still active and Snippet1 is called.
In Snippet1, the request parameter is checked and if it is “fail”, a BPEL fault will be raised.
A ServiceRuntimeException is thrown in the business process and this triggers the global transaction rollback, as shown in Figure 33.

Figure 33. Test component ends in ServiceRuntimeException
Look in the database table and you will observe that the record is not committed to the database. There is no entry for “fail”.

Figure 34. Verify the database after the exception

In this scenario, the transaction rollback is initiated by ServiceRuntimeException raised in the business process. Since the transaction context is used by the web service and the database, the corresponding transactions at the web service and the database transaction are rolled back, thereby ensuring data integrity. ServiceRuntimeException itself is induced using a BPEL fault.

Comments