Добрый день, коллеги.

Есть проблема: нужно заставить файловый канал формировать имена файлов по стандарту принимающего ФТП сервера.
например, у меня IDOC содержит

нужно получить имя файла
\IN\cust400002\folder\file%DATE%.xml

получить \IN\cust0000400002\folder\file%DATE%.xml - просто, через подстановку. Но как сделать минимальное преобразование?
Корежить IDOC на мапинге - не выход, так как не совсем ясно, что на принимающей стороне с ним делать собираются.
Есть ли какие-то возможности не просто взять payload:ххх, а, например, сделать substring(payload:xxx)?
А может можно как-то на этапе мапинга определить какую-то переменную, которая будет доступна при формировании имени файла, но не попадет в выходной документ?

Помогите, пожалуйста! Нужно достаточно срочно.

Насколько понял из сообщения динамической должна быть папка, а не файл?

Вот это думаю подойдет:
http://wiki.scn.sap.com/wiki/display/XI ... sibilities
Timestamp можно добавлять в свойствах комм.канала.

спасибо. Позже я посмотрю "Adapter-Specific Message Attributes and Dynamic Configuration". Сейчас временно сделал маппинг и исковеркал поле

в шапке IDOC. вроде доходит нормально.
IMHO, программить такие простейшие вещи это как палить из рельсотрона по воробьям. Неужели в переменных нельзя было сделать простейший набор функций обработки строк?

Вечер добрый!

Вот пример мэппинга Adapter-Specific Message Attributes через user-defined function, там просто достаточно:
http://help.sap.com/saphelp_nw04/helpda ... ameset.htm

Если в нем заменить имя параметра на Directory - получите искомое, тут технические имена есть:
http://help.sap.com/saphelp_nw04/helpda ... ameset.htm

Есть два варианта, либо как автор делал - через маппинг поля. Но это тогда для каждого процесса делать надо (хотя и не долго).
Либо - второй вариант - сделать подмену adapter-specific параметра, как по ссылке. Только, если эту штуку не в UDF прописать, а в Adapter Module, чтобы уже раз и навсегда.

Тут есть небольшая "закавыка" - в данном конкретном случае это работает, если система-получатель не делает различия между 00000111 и 111.
Если же для получателя это критично (предположим, это будет текстовое поле) - такой фокус уже не пройдет.


А как в модуле получить значение RECIPNT_NO, убрать нули и сформировать нужный путь?
Стандартный DynamicConfigurationBean вроде такого не позволяет, а писать тут свой модуль - это разработка "рельсотрона", ИМХО.

Вот почему бы в описании пеменных для подстановки не сделать элементарные строковые функции?их всего-то штуки 4 надо, substr replace repeat ну и убрать незначащие нули. Ну или просто регэкспы как в перле.

А в этой теме папка без нулей всегда, для этого случая вроде нормальный вариант с маппингом, как мне кажется.



Я имел в виду не стандартный модуль, а свой разработанный под этот случай. В классах при разработке модуля есть доступ к payload, получить значение и убрать нули это сделать быстро. Далее поменять свойство сообщения "http://sap.com/xi/XI/System/File". Сам я так не пробовал делать, так как не было необходимости, я через переменные параметры comm.channel делал.
Модуль долго делается только в первый раз обычно, дальше уже не страшно Ну и главное замечание - это естественно имеет смысл только в случае, если много процессов и много маппингов приходится менять.



Это надо уже в SAP предъявы писать

Условие по папке - да, без нулей. Но в процессе мэппинга получается поле RECIPNT_NO, которое отличается от исходного. Конечная система это поле принимает.
А вот если с точки зрения бизнеса не все равно, каким будет номер получателя - с нулями или без - то такой вариант не пройдет.

Что-то много слов написал. Короче, это не очень хорошо - менять бизнес-содержимое ради технических настроек.


Согласен, структура у модуля вполне понятна и логична - главное, один раз разобраться. Но, имхо, их лучше делать тогда, когда задача не решается стандартными методами и инструментами.
А то очень "тяжелая" операция в интерфейсе появляется - загрузить весь payload, распарсить, вытащить нужное значение. Создание пути к файлу того не стоит.

