Mode de validation et traitement du niveau de synchronisation

Le mode de validation correspond au type de traitement de validation effectué par IMS.

Le mode de validation correspond au type de traitement de validation effectué par IMS. Le client Java définit le protocole du mode de validation à utiliser lorsqu'il soumet une requête de transaction à IMS. IMS Connect et IMS prennent en charge deux types de traitement de mode de validation : le mode de validation 0 (valider-envoyer) où IMS valide les changements apportés à la base de données d'IMS puis envoie le message de sortie au client, et le mode de validation 1 (envoyer-valider) où IMS envoie le message de sortie au client puis valide les changements apportés à la base de données.

Associés aux protocoles des modes de validation, IMS Connect et IMS prennent aussi en charge trois niveaux de synchronisation (niveaux de synch.) : NONE, CONFIRM et SYNCPT. Ces trois niveaux peuvent être utilisés avec le mode de validation 1. En revanche, seul le niveau CONFIRM peut être utilisé avec le mode de validation 0.

Alors qu'IMS Connector for Java fournit automatiquement le niveau de synchronisation lorsqu'il communique avec IMS Connect, le niveau de synchronisation doit être explicitement défini par le client Java en appliquant la méthode setSyncLevel(int) à NONE ou CONFIRM. Actuellement, le clientJava ne peut pas explicitement définir le niveau de synchronisation sur SYNCPT. Pour les interactions en mode de validation 1, le niveau de synchronisation par défaut est NONE. Cela permettra seulement de définir l'instruction d'interaction sur SYNC_SEND_RECEIVE sans définition de niveau de synchronisation. Pour les interactions en mode de validation 0, le niveau de synchronisation par défaut est CONFIRM. Cela permettra seulement de définir l'instruction d'interaction sur Verb to SYNC_SEND_RECEIVE et le mode de validation sur 0 sans définition de niveau de synchronisation. Si une valeur autre que 0 ou 1 est transmise à la méthode setSyncLevel(int), une erreur est émise.

IMS Connector for Java prend en charge les combinaisons suivantes :

Si le client Java soumet une requête de transaction avec le mode de validation 1 et le niveau de synchronisation CONFIRM, IMS Connector for Java transmet la requête via IMS Connect à IMS. IMS traite alors cette transaction et tente d'envoyer le message de sortie au client Java via IMS Connector for Java. IMS Connector for Java envoie un accusé de réception positif au nom du client Java à IMS. IMS enverra un code retour à IMS Connector for Java indiquant si les changements ont été validés ou non. Si c'est le cas, IMS Connector for Java enverra la sortie au client Java. Dans le cas contraire, le client Java recevra une exception. Si une erreur se produit lors de ce processus, le client Java recevra une exception.

Le type d'exception envoyé détermine également si le message de sortie est disponible ou n'est pas disponible pour récupération. Par exemple, si le client Java reçoit l'exception IMSDFSMessageException indiquant que la transaction n'est plus en cours, l'application n'a pas été exécutée. Par conséquent, il n'y a aucun message de sortie à récupérer. Cependant, si la transaction est exécutée mais que la valeur executionTimeout expire avant que le message de sortie ne soit renvoyé à IMS Connect, le client Java recevra une exception EISSystemException indiquant qu'un délai d'attente d'exécution a eu lieu. Dans ce cas, le message de sortie sera mis en file d'attente dans la file d'attente de sortie asynchrone OTMA d'IMS ou dans le TPIPE approprié pour une récupération ultérieure.

Remarque : dans la terminologie IMS/OTMA, un canal de transaction (TPIPE) est une connexion logique entre un client (IMS Connect) et le serveur (IMS/OTMA). Pour les interactions en mode de validation 0, le TPIPE est identifié par l'ID client utilisé pour l'interaction concernée. Chaque ID client utilisé pour une transaction en mode de validation 0 possède son propre TPIPE. Pour les interactions en mode de validation 1, le TPIPE est identifié par le numéro de port IMS Connect utilisé pour l'interaction. Par conséquent, chaque port possède un TPIPE qui sera utilisé pour tous les clients exécutant des interactions en mode de validation 1 sur ce port.

