Developing a distributed WS-AT transaction using an IBM BPM Advanced Integration Service, Part 5: Execution cases

Leveraging the capabilities of the Advanced Integration Services (AIS) in IBM Business Process Manager V8.0.1 Advanced, this series describes the implementation of a distributed WS-AT scenario involving two databases (Microsoft® SQL Server and IBM® DB2®) installed on two different machines and accessed via two web services. The implementation illustrates the automatic rollback capabilities offered by the SCA-based management in an AIS in collaboration with the WS-AT protocol. In the final article in this series, you'll learn how to execute and test different transactional scenarios with the components designed and developed in the previous parts of the series.

Share:

Carlo Randone (carlo_randone@it.ibm.com), Certified IT Architect , IBM

Carlo Randone photoCarlo Randone is a Certified IBM IT Architect and Open Group Master Certified IT Architect in IBM Global Business Services, Italy. Carlo has a deep knowledge of different development platforms and middleware on heterogeneous environments and operating systems. He worked for several years as a Certified Trainer and Solution Developer for a Microsoft® Certified Partner.

Since joining IBM in 2000, Carlo's main job interests are related to SOA and BPM, and their related software engineering methodologies and enabling platforms, and Enterprise Architecture planning and design. He enjoys collecting documentation and hardware pieces related to the historical development of IT, and to support this hobby he is a member of the Charles Babbage Institute.



Marco Antonioni (marco_antonioni@it.ibm.com), Certified IT Architect, IBM

Marco Antonioni photoMarco Antonioni is a Certified IT Architect and Open Group Master Certified IT Architect in IBM Software Group, Italy. Marco has a deep knowledge of WebSphere platforms (WebSphere Application Server, WebSphere Process Server, IBM Business Process Manager, IBM Operational Decision Manager, IBM Business Monitor, WebSphere Service Registry and Repository, and WebSphere Message Broker). Since joining IBM in 2000, his main role has been as a BPM Solution Architect in IBM Software Services for WebSphere.



15 October 2013

Also available in Chinese

Execution cases

The final part of this series presents some interesting execution cases. In a real-world situation these kinds of scenarios could become the basis to develop some practical test cases for the transactional solution.

Case 1: All okay

In this scenario, funds are transferred from an account on Bank1 (on SQL Server) to an account on Bank2 (on DB2), with existing accounts and without trigger-based exceptions (the requested amount to transfer is available on Bank1). The outcome in this scenario is a transaction commit. We'll call this case as an "all okay" case.

Following are example input values for this case, as shown in Figure 1:

  • Data source for Bank1 (to Charge) (-): Data Source=localhost; Uid=sa; Initial Catalog=Bank1; Pwd=mypwd
  • Table for Account1 for charge (on Bank1): dbo.Accounts
  • Account1 for charge (on Bank1): Karl
  • Data source for Bank2 (to Credit) (+): jdbc/bank2db2
  • Table for Account2 for credit (on Bank2): ADMINISTRATOR.Accounts
  • Account2 for credit (on Bank2): Donald
  • Money to transfer: 10
Figure 1. Inputs for the "all okay" case
Inputs for the all okay case

Figure 2 shows the related "all okay" message in the error Coach.

Figure 2. Output from the "all okay" case
Output from the all okay case

As you can see, the final output message is the concatenation of the (positive) output message from the Credit eeb service and the (positive) output message from the Charge web service.

Case 2 – Insufficient money

In this scenario, funds are transferred from an account on Bank1 (on SQL Server) to an account on Bank2 (on DB2), with existing accounts and with a database trigger-based exception due to insufficient money on the charge account (on Bank1). The outcome of this scenario is a transaction rollback.

Following are example input values for this case, as shown in Figure 3:

  • Data source for Bank1 (to Charge) (-): Data Source=localhost; Uid=sa; Initial Catalog=Bank1; Pwd=mypwd Table for Account1 for charge (on Bank1): dbo.Accounts
  • Account1 for charge (on Bank1): Karl
  • Data source for Bank2 (to Credit) (+): jdbc/bank2db2
  • Table for Account2 for credit (on Bank2): ADMINISTRATOR.Accounts
  • Account2 for credit (on Bank2): Donald
  • Money to transfer: 200
Figure 3. Parameter values to create an Insufficient Money case
Parameter values to create an Insufficient Money case

Figure 4 shows the output message in the error Coach. The transaction is rolled back, and the amounts in the Karl and Donald accounts do not change.

Figure 4. The error for Insufficient Money
The error for Insufficient Money

In this case the runtime fault, intercepted by the Charge web service, comes from the database trigger on the SQL Server database (Bank1).

