Наводим мосты – 3: экзотика и рекомендации.

nbridge4
Продолжение, начало здесь:
SAP PI Async-Sync Bridge. Наводим мосты или как связать между собой асинхронный и синхронный интерфейсы без помощи ccBPM.
и здесь:
Sync-Async Bridge или что нам стоит мост построить, часть вторая.

Содержание:
4. Отправка system acknowledgement в асинхронно-синхронных мостах (с версии 7.3).
5. Асинхронно – синхронный мост через mapping lookup.
6. Рекомендации по выбору варианта моста.
7. Дополнительная информация.

4. Отправка system acknowledgement в асинхронно-синхронных мостах (с версии 7.3)

Начиная с версии SAP PI 7.3 в пул модулей для построения мостов была добавлена пара новых модулей для отправки исходной системе технического подтверждения о доставке. Дело в том, что в обычных интерфейсах, если система-отправитель запросила техническое подтверждение (system acknowledgement), канал связи автоматически возвращает техническое сообщение-подтверждение.
В случае асинхронно-синхронного моста автоматическая отправка такого подтверждения не работает.

Для отправки такого подтверждения с версии SAP PI 7.3 нужно использовать следующие модули:

SendAckBean
Применяется для отправки исходной системе технического подтверждения доставки (system acknowledgement). Модуль устанавливается самым последним в цепочке модулей. Необходимо также использовать CloneMessageBean.

CloneMessageBean
Применяется для замены обрабатываемого сообщения копией. Вся дальнейшая цепочка модулей будет работать с копией, оставив исходное сообщение нетронутым. Модуль используется только в связке с SendAckBean в асинхронно-синхронном мосте.

Для включения модулей в канал связи нужно перейти на вкладку “Module” и внести следующие значения:

Module Name Type Module Key
AF_Modules/CloneMessageBean Local Enterprise Bean key2
Local Enterprise Bean Другие модули адаптера и моста
AF_Modules/SendAckBean Local Enterprise Bean key1

“Module Key” может быть любым, параметров настройки данные модули не имеют.

5. Асинхронно – синхронный мост через mapping lookup.

Отдельно хочу упомянуть возможность построения асинхронно-синхронного моста через мэппинг.
Схема такого моста выглядит следующим образом:

Рис.1: асинхронно-синхронный мост с помощью Mapping Lookup

Рис.1: асинхронно-синхронный мост с помощью Mapping Lookup

Плюсы:

  • Удобен для небольшого количества данных.
  • Начиная с версии SAP PI 7.1 RFC и JDBC lookup введены в стандартные функции мэппинга и не требуют знания Java.

Минусы:

  • Требует знания Java (для RFC и JDBC – версии PI до 7.0 включительно, остальные адаптеры – для любой версии)
  • Производительность сильно зависит от объема данных.
  • Смешивание логики преобразования формата сообщений и транспорта/маршрутизации.
  • Так как используется Java, то это клиентская разработка – требуется поддержка интерфейса программистом.

Надо сказать, что основное назначение lookup – получение дополнительных данных из внешней системы в процессе мэппинга сообщений.

Для построения такого моста необходимо создать следующие объекты:

Рис.2: Объекты разработки в Integration Repository

Рис.2: Объекты разработки в Integration Repository

Настроенный RFC Lookup в преобразовании выглядит так:

Рис.3: Message Mapping - RFC Lookup

Рис.3: Message Mapping – RFC Lookup

В Integration Directory необходимо настроить стандартный асинхронный интерфейс со всеми каналами связи и правилами маршрутизации. Дополнительно нужно будет создать еще один канал связи (по которому будет проходить RFC-вызов) и указать этот канал связи в параметрах Interface Determination.

Если все настроено правильно, то в процессе выполнения мэппинга будет сделан RFC-вызов и результаты его будет видно на выходе интерфейса – в сообщении-ответе.

Более подробнее о look-up можно узнать здесь:

Usage of SOAP Lookup and RFC Lookup in a Single Mapping Program (sdn.sap.com, english)
Adding Lookups to Mapping Programs (help.sap.com, NW7.3, english)

6. Рекомендации по выбору варианта моста.


Какой же вариант моста выбрать для своего интерфейса? Вопрос творческий, но попробую дать несколько рекомендаций:

  • Для начала, смотрим на интерфейс и пытаемся понять – а можно ли обойтись совсем без моста? Да-да.
    Возможно, проще изменить логику работы одной из систем, чем подключать модули и увеличивать сложность интерфейса.
    Это вообще “золотое” правило работы в PI: чем проще интерфейс – тем он быстрее и надежнее.
  • Смотрим на исходную систему и понимаем тип моста: асинхронно-синхронный или синхронно-асинхронный.
  • Выбираем основной канал связи, в котором будем “строить” мост. В общем случае – предпочтительнее делать это в receiver communication channel. В этом варианте сообщение обрабатывается в PI в обычном режиме и меняет свои свойства только в одном месте – адаптере системы-получателя. Но бывают причины, когда такой вариант невозможен – например, для связи с конечной системой уже существует канал, он используется совместно несколькими интерфейсами. Либо нет возможности добавить необходимые модули в адаптер (безопасность, адаптер и так нагружен большим количеством подключенных модулей). В таких условиях для модулей моста используется Sender Communication channel.
  • Объем информации, проходящей через асинхронно-синхронный мост. Если при помощи моста нужно получить дополнительные значения одного-двух полей из ERP, базы данных или web-сервиса – используйте mapping lookup. Если же информации больше – то нужен полноценный мост.
  • Нужен ли нам мэппинг? Если нужен – только в одну или в обе стороны? Проверяем, доступен ли необходимый нам мэппинг в выбранном варианте моста.

И главная рекомендация – не бойтесь и экспериментируйте, все у вас получится!

7. Дополнительная информация.

Официальная информация по мостам на базе модулей в составе справки на SAP Netweaver 7.4 (English):
Configuring Async/Sync and Sync/Async Bridge in the JMS Adapter

Пошаговая инструкция-пример от SAP на SDN.SAP.COM (English):
“Async/Sync and Sync/Async Bridge Scenarios Configuring Async/Sync Bridge and Sync/Async Bridge
without BPM”

© Алексей Петров, 2014

5 thoughts on “Наводим мосты – 3: экзотика и рекомендации.

  1. Дмитрий Олейников

    Спасибо за понятные статьи! Не могли бы Вы в одной из будущих статей обратиться к теме подтверждения сообщений? имеется в виду различные acknowledgementы. как сделать, чтобы PI (версий младше чем 7.3) слал отправителю подтверждение, что сообщение успешно достигло получателя? Как сделать, чтобы SAP ERP рапортовал об успешности (или провале) обработки присланного сообщения?

    Reply
    1. pitroff.ru Post author

      Спасибо на добром слове, Дмитрий!

      Записал в планы, быстро не обещаю – очень много работы сейчас.

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

      Далее – кому нужно отправить подтверждение или ошибку:
      – администратору – это Alert Framework;
      – исходной системе – тут можно использовать ccBPM (при инсталляции ABAP+J2EE), ALEAUD в IDoc’ах, ну и ABAP никто не отменял – сделать в обработке полученных данных обратный вызов (“ERP -> PI -> исходная система) и отправить свое подтверждение.

      Reply
      1. Дмитрий Олейников

        Спасибо за наводки. Я время от времени экспериментирую с попытками отправлять и получать подтверждения. Но, получается не все понимаю. Вот чего добился на сегодняшний день:
        1)SYSTAT01 – при получении такого IDOC, ERP меняет статус указанного внутри IDOC на указанный – это может служить для передачи статуса из внешней системы (ну например, ПРИНЯТ, а с остальными отдельно разбираться, почему не пришел статус). Есть сложность отправки systat из ЕРП во внешнюю систему – нужно писать свои программы для отработки всех видов IDOC, которые мы используем.
        2)через программу RBDSTAT формировать ALEAUD и отправлять их на отдельный порт, который слушается например через JCo. Мне программисты написали спец. заглушку, которая просто принимает IDOC. Но тут проблема, как сопоставить ответ и исходное сообщение. Получается у нас передающая система не имеет ID документа, который есть в САП.
        3) есть планы попробовать сделать Z_RBDSTATE, чтобы слать ZALEAUD, так как PI сразу превращает обычный ALEAUD в XI ответ и мне не удалось его пробросить дальше в вызываемую систему.
        4)сделан прототип схемы обхода PI, когда внешняя система отправляет IDOC напрямую в ERP. Причем, ответный ALEAUD содержит DOCNUM переданного сообщения! Но, тут вызывает подозрения ненадежность или потенциальная сложность системы, чтобы как-то приблизиться к характеристикам PI по возможности мониторинга.
        Может что-то у нас не так настроено, где-то галочка не стоит, какая-то связка не указана в схеме распределения, что-то неверно в профиле партнера или настройке порта.
        С нетерпением жду, когда у Вас появится время написать статью про акноледжменты.

        Reply
  2. Андрей Петин

    Мне кажется, стоит подчеркнуть то, что в зависимости от размещения модулей сообщение в AEX будет проходить либо в синхронном режиме, либо в асинхронном.
    Т.е., если модули Async-Sync Bridge размещены в канале-сендере, то сообщение сразу будет считаться синхронным со всеми вытекающими – невозможность переотправки, сразу перевод в статус Canceled (хотя это может быть и неплохо).

    Reply
    1. pitroff.ru Post author

      Да, спасибо, Андрей, дельное замечание.

      Если нужна гарантированная доставка – тогда модули в receiver channel, если важнее сам факт “отработал”-“не отработал”, а ошибками занимается исходная система – то тогда модули ставим в sender channel.

      Reply

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

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