Интеграция приложений на основе WebSphere MQ

Создание интерфейсов передачи сообщений. Триггеринг

Разбить на страницы
Показывать лекцию целиком

Состояние каналов. Создание интерфейсов передачи сообщений

Как говорилось в предыдущей лекции, сообщения передаются с помощью каналов, с одинаковыми именами, расположенными как на одном, так и на другом менеджере. Для управления процессом старта каналов существует специальная служба, которая называется 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 - в нее будет доставляться сообщение (рис. 4.1);
  • receiver канал Win2000_REP_HPUX.CH (рис. 4.2).
    •

    Создадим объекты на менеджере QM_Win2000_REP:

  • трансмиссионная очередь Win2000_REP_HPUX_TRANS.TQ (рис. 4.3);

  • удаленная локальная очередь Win2000_REP_HPUX_REMOT.RQ (рис. 4.4), имеющая атрибуты:

  • 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 (рис. 4.5), имеющий атрибуты:
  • Connection Name - 198.32.100.16 ( 1421 );
  • Transmission Queue - Win2000_REP_HPUX_TRANS.TQ ;
    • (рис 4.2) Локальная очередь Win2000_REP_HPUX.Q(рис 4.1) Receiver канал Win2000_REP_HPUX.CH(рис 4.4) Трансмиссионная очередь Win2000_REP_HPUX_TRANS.TQ(рис 4.3) Удаленная локальная очередь Win2000_REP_HPUX_REMOT.RQ(рис 4.5) sender канал Win2000_REP_HPUX.CH

    Поместим тестовое сообщение в локальную удаленную очередь Win2000_REP_HPUX_REMOT.RQ с помощью программы amqsput.exe, входящей в пакет демонстрационных программ, введя в командной строке:

    amqsput Win2000_REP_HPUX_REMOT.RQ QM_Win2000_REP

    Далее вводим текст сообщения:

    Тестовое сообщение от QM_Win2000_REP.

    Работа программы amqsput.exe показана на рис. 4.6.

    (рис 4.6) Работа программы amqsput.exe

    После нажатия клавиши "Enter" сообщение должно попасть в трансмиссионную очередь Win2000_REP_HPUX_TRANS.TQ. Оно будет находиться в ней до тех пор, пока sender канал не будет стартован. После старта канала сообщение будет доставлено в очередь Win2000_REP_HPUX.Q на менеджер QM_HPUX (рис. 4.7).

    (рис 4.7) Просмотр сообщения через Message Browser

    Соединение типа клиент-сервер

    Рассмотрим ситуацию, предполагающую наличие одного сервера с установленным менеджером очередей и множества рабочих станций, которые должны доставлять или получать сообщения от этого менеджера. Предположим, что для каждой рабочей станции на менеджере очередей создана своя локальная очередь для получения сообщений .

    Подключение рабочей станции производится с помощью канала типа Server Connection, создаваемого на менеджере очередей. Форма для создания канала с помощью WebSphere MQ Explorer представлена на рис.4.8 и имеет закладки General, Extended, MCA, Exits и SSL. Атрибуты, вводимые в этих закладках, описаны в лекции 3. Основным атрибутом является Channel Name. Кроме имени канала никакие другие атрибуты не играют роли в процессе подключения рабочей станции.

    (рис 4.8) Форма создания канала Server Connection

    Кроме создания канала на менеджере очередей нужно разрешить учетной записи рабочей станции подключение к менеджеру и дать соответствующие права на очереди, с которыми рабочая станция будет работать. Предположим, что станция имеет учетную запись (имя пользователя) 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 как показано на рис.4.9.

    (рис 4.9) Параметры переменной 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 это объект, содержащий информацию о прикладной программе, которая может быть выполнена на определенных условиях при использовании механизма триггеринга . Форма для создания процесса изображена на рис. 4.10.

    (рис 4.10) Форма для создания процесса 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 ;
  • После нажатия на кнопку (рис 4.11) Консоль WebSphere MQ Services
  • Выполнить старт 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). Последующий старт канала облегчается отсутствием необходимости выполнения команды .

  • Остановить канал отправитель, выполнив пункт Stop контекстного меню. При выполнении данного меню появится форма, изображенная на рис.4.12, имеющая следующие параметры:

    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.

    (рис 4.12) Остановка канала
  • Остановить канал получатель.
  • Выполнить пункт контекстного меню Reset для канала получателя, выставив значение Message Sequence Number в единицу.
  • Стартовать канал получатель при помощи контекстного меню Start.
  • Выполнить пункт контекстного меню (рис 4.13) Выравнивание счетчика сообщений
  • Если использовался способ остановки с прерыванием транзакции, то выполнить пункт контекстного меню (рис 4.14) Метод обработки сообщений с незавершенной транзакцией
  • Выполнить пункт контекстного меню Ping для канала отправителя с целью проверки установления соединения с каналом получателем. Данный пункт выполнять не обязательно, если вы уверены, что связь между каналами может быть установлена.
  • Выполнить пункт контекстного меню Start для канала отправителя.
    •

    Эту процедуру следует выполнить когда устранены все неполадки, приведшие к остановке каналов или переходу в неопределенное состояние. Если в сети существуют проблемы со связью, то канал отправитель может не перейти в состояние running и тогда всю процедуру надо будет вновь повторить сначала. Следует заметить, что WebSphere MQ гарантирует доставку сообщений, но только при правильных настройках всех объектов, участвующих в процессе передачи. Если установить тип сообщений Non Persistent, то никакими силами не удастся восстановить сообщения, например, после перезагрузки компьютера или после остановки менеджера. Материалов, приведенной в данной лекции вполне достаточно для создания и управления интерфейсами передачи и обработки данных.

    Страницы:

    Состояние каналов. Создание интерфейсов передачи сообщений

    Как говорилось в предыдущей лекции, сообщения передаются с помощью каналов, с одинаковыми именами, расположенными как на одном, так и на другом менеджере. Для управления процессом старта каналов существует специальная служба, которая называется 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 - в нее будет доставляться сообщение (рис. 4.1);
  • receiver канал Win2000_REP_HPUX.CH (рис. 4.2).
    •

    Создадим объекты на менеджере QM_Win2000_REP:

  • трансмиссионная очередь Win2000_REP_HPUX_TRANS.TQ (рис. 4.3);

  • удаленная локальная очередь Win2000_REP_HPUX_REMOT.RQ (рис. 4.4), имеющая атрибуты:

  • 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 (рис. 4.5), имеющий атрибуты:
  • Connection Name - 198.32.100.16 ( 1421 );
  • Transmission Queue - Win2000_REP_HPUX_TRANS.TQ ;
    • (рис 4.2) Локальная очередь Win2000_REP_HPUX.Q(рис 4.1) Receiver канал Win2000_REP_HPUX.CH(рис 4.4) Трансмиссионная очередь Win2000_REP_HPUX_TRANS.TQ(рис 4.3) Удаленная локальная очередь Win2000_REP_HPUX_REMOT.RQ(рис 4.5) sender канал Win2000_REP_HPUX.CH

    Поместим тестовое сообщение в локальную удаленную очередь Win2000_REP_HPUX_REMOT.RQ с помощью программы amqsput.exe, входящей в пакет демонстрационных программ, введя в командной строке:

    amqsput Win2000_REP_HPUX_REMOT.RQ QM_Win2000_REP

    Далее вводим текст сообщения:

    Тестовое сообщение от QM_Win2000_REP.

    Работа программы amqsput.exe показана на рис. 4.6.

    (рис 4.6) Работа программы amqsput.exe

    После нажатия клавиши "Enter" сообщение должно попасть в трансмиссионную очередь Win2000_REP_HPUX_TRANS.TQ. Оно будет находиться в ней до тех пор, пока sender канал не будет стартован. После старта канала сообщение будет доставлено в очередь Win2000_REP_HPUX.Q на менеджер QM_HPUX (рис. 4.7).

    (рис 4.7) Просмотр сообщения через Message Browser

    Соединение типа клиент-сервер

    Рассмотрим ситуацию, предполагающую наличие одного сервера с установленным менеджером очередей и множества рабочих станций, которые должны доставлять или получать сообщения от этого менеджера. Предположим, что для каждой рабочей станции на менеджере очередей создана своя локальная очередь для получения сообщений .

    Подключение рабочей станции производится с помощью канала типа Server Connection, создаваемого на менеджере очередей. Форма для создания канала с помощью WebSphere MQ Explorer представлена на рис.4.8 и имеет закладки General, Extended, MCA, Exits и SSL. Атрибуты, вводимые в этих закладках, описаны в лекции 3. Основным атрибутом является Channel Name. Кроме имени канала никакие другие атрибуты не играют роли в процессе подключения рабочей станции.

    (рис 4.8) Форма создания канала Server Connection

    Кроме создания канала на менеджере очередей нужно разрешить учетной записи рабочей станции подключение к менеджеру и дать соответствующие права на очереди, с которыми рабочая станция будет работать. Предположим, что станция имеет учетную запись (имя пользователя) 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 как показано на рис.4.9.

    (рис 4.9) Параметры переменной 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 это объект, содержащий информацию о прикладной программе, которая может быть выполнена на определенных условиях при использовании механизма триггеринга . Форма для создания процесса изображена на рис. 4.10.

    (рис 4.10) Форма для создания процесса 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 ;
  • После нажатия на кнопку (рис 4.11) Консоль WebSphere MQ Services
  • Выполнить старт 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). Последующий старт канала облегчается отсутствием необходимости выполнения команды .

  • Остановить канал отправитель, выполнив пункт Stop контекстного меню. При выполнении данного меню появится форма, изображенная на рис.4.12, имеющая следующие параметры:

    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.

    (рис 4.12) Остановка канала
  • Остановить канал получатель.
  • Выполнить пункт контекстного меню Reset для канала получателя, выставив значение Message Sequence Number в единицу.
  • Стартовать канал получатель при помощи контекстного меню Start.
  • Выполнить пункт контекстного меню (рис 4.13) Выравнивание счетчика сообщений
  • Если использовался способ остановки с прерыванием транзакции, то выполнить пункт контекстного меню (рис 4.14) Метод обработки сообщений с незавершенной транзакцией
  • Выполнить пункт контекстного меню Ping для канала отправителя с целью проверки установления соединения с каналом получателем. Данный пункт выполнять не обязательно, если вы уверены, что связь между каналами может быть установлена.
  • Выполнить пункт контекстного меню Start для канала отправителя.
    •

    Эту процедуру следует выполнить когда устранены все неполадки, приведшие к остановке каналов или переходу в неопределенное состояние. Если в сети существуют проблемы со связью, то канал отправитель может не перейти в состояние running и тогда всю процедуру надо будет вновь повторить сначала. Следует заметить, что WebSphere MQ гарантирует доставку сообщений, но только при правильных настройках всех объектов, участвующих в процессе передачи. Если установить тип сообщений Non Persistent, то никакими силами не удастся восстановить сообщения, например, после перезагрузки компьютера или после остановки менеджера. Материалов, приведенной в данной лекции вполне достаточно для создания и управления интерфейсами передачи и обработки данных.

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^