Legend for the example

  1. The transformation server begins to run the map and detects the presence of the -GTX adapter command in the first input card.
  2. The transformation server reads the value of the TransManager entry in the dtx.ini file. In this example, the value is MQS,qm_name which indicates to the transformation server that this card is going to participate in an XA type of global transaction. The other option for the TransManager value would be MSDTC,machine_name, which would indicate the OLE Transactions type of the global transaction.
  3. The transformation server calls the IBM® WebSphere® MQ adapter and the adapter receives a request to initiate a new XA global transaction.

    The transformation server passes the qm_name value from the dtx.ini file to the IBM WebSphere MQ adapter. This is so that the queue manager selected to serve as the XA transaction monitor recognizes the adapter.

  4. The IBM WebSphere MQ adapter connects to the qm_name queue manager.

    The IBM WebSphere MQ queue manager returns the connection handle to the adapter.

  5. The IBM WebSphere MQ adapter requests that the IBM WebSphere MQ queue manager start a new global transaction. The IBM WebSphere MQ queue manager has already recognized the process context of the application that has requested to start the transaction (Process A).
  6. The IBM WebSphere MQ queue manager searches to determine if there is any other XA resource manager registered with the qm_name queue manager. In this search, the Oracle entry is discovered.

    The IBM WebSphere MQ queue manager then calls the Oracle resource manager to inform it about the new global transaction started on behalf of the Process A process.

    The Oracle resource manager acknowledges this and the IBM WebSphere MQ queue manager notifies the IBM WebSphere MQ adapter that a new global transaction started.

    The IBM WebSphere MQ adapter reports this to the transformation server.

  7. The transformation server continues to run the map. The first input card is IBM WebSphere MQ.

    The transformation server requests that the IBM WebSphere MQ adapter connect to the queue manager and queue specified in the adapter command of the card (-QMN QMNAME -QN QUEUE1).

  8. The IBM WebSphere MQ adapter recognizes that this card belongs to a global transaction because the -GTX adapter command was specified. Because of this, instead of connecting again to the IBM WebSphere MQ queue manager, it uses the connection handle obtained in Step 4. Therefore, if the -GTX adapter command is used, the -QMN adapter command is irrelevant because the IBM WebSphere MQ adapter will use the qm_name queue manager.
  9. The transformation server requests that the IBM WebSphere MQ adapter get a message.
  10. The IBM WebSphere MQ adapter sends a GET request to the IBM WebSphere MQ queue manager.

    The IBM WebSphere MQ queue manager checks the process context of the application and gets the message within the transaction started on behalf of this same process.

    The IBM WebSphere MQ queue manager returns the message to the adapter and the adapter passes it back to the transformation server.

  11. The transformation server now examines the output card. It requests that the Oracle adapter connect to the Oracle resource manager.
  12. The Oracle adapter recognizes that it is participating in a global transaction, because of the presence of the -GTX adapter command. Instead of using the regular connection mechanism, the Oracle adapter calls special Oracle XA functions to obtain the connection handles.
  13. The Oracle resource manager checks the process context of the application and it recognizes that this application started the global transaction, as communicated by the IBM WebSphere MQ queue manager previously in Step 6.

    The Oracle resource manager returns a special connection handle to the Oracle adapter. Operations performed on this connection will belong to the global transaction.

  14. The transformation server passes data from the input card, an IBM WebSphere MQ message, to the output card.
  15. The transformation server issues a request to the Oracle adapter to store this data in the database table.
  16. The Oracle adapter calls the Oracle resource manager with the INSERT request, using the connection handle obtained in Step 13.
  17. The Oracle resource manager stores data in the table and notifies the Oracle adapter, which then informs the transformation server that the database output operation was performed successfully.
  18. The mapping was successful and the transformation server calls the IBM WebSphere MQ adapter to commit the global transaction.
  19. The IBM WebSphere MQ adapter calls the IBM WebSphere MQ queue manager with the COMMIT request.
  20. The IBM WebSphere MQ queue manager knows that this process started the global transaction and that it now should commit it.

    The IBM WebSphere MQ queue manager and the Oracle resource manager now start working together to commit the transaction. They exchange information using the XA two-phase commit protocol to ensure that either everything is committed, message retrieved and data inserted in the table, or that everything is rolled back.

    No partial outcome is possible. The XA protocol ensures this with its functions and the help of the transaction logs managed both by the IBM WebSphere MQ queue manager and the Oracle resource manager.

    When the committing process is done, the IBM WebSphere MQ queue manager informs the IBM WebSphere MQ adapter about the successful commit and the IBM WebSphere MQ adapter passes this information to the transformation server.

  21. The map has completed successfully.