Всем привет.
Версия PI 7.3
Проблема такая - из ERP выходит сообщение через прокси. У него есть какой-то GUID. Далее банально в ICO без проверки каких-либо условий сообщение расходится на две системы-получателя. Соответственно, у новых сообщений отправленных получателям генерятся новые GUID.

Вопрос: можно ли как-нибудь проследить связь исходного сообщения вышедшего из ERP и этих двух новых сообщений для удобного поиска?

Потому что хотелось бы по исходному GUID быстро получать всю цепочку порождённых сообщений. Выцепить GUID исходного сообщения - не проблема, но вот что с ним делать? Сохранить в Reference ID? В принципе асинхронный ответ не предполагается и Reference ID не используется, так что поле идеально бы подошло. Но можно ли так делать? Может есть более просто решение?

Нашли решение.
Используйте модуль AF_Modules/DynamicConfigurationBean
http://help.sap.com/saphelp_nw04/helpda ... ontent.htm

Модуль прописывается дважды в канале Sender перед вызовом непосредственно адаптера. Выглядит это так:
1 | AF_Modules/DynamicConfigurationBean | Local Enterprise Bean | 0
2 | AF_Modules/DynamicConfigurationBean | Local Enterprise Bean | 1
3 | CallSapAdapter | Local Enterprise Bean | soap

Затем прописываются параметры
Module Key = 0
Parameter Name = key.0
Parameter Value = read http://sap.com/xi/XI/System/Messaging refToMessageId

Module Key = 0
Parameter Name = value.0
Parameter Value = message.messageId

Module Key = 1
Parameter Name = key.0
Parameter Value = write http://sap.com/xi/XI/System/Messaging refToMessageId

Module Key = 1
Parameter Name = value.0
Parameter Value = message.refToMessageId

И всё, работает!

Добрый день!

Дважды его прописывать не нужно.
Модуль этот может сколько угодно параметров обрабатывать.
Просто каждый следующий параметр пишется с новой цифры, т.е.:
key.0
value.0
key.1
value.1
и т.д.

Параметр refToMessageId можно использовать, хоть он и не для того предназначен:
message.refToMessageId - Reference ID for the synchronous response

Возможно, Вы ошиблись при копировании, но операция выглядит странно:

1 | AF_Modules/DynamicConfigurationBean | Local Enterprise Bean | 0




Читаем значение refToMessageId, пишем его в adapter-specifiс часть заголовка в параметр messageID. Зачем?



Пишем refToMessageId из заголовка в refToMessageId заголовка.

Какая-то путаница, имхо.

Тут скорее нужно


То есть, записать ID сообщения в refToMessageId.

Для справки - все параметры и операции DynamicConfigurationBean:
http://help.sap.com/saphelp_nw74/helpda ... ontent.htm

P.S.: Но что-то мне подсказывает, что при разделении сообщения в ICO PI сам должен где-то проставлять GUID исходного сообщения.. Гляну на досуге.

Посмотрел внимательнее - действительно, стандартно PI пишет исходный ID в HopList:


1-Исходный ID
2-ID после клонирования

Но поиском тут особо не воспользуешься, так что Ваша идея с referenceID - хороша.