[z/OS]

Demande de travail à distance WOLA (WebSphere Optimized Local Adapter) sur une cible Enterprise Java Bean

Cette fonction permet à une application client telle que batch, CICS, etc. de contacter une instance de serveur WebSphere Application Server hébergeant une application dont les résultats et l'exécution de logique métier sont requis par le client. L'appel distant est effectué à l'aide des API BBOA1INV/BBGA1INV et BBOA1SRQ/BBGA1SRQ et d'une application proxy (RemoteEJBProxy), qui est livrée avec WebSphere Application Server for z/OS.

Avant d'installer cette fonction, consultez les exigences et les paramètres de configuration :
  1. Fédérez l'espace de noms de l'instance de WebSphere Application Server sur le serveur z/OS WebSphere Application Server local pour permettre au serveur local de rechercher l'application sur le serveur distant. L'application distante doit être un bean Enterprise Java™ sans étant implémentant une méthode appelée execute(), qui accepte un tableau d'octets en entrée et qui renvoie un tableau d'octets en sortie, comme défini par l'interface com.ibm.websphere.ola.Execute. Elle doit également spécifier le nom com.ibm.websphere.ola.ExecuteHome pour l'interface home EJB et com.ibm.websphere.ola.Execute pour l'interface distante lors de l'utilisation des spécifications EJB version 2.1 ou antérieure, ou doit définir l'annotation @RemoteHome spécifiant com.ibm.websphere.ola.ExecuteHome lors de l'utilisation de la spécification EJB 3.0. Ces interfaces sont disponibles lors de l'exécution dans WebSphere Application Server for z/OS et dans WebSphere Application Server pour les plateformes réparties. Pour les opérations de développement d'application distante, les interfaces mentionnées sont livrées avec WebSphere Application Server for z/OS dans le cadre de l'outil d'assemblage ola_apis.jar. N'intégrez pas ces interfaces dans votre fichier EAR d'application.
  2. Installez le fichier EAR de proxy d'adaptateur local optimisé (ola_proxy.ear) qui contient l'application RemoteEJBProxy sur l'instance de serveur z/OS WebSphere Application Server locale. Le fichier EAR se trouve dans le répertoire $(WAS_INSTALL_ROOT)/installableApps du système de fichiers de WebSphere Application Server for z/OS.

    L'application remoteEJBProxy est associée par défaut au nom JNDI : ejb/com/ibm/ws390/ola/jca/RemoteEJBProxyHome. Si, pour une raison quelle qu'elle soit, la valeur par défaut doit être modifiée, le nom JNDI de la ressource cible de l'application proxy peut être personnalisé via la page de la console d'administration sous Applications > ola_proxy > Nom JNDI d'EJB > Nom JNDI pour toutes les interfaces. Si le nom JNDI est mis à jour, le module d'exécution WebSphere doit être informé de la modification via la définition de la variable d'environnement ola_remote_ejb_proxy_jndiname, comme mentionné dans la rubrique Variables d'environnement des adaptateurs locaux optimisés.

    Il est à noter que la modification du nom JNDI par défaut de l'application remoteEJBProxy est une étape facultative. Elle n'est pas obligatoire, sauf si elle doit être modifiée.

  3. Redémarrez les serveurs.

Les procédures d'appel des API Invoke (BBOA1INV/BBGA1INV) et send request (BBOA1SRQ/BBGA1SRQ) sont identiques à celles des appels locaux, à ceci près que le paramètre de type de demande d'appel (requesttype) doit avoir pour valeur 2, comme indiqué dans la rubrique Adaptateurs locaux optimisés pour les API z/OS.

Le nom de service (nom JNDI) spécifié lors des appels d'API invoke ou send request doit correspondre au nom que le serveur WebSphere Application Server for z/OS local utilise pour rechercher l'application distante à l'aide de l'espace de nom JNDI fédéré du serveur distant. Par exemple, si l'espace de nom du serveur distant a été fédéré dans l'emplacement remote/server5 et que l'application est installée à l'aide du nom JNDI ejb/myRemoteApp sur le serveur distant, le nom de service spécifié sur l'API invoke ou sur l'API send request correspond à remote/server5/ejb/myRemoteApp.

Cette fonction permet également d'appeler l'application distante dans le cadre d'une transaction globale déclenchée par le client. Lors de l'utilisation d'un client CICS dans le cadre d'une transaction globale, le résultat peut être un ABEND ASP3 lorsque CICS détecte que la transaction a été annulée une fois qu'elle a émis une commande permettant de valider la transaction globale. Il s'agit d'un cas prévu, étant donné le traitement par CICS de ce type de scénario. L'annulation est également un comportement attendu dans les cas où une condition d'erreur se produit lors du traitement de l'appel EJB, de sorte que le résultat de la transaction globale ne peut pas être autre que l'annulation.


Icône indiquant le type de rubrique Rubrique de référence



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=cdat_ola_remotequest
Nom du fichier : cdat_ola_remotequest.html