liveruwow

В практике разработки интерфейсов на SAP Process Integration достаточно. Информацию (синхронный режим), вызвать web-сервис (в асинхронном режиме). Параметры модулей задаются там же, на вкладе «Module» в разделе. Рис.4: Схема примера асинхронно-синхронного моста SOAP-RFC-File. Once ago I worked on the scenario where plain text file had to be taken along with additional file. Модулей, разработка RFC-модулей, отчетов с использованием языка ABAP. И поддержка программного обеспечения для нужд компании, поддержка web-сайта. Service Manager at Philip Morris International.

Первая ссылка, как впрочем и все остальные на SDN, подразумевает использование SOAP адаптера для XI. А вот за вторую - отдельное спасибо! Походу не прорабатывался в базовой ERP вопрос стыковки IDoc напрямую в WebService. Чтож, придётся ваять собственную технологию.

Предположительно, формирование и выдача готового IDoc в XML формате - максимально стандарт. Далее, некая программка, отрабатывающая по событию пост-обработки выдачи в порт и использующая связку тип сообщения - сервис для формирования структур вызова опять же стандарных классов, сформированных SAPом по WSDL. Дело в том, что существующие в R/3 механизмы обмена через ALE и WSDL не удаётся 'безшовно' подружить между собой. Да, есть HTTP-port с меткой SOAP, есть WSDL сервис работающий, но не нашли настройки, которая бы связывала определённый порт с методом send WSDL и генерила бы стандартную оболочку сервиса над IDOC. Пока тема открыта, т.к. ABAP разработку (для оборачивания IDOC в WSDL) не делали и настройки нет.

Сейчас всё работает по FTP. Дыбра — это животное в дебрях тундры, брат бобра и выдры, враг кобры и пудры, бодро тыбрит ядра кедра в ведрах и дробит добро в недрах. Дело в том, что существующие в R/3 механизмы обмена через ALE и WSDL не удаётся 'безшовно' подружить между собой. Да, есть HTTP-port с меткой SOAP, есть WSDL сервис работающий, но не нашли настройки, которая бы связывала определённый порт с методом send WSDL и генерила бы стандартную оболочку сервиса над IDOC.

Пока тема открыта, т.к. ABAP разработку (для оборачивания IDOC в WSDL) не делали и настройки нет. Сейчас всё работает по FTP. Тут какая-то путаница в терминологии, по-моему. WSDL - это метаданные, что-то вроде сигнатуры веб-методов и описание типов данных. Наверное, имеется в виду, оборачивание в SOAP Envelope. А WSDL по большому счету не так уж и нужен, если разработчик у интерфейсов один и тот же.

По существу вопроса - а разве нельзя сделать функциональный модуль с параметром в виде структуры IDoc, и на базе его сгенерировать веб-сервис?

Содержание: 1. 2.1 2.2 2.3 2.4 1. Что такое «мосты» в интеграции?

В практике разработки интерфейсов на SAP Process Integration достаточно часто встречается задача по связыванию систем, работающих в разных режимах. Предположим, необходимо принять файл (асинхронный режим), передать его при помощи RFC-вызова в SAP ERP (синхронный режим), а ответ, в свою очередь, выгрузить на FTP в виде файла (асинхронный режим). Или другая задача: из системы ERP запросить у внешней системы дополнительную информацию (синхронный режим), вызвать web-сервис (в асинхронном режиме), затем предоставить web-сервис для ответа (то есть ждать асинхронного вызова от внешней системы) и вернуть ответ в ERP ожидающей программе. В общем виде эти задачи можно представить следующим образом. Рис.2: Синхронно — асинхронный мост В SAP Process Integration есть два способа решить такого рода задачу:.

Использовать ccBPM. Для этого нужно создать интеграционный процесс в SAP PI и использовать его элементы для построения моста.

Плюсы — мост можно использовать в сложном процессе, связывающем множество систем. Минусы — время разработки и тестирования, сложность мониторинга и отладки, невозможность использования ccBPM на Single Stack инсталляции. Данный способ я рекомендую использовать только в том случае, если нужно включить мост в более сложный процесс ccBPM. Подробнее о ссBPM Bridge можно почитать на help.sap.com:. Использование стандартных модулей адаптеров.

Плюсы — скорость разработки сопоставима с обычным интерфейсом, используются стандартные элементы разработки, простая отладка и мониторинг. Минусы — нужна аккуратность при заполнении параметров модулей, трудно для новичков, закрытый код модулей, путанная (и иногда противоречивая) информация в интернете. Давайте рассмотрим поближе второй способ построения мостов. Async-Sync Bridge. Познакомьтесь — RequestResponseBean и ResponseOnewayBean. Начнем с асинхронно-синхронного моста.

Напомню, это случай, когда исходная система работает в асинхронном режиме, то есть отправкой запроса и ожиданием ответа занимаются разные (условно-независимые) ее части. Целевая система, в свою очередь, синхронизирует запрос и ответ, и отправляет ответ в тот же канал, по которому пришел запрос. Я сознательно буду по минимуму затрагивать процесс создания самих интерфейсов и программ мэппинга в Integration Builder, возможные затруднения разобраны в примерах. В работе этого варианта моста принимают участие два модуля:. RequestResponseBean отвечает за преобразование асинхронного сообщения в синхронное и передачу его либо далее по цепочке модулей, либо в подсистему обработки сообщений PI. ResponseOnewayBean — модуль, преобразующий синхронное сообщение-ответ в асинхронное и перенаправляющий его получателю.

Модули могут быть использованы как в канале-отправителе (sender communication channel), так и в канале-получателе (receiver communication channel). Дополнительная информация: модули в адаптере выполняются один за другим, в порядке размещения (сверху-вниз) на вкладке «Module» в настройках канала связи.

Выходные данные вышестоящего модуля являются входными для следующего. В списке модулей всегда присутствует собственный модуль адаптера, CallSAPAdapter. Параметры модулей задаются там же, на вкладе «Module» в разделе «Module Configuration». Для включения модулей в канал связи нужно перейти на вкладку «Module» и внести следующие значения: Module Name Type Module Key AFModules/RequestResponseBean Local Enterprise Bean RqResp CallSAPAdapter Local Enterprise Bean sap AFModules/ResponseOnewayBean Local Enterprise Bean RespOneW «Module Key» может быть любым — главное, чтобы он был уникальным и ключи было бы сложно перепутать — это поможет нам впоследствии при определении параметров модулей. Дальнейшие настройки зависят от того, где мы разместили наши модули — в канале-отправителе (sender communication channel) или канале-получателе (receiver communication channel). 2.1 Асинхронно-синхронный мост с модулями в Sender Communication Channel Логика работы модулей в Sender Channel следующая. Рис.3: Логика работы асинхронно-синхронного моста при размещении адаптеров в канале связи отправителя.

Прием асинхронного сообщения по каналу связи с внешней системой, передача его модулю RequestResponseBean. Модуль меняет тип сообщения с асинхронного на синхронный, прописывая это в техническом заголовке сообщения. В зависимости от параметра passThrough либо передаем сообщение дальше по цепочке модулей, либо напрямую в подсистему обработки PI (пропуская п.3).

Обработка сообщения стандартным модулем адаптера, передача его в подсистему обработки сообщений PI. Отправка запроса через синхронный канал связи. Синхронный вызов внешней системы, получение результата. Прием ответа из синхронного канала связи. Возврат ответа в модуль ResponseOnewayBean, который, в свою очередь, меняет тип сообщения с синхронного на асинхронный и, используя параметры настройки, определяет — в какую систему отдать ответ. Передача сообщения в выбранный канал связи. Доставка сообщения во внешнюю систему по асинхронному каналу связи.

Параметры модуля RequestResponseBean при размещении его в Sender Communication Channel: Параметр Назначение Возможные значения Значения по умолчанию passThrough Определяет, куда модуль должен передать обработанное сообщение: — подсистеме обработки сообщений PI — false; — следующему модулю в цепочке — true true/false false timeout Время ожидания ответа модулями моста, начиная с момента окончания работы модуля RequestResponseBean. Задается в миллисекундах 300000 Не забывайте, что параметры в Java — контекстно-зависимые и никакой проверки при сохранении канала для этих параметров не проводится! Ошибки в написании и регистрах букв всплывут только при тестировании, причем порой очень сложно понять причину ошибки. Параметры модуля ResponseOnewayBean при размещении его в Sender Communication Channel: Параметр Назначение Возможные значения Значения по умолчанию receiverParty Наименование Communication Component и Party(если есть) для системы — получателя.

Необязательный. Если не задано — система пользуется данными из технического заголовка сообщения. ReceiverService Необязательный. receiverChannel Имя канала связи получателя. Необязательный.

Если не задано — система ищет подходящий receiver agreement, основываясь на информации в техническом заголовке сообщения. AdapterType Параметры канала связи — тип и пространство имен адаптера канала связи получателя. Необязательный. Значения можно взять из канала связи в Integration Builder — поле Adapter Type.

Пример значений: File, adapterNamespace Необязательный. При желании можно также обрабатывать сообщения об ошибках: Параметр Назначение Возможные значения receiverChannelOnFault Имя канала связи получателя для сообщений об ошибках. ReplaceInterfaceOnFault true — заменить интерфейс и пространство имен сообщения об ошибке приложения на собственные; false — не трогать заголовок сообщения true/false interfaceOnFault Имя интерфейса для замены в заголовке interfaceNamespaceOnFault Пространство имен интерфейса для замены в заголовке сообщения. — теоретически, можно не задавать параметров вообще.

Нужно будет только создать «искусственный» receiver agreement, где будут заданы: система отправитель = синхронная система, получатель = конечная асинхронная система, интерфейс = исходный интерфейс-запрос. «Искусственный» — потому как PI не даст выбрать такой набор параметров в agreement — их придется прописывать в полях объекта вручную (copy-paste). Именно такая «каша» образуется в заголовке возвращаемого от синхронной системы сообщения в результате работы моста. Если типы адаптеров исходной асинхронной системы и конечного получателя не совпадают — придется все же задать adapterType и adapterNamespace конечного канала связи. На практике — проще аккуратно задать все необходимые параметры в настройках модуля.

После того, как мы установили необходимые модули в Sender Communication Channel, нам остается лишь создать правила маршрутизации, связывающие исходную асинхронную систему с синхронной системой. Это можно сделать двумя способами:. создать связку Receiver Determination - Interface Determination - Receiver Agreement. создать Integrated Configuration Маршрутизация ответа от синхронной системы будет автоматической, до конечной точки сообщение направит модуль моста. 2.2 Пример асинхронно-синхронного моста с модулями в Sender Communication Channel. Давайте посмотрим, как это выглядит на практике.

Схематично мост выглядит следующим образом. Рис.4: Схема примера асинхронно-синхронного моста SOAP- RFC-File Исходная система запрашивает дополнительную информацию о персоне/партнере по некоторому ID.

Передача запроса осуществляется посредством вызова асинхронного web-сервиса. Информация храниться в ERP (в данном конкретном примере — это ABAP часть инсталляции PI).

Получение информации возможно путем синхронного вызова функционального модуля, доступного по RFC. Ответ должен быть выгружен в файловую систему (в данном случае — папка на сервере PI) в виде XML-файла, откуда, «по легенде», он будет забран внешней системой. Для реализации этого интерфейса нам понадобятся следующие объекты разработки. Рис.9: Синхронный Operation Mapping между двумя асинхронными интерфейсами и RFC Дело в том, что система не даст создать двусторонний синхронный мэппинг, так как исходный интерфейс SIExtSystemRequestAsync у нас асинхронный. Хотя, на этапе выполнения интерфейса, модули моста «создадут видимость» синхронной работы и мэппинг будет выполнен в обе стороны.

Алгоритм создания объекта OMExtSystemRequesttoRFC следующий:. Создаем Message Mapping MMExtSystemRequesttoRFC для интерфейсов SIExtSystemRequestAsync и ZZEXTREQUEST. Создаем Message Mapping MMRFCtoExtSystemResponse для интерфейсов ZZEXTREQUEST.Response и SIExtSystemRequestAsync. Внимание: редактируем исходный интерфейс SIExtSystemRequestAsync: меняем его тип на синхронный, добавляем в качестве ответа message type из интерфейса SIExtSystemResponse. Сохраняем, но НЕ АКТИВИРУЕМ. Создаем Operation Mapping, исходный интерфейс — SIExtSystemRequestAsync(он у нас сейчас синхронный), целевой — RFC.

Подставляем мэппинги из пунктов 1 и 2 во вкладки request и response соответственно. Отменяем изменения интерфейса (возвращаем его в прежний, асинхронный вид). Активируем все изменения.

Таким способом мы получили мэппинг OMExtSystemRequesttoRFC, который будет выполнять все преобразования в нашем интерфейсе. Теперь переходим к настройке интерфейса, запускаем Integration Builder и создаем следующие объекты. Рис.16: Файл с дополнительной информацией из ERP Итак, мы настроили пример асинхронно-синхронного моста с модулями в канале связи системы отправителя.

Поздравляю Вас, можно немного передохнуть, а затем переходить к следующему варианту моста. 2.3 Асинхронно-синхронный мост с модулями в Receiver Communication Channel. Предположим, что мы не хотим (или не можем) затрагивать Sender Communication Channel. Существует возможность разместить те же модули в синхронном канале связи системы-получателя. Логика работы асинхронно-синхронного моста с модулями в канале получателя следующая.

Рис.17: Логика работы асинхронно-синхронного моста при размещении адаптеров в канале связи получателя. Прием асинхронного сообщения по каналу связи с внешней системой.

Передача сообщения в PI. Обработка сообщения в PI, передача его в синхронный канал связи на вход модуля RequestResponseBean. RequestResponseBean переводит тип сообщения из асинхронного в синхронный, затем, используя параметры настройки, определяет — в какую систему вернуть ответ. В зависимости от параметра passThrough, сообщение либо передается далее по цепочке модулей до стандартного адаптера, либо напрямую в модуль ResponseOnewayBean (пропуская пп.4-6). Синхронный вызов внешней системы, получение результата. Возврат ответа в модуль ResponseOnewayBean, который меняет тип сообщения с синхронного на асинхронный.

Возврат ответа в подсистему обработки сообщений, которая проводит маршрутизацию на базе заголовка сообщения. Параметры в заголовке сообщения изменены модулем RequestResponseBean на шаге 4. Передача сообщения в выбранный канал связи. Доставка сообщения во внешнюю систему по асинхронному каналу связи. Мост строиться с использованием все тех же модулей RequestResponseBean и ResponseOnewayBean. Параметры модуля RequestResponseBean: Параметр Назначение Возможные значения Значения по умолчанию passThrough Определяет, куда модуль должен передать обработанное сообщение: — следующему модулю в цепочке — true; — напрямую в модуль ResponseOnewayBean — false; true/false false timeout Время ожидания ответа модулем, начиная с момента отправки сообщения далее. Задается в миллисекундах 300000 Для модуля ResponseOnewayBean, включенного в Receiver Communication Channel, возможных параметров немного — мы, при необходимости, можем только при получении сообщения об ошибке заменить в заголовке интерфейс на свой (например, с целью изменить дальнейшую маршрутизацию).

Параметр Назначение Возможные значения replaceInterface true — подменить интерфейс-отправитель и его пространство имен в сообщении; false — не трогать заголовок сообщения true/false interface Имя интерфейса для замены в заголовке. Заменяется интерфейс-отправитель. Рис.23: Объекты разработки в Integration Repository Итого:.

Два асинхронных интерфейса для асинхронной системы (запрос и ответ): SIExtSystemRequestAsync и SIExtSystemResponse. Синхронный интерфейс SISOAPADDINFOSync. Асинхронный интерфейс SIERPSOAPResponseAsync (передает сообщение ZZSOAPEXTREQUEST.Response от синхронного SISOAPADDINFOSync).

Асинхронный Operations Mapping для запроса OMExtSystemRequesttoSOAPRequest. Асинхронный Operations Mapping для ответа OMERPSOAPResptoExtSystemResponse Объекты создаются стандартным способом, никаких особенностей или технических хитростей тут нет.

Единственное, при активации мэппинга OMExtSystemRequesttoSOAPRequest система выдаст предупреждение о несоответствии типов интерфейсов, но активации объекта это не помешает. Теперь, когда все объекты разработки у нас готовы — переходим к настройке в Integration Directory. Рис.26: Канал связи SOAP Receiver — настройка модулей Параметры модуля ResponseOnewayBean задают имя и пространство имен интерфейса для замены в заголовке сообщения.

В результате работы модуля сообщение-ответ от SOAP меняет заголовок и становиться асинхронным, отправленным с интерфейса SIERPSOAPResponseAsync. ВНИМАНИЕ: с синхронным вызовом адаптера RFC такая подмена НЕ РАБОТАЕТ! Для организации моста с синхронным RFC нужно использовать прием с синхронным мэппингом и Receiver Determination (или Integrated Configuration),. Для создания Integrated Configuration обязательно наличие двух каналов связи — отправителя и получателя. Но канал SOAP у нас определен как получатель, и использовать его для маршрутизации ответа не получится. Выход — создать псевдо-канал, который займет место в Integrated Configuration на вкладке Inbound Processing.

Тип адаптера для этого канала не важен, я выбрал SOAP. ↓.

pitroff.ru Post author Женя, спасибо за дополнение! LookUp — да, можно попробовать. Поставлю это в следующую статью, в раздел «Экзотика».

) Насчет «самая простая» — не соглашусь, есть ньюансы: нужно хотя бы минимально знать java и при разработке учитывать производительность lookup. Да, не уверен еще, что на все адаптеры можно настроить lookup (RFC, JDBC, SOAP — точно можно, остальные — надо смотреть).

Фактически, нужно будет сделать собственную разработку. Мост на модулях — это стандарт. Не очень «прямой»:), но стандарт. ↓.

Райчо Привет, Я думаю что ошибка получается в AFModules/ResponseOnewayBean. Это часть лога обработки сообщения: 3/28/2014 10:33:27 AM Information SOAP: completed the processing 3/28/2014 10:33:27 AM Information SOAP: continuing to response message ed2abb59-b685-11e3-c9297d6 3/28/2014 10:33:27 AM Information MP: processing local module localejbs/AFModules/ResponseOnewayBean 3/28/2014 10:33:27 AM Error MP: exception caught with cause com.sap.aii.adapter.xi.routing.RoutingException: InterfaceDetermination did not yield any actual interface Другие тоже получают тоже самую ошибку: Если можете помочь буду благодарен 🙂. ↓. pitroff.ru Post author Привет, не похоже, скорее всего — ошибка правил маршрутизации. На SCN таких ошибок много, причем иногда — интерфейс вообще модули не использует. Модуль ResponseOnewayBean начинает свои сообщения об ошибке с «ROB:».

🙂 Еще раз — проверьте обратную маршрутизацию, алгоритм поиска такой (если Вы используете Integrated Configuration — то искать на соответствующей вкладке): — посмотреть внимательно, совпадает ли имя интерфейса в параметрах модуля ResponseOneWayBean с именем интерфейса-отправителя в Receiver Determination — может быть банальная опечатка в настройках модуля. — проверить Interface Determination — есть ли условия на маршрутизацию (если ни одно не выполняется — то будет как раз такая ошибка). — посмотрите в тексте сообщения — сменился ли интерфейс по итогам работы ResponseOneWayBean — в заголовке SOAP-XML, в разделе Sender. По итогам — будем дальше смотреть.

↓. Райчо Привет, Я посмотрел опять — имя и пространство имен в модуле ResponseOneWayBean совпадает с то что указано в Sender моего Integrated Configuration. У меня нет условий на маршрутизацию. А текст сообщения ошибки совпадает с сообщением запроса, ответ от вебсервиса не виден (хотя я уверен вебсервис выполняется. Я еще попробовал задать Stateless (XI30-compatible) на интерфейсе file sender как предлагают здесь: Ошибка поменялась на: Transmitting the message to endpoint using connection AFW failed, due to: com.sap.engine.interfaces.messaging.api.exception.ConfigException: No sender agreement configured that matches the message’s header fields (sender party: «», sender service: «BCBRWEB», interface: «SI4», receiver party: «», receiver service: «BCBRWEB») Мне не совсем ясно — почему для Receiver service ожидает то же самое как для Sender service.

И нужно ли в версии 7.31 ползьзовать опцию Stateless (XI30-compatible)? ↓. Виталий отличная статья, подробно с примерами однако, у меня на практике что-то не сложилось пробовал оба варианта с модулями в отправителе и в получателе, и получал похожие ошибки в обоих случаях: cause: com.sap.engine.services.jndi.persistent.exceptions720.NameNotFoundException: Object not found in lookup of RequestResponseBean с чем может быть связано такое сообщение? Направьте меня на путь истинный, пожалуйста 😉 Мне необходимо реализовать асинхронно/синхронный мост в PI 7.40: источник — плоский файл (служит исключительно для того, чтобы дернуть JDBC-receiver) JDBC-receiver (а не sender) использую, т.к. ↓.

Николай Добрый день! Еще небольшой вопросик. Интерсно, а зачем нужен параметр replaceInterface в модуле ResponseOnewayBean (вариант «Мост с модулями в Receiver Communication Channel»)? Если поставить его в false, то система в процессе маршрутизации обратного сообщения потребует receiver agreemenr’а для от, интерфейс. В то же время, я не нашел способа создать Interface mapping, в котором бы в качестве и Source Interface выступал бы. При этом, чтобы бралось его response-сообщение и маппилось бы на сообщение асинхронного интерфейса системы.