Potrzebuję zmienić kod C++, aby połączyć się z produktem WebSphere MQ przy użyciu tabeli rozpoznawania kanału klienta. Istnieje około 5000 klientów MQ i 10 serwerów MQ w systemie Windows 2003 z wersją 6.0. Pomóż mi, jeśli ktoś używa C++ z CCDT.Klient C++ łączący się z IBM MQ przez SSL
Ustaw zmienne środowiskowe MQCHLLIB i MQCHLTAB tak, aby wskazywały tabelę kanałów zgodnie z opisem w "Using WebSphere MQ environment variables." Następnie ustaw SSLKEYR zgodnie z opisem w tej samej sekcji instrukcji. Pozwoli to aplikacji znaleźć pliki CCDT i KDB. Upewnij się, że CCDT zawiera definicje kanałów, które określają właściwy SSLCIPH, a następnie łączą się jak zwykle. Żadne zmiany kodu nie powinny być wymagane.
Słowo porady, użyj klienta WMQ v7, mimo że serwer jest na v6. Klient jest kompatybilny wstecz, o ile nie próbujesz korzystać z funkcji v7, takich jak automatyczne ponowne połączenie. Jednak wersja 6 jest wycofywana z użycia w przyszłym roku i jeśli chcesz uniknąć ponownego testowania i ponownego rozmieszczenia - lub uruchomienia nieobsługiwanej wersji - wdrożyć jak najwięcej na komponentach v7.
Witaj, Rob, Dziękujemy za szybką odpowiedź. Jestem administratorem MQ i żaden z zespołów aplikacji nie ma doświadczenia z C++ Code, ponieważ używa tego samego, który został rozwinięty 8 lat wstecz. Kod pobiera parametry połączenia MQ z pliku .xml. Jeśli nic nie trzeba zmieniać w kodzie, domyślnie klient łączy się z menedżerami kolejek za pomocą pliku .xml. Proszę, popraw mnie, jeśli się mylę. – Nikhil
Zależy od zawartości pliku XML i sposobu łączenia aplikacji. Jeśli aplikacja używa MQCONNX i obecnie nie wypełnia parametrów SSL, to naprawdę musi zostać zmieniona. Z drugiej strony, jeśli aplikacja korzysta z CCDT, dodanie zmiennej środowiskowej SSLKEYR pozwala znaleźć plik KDB, a skonstruowanie nowego CCDT z załączonym kanałem SSL zakończy konwersję. To naprawdę zależy od tego, w jaki sposób aplikacja jest kodowana, aby wiedzieć, która z nich jest właściwą czynnością. –
Plik XML zawiera informacje o połączeniach MQ Servers, takie jak nazwa hosta, nazwa menedżera kolejek, kanał i port. Klient najpierw próbuje połączyć się z pierwszym menedżerem kolejek w pliku xml i jeśli nie uda się nawiązać połączenia, przechodzi do 2. menedżera kolejek. Połączenia klientów nie są równoważone obciążeniem, a wszystkie serwery są w klastrze. Jestem pewien, że klienci łączący się przy użyciu MQCONN potwierdzą to samo z programistami. Czytałem o nowych funkcjach w wersji 7.0 dotyczących automatycznego ponownego łączenia i klientów wybierających losowo menedżerów kolejek z tabeli definicji kanału klienta. –
Duża różnica tutaj między MQCONN i MQCONNX. Jeśli plik XML zawiera host, kanał i port, aplikacje używają MQCONNX, który pozwala określić wszystkie szczegóły połączenia. W takim przypadku konieczne będzie dodanie opcji SSL CipherSpec do opcji połączenia opisanych poniżej: http://bit.ly/aMLFnO Oczywiście nadal musisz poinformować aplikację, gdzie znaleźć plik KDB i to jest SSLKEYR zmienna środowiskowa, jak opisano wcześniej. –
Aby dowiedzieć się, czy aplikacja używa MQCONN lub MQCONNX, czy poniższe polecenie służy do śledzenia wywołań interfejsu API MQ? strmqtrc -x all -t api (w systemie Windows) strmqtrc -t api – Nikhil