CCF-to-J2C Architecture Migration

Chapter 5. Post-migration steps 63

WSIFException when being constructed (Example 5-5). This exception can

occur for a number of reasons and could indicate that:

򐂰 The WSDL file is not packaged with the application.

򐂰 The service is not defined within the WSDL.

򐂰 The typemap class is not packaged with the application.

If such an exception occurs, it indicates that the service proxy bean is unusable.

Therefore, each construction of a proxy object must now be wrapped in a

try/catch clause, which can be auto-created by WebSphere Studio. (Highlight the

code and right-click Source

→ Surround with try/catch block.) The application

should handle the error as it would an execute() error.

Example 5-5 WSIFException thrown by service proxy constructor

/* In CCF */

Commad cmd = new Command();

/* In J2C */

try {

CommandProxy cmd = new CommandProxy();

} catch(WSIFException e) {

...

}

5.1.4 Transactions

Two-phase commits

J2EE allows for two-phase commit control of IMS and CICS transactions through

global transaction management based on EJB deployment descriptors. This

means that changes to your application, including changes to IMS and CICS, are

either all fully completed or all rolled back, leaving the application in a consistent

state. Note that CICS two-phase commits are only supported when the

connection to CICS from WebSphere is local on z/OS®.

J2EE-compliant application servers such as the WebSphere Application Server

serve as a transaction manager by communicating with the resource managers

(CICS, IMS, DB2, WebSphere MQ) to coordinate a transaction. This is a global

transaction that encompasses the activities for all involved resource managers. If

a problem occurs, the updates made to all resources are returned to a consistent

state. Transactional code is not required: The application server takes care of the

two-phase commit processing.

In order to use transaction support with the IMS / CICS Connector, you must set

a transaction attribute in your application EJB deployment descriptors. These

EJBs can be either the ones that were created when migrating the application, or

64 CCF-to-J2C Architecture Migration

pre-existing application EJBs. In order to do this in WebSphere Studio, follow

these steps:

1. Switch to the J2EE perspective. On the J2EE hierarchy tab, expand EJB

modules, right-click your EJB and select Open With

→ Deployment

Descriptor Editor.

2. Select the Assembly Descriptor tab.

3. Click the Add button below Container Transactions.

4. Select your beans by selecting the appropriate check boxes, then click Next.

5. Set the Container transaction type to Required and select the methods you

created when generating the J2CA code (Figure 5-4). Click Finish.

Figure 5-4 Setting the transaction type

6. Your beans should now appear in the Container Transactions box on the EJB

Deployment Descriptor page. Save and close the editor.

Chapter 5. Post-migration steps 65

The EAB-generated code did not support two-phase commits. Therefore,

transactional logic that was added to the client code for use with EAB connectors

should now be removed. Also, the calls to IMS and CICS differ with J2CA as they

did with EAB code.

Note that in order for two-phased commits to be supported, you must use IMS

Connect Version 2.1 or later and IMS Version 8 or later.

Local transactions

The javax.resource.cci.LocalTransaction class enables you to manage

transactions locally. However, these local transactions are not supported by the

IMS connector. To have transaction support for calls to IMS, the transactions

must be managed by a transaction manager.

Making the call to the EIS

Example 5-6 shows a call to IMS from client code that is accessing

EAB-generated connector code. The InputMsg class is the EAB input class. It is

created and populated. The getIMSTransaction() method in this example returns

a class that takes care of transactional behavior such as commits and rollbacks.

The com.ibm.record.IByteBuffer class in this example is an EAB class that will be

removed. The import statement for this class should already have been deleted.

Example 5-6 Call to IMS using EAB-generated code with transactions

InputMsg input = new InputMsg();

input.setMi__rejected("X");

input.setMi__approved("");

//populate the input class

...

IByteBuffer output = (IByteBuffer) this.getIMSTransaction().execute(input);

Example 5-7 on page 66 is a client code sample that makes a call to IMS

using the newly generated J2CA code. Input class MessageIn is created and

populated. The generated proxy class is then created and populated and the

call to IMS is made using the execute method.

Note: CICS CCF code contains a field in the InteractionSpec to set an

extended logical unit of work (CICSELUW). CICSELUW is not available in

J2CA but its function is addressed by the deployment descriptor.