Введение

Подавляющее большинство интеграционных сценариев, в которых применяется интеграционная шина SAP PI, протекают следующим образом. Система-источник выполняет запрос, SAP PI осуществляет преобразование данных запроса, система-получатель выполняет обработку запроса и формирует ответное сообщение, SAP PI выполняет преобразование данных ответа и возвращает его системе-отправителю (рис. 1).

Рис. 1

Однако существуют ситуации, в которых сценарий интеграции отходит от описанной выше схемы. Примером такой ситуации является обработка запроса исключительно с помощью SAP PI (т.е. преобразования и данных запроса, и самого запроса), ввиду отсутствия системы-получателя данных (рис. 2).

Рис. 2

Подобный сценарий в SAP PI невозможно реализовать штатно, так как система требует явного указания системы-получателя и применение активного канала.

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

Общая схема интеграции

В ходе статьи будет настроена следующая цепочка взаимодействия:

Система-отправитель синхронно посылает XML-сообщение, которое будет передано в систему-посредника, являющейся СУБД.

В СУБД сообщение будет передано как SQL-запрос по принципу “SELECT ‘<XML-сообщение>’ as RESULT”.

 База данных без преобразования вернёт XML-сообщение в качестве ответного сообщения системе-отправителю.

 В свою очередь SAP PI выполняет преобразование XML-сообщения в SQL-запрос и последующее преобразование SQL-ответа обратно в XML-сообщение без потери полезной нагрузки (рис. 3).

Рис. 3

В предложенном ниже решении будут использованы СУБД Microsoft SQL Server и XSLT-преобразования. В общем случае в качестве СУБД можно использовать не только SQL Server, но и любую другую систему, для которой имеется JDBC-драйвер (с соответствующей адаптацией текста SQL-запроса). Преобразование может быть выполнено и другими доступными способами, например, через Java-класс или через Message Mapping c применением UDF. Message Mapping является не очень удобным способом, так как для работы программы требуется обозначение типа сообщения (потребуется создавать копию Message Mapping для каждого типа сообщения), а отдельный Java-класс требует предварительной компиляции в JAR-пакет. Стоит также отметить, что XSLT является менее производительным вариантом реализации, но более универсальным и гибким.

Подготовка JDBC-адаптера для системы-посредника

Для корректной работы SAP PI мы не можем избежать (по состоянию программного продукта на дату написания статьи) работы с внешней системой и адаптером. В задачу адаптера входит изменение метаданных сообщения (замена системы-отправителя и системы-получателя). Для отработки адаптера выбираем внешнюю систему-посредника, являющейся СУБД, для примера я выбрал Microsoft SQL Server. В продуктивном ландшафте желательно использовать СУБД с минимальным временем отклика для работы с SAP PI, вплоть до подключения интеграционной шины к системной базе данных, используемой SAP PI для собственных нужд.

Настройка самого адаптера ничем не отличаются от обычной настройки JDBC-адаптера в SAP PI. С точки зрения безопасности для полноценной работы интеграционного сценария пользователю СУБД требуется присвоить минимальные полномочия (достаточно разрешения подключения к системе), так как обращений к процедурам, функциям и таблицам базы данных происходить не будет. 

Конвертация запроса (XML => SQL)

Запрос от системы-источника необходимо преобразовать в SQL-запрос. Для этого воспользуемся XSLT-шаблоном, работа которого описана ниже. Шаблон подходит только для SQL Server в