Voici les manières dont vous pouvez appeler des applications sortantes dans WebSphere Application Server avec WebSphere Optimized Local Adapters.
Les API receive request (BBOA1RCV) et host service (BBOA1SRV) WOLA permettent de rendre n'importe quelle application disponible pour les applications Java s'exécutant dans WebSphere Application Server, qui peuvent alors l'appeler avec des méthodes de style JCA. Pour plus d'informations sur l'utilisation de ces API, voir API des adaptateurs locaux optimisés pour z/OS.
Les applications s'exécutant sous z/OS dans CICS, IMS, USS ou en batch peuvent toutes utiliser les API WOLA pour s'établir comme serveurs WOLA et accepter les demandes de WebSphere Application Server.
Le serveur de liaison WOLA est une application qui peut être lancée dans une région CICS et fonctionne comme serveur ou comme proxy pour les appels aux programmes CICS existants. Dans ce cas, l'application WebSphere Application Server appelle les programmes CICS non modifiés existants via une liaison EXEC CICS LINK avec soit une zone de communication (COMMAREA), soit un canal et un conteneur pour transmettre les données et obtenir la réponse.
Le mécanisme par défaut utilisé par WOLA pour transmettre un message à un programme CICS est la zone COMMAREA. Vous pouvez spécifier qu'un conteneur CICS délivre le message de demande et qu'un autre soit utilisé pour la réponse, à l'aide des propriétés de fabrique de connexions. Pour un conteneur de demande/réponse unique, vous définissez l'enregistrement de demande comme IndexedRecord contenant une seule entrée. Vous pouvez également spécifier que WOLA délivre plusieurs messages dans plusieurs conteneurs pour le nom de canal que vous fournissez, en utilisant des méthodes setter ou en indiquant que vous le demandez dans la fabrique de connexions. Pour des enregistrements multiples, vous fournissez un MappedRecord à WOLA pour l'appel sortant à CICS. Pour plus d'informations sur la prise en charge des canaux et des conteneurs CICS dans WOLA, voir Transactions WebSphere Application Server BBOC, BBO$, BBO#.
Pour générer une implémentation prenant en charge des conteneurs CICS :
La troisième manière dont des appels sortants peuvent être effectués via WOLA est pour l'appel de transactions IMS existantes. Pour cela, WOLA utilise l'interface appelable OTMA IMS. Une méthode setter dans la spécification de connexion et la fabrique de connexions WOLA indique qu'OTMA est utilisé. Les applications WebSphere Application Server doivent sélectionner un nom de serveur et un ID de groupe OTMA et elles doivent mettre leurs messages sous forme de messages IMS puis appeler l'adaptateur de ressources WOLA en sélectionnant OTMA comme protocole sous-jacent.
Les données de message de demande IMS pour WOLA via OTMA doivent être mises sous la forme IMS standard suivante : LLZZ ou LLLLZZ plus l'ID de transaction IMS (8 caractères) plus les données de message IMS.
Les données de message de réponse IMS de l'appel WOLA via OTMA peuvent être renvoyées sous la forme LLZZ plus les données de réponse ou LLLLZZ plus les données de réponse. Il vous est recommandé de passer en revue les options de configuration de WOLA via OTMA pour indiquer que vous utiliserez la forme LLZZ ou la forme LLLLZZ, et la prise en charge WOLA des messages de demande et de réponse ; ces paramètres peuvent être définis avec des méthodes setter dans la spécification de connexion ou avec des propriétés dans la fabrique de connexions.
Lorsque vous utilisez l'Importateur de données du plan de travail, inspectez le copybook COBOL ou la structure PL/I, voyez le format utilisé pour les messages de demande IMS (LLZZ ou LLLLZZ) et sélectionnez l'indicateur associé dans la fabrique de connexions WOLA (ou utilisez la méthode setter appropriée) qui correspond à ce format. Pour des détails sur les formats de message, voir Appel de transactions IMS existantes avec les adaptateurs locaux optimisés via OTMA. Pour des détails sur WOLA via OTMA, voir (Facultatif) Utiliser l'environnement IMS.
WOLA prend également en charge les transactions globales à validation en deux phases dans les deux sens entre WebSphere Application Server et CICS, et WebSphere Application Server et IMS. Pour plus d'informations sur WOLA et les transactions globales, voir Appel d'un bean enterprise depuis un espace d'adresses externe dans une transaction démarrée par un client.
Pour des informations sur WebSphere Application Server et les transactions globales IMS, voir Appel de transactions IMS existantes avec les adaptateurs locaux optimisés via OTMA.
Avec le mode distant, vous pouvez utiliser le plan de travail et WebSphere Application Server, et déployer ou redéployer votre application sans avoir à effectuer de modifications dans le serveur WebSphere Application Server z/OS où s'exécute le proxy WOLA. Le recours à cette méthode peut être nécessaire pour le développement et le test de mises à jour d'application. Pour plus d'informations sur l'utilisation de WOLA en mode développement ou distant, voir Déploiement des adaptateurs locaux optimisés en mode développement
Voici un exemple d'implementation d'appel externe WOLA générée, créé avec le nom zCUSTCPY_Out. Il a été configuré pour utiliser le nom JNDI eis/ola et le nom de service cible ZCUSTGET. Ce code a été généré pour inclure une classe auxiliaire de liaison de données créée à partir d'un copybook COBOL avec une définition de niveau 01 nommée 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;
}
< ... d'autres méthodes de génération suivent... >
Pour utiliser cette classe, une application doit simplement créer un enregistrement CUSTOMER à transmettre en entrée et recevoir en sortie, puis créer une instance de zCUSTCPY_Out() pour effectuer l'appel externe via l'adaptateur de ressources WOLA à l'application cible.
Lors de l'installion de l'application utilisant ces outils, veillez à installer l'adaptateur de ressources WOLA et à créer une fabrique de connexions ayant le nom spécifié pour le nom JNDI (dans l'exemple, le nom JNDI est eis/ola). Vous devez également fournir le nom du registre WOLA dans la fabrique de connexions. Si vous utilisez WOLA via OTMA, fournissez le nom de serveur et le nom de groupe OTMA IMS dans la fabrique de connexions. Pour des informations sur les propriétés de fabrique de connexions WOLA liées au support WOLA via OTMA, voir Considérations sur la fabrique de connexions pour les adaptateurs locaux optimisés.