Если речь о методе, предложенном sapman, мне кажется он немного другое имел в виду:
12 - RFC асинхр
Кроме того, если 11 на схеме асинхронно, как 12 может быть сделано синхронно без bpm?

А чем тут 3-я система поможет?

Стандартные модели распределения IDOC/Enterprise Services вроде так и устроены - асинхронные интерфейсы, получатель сам генерирует ответное сообщение. Для понимания процесса достаточно одной фразы в его описании, процесс ведь тривиальный. А так получается для упрощения понимания вы предлагаете усложнить сам процесс, прикрутив к нему ccBPM, что в свою очередь не лучшим образом отразится на его поддержке и понимании. Если например синхронный RFC интерфейс свалится с ошибкой, считанные из файла данные потеряются, т.к. повторно его перезапустить не получится

- единственно верное и проверенное решение.

Еще один минус ccBPM - при большой нагрузке будет работать оооочень медленно.

P.S.: Задача-то классическая, и не нужно к ней придумывать столько решений.

да, тут 11 д.б. асинхронно тогда, ошибся при рисовании


она может сыграть роль BPE-сервера, то есть получить вызов по XI-протоколу и дальше по своей логике маршрут обработки выстроить.

Это точно! ещё и абап требуется, а это дорохо.

sapman предложил самый простой и правильный способ. Если товарисч смог написать rfc модуль то и с прокси справится - тем более у прокси куча преимуществ перед rfc - перезапуск на стороне ерп - отладить можно - монитор стандартный.

не факт что в системе есть абап-прокси.
По простоте и правильности соглашусь с pitroff, лучше через ResponseOnewayBean для синхронного RFC _либо_ надо менять шаблон интеграционного сценария и делать Notification/Confirmation логику в RFC. Но, этот подход работает лишь если есть разработчик и ключ разработки в RFC-системе, а кто сказал что это всегда возможно? Ну или Global data types взять, есть стандартные интерфейсы и прокси, вы будете их переписывать или плодить enhancement'ы для изменения логики шаблона?

pitroff, тогда вопрос вам. Если в момент срабатывания файлового канала система ERP окажется недоступной из XI, или синхронный RFC интерфейс отработает с ошибкой(дамп), каким образом считанные из файла данные попадут в ERP?

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

Задача обрабатывать ошибки связи и дампы в исходном сообщении не стояла.

Серьезно - пока только в теории (надо проверять, но не до экспериментов пока):
Если включена архивация/удаление файла после успешной загрузки - файл останется на месте до последующей попытки вызова канала связи.

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

Но сперва надо сформулировать - какие возможные ошибки нужно/не нужно обрабатывать с помощью XI. На мой взгляд, дамп в ERP - это уже признак плохо протестированного интерфейса.

Да, для синхронного варианта будет нормально: при архивации ошибочных в errors попадёт, без неё должен остаться на месте (не проверял такое, обычно всё с архивацией делаю). А так, ошибки без ccBPM кто-то из службы поддержки должен обработать, через алерты или ручным просмотром мониторинга.

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

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

Останется, но XI вряд ли станет пытаться отправить его повторно

Это вы называете нормально )) Итак мы снова вернулись к вопросу зачем нам XI и упрощению сопровождения. Даже с алертами непрогруженные файлы все равно придется перекидывать руками

ну хорошо, XI не прокатил, а если синхронный RFC запрос откуда-то не прошёл или асинхронный в очереди завис, как это следует обрабатывать правильно? И как с файлом поступать? Честная ошибка самое простое для сопровождения.

В асинхронном режиме таких проблем просто не возникает. Если файл сразу отправить не удалось, он будет находиться в очереди и XI периодически будет предпринимать попытки его отправить, при этом можно гарантировать что файлы будут доставлены в правильной последовательности. Если проблема имела временный характер, рано или поздно все само прогрузится, никаких действий от сопровождения не требуется
В случае синхронного интерфейса задача обеспечения доставки перекладывается на прикладные системы, как правило это система отправителя (автоматический перезапуск в случае ошибки и т.д.). Когда есть возможность доработки системы это делается просто, но в случае с файловым каналом весьма затруднительно

Если вместо SOA используются файлы, то я считаю нормальным использовать ручной мониторинг. Какая задача - такой и сценарий.

Очень бы не хотелось впадать в демагогию, но в таком варианте реализации тоже нет 100% гарантии работы интерфейса.

Если я правильно понял предложенный Вами вариант, то как обработать такую ошибку?

файл -> XI -> RFC (до этого момента все успешно, файл загружен и перемещен в архив) -> RFC2(reply) -> dump

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

Если до предела упростить, то:
- синхронный интерфейс используется, когда исходная система ждет ответа
- асинхронный - во всех остальных случаях.