Перекодировка данных при передаче сообщения

При построении гетерогенной среды, администраторы и программисты часто сталкиваются с проблемой согласования кодовых страниц при формировании и обработке пользовательских данных. В данной статье мы рассмотрим различные варианты перекодировки, обсудим их плюсы и минусы, а также попытаемся определить целесообразность их использования. Для начала нам необходимо описать топологию нашей среды. Для рассмотрения всех вариантов перекодировки в рамках одной топологии выберем топологию, состоящую из 3 менеджеров последовательно взаимодействующих между собой. Менеджер QM1 функционирует на платформе zEnterprise с  ОС z/OS в кодовой странице 1025, менеджер QM2 на платформе Intel с Windows в кодовой странице 866, а менеджер QM3 на платформе SUN в кодовой странице UTF-8.

WMQ-Conversation-Topology

Как видно из приведённого изображения у менеджера QM1 нет прямой связи с менеджером QM3 и как следствие этого при передаче сообщений с менеджера QM1 на менеджер QM3 они пройдут транзитом через менеджер QM2.

При инициализации каналов сообщений менеджеры договариваются между собой о параметрах взаимодействия и в частности передают информацию о кодовых страницах, в которых они работают, это делается для того, чтобы при передаче сообщений производить перекодировку заголовка сообщений (MQMD). MCA отправитель на основании полученных данных в секции инициализации канала находит необходимую таблицу перекодировки (папка “\conv\table” для распределённых систем) которая в последствии используется для перекодировки заголовка сообщения перед его отправкой. В случае, если таблица перекодировки не найдена, MCA выдаст ошибку согласования и перейдёт в состояние RETRYING.

B менеджере существует 2 встроенных механизма перекодировки данных: перекодировка при передаче от менеджера к менеджеру по каналам сообщений, перекодировка при получении данных прикладной программой. Первый механизм работает для всех сообщений проходящих по каналу, если выполнены некоторые условия, второй способ работает при выполнении вызова MQGet, если выставлены специальные опции и выполнен ряд условий при формировании сообщения. Необходимыми условиями для перекодировки данных является выставление атрибутов “Format = MQMSTR” и “CodedCharSetId” в заголовке сообщения. Выставив данные атрибуты Вы уведомили менеджер о том что сообщение содержит текстовые данные в определённой кодовой странице. Давайте более подробно рассмотрим эти варианты.

Перекодировка при передаче от менеджера к менеджеру

Для активирования данного механизма необходимо на канале сообщений с типом SENDER или SERVER выставить атрибут CONVERT в значение yes. Если канал в настоящее время находится в рабочем состоянии, то его необходимо перезапустить для применения опции перекодировки. Данный метод наиболее приемлем в случае интеграции “старых” приложений, которые всегда работают в кодовой странице ОС и были унаследованы Вами (модифицировать код не представляется возможным, приложения работают в контейнерах, где функционал перекодировки не предусмотрен).

Плюсы метода:

  • управление механизмом осуществляется на уровне администрирования;
  • прикладной программный код не требует переработки;
  • перекодировка осуществляется до передачи сообщения на сторону получателя, что позволит уменьшить трафик в случае установки неверных кодовых страниц (при невозможности перекодировки сообщения помещаются в очередь ошибочных сообщений);

Минусы метода:

  • перекодируются все сообщения проходящие по каналу и удовлетворяющие условиям, описанным выше;
  • в случае неверной настройки менеджера (отсутствует очередь ошибочных сообщений или она переполнена) и невозможности перекодировать сообщение оно “застрянет” в очереди и остановит работу канала.

Первый минус хорошо заметен в нашей топологии при условии использования данного метода и передаче сообщений с менеджера QM1 на менеджер QM3, а именно наличие как минимум одной, а то и двух  не нужных перекодировок. Давайте рассмотрим данный случай более подробно:

  1. При выполнении вызова MQPut создаётся сообщение на менеджере QM1, которое маркируется кодовой страницей 1025;
  2. Во время передачи сообщения по каналу связи между QM1 и QM2 происходит перекодировка 1025 -> 866;
  3. Поскольку сообщение адресовано на менеджер QM3, то при получении его на менеджере QM2 отработает механизм транзита и сообщение будет помещено в очередь передачи на менеджер QM3;
  4. Во время передачи сообщения по каналу связи между QM2 и QM3 происходит перекодировка 866 -> 1208;

Если приложение получившее сообщение на менеджере QM3 работает в кодовой странице  1208, то в процессе передачи сообщения произошла одна лишняя перекодировка, а если приложение работает в иной кодовой странице и само запросит у менеджера перекодировку используя второй метод – то в процессе передачи произошло две лишних перекодировки. При большом трафике и наличии транзитных менеджеров данный метод приводит к большому числу не нужных перекодировок, что может сказаться на общей производительности среды.

Перекодировка при получении данных прикладной программой

Данный метод можно назвать перекодировкой по требованию. Для перекодировки сообщений прикладная программа должна правильно сформировать опции вызова MQGet, а именно заполнить поля CodedCharSetId, Encoding в заголовке сообщения  и указать опцию MQGMO_CONVERT. При выполнении данного вызова менеджер сообщений прежде чем отдать тело сообщения прикладной программе проверит, соответствует ли кодовая страница в заголовке сообщения той, которую указала прикладная программа, если кодовые страница отличаются, то менеджер найдёт соответствующую таблицу перекодировки и произведёт перекодировку. Если перекодировка сообщения не возможна, то менеджер вернёт прикладной программе не перекодированное сообщение, выставив в поля заголовка CodedCharSetId, Encoding значения указанные в исходном сообщении.

Плюсы метода:

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

Минусы метода:

  • при использовании не типичных кодовых страниц, администратору необходимо заранее заготовить таблицы перекодировки;
  • если используется сбор статистики по сообщениям (фиксируется не только заголовок, но и тело сообщения),  проходящим по каналам связи, то необходимо предусмотреть функции перекодировки при сборе статистики, иначе тело сообщения будет не читаемым.
Выводы

Если Ваша топология использует большое количество менеджеров, работающих в различных кодовых страницах, у Вас нет унаследованных “старых” приложений, то 2 вариант перекодировки, а именно перекодировка по требованию это единственный приемлемых вариант. Если в среде функционируют “старые” приложения, то имеет смысл совместить оба метода и производить перекодировку сообщений при передаче между менеджерами на последней стадии, то есть при передаче сообщений на менеджер в рамках которого и функционируют “старые” приложения.

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
Метки: , , ,
Опубликовано в WebSphere MQ, Основы

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

*

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Выбор языка: