Давайте теперь разберемся, как работает маршрутизация сообщения в SAP PI. Примером нам послужит.. обычная почта!
Весь цикл статей:
SAP Process Integration – основы. Часть 1: историческая.
SAP Process Integration – основы. Часть 2 – обзор архитектуры.
SAP Process Integration – основы. Часть 3 – System Landscape Directory.
Основы SAP PI. Часть 4 – “Что такое интерфейс?”.
Основы SAP PI. Часть 5 – “Integration Directory, настройка интерфейса“
Основы SAP PI. Часть 6 – “Правила маршрутизации и pipeline. Почтальон Пиайкин за работой.“
Основы SAP PI. Часть 7 — «Системы всего ландшафта – соединяйся! Адаптеры».
Итак, SAP Process Integration получает на вход одного из адаптеров некое “послание”, переводит его во внутренний формат и передает в Integration Engine.
Правила маршрутизации.
Получив конверт, “почтальон” сначала определяется, от кого оно (на нашей почте письма без обратного адреса не обрабатываются). В SAP PI “от кого” означает имя бизнес-системы – отправителя и исходящий интерфейс. За этот выбор отвечает специальный объект Integration Directory – Sender Agreement.
Если по каналу связи можно однозначно определить отправителя – то объект Sender Agreement не нужен. Например, канал связи RFC позволяет сказать – из какой системы и с какого функционального модуля пришел вызов; файловый канал связи обязательно требует наличия Sender Agreement.
Затем выясняем – кому предназначено сообщение, то есть определяем по заданному правилу имя бизнес-сиcтемы – получателя сообщения.
За это отвечает объект Receiver Determination.
Следующим этапом нужно понять – куда доставить сообщение, на какой адрес? В SAP PI этому этапу соответствует выбор интерфейса – получателя, объект ID – Interface Determination.
Поскольку у нас супер-почтальон 🙂 – перед ним стоит еще одна задача: если язык отправителя (исходящий интерфейс) отличается от языка получателя (входящий интерфейс), то почтальон должен “перевести” сообщение с одного языка на другой. Для выполнения этого в объекте Interface Determination указывается не только целевой интерфейс, но и Interface Mapping из репозитария ESR – то есть определяется, какая программа преобразования должна быть выполнена для заданной пары интерфейсов во время передачи сообщения.
Ну и в завершении почтовой процедуры нужно выбрать способ доставки (авиа, наземное, голубиной почтой :). В правилах маршрутизации – это выбор канала связи, за что отвечает Receiver Agreement.
Полная схема работы правил маршрутизации будет выглядеть так:
Integrated Configuration – маршрутизация в J2EE.
Вспомним, что мы с вами говорим о “полной” инсталляции SAP PI – то есть ABAP+J2EE. Из обзора архитектуры мы знаем, что Integration Engine работает в ABAP-части; также знаем, что есть вариант инсталляции, в котором присутствует только J2EE сервер.
А как же там устроена маршрутизация?
В процессе работы над улучшением производительности SAP PI программисты SAP придумали новый способ маршрутизации, позволяющий не использовать ABAP-часть. В дальнейшем, появилась возможность инсталляции Process Integration без ABAP – только Advanced Adapter Engine Extended(AAEX) на базе J2EE-сервера.
Для такой маршрутизации был создан отдельный объект конфигурации – Integrated Configuration. В варианте AAEX объект Integrated Configuration становится единственным способом задания правил маршрутизации.
Но, с точки зрения алгоритма обработки сообщения – он ничем не отличается от Integration Engine. Логика работы точно такая же; все те же “вопросы почтальона”: “От кого?” – “Кому?” – “Куда?” – “Как?”. Основное отличие – все настройки правил маршрутизации производятся в одном объекте:
Вот таким образом SAP Process Integration определяет – как и куда отправить принятую информацию. На самом деле, в правилах маршрутизации существует большое количество дополнительных возможностей и опций (например, тиражирование сообщения на несколько получателей или маршрутизация по условию) – но о них мы будем говорить позже.
Да, кстати, если сравнить со схемой работы XI 2.0 SR1 – c тех пор почти ничего не поменялось 🙂
“Почтальон” за работой: pipeline.
Давайте теперь рассмотрим процесс обработки сообщения от подачи на вход SAP PI до отсылки его получателю.
Введем новый термин – конвейер обработки сообщений или pipeline.
Pipeline – это строго определенная последовательность действий по обработке сообщения внутри Integration Server (или подсистемы обработки сообщений в случае AAEX).
Итак, сообщение из бизнес-системы поступает на вход адаптера. Адаптер переводит его во внутренний формат SAP PI – SOAP-XI XML-документ и передает на вход pipeline.
Далее выполняется следующая цепочка шагов:
- Определение получателя.
- Определение интерфейса-получателя.
- Тиражирование сообщения (в случае, если определено несколько различных получателей).
Далее сообщение (или каждая из его копий) проходит следующие шаги:
- Мэппинг.
- Техническая маршрутизация (выбор канала связи с получателем).
- Передача сообщения адаптеру.
Здесь сообщение покидает pipeline. Адаптер переводит его во внешний формат и передает получателю.
Если собрать воедино всю изученную нами информацию, то схема типового интерфейса в SAP PI будет выглядеть следующим образом:
Над каждым из шагов исполнения расположен соответствующий ему объект разработки и/или настройки. Схему удобно использовать при создании собственных интерфейсов на первых порах, чтобы не пропустить какой-либо из объектов или разобраться, на каком шаге произошла та или иная ошибка.
На схеме даны основные объекты. Детализацию (к примеру, из каких подобъектов разработки состоит Outbound Interface) мы рассмотрим позже.
Вот так вот и работает наш почтальон Пиайкин, разбирая приходящую почту. 🙂
На сегодня это все, продолжение следует.
Удачи в интеграции!
Ваш Pitroff.
Алексей, спасибо за цикл статей.
Подскажите насчет Sender Agreement.
Насколько я понимаю, имя канала не является ключом.
Соответственно, теоретически можно создать несколько Sender Agreement для разных систем, но указать там один и тот же канал (например, файловый). Как же в этом случае для входящего сообщения будет определяться отправитель?
Андрей, канал для Sender Agreement как раз ключ. SA нужен для того, чтобы определить (для тех каналов, где это невозможно определить из сообщения или технической информации) как заполнить ключевые поля в заголовке сообщения. То есть если для конкретного файлового канала определен SA, то все, что приходит с этого канала, считается отправленным от системы и интерфейса, заданных в этом SA.
Алексей, спасибо за ответ.
То, что вы написали, мне понятно.
Но ведь для Sender Agreement ключом является заголовок отправителя – система, интерфейс, пространство имён, то есть этот набор значений уникален среди Sender Agreement’ов.
А именно канал я могу задать один и тот же в разных SA.
То есть, к примеру, теоретически я могу прописать один и тот же канал cc_FileSender_Out в двух разных SA: для системы (service) SYS1 и SYS2.
Если в папке, указанной в канале cc_FileSender_Out, появится файл, то какая система-отправитель будет определена? Ведь этот канал указан в SA для нескольких систем.
Вроде бы Integration Builder не ругается, если в разных SA канал совпадает (у меня, правда, PI версии 7.0).
Попробовал на SOAP-каналах.
Кажется, в этом случае берётся первый по порядку SA, подходящий по используемому каналу.
С файловыми адаптерами такого не выйдет, там должно быть однозначное соответствие.
По SOAP – не проверял, но даже в древнем манускрипте 🙂 пишут, что
“Using the Sender JMS, JDBC/File/FTP, or SOAP Adapter.
…
· There must be exactly one sender agreement for each communication channel”
http://help.sap.com/saphelp_erp2004/helpdata/en/b1/f29e7a56e18a439984a3c6630951d2/content.htm
Большое спасибо, идея теперь понятна.
Спасибо огромное за потраченное время! Кратко,но емко и понятно -высший класс! Прояснили мне целостную картину,спасибо!