Je dois modifier le code C++ pour me connecter à WebSphere MQ à l'aide de la table de définitions de canal client. Il y a environ 5000+ clients MQ et 10 serveurs MQ sous Windows 2003 avec v6.0. S'il vous plaît aidez-moi si quelqu'un utilisant C++ avec CCDT.Client C++ se connectant à IBM MQ via SSL
Définissez les variables d'environnement MQCHLLIB et MQCHLTAB pour pointer vers la table de canaux comme décrit dans "Using WebSphere MQ environment variables". Ensuite, définissez SSLKEYR comme décrit dans la même section du manuel. Ceux-ci permettront à l'application de trouver les fichiers CCDT et KDB. Assurez-vous que le CCDT contient des définitions de canal qui spécifient le bon SSLCIPH, puis se connectent comme d'habitude. Aucun changement de code ne devrait être requis. Un conseil, utilisez le client WMQ v7, même si le serveur est à la version v6. Le client est rétrocompatible tant que vous n'essayez pas d'utiliser les fonctionnalités de la version 7 comme la reconnexion automatique. Cependant, v6 est en fin de vie l'année prochaine et si vous voulez éviter de retester et de redéployer - ou d'exécuter une version non supportée - déployez autant que possible sur les composants v7.
Salut Rob, Merci pour votre réponse rapide. Je suis MQ Admin et aucun membre de l'équipe d'application n'a d'expérience avec le code C++ car il utilise le même qui a été développé il y a 8 ans. Et le code prend les paramètres de connexion MQ à partir du fichier .xml. Si rien ne doit être modifié dans le code, le client se connecte par défaut aux gestionnaires de files d'attente en utilisant le fichier .xml. Corrigez-moi si je me trompe. – Nikhil
Dépend de ce qui se trouve dans le fichier XML et de la manière dont l'application se connecte. Si l'application utilise MQCONNX et ne remplit pas actuellement les paramètres SSL, elle doit être modifiée. D'un autre côté, si l'application utilise le CCDT, l'ajout de la variable d'environnement SSLKEYR lui permet de trouver le fichier KDB et la construction d'un nouveau CCDT avec les paramètres de canal SSL inclus compléterait la conversion. Donc, cela dépend vraiment de la façon dont l'application est codée pour savoir laquelle de ces actions est correcte. –
Le fichier XML contient les informations de connexion des serveurs MQ telles que le nom d'hôte, le nom du gestionnaire de files d'attente, le canal et le port. Le client essaie d'abord de se connecter au premier gestionnaire de files d'attente dans un fichier XML et s'il ne parvient pas à établir la connexion, il passe au deuxième gestionnaire de files d'attente. Les connexions client ne sont pas équilibrées et tous les serveurs sont en cluster. Je suis sûr que les clients se connectant à l'aide de MQCONN et confirmera également la même chose avec les développeurs. J'ai lu sur les nouvelles fonctionnalités de la version 7.0 sur la reconnexion automatique et les clients sélectionnant les gestionnaires de files d'attente de manière aléatoire à partir de la table de définition du canal client. –
Grande différence ici entre MQCONN et MQCONNX. Si le fichier XML contient l'hôte, le canal et le port, les applications utilisent MQCONNX, ce qui vous permet de spécifier tous les détails de la connexion. Dans ce cas, il sera nécessaire d'ajouter le SSL CipherSpec aux options de connexion comme décrit ici: http://bit.ly/aMLFnO Bien sûr, vous devez toujours indiquer à l'application où trouver le fichier KDB et c'est le SSLKEYR variable d'environnement comme décrit précédemment. –
Pour savoir si l'application utilisant MQCONN ou MQCONNX, la commande ci-dessous pour tracer les appels d'API MQ aide-t-elle? strmqtrc -x tous les t api (sous Windows) strmqtrc -t api – Nikhil