Utilisez cette tâche quand vous voulez utiliser les API natives
d'adaptateurs locaux optimisés pour connecter un espace d'adressage externe à une application WebSphere
Server for z/OS et appeler une application EJB (Enterprise JavaBeans)
déployée sur le serveur d'applications.
Avant de commencer
Le groupe de démons de
WebSphere
Application Server doit être activé
sur l'image z/OS d'où provient la demande d'enregistrement.
Dans CICS)
(Customer Information Control System), le programme TRUE associé à la tâche des adaptateurs locaux optimisés doit être activé avant d'établir
une connexion entre CICS et WebSphere
Application Server.
Pour avoir des informations sur la manière dont le programme TRUE est activé
par les transactions, voir la rubrique Installation des transactions BBOC, BBO$ et
BBO# sur l'environnement client et la rubrique Transactions BBOC, BBO$, BBO#
de WebSphere
Application Server. Pour les programmes qui s'exécutent
dans un traitement par lots z/OS et USS (UNIX Systems Services), l'activation du programme TRUE
n'est pas requise. Assurez-vous que l'espace d'adressage actuel a déjà été enregistré
et lié au groupe de démons WebSphere
Application Server cible
avec un appel à l'API Register BBOA1REG.
Pourquoi et quand exécuter cette tâche
Les API d'adaptateurs appellent un bean session sans état à partir d'un programme externe en langage natif et extraient une réponse. Cela a été conçu
pour les utilisateurs qui veulent plus de flexibilité et pour qui
la longueur maximum de zone de réponse n'est pas connue à l'avance.
Procédure
- L'application en langage natif de l'espace d'adressage client, par exemple en Cobol, PL/I, C/C++ ou langage assembleur, appelle l'API Get Connection
BBOA1CNG et passe le nom enregistré utilisé pour l'appel Register. Un descripteur de connexion est renvoyé. Il doit être utilisé pour tous les futurs appels
d'API.
- L'application client collecte tous les paramètres et désigne
le service cible en tant que nom de chemin de l'interface de base JNDI (Java Naming
and Directory Interface) pour le bean enterprise qu'elle veut appeler
et appelle l'API Send Request BBOA1SRQ. Le résultat est une connexion à la région de contrôle WebSphere
Application Server,
puis à une région serviteur dérivée de Workload Manager (WLM)
où l'interface de base JNDI passée exécute sa méthode create. La méthode prédéfinie, execute, est localisée et appelée avec les paramètres
du tableau d'octets.
Le contrôle est renvoyée immédiatement au programme appelant si le
paramètre asynchrone est spécifié et défini sur 1. Si le
paramètre asynchrone est défini sur 0 (zéro), l'API renvoie
la longueur de la réponse dans le paramètre ResponseLength ainsi que
la valeur de retour.
- Dans le serviteur WebSphere
Application Server, la méthode execute
du bean cible appelle une logique métier. La
méthode execute d'un bean cible peut maintenant appeler la logique métier
requise avant de renvoyer les données de réponse sous la forme d'un tableau d'octets
sérialisé au programme appelant en langage natif.
- Un code retour et un code motif 0 (zéro) indiquent que l'instruction
Send_Request de l'API client a été mise en file d'attente avec succès. Quand le paramètre
asynchrone est défini sur 0 (zéro), la longueur de la réponse
est fournie dans le paramètre ResponseLength ainsi que la valeur de retour. Quand
le paramètre asynchrone est défini sur 1, la réponse peut ne pas
être prête et un appel à l'API Receive_RespLen BBOA1RCL est requis
pour déterminer la longueur de la réponse et si la réponse est arrivée.
- Pour les appels asynchrones Send_Request, l'application client
appelle l'API Receive_RespLen BBOA1RCL avec un appel asynchrone
0 où 1. L'appel asynchrone 0 (zéro) indique que l'API
d'adaptateur doit bloquer l'unité d'exécution jusqu'à réception d'une réponse. L'appel
asynchrone 1 indique que l'API d'adaptateur indique immédiatement en retour
si une réponse est arrivée ou non.
- Un code retour et un code motif 0 (zéro) indiquent que l'instruction
Receive_RespLen de l'API client s'est terminée avec succès. Quand le
paramètre asynchrone est défini sur 1, un ResponseLength et
une valeur de retour de tous les 0xFF indiquent qu'il n'y a pas encore de réponse
reçue à la connexion passée. Cela fournit à l'application client
plus de contrôle sur la manière d'envoyer des demandes et de recevoir des réponses.
Le client peut grouper les requêtes d'envoi et les expédier sous la forme de séquence
via un groupe de connexions, puis interroger régulièrement ces connexions
dans l'attente des réponses. Une connexion en train de traiter une instruction Send_Request avec
un appel asynchrone 1 ne peut pas recevoir une autre instruction Send_Request pour
la même connexion jusqu'à ce que les appels des API Receive_RespLen et Get_Data associés
soient traités.
Important : L'utilisation de ces API
de manière asynchrone avec le paramètre asynchrone défini sur 1,
le regroupement des requêtes et le traitement simultané ne peuvent être effectués
que sur des connexions qui sont configurées comme non transactionnelles. Par exemple,
quand on utilise CICS pour aligner une unité de travail avec une unité
de récupération RRS et qu'un point de synchronisation sous CICS doit être propagé
au serveur WebSphere
Application Server, il ne peut y avoir qu'une seule connexion
à un serveur WebSphere spécifique dans la tâche CICS actuelle. Cette requête
reçoit un code retour d'avertissement qui indique que l'adaptateur ne propage pas
la validation via plus d'une connexion au même
serveur dans la même tâche CICS.
- Les applications client utilisent la longueur de réponse renvoyée
par l'API Receive_RespLen pour s'assurer qu'elle a une zone suffisamment grande pour contenir
les données de réponse et qu'elle utilise l'appel d'API Get Data BBOA1GET pour copier
les données de la réponse dans sa mémoire tampon.
- Les applications client répètent cette manoeuvre en utilisant le même
descripteur de connexion jusqu'à ce qu'il soit prêt pour libérer la connexion. Quand la connexion
est libérée, l'API Connection_Release BBOA1CNR est appelée. Les descripteurs de connexion
doivent être libérés avant d'être retenus sur un appel d'API Connection
Get et utilisés à nouveau.
Résultats
Le client appelle un bean de session sans état à partir de
WebSphere
Application Server
en utilisant les API des adaptateurs locaux optimisés.