Quel que soit le mode de validation utilisé par votre client Java lorsqu'il exécute une transaction IMS, le client Java définit une valeur pour la propriété interactionVerb d'IMSInteractionSpec. Si une interaction en mode de validation 0 est définie, il est possible que le client Java doive fournir une valeur pour la propriété ID client d'IMSConnectionSpec. Cette propriété est une propriété d'IMSConnectionSpec qui identifie le TPIPE ou la file d'attente de sortie asynchrone OTMA d'IMS où sont placés les messages de sortie récupérables. C'est le type de connexion socket que le client Java utilise qui détermine si le client Java fournit ou non un ID client pour une interaction en mode de validation 0.

Pour extraire les messages de sortie d'un TPIPE, le client Java soumet une requête dans laquelle il définit l'une des valeurs SYNC_RECEIVE_ASYNCOUTPUT, SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT ou SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT pour la propriété interactionVerb d'IMSInteractionSpec et une valeur pour la propriété ID client. Pour plus d'informations sur la prise en charge de messages de sortie asynchrones, voir le Chapitre 9 : Protocoles dans Guide et références IMS Connect.

Vous pouvez en général utiliser les interactions SYNC_RECEIVE_ASYNCOUTPUT, SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT ou SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT pour récupérer les messages de sortie mis en file d'attente pour un ID client, quelle que soit la manière dont ils ont été mis en file d'attente pour l'ID client, en tant que résultat de l'échec d'une transaction en mode de validation 0 ou d'une application IMS ayant effectuée une insertion dans un PCB alternatif (Alternate Program Communication Block). Dans le cas de la récupération d'un message de sortie issu de l'échec d'une transaction en mode de validation 0, l'ID client fourni dans IMSConnectionSpec pour une requête de récupération doit correspondre à l'ID client qui a été défini sur la transaction ayant échoué.

Si la file d'attente de sortie asynchrone OTMA ne comporte aucun élément pour cet ID client, vous recevrez une exception concernant le délai d'attente d'exécution. Cette exception signifie que la file d'attente ne contient aucun message ou que le délai d'attente défini était trop court pour qu'IMS Connect puisse récupérer le message dans la file d'attente. Pour les interactions SYNC_RECEIVE_ASYNCOUTPUT, SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT ou SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT ainsi que SYNC_SEND_RECEIVE, le délai d'attente d'exécution correspond à la durée pendant laquelle IMS Connect attend une réponse d'IMS. Si vous ne définissez pas de valeur pour ce délai d'attente pour une requête de récupération, la valeur par défaut sera utilisée. Cette valeur est la valeur TIMEOUT du membre de configuration d'IMS Connect. Il peut s'avérer nécessaire que l'utilisateur fasse un essai avec cette valeur afin de s'assurer que les messages de sortie sont bien renvoyés, quel que soit le type d'interaction.

Traitement des modes de validation et connexions socket

Toutes les connexions socket créées par l'adaptateur de ressources du gestionnaire de transactions IMS sont persistantes. En d'autres termes, la connexion socket entre IMS Connector for Java et IMS Connect peut être réutilisée à plusieurs reprises pour plusieurs interactions avec IMS Connect. Elle ne sera pas fermée entre les interactions puis rouverte. Il existe deux types de connexions persistantes : les connexions partageables et les connexions dédiées.

Connexion socket persistante partageable

Une connexion socket persistante partageable est une connexion qui peut être partagée (réutilisée à plusieurs reprises) par plusieurs applications exécutant des interactions en mode de validation 0 ou 1. Pour une application exécutant l'interaction en mode de validation 0 sur un socket persistant partageable, l'adaptateur de ressources IMS génère automatiquement un ID client avec le préfixe "HWS". Cet ID client représente et identifie la connexion socket ainsi que le TPIPE OTMA associé. Pour ce type de connexion socket, seul les ID client générés par l'adaptateur de ressources IMS TM sont autorisés. Un ID client défini par l'utilisateur n'est pas autorisé pour la prise en charge des connexions socket persistantes partageables.

Remarque : Cet ID client ne doit pas être confondu avec l'ID client alternatif, propriété de l'objet IMSInteractionSpec qui sert à extraire les messages de sortie asynchrones de n'importe quelle file d'attente de stockage temporaire OTMA (TPIPE).
Remarque : Les programmes d'application IMS qui intègrent les messages dans un PCB alternatif ne doivent pas utiliser les noms commençant par "HWS" pour les PCB alternatifs.

