134 CCF-to-J2C Architecture Migration
6. We chose ECIConnectionFactory as the type.
Figure 7-44 Selecting the ECIConnection Factory
Chapter 7. Migrating a real-life application 135
We entered the appropriate JNDI Name for the resource.
Figure 7-45 Creating JNDI name
136 CCF-to-J2C Architecture Migration
Updating the runtime references
We deployed the manually created Services the same way as for the CMA
migrated classes. (See “Runtime references” on page 112.) They were added to
the Web module as a utility project and we deployed the application to a WTE 5.1
environment. We did not have to add any references to any Web Service libraries
in the WebSphere V5.1 environment.
Figure 7-46 Updating the Web module with the new manually created Service Project
Updating the code
After removing the CCF classes, we received the same errors that we had in the
automated migration, but we solved these problems in a different way.
All manipulation of the byte array for the CICS was removed. We added code to
instantiate, initialize, and execute the Service using a CommandProxy instead of
using the buildECI() and flowECI() methods.
Chapter 7. Migrating a real-life application 137
Eliminating the use of getBytes
The getBytes() method calls were obsolete with the use of the CommandProxies.
We commented out all getBytes() calls in the buildRequest() methods and all
other places where they were used.
Replacing the use of SystInfo classes
We replaced this calls by calls to correspondent Record classes the same way as
we did for the automated migration, seen in “Replacing the use of SystInfo
classes” on page 115.
Adding code to use the CommandProxy
In the original code, the response record was created from the byte array
returned from CICS. We replaced this with a CommandProxy (Example 7-12).
Example 7-11 The original code (from a buildResponse() method)
...
response = new MessageRecord(eciRequest.Commarea);
...
The replacement code replaces both the response Record object creation and all
application-specific code, creating an ECIRequest and flowing it to CICS.
Example 7-12 The replacement code (still in the buildResponse() method)
...
MessageCommandProxy proxy = new MessageCommandProxy();
proxy.setMessageRequestRecord(request);
proxy.execute();
response = proxy.getMessageResponseRecordPart();
...
Updating the exception handling
We decided that it would be beneficial to catch explicitly any exceptions thrown
during the communication with CICS, as opposed to letting them be caught in the
‘java.lang.Exception category (see “Modifying the exception handling” on
page 115).
The original code looked like Example 7-13.
Example 7-13 Original exception handling code (buildResponse)
try {
...
do something with the CCF class
...
138 CCF-to-J2C Architecture Migration
} catch (com.ibm.record.RecordException re) {
{
throw new NovaException(
re,
ErrorCodes.ERRCOD_IBMREC_CUSTOMCREATE_ERROR,
"LegacyOrderReadCTGCommand.buildResponse");
}
After modification, the code looked like Example 7-14.
Example 7-14 Exception handling with modification for J2CA exceptions (buildResponse() )
try{
MessageCommandProxy proxy = new MessageCommandProxy();
proxy.setMessageRequestRecord(request);
proxy.execute();
response = proxy.getMessageResponseRecordPart();
} catch (WSIFException re) {
//ITSO
throw new NovaException(re,
ErrorCodes.ERRCOD_IBMREC_CUSTOMCREATE_ERROR, this.getClass().getName() +
".buildResponse");
} catch (Exception e) {
//ITSO
throw new NovaException(e,
ErrorCodes.ERRCOD_IBMREC_CUSTOMCREATE_ERROR, this.getClass().getName() +
".buildResponse");
}
Note: The code in the try {} block throws both a java.lang.Exception and a
WSIFException. This is the reason for having both catch clauses.
Get CCF-to-J2C Architecture Migration now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
