Writing the Server Implementation Class

You create the server application by extending the base implementation class, _AccountInterfaceImplBase, which is generated by the IDL compiler as seen in Example 7-3. The class name of the server implementation must be _AccountInterfaceImpl.

Example 7-3. Code from the _AccountInterfaceImplBase Class

In the Workbench you will see that there are a number of classes and one interface created in the accountObject package. You can see the list in Figure 7-6. The interface was created as a result of the interface defined in the IDL called AccountInterface. The interface contains one method called getAccount method. We will be implementing the getAccount method in our implementation class and that is expecting to receive an account number and return the AccountData structure.

VisualAge for Java: Workbench showing the classes of the accountObject package

Figure 7-6. VisualAge for Java: Workbench showing the classes of the accountObject package

Example 7-4. Class Declaration

import com.ibm.cics.server.*;
import java.io.*;
/**
 * This type was created in VisualAge.
 */
public class _AccountInterfaceImpl extends _AccountInterfaceImplBase {
     CommAreaHolder crudCA;
     Program cobolProg;
}

An Implementation class for the sample application is supplied on the CD-ROM. Import the file called _AccountInterfaceImpl.java into your project as follows:

  1. Highlight the KanDoIT Server project, right-click and select Import.

  2. Select the Directory radio button to indicate the file that is to be imported from a directory and click Next. The Import from a directory SmartGuide dialog appears as seen in Figure 7-7.

  3. In the Directory field, browse to find the directory on the CD-ROM where the file is located, for example, \cicsadp\CORBA Server\Java Source\CORBA Server\accountObject.

  4. Ensure that only the .java file type checkbox is selected, select Details next to .java and ensure that the _AccountInterfaceImpl.java file is the only file that is checked. Now select OK and then Finish.

The .java file will be compiled into bytecode and the package is created under the KanDoIT Server project. This adds a further class to the accountObject class and extends the _AccountInterfaceImplBase class that was generated from the IDL definition. You can view the source code for the class and see the methods it contains. Examples Example 7-4 through Example 7-7 show the resulting code. Figure 7-8 shows the resulting structure.

VisualAge for Java: Workbench

Figure 7-8. VisualAge for Java: Workbench

There are three methods in the _accountInterfaceImpl class:

Although working with byte arrays is simple in COBOL, C, or PL/I, this is not a normal way of working with data in Java. In this sample application we’ve used string manipulation to keep the sample simple and clear. A better way to work with this data is to use the IBM Java Record Framework.

getAccount( )

This is the method specified in the IDL definition of accountObject that will be invoked by CORBA clients. The declaration for the method shows that the method will take an account number (as a string) and return an AccountData structure. Several variables are then declared and initialized with values in the order that the NACT02 program expects them. We only want to request data from the NACT application, so crudFunction is set to E to specify an enquire request. crudResponse, crudReason, and crudCICSFunc are set to zero or blank values to ensure false errors are not detected when the NACT02 program returns with customer account information. These string variables are concatenated to form the 22 bytes that will make up the request COMMAREA accepted by the NACT02 program, into a string variable called reqCommArea. This is passed to another method in _AccountInterfaceImpl class called callCRUD, which will convert reqCommArea into a byte array and link to the NACT02 program, and finally return the customer account record into a variable returnedCommArea.

At this point returnedCommArea is just a string of characters. A new variable result is declared of type AccountData, to hold the customer data in the format the client expects, and as defined in the IDL. The next block of code then extracts the customer data fields from returnedCommArea using the matching field in result, which is then returned to the requesting client application.

Example 7-5. getAccount( ) Method

public AccountData getAccount(String acctno) {
    String reqCommArea = new String();
    String crudVersion  = "V1A";          // version number of CRUD application
    String crudFunction = "E";            // Enquire request
    String crudResponse = "0000";         // empty
    String crudReason   = "    ";         // empty
    String crudCICSFunc = "     ";        // empty
    String acctAccountID = acctno;        // acctno provided by client
    // build up the 22 bytes of commarea expected by the COBOL program
    reqCommArea = crudVersion + crudFunction;
    reqCommArea += crudResponse + crudReason;
    reqCommArea += crudCICSFunc + acctAccountID;
    // pass the request data to the COBOL CRUD program and receive account into
    // returnedCommArea
    String returnedCommArea=callCRUD(reqCommArea);
    // create objects to hold returned account data
    AccountData result = new AccountData();
    try  {
   // extract the returned data and set each field in account object
            result.respcode = returnedCommArea.substring(4,8);
            result.reascode = returnedCommArea.substring(8,12);
            result.cicsfunc = returnedCommArea.substring(12,17);
            result.acctid = returnedCommArea.substring(17,22);
            result.lastname = returnedCommArea.substring(22,40);
            result.firstname = returnedCommArea.substring(40,52);
            result.midinit = returnedCommArea.substring(52,53);
            result.title = returnedCommArea.substring(53,57);
            result.telnum = returnedCommArea.substring(57,67);
            result.addr1 = returnedCommArea.substring(67,91);
            result.addr2 = returnedCommArea.substring(91,115);
            result.addr3 = returnedCommArea.substring(115,139);
            result.auth1 = returnedCommArea.substring(139,171);
            result.auth2 = returnedCommArea.substring(171,203);
            result.auth3 = returnedCommArea.substring(203,235);
            result.auth4 = returnedCommArea.substring(235,267);
            result.cards = returnedCommArea.substring(267,268);
            result.issuemonth = returnedCommArea.substring(268,270);
            result.issueday = returnedCommArea.substring(270,272);
            result.issueyear = returnedCommArea.substring(272,274);
            result.reason = returnedCommArea.substring(274,275);
            result.code = returnedCommArea.substring(275,276);
            result.approver = returnedCommArea.substring(276,279);
            result.scode1 = returnedCommArea.substring(279,280);
            result.scode2 = returnedCommArea.substring(280,281);
            result.scode3 = returnedCommArea.substring(281,282);
            result.status = returnedCommArea.substring(282,284);
            result.limit = returnedCommArea.substring(284,292);
     }    catch (Exception e)  {
   System.err.println("Exception occurred trying to build response: " + e.toString());
   }
    // return the account object to the client
    return result;
}
callCRUD( )

This method links to another CICS program, in this case the NACT02 program. This method is invoked by the getAccount method which provides a string variable containing the 22 bytes to be passed to the NACT02 program. The first step is to instantiate a new program object, cobolProg, which is one of the classes in the JCICS class library. The program object represents the NACT02 program to be linked to, and the name is specified using the setName( ) method.

Next, a new instance of a CommAreaHolder object, crudCA, is created to contain the COMMAREA data. Before linking to NACT02, the request data must be converted to byte array format. This is done by invoking the buildCA( ) method and providing the request data requestCA as a parameter. The buildCA( ) method returns the byte array and we store it into the value property of crudCA.

The next line performs the link to NACT02, passing the request COMMAREA in crudCA.value. The requestCA.length parameter specifies the length of the COMMAREA being passed—in this case 22 bytes. The link populates crudCA.value with the response from the NACT02 program, which will be the entire customer account record. The method then converts the returned COMMAREA to a string and returns to the getAccount( ) method.

buildCA( )

This method converts a request string to a byte array. This method takes the request string passed by the callCRUD( ) method and converts it to byte-array format, required by the progam link. The request string, passed in the variable value, is appended to a string of spaces long enough to contain the COMMAREA that will be returned by the NACT02 program. This string is written to the ByteArrayOutputStream baos using the OutputStreamWriter osw. The method converts the ByteArrayOutputStream to byte-array format using the toByteArray( ) method and returns to callCRUD( ).