Les messages de sortie ne pouvant pas être transmis à un client Java qui exécute une interaction en mode de validation 0 sur une connexion socket persistante partageable peut être mis en file d'attente pour être récupéré ultérieurement. Par ailleurs, les interactions en mode de validation 0 ou 1 sur une connexion socket persistante partageable générant un basculement de type programme à programme qui appelle une autre interaction en mode de validation 0 entraînant un message de sortie secondaire, peuvent à nouveau être mises en file d'attente pour une récupération ultérieure. Les interactions SYNC_RECEIVE_ASYNCOUTPUT, SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT et SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT sont prises en charge sur les connexions persistantes partageables. Si l'ID client alternatif n'est pas utilisé, pour récupérer les messages de sortie mis en attente dans la file de stockage temporaire asynchrone OTMA d'IMS ou TPIPE, les instructions d'interaction doivent être appelées a u sein de la même application client car c'est le même ID client généré qui identifie la connexion socket partageable et le TPIPE OTMA associé qui doit être utilisé.

Les messages de sortie non distribués peuvent être traités de plusieurs façons sur une connexion socket persistante partageable. Ils peuvent être extraits en spécifiant, comme ID client alternatif de l'objet IMSInteractionSpec, le nom de la file de stockage temporaire OTMA dans laquelle les messages de sortie asynchrones sont mis en attente. L'autre solution consiste à les purger. Pour cela, vous devez vérifier que la propriété purgeAsyncOutput d'IMSInteractionSpec est définie sur TRUE. Cette propriété d'entrée détermine si IMS Connect purge le message de sortie non distribué du PCB d'entrée-sortie. La propriété purgeAsyncOutput est uniquement valide avec l'instruction d'interaction SYNC_SEND_RECEIVE. Si elle n'est pas définie sur SYNC_SEND_RECEIVE, la valeur par défaut est TRUE.

Vous pouvez les rediriger en définissant la propriété reRoute d' IMSInteractionSpec sur TRUE. Cette propriété est uniquement valide avec l'instruction d'interaction SYNC_SEND_RECEIVE. Si la propriété reRoute est définie sur TRUE, le message de sortie non distribué est mis en file d'attente vers une destination donnée fournie par l'application client et définie sur la propriété reRouteName d'IMSInteractionSpec. Si la propriété reRoute est définie sur TRUE et qu'aucune propriété reRouteName n'est fournie, la valeur de cette propriété reRouteName est alors la valeur définie dans le fichier de configuration d'IMS Connect. Si aucune valeur n'est définie dans le fichier de configuration d'IMS Connect, la valeur par défaut utilisée est HWS$DEF.

Les connexions socket persistantes partageables sont créées par une fabrique de connexions IMS avec des valeurs requises pour les propriétés personnalisées suivantes :
  • Nom d'hôte = nom d'hôte TCP/IP de la machine sur laquelle IMS Connect est exécuté
  • Numéro de port = numéro de port associé
  • Nom du magasin de données = nom de la cible IMS
  • CM0Dedicated = FALSE
FALSE est la valeur par défaut de la propriété CM0Dedicated garantissant que la fabrique de connexions va créer des connexions socket persistantes partageables.

Connexion socket persistante dédiée