Спасибо, коллеги.
На данный момент бизнес позволяет курочить шапку IDOC. Если не будет позволять, никто не мешает сделать новое поле в выходном документе. Ну если и этого нельзя - буду осваивать программирование модулей

Кстати, в мапинге можно создавать переменные. они используются только на время мапинга или их можно выцепить при формировании имени файла?

Да не надо тут модулей, одной маленькой Java-функции достаточно.

Adapter-Specific Message Attributes сохраняются в заголовке сообщения и живут там до тех пор, пока идет обработка в XI.

То есть Вы в своей функции в мэппинге формируете путь, он сохраняется в заголовке XI-SOAP (можно через SXI_MONITOR посмотреть - после мэппинга появится отдельный подпункт в Header).
Само бизнес-содержимое при этом остается неизменным.
А затем его может использовать адаптер, причем файловый адаптер - в стандарте, нужно только установить следующие параметры канала связи:

Use Adapter-Specific Message Attributes
Fail If Adapter-Specific Message Attributes Missing - если нужно, чтобы использовались только атрибуты, без этого параметра PI попытается получить путь из стандартных настроек.

Ну и выбрать, какой из параметров брать из заголовка:

На скриншоте - 7.4, в других версиях может выглядеть по-другому.

ага! интересно. Я попытался нагуглить, как это делается. Понятного ХАУТУ или СТЕП-БАЙ-СТЕП не нашел. Все требует каких-то пререквизитных знаний.

Правильно ли я понял, в мессеж мапинге в , во вкладке Functions в окошке Functions and Java Areas выбрать Attributes and Methods. Затем в правой части (в редакторе) написать код на JAVA. в коде нужно написать как-то так (бесстыдно выдрано у Grzegorz Glowacki. http://wiki.scn.sap.com/wiki/display/XI/Dynamic+file+name+and+directory+in+Receiver+File+Adapter+-+summary+of+possibilities):


но использовать не FileName, а Directory.
но потом , этот товарищь делает графический мапинг полученного значения в выходное сообщение и выполняет подстановку как и я, что меня не устраивает.

Кстати, нужны ли жабовские обертки для кода? Ну типа, всякие заклинания class? или , там, всякие фигурные скобки {} ? как определяются входные параметры этой UDF?

Помогите разобраться.
Вот еще нашел :http://wiki.scn.sap.com/wiki/display/XI/Accessing+Adapter-specific+attributes пока покурю его.

Чтобы вызвать UDF его надо использовать в мэппинге, даже если не планируется изменять поля Payload. Что-то вроде фиктивного вызова. Сделать UDF действительно лучше, чем изменять бизнес поле, но маппинг все равно у вас будет присутствовать и тот же Payload подгружать.

Этот способ не поможет вам избавиться от MessMapping в каждом из процессов, которые идут на файловый CommChannel. Повторюсь, если процессов мало (1 или 2) смело добавляйте то что написано тут и не парьтесь:

http://wiki.scn.sap.com/wiki/display/XI/Dynamic+file+name+and+directory+in+Receiver+File+Adapter+-+summary+of+possibilities

Вот еще интересная инфа по модулям для динамического пути:

http://scn.sap.com/docs/DOC-46112

Не обратил сначала внимание, а ведь можно папку для выгрузки изменить стандартным парсингом строки без подгрузки payload:
String dynamicpath = msg.getMessageProperty("http://sap.com/xi/XI/System/File", "Directory");

Инфа по ссылке хороша для понимания работы модуля, но там значения пути зависят от неких букв в имени файла и задаются через константы в самом модуле.



Да, затем записать через:

String path = "C:\temp\blabla";
MessagePropertyKey dynParamPath = new MessagePropertyKey("http://sap.com/xi/XI/System/File", "Directory");
msg.setMessageProperty(dynParamPath,path);

Но поскольку в пути должно участвовать измененное содержимое поля RECIPNT_NO - парсить сообщение все равно придется, что в UDF, что в модуле.
Просто почему-то мне кажется, что message mapping сделает это более оптимально.