| |
Создание интерфейсов передачи сообщений. Триггеринг
Состояние каналов. Создание интерфейсов передачи сообщений
Как говорилось в предыдущей лекции, сообщения передаются с помощью каналов, с одинаковыми именами, расположенными как на одном, так и на другом менеджере. Для управления процессом старта каналов существует специальная служба, которая называется Channel initiator. На платформе Windows NT она запускается автоматически при старте менеджера с помощью WebSphere MQ Explorer. На других платформах она запускается с помощью команды runmqchi (на AS/400 - strmqmchi). На менеджере, отправляющем сообщение, должен быть создан канал отправитель, на менеджере получателе, соответственно, получатель. Рассмотрим подробнее работу пар каналов.
Sender => Receiver
Наиболее распространенная пара. Sender канал инициирует соединение с receiver каналом, затем передает сообщения.
Server => Receiver
В данном случае server канал выполняет роль sender канала. Пара имеет право на существование, но лучше использовать связку Sender => Receiver.
Server => Requester
В этой паре requester канал инициирует соединение, затем server канал начинает передачу данных.
Sender => Requester
Requester канал инициирует соединение в случае разрыва с sender каналом. Sender канал в свою очередь инициирует соединение с requester каналом, и только после этого начинается процесс передачи.
Каналы могут находиться в следующих состояниях.
Initialising - WebSphere MQ делает попытку произвести старт канала.
Starting - канал начал процесс старта и ждет установки соединения (активации слота).
Binding - после активации слота идет попытка установления соединения и передача данных инициации между каналами.
Requesting - requester канал ждет ответа от sender канала.
Running - состояние при котором либо идет передача данных, либо канал отправитель ждет сообщений из трансмиссионной очереди. Единственное состояние каналов отправителей, при котором возможна передача данных.
Paused - канал ожидает истечения времени, указанного в атрибуте Message retry interval.
Stopping - канал переходит в это промежуточное состояние в процессе остановки канала командой MQSC stop channel, либо при возникновении какой-либо ошибки.
Retrying - ожидание очередной попытки старта канала с помощью Channel initiator.
Stopped - канал остановлен. Стартовать его можно либо с помощью WebSphere MQ Explorer либо с помощью команды MQSC start channel. Ниже мы приведем подробную инструкцию для старта каналов.
Inactive - состояние канала, говорящее о том, что либо он никогда не был стартован, либо истекло время, указанное в атрибуте Disconnect Interval для канала отправителя. Для канала получателя это нормальное состояние, так как он переходит в состояние Running при инициации связи со стороны канала отправителя. |
|
Пиктограммы состояния каналов
Состояние канала отображается в WebSphere MQ Explorer пиктограммами. Одной пиктограмме может соответствовать несколько состояний канала.
|
neutral (нейтральное). Соответствует состоянию Inactive |
|
running (стартован). Соответствует только состоянию Running. |
|
stopped (остановлен). Соответствует состоянию Stopped. |
|
alert (неопределенное состояние). Соответствует состояниям Binding, Requesting, Retrying, Stopping. |
|
warning (предупреждающее состояние). Обычно возникает при появлении ошибок. |
Как правило, причиной остановки канала может быть только команда. Причин возникновения неопределенного состояния может быть несколько: разрыв связи, неправильный IP адрес в каналах отправителях или в requester, попытка стартовать канал, когда канал на другом конце остановлен или находится в неопределенном состоянии и пр. Самое главное, что нужно делать, чтобы избежать ошибок, это правильно заполнять атрибуты каналов и удаленных локальных очередей и контролировать работу каналов на обоих менеджерах. Напомним, что главным определяющим атрибутом канала отправителя является Disconnect Interval, по истечении которого канал переходит в состояние Inactive, если в соответствующей трансмиссионной очереди не будет новых сообщений. Для возобновления передачи нужно либо вручную стартовать канал, либо настроить автоматический старт.
Для создания интерфейса передачи сообщений от одного менеджера очередей к другому необходимо создать ряд объектов как на одном менеджере, так и на другом.
Предположим, нам нужно передать сообщения от одного менеджера QM_Win2000_REP, расположенного на платформе NT, имеющего IP адрес 198.32.100.26, порт для службы listener - 1415 к другому менеджеру QM_HPUX, расположенному на платформе UNIX с адресом 198.32.100.16, порт для службы listener - 1421. Подключим менеджер QM_HPUX для удаленного управления с помощью WebSphere MQ Explorer. Создадим объекты на платформе UNIX:
- локальная очередь Win2000_REP_HPUX.Q - в нее будет доставляться сообщение
- receiver канал Win2000_REP_HPUX.CH.
Создадим объекты на менеджере QM_Win2000_REP:
- трансмиссионная очередь Win2000_REP_HPUX_TRANS.TQ ;
- удаленная локальная очередь Win2000_REP_HPUX_REMOT.RQ , имеющая атрибуты:
- Remote Queue Name - Win2000_REP_HPUX.Q;
- Remote Queue Manager Name - QM_HPUX;
- Transmission Queue Name - Win2000_REP_HPUX_TRANS.TQ;
- sender канал Win2000_REP_HPUX.CH, имеющий атрибуты:
- Connection Name - 198.32.100.16(1421);
- Transmission Queue - Win2000_REP_HPUX_TRANS.TQ;
Поместим тестовое сообщение в локальную удаленную очередь Win2000_REP_HPUX_REMOT.RQ с помощью программы amqsput.exe, входящей в пакет демонстрационных программ, введя в командной строке:
amqsput Win2000_REP_HPUX_REMOT.RQ QM_Win2000_REP
Далее вводим текст сообщения:
Тестовое сообщение от QM_Win2000_REP.
Работа программы amqsput.exe показана на
После нажатия клавиши "Enter" сообщение должно попасть в трансмиссионную очередь Win2000_REP_HPUX_TRANS.TQ. Оно будет находиться в ней до тех пор, пока sender канал не будет стартован. После старта канала сообщение будет доставлено в очередь Win2000_REP_HPUX.Q на менеджер QM_HPUX
Соединение типа клиент-сервер
Рассмотрим ситуацию, предполагающую наличие одного сервера с установленным менеджером очередей и множества рабочих станций, которые должны доставлять или получать сообщения от этого менеджера. Предположим, что для каждой рабочей станции на менеджере очередей создана своя локальная очередь для получения сообщений FROM_A1.Q, FROM_A2.Q и так далее в зависимости от количества станций. Также созданы локальные очереди для отправки сообщений TO_A1.Q, TO_A2.Q и так далее. В данном случае целесообразно использовать соединение типа клиент-сервер, которое не требует установки серверной части WebSphere MQ на рабочей станции. На ней можно установить только клиентскую часть, которая присутствует в комплекте поставки.
Подключение рабочей станции производится с помощью канала типа Server Connection, создаваемого на менеджере очередей. Форма для создания канала с помощью WebSphere MQ Explorer представлена на и имеет закладки General, Extended, MCA, Exits и SSL. Атрибуты, вводимые в этих закладках описаны в лекции 3. Основным атрибутом является Channel Name. Кроме имени канала никакие другие атрибуты не играют роли в процессе подключения рабочей станции.
Кроме создания канала на менеджере очередей нужно разрешить учетной записи рабочей станции подключение к менеджеру и дать соответствующие права на очереди, с которыми рабочая станция будет работать. Предположим, что станция имеет учетную запись (имя пользователя) station1 в домене petersburg и должна работать с локальными очередями FROM_A1.Q и TO_A1.Q на менеджере QM_Win2000 с IP адресом 198.32.100.26 через канал CHANNEL_BY_A1. Тогда на сервере нужно выполнить команды авторизации
SETMQAUT -m QM_Win2000 -t qmgr
-p station1@petersburg +connect
SETMQAUT -m QM_Win2000 -n FROM_A1.Q -t queue
-p station1@petersburg +all
SETMQAUT -m QM_Win2000 -n TO_A1.Q -t queue
-p station1@petersburg +all
Первая команда дает права пользователю с учетной записью station1@petersburg на подключение к менеджеру QM_Win2000, вторая и третья разрешают производить все операции с очередями FROM_A1.Q и TO_A1.Q соответственно. Просмотреть права данной учетной записи можно с помощью команд
DSPMQAUT -m QM_Win2000 -t qmgr
-p station1@petersburg
DSPMQAUT -m QM_Win2000 -n FROM_A1.Q -t queue
-p station1@petersburg
DSPMQAUT -m QM_Win2000 -n TO_A1.Q -t queue
-p station1@petersburg
На этом действия по созданию соединения клиент-сервер на сервере завершаются. На рабочей станции необходимо создать системную переменную с именем MQSERVER как показано на
Теперь с рабочей станции можно послать сообщение в очередь FROM_A1.Q на удаленный менеджер QM_Win2000 с помощью программы amqsputc.exe, входящей в комплект поставки в качестве примера:
amqsputc FROM_A1.Q <text_message.txt
где text_message.txt - файл, содержащий текст сообщения.
Считать сообщения из очереди можно с помощью программы amqsgetc.exe:
amqsgetc TO_A1.Q
при условии, что в этой очереди они есть.
Вполне вероятно, что рабочие станции в своей работе могут использовать только одну очередь для отправки и получения сообщений. В этом случае необходимо создать такую программу, которое позволяла бы корректно разбирать и отправлять сообщения в зависимости от имен рабочих станций и/или других параметров. |
|
|
Процессы WebSphere MQ, триггеринг и автоматический старт каналов
Как правило, после поступления сообщений в очередь назначения, они обрабатываются различными прикладными программами, например, считываются из очереди и помещаются в базу данных. WebSphere MQ имеет возможность запускать процессы, как только одно или определенное количество сообщений поступает в очередь.
Процесс WebSphere MQ это объект, содержащий информацию о прикладной программе, которая может быть выполнена на определенных условиях при использовании механизма триггеринга. Форма для создания процесса изображена на
Process Definition Name - имя процесса. Уникально в пределах одного менеджера и должно отличаться от его имени. Может совпадать с именами других объектов менеджера.
Description - описание процесса.
Application Type - тип приложения. Зависит от операционной системы, на которой установлен менеджер очередей.
Application Identifier - имя выполняемой программы с указанием пути.
Environment Data - данные, которые могут быть переданы сервису Trigger Monitor.
User Data - данные, которые могут быть переданы выполняемой программе.
Для запуска процесса необходимы условия:
- сообщения поступают в очередь;
- приоритет сообщения не ниже приоритета, указанного в атрибуте Trigger Message Priority;
- количество сообщений в очереди находится в соответствии с атрибутом Trigger Type;
- существует очередь инициализации;
- атрибут Trigger Control установлен в значение On;
- существует и стартована служба сервиса WebSphere MQ Trigger monitor, в параметрах которой указана соответствующая очередь инициализации или запущена программа runmqtrm.
Предположим, что необходимо информировать пользователя о приходе каждого сообщения в очередь FOR_USER_INF.Q. Рассмотрим шаги для реализации поставленной задачи:
- Создать очередь инициализации for_user_init.
- Создать файл c:\temp\trig.bat, содержащий строку
- net send user1 Пришло сообщение в очередь FOR_USER_INF.Q
который будет посылать сообщения пользователю user1,
- Создать процесс NET_SEND.P с атрибутами:
- Process Definition Name - NET_SEND.P;
- Application Type - Windows NT;
- Application Identifier - c:\temp\trig.bat.
- Создать локальную очередь FOR_USER_INF.Q с атрибутами
- Queue Name - FOR_USER_INF.Q;
- Trigger Control - On;
- Trigger Type - Every;
- Trigger Depth - 1;
- Trigger Message Priority - 0;
- Initiation Queue Name - for_user_init ;
- Process Name - NET_SEND.P.
- Создать службу сервиса WebSphere MQ Trigger Monitor:
- Запустить утилиту создания и управления сервисами WebSphere MQ;
- Вызвать контекстное меню, правой кнопкой мыши щелкнув по имени менеджера, выбрать пункт Create, далее Trigger Monitor;
- Ввести имя очереди инициализации - for_user_init;
- После нажатия на кнопку OK в правой части консоли WebSphere MQ Services появится созданный объект Trigger Monitor (
- Выполнить старт Trigger Monitor, нажав на кнопку "Старт", расположенную на панели управления.
- Поместить тестовое сообщение в очередь FOR_USER_INF.Q и убедиться, что сетевое сообщение с текстом "Пришло сообщение в очередь FOR_USER_INF.Q" отправлено пользователю user1.
Вместо создания службы сервиса WebSphere MQ Trigger Monitor можно выполнить программу runmqtrm. Синтаксис команды
runmqtrm -q for_user_init
В этом случае процесс NET_SEND.P будет выполняться только тогда, когда программа runmqtrm запущена. |
|
Использование механизма триггеринга для автоматического старта каналов
Используя механизм триггеринга можно сделать так, чтобы каналы отправители, перешедшие в нейтральное состояние Inactive в результате истечения времени, указанного в атрибуте Disconnect Interval автоматически переходили в состояние Running при появлении в соответствующей трансмиссионной очереди сообщения. Для этого существует два способа: с использованием процесса и с использованием системной очереди инициализации. Рассмотрим вариант с использованием процесса.
Для каждой трансмиссионной очереди нужно создать:
- очередь инициализации;
- процесс и в качестве атрибута процесса User Data указать имя канала отправителя, который передает данные, поступающие в эту трансмиссионную очередь;
- в трансмиссионной очереди установить атрибуты
- Trigger Control - On;
- Trigger Type - First;
- Trigger Depth - 1;
- Trigger Message Priority - 0;
- Initiation Queue Name - имя очереди инициализации созданной в п.1;
- Process Name - имя процесса, созданного в п.2.
Теперь рассмотрим второй способ автоматического старта канала отправителя без использования процессов. Для реализации второго способа требуется лишь установить атрибуты трансмиссионной очереди:
- Trigger Control - On;
- Trigger Type - First;
- Trigger Depth - 1;
- Trigger Message Priority - 0;
- Trigger Data - имя канала отправителя, который передает данные, поступающие в эту трансмиссионную очередь;
- Initiation Queue Name - имя системной очереди инициализации SYSTEM.CHANNEL.INITQ.
Имя системной очереди инициализации может быть использовано в атрибуте Initiation Queue Name каждой трансмиссионной очереди.
В процессе рестарта каналов возможна ситуация, когда транзакция по передаче сообщения еще не завершилась, а канал получил команду на остановку. В таком случае при рестарте каналов сообщение может быть передано с принудительным завершением транзакции либо остаться в исходящей очереди посредством отката транзакции. Остановка канала может осуществляться как с прерыванием и принудительным завершением транзакции, так и без прерывания. Во втором случае транзакция успешно закрывается, что гарантирует отсутствие в трансмиссионной очереди сообщений с признаком незавершенной транзакции (uncommitted messages). Последующий старт канала облегчается отсутствием необходимости выполнения команды resolve channel с вариантами обработки uncommitted сообщений. Операции по рестарту каналов можно производить с помощью команд MQSC и с помощью WebSphere MQ Explorer, выполняя соответствующие пункты контекстного меню для каждого канала. Рассмотрим процедуру рестарта каналов с помощью WebSphere MQ Explorer.
- Остановить канал отправитель, выполнив пункт Stop контекстного меню. При выполнении данного меню появится форма, изображенная на, имеющая следующие параметры:
Force interruption of current message batch - прерывание и принудительное завершение транзакции. Если выставить флажок в этом параметре, то становится доступным параметр Allow process/thread termination позволяющий принудительно остановить процесс передачи данных. Рекомендуется не использовать эти два параметра, чтобы перед остановкой канала обеспечить передачу сообщений, по которым транзакция была уже открыта.
New state - указывается состояние канала, в которое он будет переведен после остановки. Может иметь два значения Inactive и Stopped.
Параметры в секции Filter (Only stop channels from this remote queue manager и Only stop channels from this remote connection) используются только для z/OS.
- Остановить канал получатель.
- Выполнить пункт контекстного меню Reset для канала получателя, выставив значение Message Sequence Number в единицу.
- Стартовать канал получатель при помощи контекстного меню Start.
- Выполнить пункт контекстного меню Reset для канала отправителя, выставив значение Message Sequence Number в единицу
- Если использовался способ остановки с прерыванием транзакции, то выполнить пункт контекстного меню Resolve и выбрать метод обработки сообщений, для которых транзакция не завершилась. Commit - передать сообщения, Back out - выполнить откат транзакции.
- Выполнить пункт контекстного меню Ping для канала отправителя с целью проверки установления соединения с каналом получателем. Данный пункт выполнять не обязательно, если вы уверены, что связь между каналами может быть установлена.
- Выполнить пункт контекстного меню Start для канала отправителя.
Эту процедуру следует выполнить когда устранены все неполадки, приведшие к остановке каналов или переходу в неопределенное состояние. Если в сети существуют проблемы со связью, то канал отправитель может не перейти в состояние running и тогда всю процедуру надо будет вновь повторить сначала. Следует заметить, что WebSphere MQ гарантирует доставку сообщений, но только при правильных настройках всех объектов, участвующих в процессе передачи. Если установить тип сообщений Non Persistent, то никакими силами не удастся восстановить сообщения, например, после перезагрузки компьютера или после остановки менеджера. Материалов, приведенной в данной лекции вполне достаточно для создания и управления интерфейсами передачи и обработки данных. |
|
|
|