Because the implemented SCA-based mediation executes the Credit operation first, this case explicitly shows the transactional behavior. So, for example, when we try to transfer an amount of 200 value units from the Karl account on Bank1 (SQL Server) to the Donald account on Bank2 (on DB2), given the default value of 100 value units of availability for Karl, and providing the input values listed above, the following actions are executed:

  • The TxMediation flow (the AIS implementation) starts, creating a transactional context.
  • The first operation, the call to the Credit web service on the target account, is invoked (Donald on Bank2 on DB2). The operation completes without errors. In time windows, a read of the uncommitted records on Bank2 (on DB2) would show the Donald account with the credited amount.
  • The second operation on the flow, the call to the Charge (debit) web service on the source account Karl on Bank1 (on SQL Server) is invoked. The trigger on the SQL Server accounts table raises an error, because the requested amount is not available in the Karl account. This error is intercepted (caught) by the Charge web service, which re-throws the error to the flow (the mediation in the AIS).
  • The exception is managed in the flow, which exits with a fault. At this time, the resources involved in the transaction (the DB2 target database and the SQL Server source databases) receive a rollback command. If you try to read the records on the database, the values for the two involved accounts are unchanged.
  • The error is managed in the BPMN flow with the error event, which is connected to the specific Coach to show the error details to the user. Figure 4 shows the error message in the Coach, with the "insufficient money" information.

Case 3: Invalid account

In this scenario, funds are transferred from an existing account on Bank1 (on SQL Server) to a non-existent account (Donaldx) on Bank2 (on DB2), which results in an exception being raised by the Credit web services. The outcome in this scenario is a transaction rollback.

Following are example input values for this case, as shown in Figure 5:

  • Data source for Bank1 (to Charge) (-): Data Source=localhost; Uid=sa; Initial Catalog=Bank1; Pwd=mypwd
  • Table for Account1 for charge (on Bank1): dbo.Accounts
  • Account1 for charge (on Bank1): Karl
  • Data source for Bank2 (to Credit) (+): jdbc/bank2db2
  • Table for Account2 for credit (on Bank2): ADMINISTRATOR.Accounts
  • Account2 for credit (on Bank2): Donaldx
  • Money to transfer: 10
Figure 5. Parameter values to create an Invalid Account case
Parameter values to create an Invalid Account case

Figure 6 shows the related message in the error Coach. The amount in the Karl account is not changed.

Figure 6. The error for Invalid Account on Bank2 (to Credit)
The error for Invalid Account on Bank2 (to Credit)

Case 4: Second Invalid Account

Funds are transferred from a non-existent account (Karlx) on Bank1 (on SQL Server) to an existing account on Bank2 (on DB2), which results in an exception being raised by the Charge web service. The outcome of this scenario is a transaction rollback.

Following are example input values for this case, as shown Figure 7:

  • Data source for Bank1 (to Charge) (-): Data Source=localhost; Uid=sa; Initial Catalog=Bank1; Pwd=mypwd Table for Account1 for charge (on Bank1): dbo.Accounts
  • Account1 for charge (on Bank1): Karlx
  • Data source for Bank2 (to Credit) (+): jdbc/bank2db2
  • Table for Account2 for credit (on Bank2): ADMINISTRATOR.Accounts
  • Account2 for credit (on Bank2): Donald
  • Money to transfer: 10
Figure 7. Parameter values to create a second Invalid Account case
Parameter values to create another Invalid Account case

Figure 8 shows the related message in the error Coach for this case. The amount in the Donald account is not changed.

Figure 8. The error for Invalid Account on Bank1 (to Charge)
The error for Invalid Account on Bank1 (to Charge)

Conclusion

In this series, you've seen how IBM Business Process Manager Advanced, leveraging Advanced Integration Services implementation, can manage an ACID distributed transaction between a couple of different database engines (Microsoft SQL Server and IBM DB2), using a couple of transactional web services implemented with two different technological platforms (.NET WCF and Java JAX-WS). You can implement this kind of management by configuring the interfaces of components involved in the transaction (the Charge and Credit services and the SCA-based ESB mediations in the example), with the support of the transactional capabilities of IBM WebSphere Application Server and IBM BPM Advanced.

In a scenario like the one described in this series, one team, for example, a team skilled on Windows and .NET, can develop a Windows-based web service to access a SQL Server database, and a different team (not necessarily at the same time) can develop a similar web service to access a DB2 database, but using a JEE approach like JAX-WS and the WebSphere Application Server. The two teams can work in different organizations and, as we showed you in this series, on very different technological platforms.

From the point of view of the technical integration developer, the option to leverage in IBM Business Process Manager the powerful features of the SCA programming model and the complete support of the WS-AT transactional protocol is an opportunity not only to reuse good skills, but also to support the high-level design and development of business-oriented services with strong and reliable technical "base services" designed and developed with IBM Integration Designer.


Acknowledgements

The authors would like to thank their colleagues Giuseppe Bottura and Simone Chiucchi for their reviews of this article, and their colleagues Stefano Angrisano, Matteo Franciolli, and Daniele Rossi for their contributions. We also want to thank Andrew J. Howes, Billy Lo, Frank I. Toth, Dave Screen, Callum Jackson, Konstantin Luttenberger and Oliver Rebmann for their inspiring and thoughtful developerWorks articles.

Resources

Resources specific to the .NET platform

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 Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere
ArticleID=948353
ArticleTitle=Developing a distributed WS-AT transaction using an IBM BPM Advanced Integration Service, Part 5: Execution cases
publish-date=10152013