Gestion des messages avec des noeuds finals de message
Gérez la communication des messages pour les beans gérés par message qui sont déployés en tant que noeuds finaux de message. Les noeuds finaux de message sont des beans gérés (MBeans) pour les adaptateurs de ressources entrants compatibles avec Java™ Platform, Enterprise Edition (Java EE) Connector Architecture (JCA) Version 1.5.
Pourquoi et quand exécuter cette tâche
- Les messages dont la communication a échoué nécessitent un traitement supplémentaire, tel qu'une nouvelle tentative de communication au noeud final en mode écoute ou un réacheminement vers des destinations alternatives qui traitent ce type de message. De plus, un adaptateur de ressources peut effectuer un nombre illimité de tentatives de livraisons.
- Le réacheminement des messages nécessite l'implémentation de destinations spécialisées (files d'attente et programmes d'écoute) pour traiter les messages dont la communication a échoué, ainsi que la logique permettant de détecter l'échec des communications. Le réacheminement des messages est susceptible de générer des erreurs et nécessite beaucoup de calculs en raison de sa complexité.
La fonction de désactivation (pause) et réactivation (reprise) d'un noeud final de message spécifique permet de résoudre ces problèmes en donnant la possibilité à l'administrateur d'empêcher le noeud final de traiter les messages dont la communication va échouer. Lorsque le noeud final de message est désactivé, vous pouvez réparer la ressource qui provoque les problèmes et réactiver le noeud final pour reprendre la gestion des demandes de message. Au cours de l'identification des incidents, vous n'affectez ainsi ni l'adaptateur de ressources, ni l'application qui héberge le noeud final.
Si vous vous connectez à WebSphere MQ, vous pouvez également utiliser la propriété personnalisée WAS_EndpointInitialState de la spécification d'activation pour que le noeud final du message démarre à l'état désactivé. Lorsque vous définissez cette propriété sur Inactive, le bean géré par message se connecte à la destination mais ne démarre pas la réception des messages. Utilisez ce paramètre pour désactiver automatiquement un noeud final de message lorsque vous savez que certaines tâches doivent être terminées, que des services doivent être démarrés ou que des vérifications doivent être effectuées avant le démarrage de la gestion des messages. Vous activez le noeud final de message comme vous le feriez pour réactiver un noeud final de message interrompu pendant son opération.
Procédure
Résultats
- Bean géré par message en mode écoute sur une rubrique non durable (dépend de la configuration) : Le comportement généré par la désactivation (pause) d'un noeud final de message dépend souvent de la fonction qu'il remplit. Par exemple, si vous avez configuré un bean géré par message en mode écoute sur une rubrique non durable, sur le bus d'intégration de services, la désactivation du noeud final de message revient à arrêter l'application et entraîne la fermeture de l'abonnement. Cela signifie que tous les messages publiés pendant que le noeud final de message est en pause ne sont pas reçus par le bean géré par message.
- Bean géré par message en cluster (dépend de la topologie) : Dans ce scénario, une application de bean géré par message a été déployée sur un cluster de serveurs. Un bean géré de noeud final de message donné ne contrôle que le comportement du bean géré par message dans un serveur d'un cluster. En conséquence, un seul serveur arrête le traitement des messages. En fonction de la configuration de messagerie et de l'adaptateur de ressources spécifique en cours d'utilisation, les messages qui auraient dû être consommés par le noeud final de message en pause peuvent être consommés par les noeuds finaux de message actifs du cluster ou ils peuvent rester non consommés jusqu'à la reprise du noeud final de message en pause.
- Bean géré par message en cluster, file d'attente n'appartenant pas à un cluster : Dans ce scénario, vous disposez d'un cluster de serveurs sur lesquels le même bean géré par message a été déployé . Ce scénario est similaire à celui dans lequel vous disposez de différents beans gérés par message avec les mêmes critères de sélection de messages, à l'exception du fait qu'ici, les beans gérés par message sont en fait un seul et même bean. En mettant en pause le noeud final, un seul serveur ne reçoit plus les messages alors que les autres beans gérés par message reçoivent tous les messages : aucun message n'est orphelin. Pour arrêter tous les noeuds finaux, vous devez diriger chaque serveur du cluster pour arrêter le noeud final de message local.
- Bean géré par message en cluster, file d'attente en cluster : Dans ce scénario, chaque bean géré par message retire les messages à partir d'une partition différente de la file d'attente. La messagerie via WebSphere MQ et le bus d'intégration de services dispose de fonctions similaires, mais différentes. Si vous utilisez WebSphere MQ, mettre en pause un noeud final ne permet pas aux autres instances du bean géré par message de recevoir les messages. Dans le bus d'intégration de services, les messages issus d'un noeud final en pause sont réacheminés vers les autres beans gérés par message.