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.
Cette combinaison est utilisée pour les interactions non transactionnelles. Pour les applications non conversationnelles, vous devez utiliser l'interaction SYNC_SEND_RECEIVE. Pour les applications conversationnelles, vous devez utiliser l'interaction SYNC_SEND_RECEIVE ou, éventuellement, l'interaction SYNC_END_CONVERSATION.
Cette combinaison est utilisée pour les interactions non transactionnelles. Pour les applications non conversationnelles, vous devez utiliser l'interaction SYNC_SEND_RECEIVE. Pour les applications conversationnelles, vous devez utiliser l'interaction SYNC_SEND_RECEIVE ou, éventuellement, l'interaction SYNC_END_CONVERSATION.
Cette combinaison est utilisée par IMS Connector for Java lorsqu'il participe à un traitement de validation en deux phases avec IMS. Pour plus d'informations, voir Prise en charge d'une transaction globale avec validation en deux phases.
Cette combinaison est utilisée par IMS Connector for Java pour les transactions non transactionnelles SYNC_SEND_RECEIVE, SYNC_SEND, SYNC_RECEIVE_ASYNCOUTPUT, SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_NOWAIT et SYNC_RECEIVE_ASYNCOUTPUT_SINGLE_WAIT.
Remarque : le mode de validation 0 est uniquement pris en charge pour les applications non conversationnelles fonctionnant sur des connexions TCP/IP.
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.
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.
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.
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.
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.
La valeur TRUE pour la propriété CM0Dedicated garantit que la fabrique de connexions va créer des connexions socket persistantes dédiées.
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.
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.