Here are the ways that you can use WebSphere Optimized Local Adapters to call outbound applications on WebSphere Application Server.
The WebSphere Optimized Local Adapter receive request (BBOA1RCV) or host service (BBOA1SRV) APIs can be used to make any application available to Java applications in WebSphere Application Server, which can then call them using JCA-style methods. For more information on using these APIs, see Optimized local adapters for z/OS APIs.
Applications running in z/OS batch, CICS, IMS, and USS can all use the WebSphere Optimized Local Adapter APIs to establish themselves as WebSphere Optimized Local Adapter servers, accepting requests from the WebSphere Application Server.
The WebSphere Optimized Local Adapter Link Server is an application that can be started in a CICS region and it serves as a server or as a proxy for calls to existing CICS programs. In this case, the WebSphere Application Server application calls existing unchanged CICS programs over an EXEC CICS LINK with either a communications area (COMMAREA), or a channel and container to pass in and get response data back.
The default mechanism used by WebSphere Optimized Local Adapter for passing the message payload to a CICS program is the COMMAREA. You can specify that a single CICS container deliver the request message and another be used for the response, by using connection factory properties. For a single request/response container, you set up the request record as an IndexedRecord containing a single entry. You can also specify that WebSphere Optimized Local Adapter deliver multiple messages in multiple containers for the channel name that you supply, by using setter methods or by indicating this is requested in the connection factory. For multiple records, you supply a MappedRecord to WebSphere Optimized Local Adapter for the outbound call to CICS. For more information on CICS Channels and Containers support in WebSphere Optimized Local Adapter, see WebSphere Application Server transactions BBOC, BBO$, BBO#.
To generate an implementation that supports CICS containers:
The third way outbound calls can be made over WebSphere Optimized Local Adapter is for calling existing IMS transactions. For this, WebSphere Optimized Local Adapter uses the IMS OTMA Callable Interface. There is a setter method on the WebSphere Optimized Local Adapter connection specification and connection factory that indicates OTMA is in use. WebSphere Application Server applications need to select an OTMA Server name and Group ID and they need to bundle their message payloads as IMS messages and then call the WebSphere Optimized Local Adapter resource adapter, selecting OTMA as the underlying protocol.
IMS request message data for WebSphere Optimized Local Adapter over OTMA must be constructed in the following standard IMS form: LLZZ or LLLLZZ plus IMS transaction ID (8 chars) plus IMS message data.
IMS response message data from the WebSphere Optimized Local Adapter over OTMA call can be returned as either LLZZ plus response data or LLLLZZ plus response data. It is recommended that you review the options for setting up WebSphere Optimized Local Adapter over OTMA to indicate you will be using LLZZ form or LLLLZZ form, WebSphere Optimized Local Adapter supports both for request and response payloads, and these can be set with setter methods on the connection specification or with properties on the connection factory.
When using the workbench Data Importer, inspect the COBOL copy book or PL/I structure, see which format is used for the IMS request payload (LLZZ or LLLLZZ), and select the associated flag in the WebSphere Optimized Local Adapter connection factory (or use the proper setter method) that is aligned with that format. For details on message payload formats, see Calling existing IMS transactions with optimized local adapters over OTMA. For details on WebSphere Optimized Local Adapter over OTMA, see (Optional) Use the IMS environment.
WebSphere Optimized Local Adapter also supports two-phase commit global transactions in both directions between WebSphere Application Server and CICS, and WebSphere Application Server and IMS. For more information on WebSphere Optimized Local Adapter and global transactions, see Calling an enterprise bean from an external address space within a client-initiated transaction.
For information on WebSphere Application Server and IMS global transactions, see Calling existing IMS transactions with optimized local adapters over OTMA.
When using the remote mode, you can use workbench and WebSphere Application Server, and deploy or redeploy your application without having to make any changes in the WebSphere Application Server z/OS server where the WebSphere Optimized Local Adapter proxy is running. You might need to use this method when developing and testing application updates. For more information on using WebSphere Optimized Local Adapter in Development or Remote mode, see Optimized local adapters deployment in development mode
Here is a sample generated WebSphere Optimized Local Adapter external call implementation that was created with the name of zCUSTCPY_Out. It was configured to use a JNDI name of eis/ola and a target service name of ZCUSTGET. This was generated to include data binding helper class that was created from a COBOL copy book with a Level 01 definition called CUSTOMER.
package com.ibm.rad.ola.test;
import javax.resource.ResourceException;
import javax.resource.cci.Connection;
import javax.resource.cci.Interaction;
import javax.resource.cci.ConnectionFactory;
import javax.resource.cci.ConnectionSpec;
import javax.resource.cci.InteractionSpec;
import javax.resource.cci.Record;
import javax.resource.cci.ResourceAdapterMetaData;
/**
* @j2c.connectionFactory jndi-name="eis/ola"
* @j2c.connectionSpec class="com.ibm.websphere.ola.ConnectionSpecImpl"
* @generated
*/
public class ZCICSCustGetImpl implements com.ibm.rad.ola.test.ZCICSCustGet {
private ConnectionSpec typeLevelConnectionSpec;
private InteractionSpec invokedInteractionSpec;
private InteractionSpec interactionSpec;
private ConnectionSpec connectionSpec;
private Connection connection;
private ConnectionFactory connectionFactory;
/**
* @j2c.interactionSpec class="com.ibm.websphere.ola.InteractionSpecImpl"
* @j2c.interactionSpec-property name="serviceName" value="ZCUSTGET"
* @generated
*/
public com.ibm.rad.ola.test.CUSTOMER zCUSTCPY_Out(
com.ibm.rad.ola.test.CUSTOMER arg)
throws javax.resource.ResourceException {
ConnectionSpec cs = getConnectionSpec();
InteractionSpec is = interactionSpec;
try {
if (cs == null) {
cs = getTypeLevelConnectionSpec();
}
if (is == null) {
is = new com.ibm.websphere.ola.InteractionSpecImpl();
((com.ibm.websphere.ola.InteractionSpecImpl) is)
.setServiceName("ZCUSTGET");
}
} catch (Exception e) {
throw new ResourceException(e.getMessage());
}
com.ibm.rad.ola.test.CUSTOMER output = new
com.ibm.rad.ola.test.CUSTOMER();
invoke(cs, is, arg, output);
return output;
}
< ... more generate methods follow ... >
An application wishing to use this class simply needs to new up a CUSTOMER record to be passed as input and received as output and then new up an instance of zCUSTCPY_Out() to make the external call over the WebSphere Optimized Local Adapter resource adapter to the target application.
When installing the application that uses these tools, be sure to install the WebSphere Optimized Local Adapter resource adapter and create a connection factory with the same name that was specified in the prompt for JNDI name (in the example, the JNDI name is eis/ola). Also, the WebSphere Optimized Local Adapter Register name must be provided on the connection factory. When using WebSphere Optimized Local Adapter over OTMA, provide the IMS OTMA server name and group name on the connection factory. For information on the WebSphere Optimized Local Adapter connection factory properties related to the WebSphere Optimized Local Adapter over OTMA support, see Connection factory considerations for optimized local adapters.