Une connexion socket persistante dédiée est utilisée pour les applications Java exécutant des interactions en mode de validation 0 uniquement. Elle peut être partagée (réutilisée à multiples reprise) par plusieurs applications avec le même ID client défini par l'utilisateur. Pour ce type de connexion socket, seules les interactions avec un ID client défini par l'utilisateur sont autorisées. Pour être valide, un ID client défini par l'utilisateur doit avoir la forme suivante :
  • Une chaîne de 8 caractères maximum, alphanumériques (A-Z, 0-9) ou spéciaux (@,#,$).
  • Ne pas commencer par la chaîne de caractères "HWS".
  • Ne pas être un numéro de port d'IMS Connect.
  • Ne pas contenir de lettres minuscules, elles seront modifiées en majuscules

Une connexion socket persistante dédiée signifie que la connexion socket est attribuée à un ID client spécifique et qu'elle restera dédiée à cet ID client pendant toute la connexion. Les interactions SYNC_RECEIVE_ASYNCOUTPUT, SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT et SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT sont prises en charge sur les connexions persistantes dédiées.

Les interactions SYNC_RECEIVE_ASYNCOUTPUT, SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT et SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT sur les connexions socket persistantes dédiées permettent aux applications client de récupérer les messages placés dans une file d'attente de sortie asynchrone OTMA d'IMS en tant que résultat de l'échec d'une transaction en mode de validation 0, à partir d'une application IMS ayant effectuée une insertion dans un PCB alternatif (Alternate Program Communication Block), ou à partir de la redirection du message de sortie d'une transaction ayant été exécutée sur une fabrique de connexions partageables. Pour récupérer les messages, l'application client doit fournir l'ID client, qui représente le TPIPE où sont mis en attente des messages de sortie asynchrones. Les interactions sur les connexions persistantes dédiées comportant des messages de sortie non distribués ne peuvent pas être redirigées ou purgées.

Les connexions socket persistantes dédiées sont créées par une fabrique de connexions IMS avec certaines valeurs pour les propriétés personnalisées suivantes au moins :
  • Nom d'hôte = nom d'hôte TCP/IP de la machine sur laquelle IMS Connect est exécuté
  • Numéro de port = numéro de port associé
  • Nom du magasin de données = nom de la cible IMS
  • CM0Dedicated = TRUE

La valeur TRUE pour la propriété CM0Dedicated garantit que la fabrique de connexions va créer des connexions socket persistantes dédiées.

Remarque : si vous disposez de plusieurs fabriques de connexions configurées pour créer des sockets persistantes dédiées pour la même instance d'IMS Connect, une seule fabrique de connexions peut dédier un socket à un ID client donné à la fois. Par exemple, si la première fabrique de connexions crée une connexion socket dédiée pour l'ID client, CLIENT01 ; la deuxième fabrique reçoit l'exception suivante si elle tente de créer une connexion socket dédiée pour CLIENT01 alors que la connexion socket créée la première fabrique de connexions est toujours connectée à IMS Connect :
javax.resource.spi.EISSystemException: ICO0001E:
com.ibm.connector2.ims.ico.IMSTCPIPManagedConnection@23766050.processOutputOTMAMsg
(byte [], InteractionSpec,Record) error. IMS Connect returned error: RETCODE=[8], 
REASONCODE=[DUPECLNT]. 
Duplicate client ID was used;  the client ID is currently in use. 

Mise en oeuvre de connexions persistantes

Une connexion TCP/IP entre IMS Connector for Java et IMS Connect est persistante ; en d'autres termes, elle reste ouverte tant qu'IMS Connector for Java ou IMS Connect ne la déconnecte pas en raison d'une erreur. Ceci concerne aussi bien les connexions socket persistantes partageables que les connexions socket persistantes dédiées. Cependant, dans le cas d'une connexion socket persistante dédiée, la connexion peut uniquement être utilisée par les interactions dont l'ID client est celui qui a été utilisé pour établir la connexion. Le nombre de connexions socket augmente à mesure que de nouveaux ID client sont utilisés pour les interactions sur les connexions socket persistantes dédiées.

Si la propriété correspondant au nombre maximum de connexions (MaxConnections) est définie sur une valeur non nulle ainsi que la propriété correspondant au délai d'attente de connexion, l'application reçoit l'exception ConnectionWaitTimeoutException une fois le délai d'attente de connexion écoulé, lorsque le nombre maximum de connexions est atteint et que toutes les connexions sont utilisées. Ce type de comportement est courant pour WebSphere Application Server. L'exception ConnectionWaitTimeoutException s'applique aussi bien aux connexions partageables qu'aux connexions dédiées.

Cependant, si l'une des connexions persistantes n'est pas en cours d'utilisation, WebSphere Application Server la déconnecte afin de pouvoir répondre à la requête demandant la création d'une nouvelle connexion socket persistante. Il s'agit ici aussi d'un comportement courant de WebSphere Application Server qui s'applique aux connexions partageables et dédiées.


Vos commentaires