Продолжаю копать эту тему.

в ERP в BD64 добавил ALEAUD к схеме распределения для PI/XI
Сделал вариант RBDSTATE как рекомендуется в HOWTO
в SM36 запланировал выполнение нового задания

пробую посылать IDOC из PI и напрямую из внешней LS системы через JCo (программисты написали мне тестилку для этого).
Появляются на выходе из ЕРП IDOC ALEAUD - вроде все ок.
Приходят в PI. в IDX5 я их вижу.

для документов, пришедших минуя PI вижу:

Вроде логично, что не может найти. Там его и нет. НО вот для сообщений, пришедших из PI вижу и интерфейс отправитель и получатель одинаковы

SXI_MONITOR показывает и Request message ID и Message ID

В ESB описал:
RD, ID, RA, CC и для интерфейса отправителя ALEAUD01 и для Acknowledgment - обе цепочки завернул на канал во внешнюю систему.

Понятно, там пока нет интерфейса для этого, но я туда просто IDOC подставил. Короче, мне кажется, хотя бы до адаптера должно дойти и принимающая сторона должна ругнуться, что нет такого интерфейса у них. Но все остывает в Integration Engine.

Что это может быть?

Может к этому типу IDOC гвоздями прибито какое-то требование, например , чтобы исходный IDOC должен приходить только с IDOC адаптера?

Я сделал прием IDOC напрямую в ERP их внешней системы. Формируется ALEAUD, но у него в поле "Порт получателя" стоит порт PI, хотя "Номер партнера" тот, что был указан в принятом IDOC. На сколько я понял, ALEAUD должен возвращаться по тому маршруту, откуда пришел. так ведь?
Где это настроить?

PS: прошу прощения - нашел опечатку. Ошибся в описании порта для выходного ALEAUD в профайле для своей LS.

Где можно почитать, как связывается входящий документ и ALEAUD на него? то есть, если мы отправили несколько IDOC, как понять к какому отнести пришедший ALEAUD?

И с этим разобрались: в поле DOCNUM есть собственный номер документа. SAP присваивает свой, но при возврате передает первоначальный.

НО вопрос с передачей ALEAUD на не-IDOC адаптер остался открытым. КАк через PI вернуть audit передавшей данные программе?

ЗЫ: Вроде написано, что ALEAUD всегда преобразуется в XI акноледжмент. А как передать его дельше - не могу найти информацию.

ДЛя тех, кому интересно:
нашел вот какой ответ на форуме:


Значит нужно просто делать новый тип сообщения и пересылать его как обычный IDOC. ALEAUD01 - так не выйдет.
Вот такой костыль, оказывается.

Я время от времени экспериментирую с попытками отправлять и получать подтверждения. Но, получается не все понимаю. Вот что хоть как-то работает на сегодняшний день:
1)SYSTAT01 — при получении такого IDOC, ERP меняет статус указанного внутри IDOC на указанный — это может служить для передачи статуса из внешней системы (ну например, ПРИНЯТ, а с остальными отдельно разбираться, почему не пришел статус). Есть сложность отправки systat из ЕРП во внешнюю систему — нужно писать свои программы для отработки всех видов IDOC, которые мы используем.
2) в ЕРП через программу RBDSTAT формировать ALEAUD и отправлять их на отдельный порт, который слушается например через JCo. Мне программисты написали спец. заглушку, которая просто принимает IDOC. Но тут проблема, как сопоставить ответ и исходное сообщение. Получается у нас передающая система не имеет ID документа, который есть в САП. (на сегодняшний день я пробовал установить галку "Apply Control Record Values from Payload" в настройках канала IDOC RECEIVER. Тогда передается не собственный номер IDOC, а то, что я установил в поле DOCNUM. То есть появился намек на то, что получится связать документ во внешней системе и ответ в ALEAUD)
3) есть планы попробовать сделать Z_RBDSTATE, чтобы слать ZALEAUD, так как PI сразу превращает обычный ALEAUD в XI ответ и мне не удалось его пробросить дальше в вызываемую систему.
4)сделан прототип схемы обхода PI, когда внешняя система отправляет IDOC напрямую в ERP. Причем, ответный ALEAUD содержит DOCNUM переданного сообщения! Но, тут вызывает подозрения ненадежность или потенциальная сложность системы, чтобы как-то приблизиться к характеристикам PI по возможности мониторинга.

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

Возможно буду выглядеть, как индус - но есть старый, хорошо написанный мануал по ALEAUD и PI:
http://www.sdn.sap.com/irj/scn/go/porta ... c616df56eb

Если же нужно перехватывать и использовать информацию из ALEAUD - нужно организовывать отправку статуса в собственном формате:
- скопировать ALEAUD в ZALEAUD
- отправлять его с помощью копии RBDSTATE - ZRBDSTATE и перехватывать его как обычное сообщение от ERP.

По п.4 - если внешняя система технически доставила IDoc в систему, то дальше мониторинг в системе устроен хорошо и надежно.
Остается гарантировать, что внешняя система обработает ошибку доставки (нет связи).

Тот мануал я видел. Но там нет способа передать статус во внешнюю не-САП систему. Действительно, нужно будет переписать RBDSTATE и слать ZALEAUD01. Получается, другого пути для PI нет.

Как раз в том мануале сценарий 2 - это отправка ALEAUD во внешнюю систему.

См. "6 Configure Scenario 2:"
Там идет генерация исходящего сообщения из ALEAUD при помощи отчета IDX_ALEREQUEST.

Не уверен, правда, что в новых версиях PI работает - пробовать надо.

Хмм, значит я чего-то недопонял. еще раз прочту.
Спасибо

УРРА! Просто выполнил этот отчет и сообщения радостно полезли во внешнюю систему!
Теперь программисты создадут мне новую WSDL и будут принимать статусные сообщения!

Получается вот как:

1) для документа, который передается в САП в виде IDOC я заполняю <SNDLAD> и <DOCNUM> в шапке, передаю документ, он обрабатывается в ERP.
2) По расписанию выполнить RBDSTATE в ERP для нужной внешней системы
3) выполнить IDX_ALEREQUEST в PI и определить, откуда-куда должны идти ALEAUD как "документы"
4) ловить документы во внешней системе

Вроде так. Весь цикл еще не тестировал.

Коллеги, я правильно понимаю, что после выполнения IDX_ALEREQUEST, все ALEAUD, попадающие под раздачу, просто передаются во внешнюю систему и более не используются как акноледжмент? то есть в SXI_MONITOR они не влияют на акноледжмент-статус.

И еще вопрос: если приемный сервис возвращает ошибку, передаваемое в него сообщение получает Ack Status с соответствующим ошибке значком, а если все OK, то остается зеленый знак вопроса "Still awaiting acknowledgment". Как при отсутствии ошибок при приеме SOAP сообщения сообщить об этом в PI?