Modèle de traitement de connexions socket persistantes partageables

Les connexions socket persistantes partageables peuvent être utilisées pour les interactions en mode de validation 1 et 0. Les scénarios suivants décrivent l'interaction SYNC_SEND_RECEIVE sur une connexion socket persistante partageable lors d'un traitement normal, d'une erreur de traitement et du délai d'attente d'exécution.

Scénario de traitement normal

IMS TM Resource Adapter, avec le serveur d'applications, obtient une connexion disponible à partir du pool de connexions ou crée une nouvelle connexion. IMS TM Resource Adapter, génère alors, dans le cadre de l'initialisation d'une nouvelle connexion, un ID client pour la connexion. Cet ID client généré identifie la connexion socket et, dans le cas d'interactions en mode de validation 0, le tpipe et la file d'attente de stockage temporaire asynchrone OTMA.

IMS TM Resource Adapter garantit qu'un socket est associé à la connexion et envoie la requête avec les données d'entrée à IMS Connect. IMS Connect envoie alors le message à IMS où IMS exécute la transaction et renvoie le message de sortie.

Pour les interactions en mode de validation 0, IMS TM Resource Adapter envoie dès réception du message de sortie un message d'accusé de réception à IMS indiquant à IMS d'éliminer le message de sortie de la file d'attente IMS. Lorsque l'application client ferme la connexion ou se termine, la connexion est renvoyée au pool de connexions pour être réutilisée par les interactions en mode de validation 0 ou 1.

Scénario d'erreur de traitement

Toutes les erreurs entraînent une exception relative aux ressources qui est émise à l'application client. Par ailleurs, certaines erreurs entraînent la déconnexion de la connexion socket par IMS Connect. Pour les interactions en mode de validation 0, une exception signifie que le message de sortie ne peut pas être distribué à l'application client. Cependant, les messages de sortie non distribués des exceptions suivantes concernant les interactions de validation en mode 0 sur des connexions socket persistantes partageables peuvent être extraits si l'interaction SYNC_SEND_RECEIVE spécifie que les messages de sortie non distribués doivent être redirigés vers une destination donnée. Pour qu'un message de sortie non distribué soit redirigé vers une destination donnée, les propriétés supplémentaires suivantes doivent être définies dans l'objet IMSInteractionSpec passé à l'interaction SYNC_SEND_RECEIVE :
  • Définissez la propriété purgeAsyncOutput à false afin que les messages de sortie non livrés ne soient pas purgés.
  • Définissez la propriété reRoute à true et spécifiez une destination de redirection dans la propriété RouteName.

Pour extraire un message de sortie non livré d'une destination de redirection, une application client séparée émet une interaction SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT ou SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT sur une connexion socket persistante dédiée. L'application client fournit la destination de réacheminement comme ID client de l'interaction.

Autre solution, pour récupérer un message de sortie non livré d'une destination de redirection, une application client séparée peut émettre une interaction SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT ou SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT sur une connexion socket persistante partageable en spécifiant l'ID client alternatif. En utilisant cet ID alternatif, l'application client peut extraire les messages de sortie asynchrones non livrés de n'importe quel tpipe.

La valeur par défaut de la propriété purgeAsyncOutput est true. Lorsque la propriété purgeAsyncOutput a cette valeur, les messages de sortie suivants sont purgés :
  • Messages de sortie non livré inséré dans le bloc de communication d'entrée-sortie par le programme d'application IMS principal.
  • Messages de sortie insérés dans le bloc de communication d'entrée-sortie par les programmes d'application IMS secondaires appelés par des basculements de programme à programme
Lorsque la propriété purgeAsyncOutput est définie à false, la destination de réacheminement doit être spécifiée.

Scénario d'expiration du délai d'attente d'exécution

Si un délai d'attente d'exécution est dépassé, la connexion socket reste ouverte mais le message de sortie n'est pas transmis à l'application client. Suite à une exception relative au délai d'attente d'exécution, il existe cependant deux possibilités d'extraire les messages de sortie non distribués pour les interactions de validation en mode 0 sur les connexions socket persistantes partageables :
  • L'application client ayant exécuté l'interaction SYNC_SEND_RECEIVE peut exécuter l'interaction SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT ou SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT.
  • Le message de sortie non transmis peut être redirigé vers une destination spécifique comme décrit dans le scénario de traitement des erreurs.

Lorsque l'application client ferme la connexion ou se termine, la connexion est renvoyée au pool de connexions pour être réutilisée par d'autres interactions en mode de validation 0 ou 1.


Vos commentaires