3 Replies Latest reply on May 28, 2012 1:56 PM by 869615

    WSAT Atomic Transactions - is it possible to have multiple XA transactions?

      Using WSAT (Atomic Transactions) calling external web services, is it possible to have 2 separate XA transactions within the same BPEL process?

      Consider the following scenario with some pseudo code:

      BPEL start

         BEGIN xa-transaction-1
            INVOKE external ws-A
            INVOKE external ws-B
            INVOKE DB-adapter-X
         COMMIT xa-transaction-1
            EXCEPTION: rollback xa-transaction-1
         BEGIN xa-transaction-2
            INVOKE external ws-C
            INVOKE external ws-D
            INVOKE DB-adapter-Y
         COMMIT xa-transaction-2
            EXCEPTION: rollback xa-transaction-2

      BPEL end

      I guess it can be resolved by having 3 different bpel processes. One master process invoking 2 childprocesses, each having their own XA transaction?

      What we have seen so far it seems begin and commit cannot really be controlled within the actual BPEL.
      The rollback seem to be triggered when a exception is thrown (and not caught in the current BPEL).
      Same for the commit, when the process exits it seem to commit.

      A side note:
      Is it possible to control/modify the Address within CoordinationContext, in the soap header, so that we can send it through TCPMON as the rest of the soap messages?
      Configuring a http proxy in EM for a composites external sources works, but the callback address does not seem to go through the proxy.

      Edited by: 866612 on 2012-maj-25 21:30
        • 1. Re: WSAT Atomic Transactions - is it possible to have multiple XA transactions?

          If your web services ws-A, ws-B, ws-C, ws-D are SOA Composites and your data source is defined as XA enables; yes its possible.

          Here the interface of the main BPEL can be anything. By default, the BPEL process starts the transaction. And for first transaction, there will be two webservice calls, ws-A and ws-B, if they are synchronous by default they participate the callers transaction (main BPEL), if they are not make them to join the transaction of the caller BPEL using the property bpel.config.transaction. After the two web service calls, you will call the DB-adapter-X, inside the BPEL, for the partnerlink of DB-adapter-X , add the property idempotent and give the value as false. By doing this what happens is after the DB-adapter-X call, the transaction is commited and a new transaction is started from the next activity. Then you will call ws-C, ws-D and then the DB-adapter-Y. Also, if any of the transactions got faulted; you need catch that fault using a catchAll block and throw a fault back at the consumer preferably a business fault with some error details in it by which the BPEL transaction is saved/not saved depending on the fault occured in transaction1/transaction2

          By doing this the possible cases can happen at run time...

          1. Transaction 1 got failed, then the BPEL process is faulted (because you will throw a fault back from the catchll branch)
          2. Transaction 2 got failed, then the BPEL process is faulted (but the transaction 1 is commited)
          3. no faults, then the BPEL process is completed successfully (transaction 1 and transaction 2 are committed).

          Let me know...

          Hope this helps,
          • 2. Re: WSAT Atomic Transactions - is it possible to have multiple XA transactions?
            Thanks for providing that information. There are still a few things that are a bit unclear.

            In this case ws-A..D are not composites. They are web services exposed from a deployed EAR containing pure java. They are deployed in a weblogic domain separate from the SOA Suite cluster.
            They do however include the transactional profile making them available for participating in WSAT with XA transaction support.

            The ws-A..D are implemented similar to this:

            public class ws-A {
              //ws operations
              public void write(...)
              public void writeSomethingElse(...)

            We are already using the idempotent flag to handle retry behavior in other processes. So if we use the idempontent flag here as well, it will perform commit in the WSAT XA transaction, and not just for parts deployed in the SOA Suite (making it possible for us to start a new XA transaction in the same BPEL)?
            • 3. Re: WSAT Atomic Transactions - is it possible to have multiple XA transactions?
              Using idempontent does not solve the problem in this case, since it is specified in the composite.xml on the binding.ws.

              We want to be able to perform commit on the XA transaction in the bpel process, and then start a new xa transaction within the same bpel process.
              Perhaps with some java embedding or being able to specify a property on the invoke activity?

              I cannot find any Oracle Documentation that describes the above scenario.