Сегодня G. Koopmann выложил пост в блоге, где предлагает создать базу всяких функций по PI.
http://scn.sap.com/community/pi-and-soa-middleware/blog/2013/02/06/if-you-fell-down-yesterday-stand-up-today#comment-340387
Как вам идея?

Если разовьется во что-то большое, думаю будет здорово.
Фреймворк можно будет какой-нибудь создать для PI

In this PI codeXchange we bundle our own functions into several classes and together with the community we build our own classes. Think of functions regarding dates, string and queue handling amongst others. An example of a date function could be to ad or subtract days from a starting date and so on. We think this could really serve the community.

для начала неплохо бы повторяющиеся задачи и проблемы описать, а то решить-то нетрудно.

сегодня -- за пять с лишним лет впервые -- до меня дошло что в графическом меппинге RFC Lookup на выход шлёт XML, который можно заворачивать не хуже чем XML Tree из источника. Теперь можно функций и наделать, а то возврат структур в MM был для меня всегда неприятной штукой из-за которой проще было сделать в xslt или в джавашном.

получается два пути

1. Сначала собрать кучу кода со всех и из этой кучи создавать библиотеки.
2. Либо сначала создать кучу "стандартных проблем", которые можно решить с помощью кода. И потом уже всем искать оптимальное решение, "идеальный код".

самой лучшей и универсальной библиотекой был бы XSLT 2.0 в джава-стеке.

Это абсолютно реальный вариант и ничем не сложный. Надо только парсер найти жавный который понимает 2.0. Делов на час. Вопрос стоит ли оно этого?

А мне бы хотелось чтобы в InterfaceDetermination можно было бы программы писать. Типа как расширенный ReceiverDetermination.....

что-то насчёт несложности сомневаюсь. Если ломать сап об коленку то конечно да, несложно, вместо ихнего старого как мамонта xalanа воткнуть что-то новое, но кто такое будет поддерживать?
Если просто притулить рядом, в IA, то каждое считывание из БД любого крошечного меппинга будет занимать 25 мегабайт для какого-нибудь Saxon-9. Да и придётся обёртки-джава меппинги для этого писать или наоборот, XSL в JAR прятать, один фиг.

Как я это думал когда-то:
1. Задеплоить XSLT2.0 как отдельный пакет, не в БД а в файловую систему
2. Сделать одну java-обёртку для вызова отдельного XSL, с указанием параметра меппинга как имени (SWCV + namespace + name) или гуида
3. Сделать вторую java-обёртку для вызова XSL из этого же IA / Jar'а, как ресурса.

п.3 проще написать один раз но деплоить новую XSL надо будет только из NWDS или чего-то вроде.
п.2 написать чуть сложней, но муторно гуиды или пути поддерживать в меппингах, зато новые XSL будут независимы от NWDS.

А как ты предлагаешь сделать?

Так и есть. Только обертку надо делать такую, чтобы парсинг вызывался как статический метод, для того чтобы он не создавался каждый раз заново. По сути будет две обертки. Первая - жава меппинг с AbstractTransfomation, а вторая - непосредственно класс со статическим методом. Его надо вместе с парсером деплоить. Можно взять несколько парсеров, и их название тоже параметром передавать
XSLT преобразование кладешь рядом в отдельный архив, параметром передаешь в обертку путь к файлу и все.
NWDS вообще не надо. Как деплоить - найди любую инструкцию как задеплоить JDBC драйвер. Процесс одинаковый.
Вопрос - насколько надо XSLT 2.0, он же не стандартизирован вроде еще. Предполагаю что XPath 2 был бы наверное интересен из-за циклов, но тоже пока что не могу как-то задачу вообразить себе такую. Везде первого хватало или других инструментов. Хотя пути неисповедимы. У меня был заказчик который принципиально хотел только XSLT. Я в принципе не против, но иногда когда всасывается по 30Гиг на вход как то тяжело с XSLT

понятно, что работать будет и даже приемлемо как-то, но поддерживать очень муторно -- все параметризованные меппинги как-то более затратны в сопровождении.
XSLT 2.0 нужен из-за distinct-values и всяких удобств в циклах, плюс полная поддержка RTF (result-tree fragments) плюс все новые функции работы над атомарными типами и узлами. Всякие сложные айдоки красиво и легко обрабатывать, не плодя кучи UDF.

Насчёт тормознутости и ресурсов под XSLT конечно согласен, это затратный способ.

Здесь речь о графике идет?

distinct-values делается через precending-sibling. А что такое result-tree fragments?

Вообще-то, в принципе, можно провести эксперимент... Но только ради эксперимента и не более Уж точно не для код-комьюнити

UDF -- да, user-defined functions в граф.меппинге.
distinct-values через preceding-sibling:: работает УЖАСНО медленно. Можно через ключи ускорить и переписать но тоже муторно.
RTF = result-tree fragments, когда в переменную пихаешь кучи узлов а потом по ней делаешь преобразование (в 1.0 поддерживается частично и по-разному, в зависимости от движка).

А что, эксперимент можно провести, действительно!

На Scn написано, что "You could of course try to import your own Java XSLT 2.0 processor in a .jar file and in the same or another .jar, you could import the .xslt files."

В чем сложность?

слишком много could