Transactionality in SCA – Part 2 – Refactoring Interfaces

More than once, customers have asked me:

‘I want to control the transactionality in my Mediation Module so that I can implement a service’s operation with three calls to a JDBC adapter – and I want them all to be tied together – either the whole operation succeeds or fails. How can I do that?’.

Well, as of WebSphere ESB 6.1, this is pretty easy. Just tie together an export of some sort, a mediation flow component, and a JDBC adapter in a Mediation Module, in a global transaction, using the techniques referenced in Part 1 of this series. Then use the new Service Invoke mediation primitive to do three sequential invocations of the JDBC adapter, and Bob’s your uncle.

The result will look something like this:

However, it sometimes gets a bit more complicated.

OK, that’s great. Now we need to implement an operation where three calls to the database need to be bound together into a transaction. However, one subsequent call should sit outside the transaction – if it fails, it shouldn’t affect the other three. How can I do that?

The trick lies in refactoring the interfaces involved. Take the mediation flow component, and conceptually split it into two, componentA and componentB. The export connects to componentA, which connects to componentB, which connects to the JDBC adapter. componentA should also be connected directly to the JDBC adapter. componentA should have the same interface as before. However, you should create a new interface for componentB, which has an operation for each transaction that needs to be bound together (the three calls to the database in our example above).

(the gotcha here is that in a mediation module, you can only have one mediation flow component, so componentB will have to be a Java component)

Here’s the important part: make sure the global transaction boundaries cover componentB and the database only. Do not include componentA or the export.

Now, have the ‘master’ operation in componentA call your new operation on componentB first. Then, have it call the other operation on the JDBC adapter directly (the one that shouldn’t be tied into the transaction).

Your transactional scenario is now set up as requested, and will behave to tie together the first three calls to the database (or whatever else you do in the operation implementation in componentB). It should look like this:

Advertisements

One Response to Transactionality in SCA – Part 2 – Refactoring Interfaces

  1. Sandra says:

    I have the following scenario:
    A JAVA project that invokes an SP from an SQL Server Data Base, the connection to the data base is done through the configuration of a JNDI in the WPS console.
    In a separate project, I have a BPEL that calls the SP in a snippet and then an exception is generated. When this occurs, it is necessary to rollback any operation that was done in the SP, but this process is not currently working.
    The question is whether there is any specific combination from the qualifiers so that this process can work, or if there is any additional configuration for the data source and for the creation of the SP in the Data Base?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: