есть ERP, генерирует IDOC, его отправляем во внешнюю систему, получаем синхронный ответ и транслируем его асинхронно в прокси в ерп. если в ответе есть определенное значение в поле, то вместо прокси ответ посылается в почту. реализовано все через модули в soap адаптере:
1) сервис интерфейс1 синхроный входящий, в нем реквест и респонс
2) сервис интерфейс2 асинхронный исходящий, в нем респонс.
3) сервис интерфейс3 асинхронный входящий, в нем респонс.
4) сервис интерфейс4 асинхронный, в нем шаблон письма

сделан следующий маппинг:
1) маппинг1 idoc->интерфейс1 реквест
2) маппинг2 интерфейс2->интерфейс3
3) маппинг3 интерфейс2->интерфейс4

создано ICO1, в котором на входе IDOC, ресивер внешняя система, в интерфейсе маппинг1, в outbound processing soap канал со следующими настройками
1 AF_Modules/RequestResponseBean Local Enterprise Bean RequestResponseBean
2 sap.com/com.sap.aii.af.soapadapter/XISOAPAdapterBean Local Enterprise Bean soap
3 AF_Modules/ResponseOnewayBean Local Enterprise Bean ResponseOnewayBean module

RequestResponseBean passThrough true
ResponseOnewayBean module interface сервис интерфейс 2
ResponseOnewayBean module interfaceNamespace сервис интерфейс 2 наймспейс
ResponseOnewayBean module replaceInterface true

и ICO2 в котором на входе сервис интерфейс2, в ресивере по условиям либо ERP, либо почта, в интерфейсе маппинг2 или маппинг3, ну и соответсвенно вызовы каналов в ERP или почту.

все прекрасно работает, пока внешняя система вместо респонса не захочет послать Fault сообщение.. тогда в мониторинге входящее сообщение ICO1 падает в ошибку, а в логах у него написано http 500 ошибка и он не может определиться что делать с таким ответом.
3/21/2016 09:42:26.890 AM Error SOAP: Response message contains an errorXIAdapter/HTTP/ADAPTER.HTTP_EXCEPTION - HTTP 500 Internal Server Error
3/21/2016 09:42:26.890 AM Information SOAP: Continuing to response message 137a19da-ef30-11e5-9b7f-000012156852
3/21/2016 09:42:26.890 AM Information SOAP: Processing completed
3/21/2016 09:42:26.906 AM Error Exception caught by adapter framework: No sender agreement configured that matches the messages header fields (sender party: "", sender service: "внешняя система", interface: "интерфейс1", receiver party: "", receiver service: "ERP")
3/21/2016 09:42:26.906 AM Error MP: exception caught with cause com.sap.engine.interfaces.messaging.api.exception.ConfigException: No sender agreement configured that matches the messages header fields (sender party: "", sender service: "внешняя система", interface: "интерфейс1", receiver party: "", receiver service: "ERP")
3/21/2016 09:42:26.906 AM Error Transmitting the message to endpoint <local> using connection IDoc_AAE_http://sap.com/xi/XI/System failed, due to: com.sap.engine.interfaces.messaging.api.exception.ConfigException: No sender agreement configured that matches the messages header fields (sender party: "", sender service: "внешняя система", interface: "интерфейс1", receiver party: "", receiver service: "ERP")

если через wsnavigator сделать вызов с теми же параметрами, то получаем в ответ структуру Fault
вопрос: как-куда добавить обработку Fault, чтобы оно слало на почту?
наверное несколько сумбурно получилось.

ОН НАСТОЯЩИЙ!!!

Я думал ответил кто, а тут лв говорит, что привидение увидела

Здравствуйте!

С ошибками SOAP - это отдельная песня. Было уже несколько тем по этому поводу.

В общем случае, fault, если это не Application Fault (который может быть описан в wsdl сервиса), генерирует System Error в PI.

Можно попытаться отключить SOAP Envelop в настройках адаптера, сгенерировать "обертку" самому через Java/XSLT, в структуре ответного сообщения описать как структуру ответа, так и структуру fault-сообщения, двумя сегментами. В адаптере выставить также признак, что не надо реагировать на ошибку. В таком случае, по идее, Вам назад в любом случае прилетит структура ответа, где в зависимости от того, был fault или нет, будет заполнена либо структура ответа, либо структура fault. А дальше уже в зависимости от результата бросаете его туда, куда Вам нужно.

P.S. Я в свое время на этот бардак глянул и сделал мост в ccBPM. Там этого гемороя нет. System Error (точнее, сам факт его возникновения) прекрасно ловится и дальше уже все разруливается. Правда, работает медленнее, ну и только для Dual Stack. Ну и минус в том, что сообщение исходное уже перезапустить не получится, в отличие от адаптерного моста, потому что исходное сообщение будет со статусом "Delivered".

это именно fault, который описан в wsdl, но он там просто описан как message. т.е. при обращении к внешней системе она может вернуть сообщение двух типов: респонс или фаулт. как их научиться отлавливать и корректно раскидывать. с одним типом проблем нет.

Ну, может быть, в этом случае стоит поиграться с параметрами "interfaceOnFault", "replaceInterfaceOnFault" и "interfaceNamespaceOnFault". Ну и отдельный ICO для ошибочного ответа.

Спасибо, помогло.

А не могли бы вы расписать решение. Какой и как параметры выставили? ICo отдельный сделали?