Liaison de message de l’écouteur amélioré TCP
Le modèle de liaison de message de l’écouteur amélioré TCP (ELM) permet de passer les données et les paramètres entre le TI et le TP du serveur à l’aide de COMMAREA. Le modèle permet également à un serveur simultané de créer une liaison vers un programme CICS DPL. L’écouteur amélioré a été introduit dans CICS Transaction Server version 1.4 et son architecture augmente l’efficacité de l’environnement TCP/IP CICS en éliminant la séquence TRM et TRM Reply. L’écouteur amélioré accepte un en-tête et demande les données du client dans le flux initial et élimine la nécessité pour l’application serveur de fournir une réponse distincte avant que les données d’application soient mises à disposition. L’écouteur amélioré requiert ce qui suit du client :
Construire et envoyer un flux de données unique composé d’un en-tête de requête suivi des données de requête de l’application au programme d’application serveur
Recevoir un flux de données unique qui se compose d’un en-tête de réponse et de données d’application du programme d’application serveur
La figure suivante résume le workflow qui se produit entre le client, l’écouteur CICS amélioré, le serveur simultané et le programme transactionnel central. Les nombres entre parenthèses indiquent l’ordre approximatif dans lequel les événements se produisent. Une description plus détaillée des événements est illustrée dans la figure.
Diagramme de workflow récapitulatif pour le modèle de programmation de liaison ELM TCP
Le modèle de programmation de liaison ELM TCP fonctionne comme suit :
Une application appelle une méthode dans un composant TI configuré dans les Services de composants ou .NET Framework.
Le runtime TI appelle le proxy TI Automation.
Si l’application est un composant COM+, le proxy TI Automation :
lit dans la bibliothèque de types créée précédemment par le Concepteur TI
mappe les types de données Automation aux types de données COBOL
Si l’application est un assembly .NET Framework, le proxy TI Automation :
lit l’assembly et les métadonnées créés précédemment par le Concepteur TI
mappe les types de données .NET Framework aux types de données COBOL
Ensuite, le proxy TI Automation :
appelle les routines de conversion pour convertir les données d’application en types COBOL centraux
génère la mémoire tampon aplatie de flux de données qui représente la déclaration ou le copybook COBOL.
transmet le message au composant de transport TCP.
Le transport TCP TI envoie une requête de connexion à l’écouteur amélioré à l’aide de l’adresse IP (Internet Protocol) de l’ordinateur central et de l’adresse de port de l’écouteur.
L’écouteur amélioré accepte la requête de connexion et indique au runtime TI d’envoyer l’ELM. L’écouteur amélioré attend ensuite l’ELM.
L’ELM est un enregistrement de données mis en forme qui identifie le TP du serveur à appeler à l’aide de son TRANID. L’écouteur TP est un TP central spécial, dont la fonction principale consiste à recevoir les appels TP de serveur envoyés par les applications clientes exécutant TCP/IP. Le TRANID de l’écouteur amélioré fourni par IBM est défini par l’utilisateur.
Le runtime de TI met en forme l’ELM et l’envoie à l’écouteur amélioré. Le TI contourne ensuite la logique de transport qui attend une réponse ELM et envoie immédiatement les données de requête d’application après l’en-tête de requête. TI attend ensuite la réponse ELM.
L’écouteur amélioré reçoit l’ELM de 35 octets, puis lit le contenu de l’en-tête ELM. L’écouteur amélioré place les 35 octets dans le message d’origine de la transaction (TIM), mais n’agit pas sur son contenu.
Le TIM décrit l’environnement TCP/IP dans lequel le serveur est en cours d’exécution et contient les informations de socket TCP/IP que le serveur simultané utilise pour communiquer avec le transport TCP COMTI et l’en-tête de message client que le serveur simultané utilise pour personnaliser son comportement d’exécution. L’en-tête contient le nom du programme serveur à lier.
L’écouteur amélioré démarre l’exemple d’application serveur TP (Mscmtics.cbl) simultané qui est défini dans la définition de l’écouteur.
Mscmtics.cbl est l’exemple de fichier TP Microsoft utilisé pour passer des données entre TI et le TP serveur à l’aide de la COMMAREA. L’exemple Mscmtics.cbl est développé par Microsoft et fourni dans le cadre du logiciel Host Integration Server. Il se trouve dans le dossier $\Microsoft Host Integration Server\SDK\Samples\Comti\ProgrammingSpecifics\Tcp. Il doit être compilé, lié et installé sur l’ordinateur central avant d’utiliser ce modèle.
Notes
Si l’écouteur amélioré ne parvient pas à démarrer le serveur simultané, l’écouteur met en forme un message d’erreur et le renvoie au transport TCP COMTI. Les raisons pour lesquelles l’écouteur ne peut pas démarrer sont les suivantes :
la connexion rejetée en raison de ressources CICS limitées (par exemple, dépasse le nombre maximal de tâches CICS ou de tâches serveur simultanées)
TRANID non valide ou désactivé pour le serveur simultané
programme de serveur simultané non valide, désactivé ou non disponible associé à l’ID de transaction
Notes
Le message d’erreur de l’écouteur CICS est basé sur des caractères et commence toujours par les lettres EZY. La longueur du message d’erreur est variable et la fin du message est déterminée par la fermeture du socket par l’écouteur CICS.
L’écouteur amélioré appelle l’interface de protocole d’application (API) de socket dans l’environnement hôte. Une fois que l’écouteur amélioré a émis la commande de démarrage pour la transaction de serveur simultanée, l’écouteur amélioré est en dehors de la boucle de traitement de l’application et est libre d’écouter une autre requête entrante.
Le serveur simultané récupère le TIM, connecte le socket et lit le contenu de l’ELM.
TI transmet les données de l’application via la COMMAREA CICS au programme d’application serveur qui contient la logique métier à l’aide d’un appel de liaison EXEC CICS standard. Le runtime TI émet également un arrêt pour le socket d’envoi 1/2, puis attend les données de réponse.
Le TP du serveur reçoit les données d’application, traite la requête et applique la logique métier aux données. Toute la logique métier est définie dans le TP du serveur.
Le serveur simultané envoie l’en-tête de réponse de l’ELM à TI via la COMMAREA.
Le TP du serveur prépare les données de réponse, puis envoie la réponse au client via la COMMAREA.
Le flux de données de réponse de l’application se compose de deux parties. La première est une réponse ELM qui informe le transport de la réussite ou de l’échec de la demande. Le transport TCP utilise la réponse ELM du flux, puis, si la réponse ELM indique que l’appel a réussi, reçoit les données de réponse de l’application jusqu’à ce que le socket soit fermé par le serveur simultané.
Le serveur simultané ferme les sockets
Le proxy TI Automation reçoit les données de réponse et traite la réponse. Le proxy TI Automation :
reçoit le message du composant de transport TCP,
lit le message dans la mémoire tampon.
Si l’application est un composant COM+, le proxy TI Automation :
mappe les types de données COBOL aux données Automation,
Appelle les routines de conversion pour convertir les types COBOL centraux en données d’application.
Si l’application est un assembly .NET, le proxy TI Automation :
Mappe les types de données COBOL aux types de données .NET Framework.
appelle les routines de conversion pour convertir les types COBOL mainframe en données d’application.
Le runtime TI renvoie les données converties à l’application COM ou .NET Framework qui a appelé la méthode.
Pour implémenter ce modèle, vous devez fournir à TI une adresse IP, un numéro de port et un nom de programme CICS pour exécuter l’application transmise par le programme de serveur simultané (Mscmtics.cbl).
Host Integration Server inclut un exemple de code montrant comment implémenter le modèle de programmation TCP ELM Link. L’exemple de code se trouve dans \répertoire d’installation\SDK\Samples\AppInt. Démarrez Microsoft Visual Studio, ouvrez le didacticiel de votre choix et suivez les instructions du fichier Lisez-moi.
Voir aussi
Composants de l’intégrateur de transactions
Messages de requête de transaction
Conversion de types de données d’Automation en z/OS COBOL]
Conversion de types de données de z/OS COBOL vers Automation
Composants CICS
Runtime TI
Choisir le modèle de programmation approprié
Modèles de programmation