[z/OS]

Utilisation des API natives d'adaptateurs locaux optimisés pour appeler une application EJB à partir d'un espace d'adressage externe

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tdat_connectejbapi
Nom du fichier : tdat_connectejbapi.html