После 9 месяцев работы в 7.1 хочу сделать некоторые заключения.

Значимые архитектурные изменения, которые стоит принять во внимание при разработке/конфигурировании:

1. Переименование message interfaces в service interfaces не голословное, а действительно серьёзное решение: теперь стало возможным иметь несколько операций в одном интерфейсе (правда, все они должны отличаться корневыми элементами). Следствия:

* Стало возможным упаковывать и расширять логику не добавляя интерфейсы (==не изменяя объекты конфигурации Directory). Например, есть веб-сервис с 5 операциями. Мы считаем этот веб-сервис одним сервисным интерфейсом (SI) и при добавлении новых операций просто расширяем SI а не добавляем новый.
Или есть БД, мы все обращения к ней так же запихиваем как операции в SI. Также удобно записывать request и response как 2 разных операции в одном интерфейсе, также экономя и группируя сущности.

Следствия в ccBPM: для контейнеров необходимо всегда указывать операцию. Выигрыша к сожалению нет. Более того, WF не заточен под операции и я лично видел ошибку "не могу стартовать интеграционный процесс тк корень неизвестен". Под отладчиком выяснилось что в таблице соответствий в абапе нет понятия "операция", а только "интерфейс", и если SI состоит из нескольких операций, то стартовать по такому SI процесс нельзя. Может быть это и поправят. Адъ и Израиль.

Следствия в ID/RD: можно выбирать пооперационный или посервисный режим. Очень удобно.

Следствия в меппингах: везде вылазят операции. Если у вас есть соглашения о наименовании и интерфейсы называются SI_FooBar_AA, то по умолчанию создаётся аналогичная операция. И глаз будет радовать конструкция SI_FooBar_AA.SI_FooBar_AA во многих местах. А если как обычно копировать один интерфейс в другой (Async Abstract SI_FooBar_AA -> Async Inbound SI_FooBar_AI) и потом менять детали нового, то в нём операция называется по-старому, и появляются уродцы SI_FooBar_AI.SI_FooBar_AA, которые не сразу заметны. Быть начеку, создавать первую операцию с именем default или main, тогда коллизий не возникает.

Следствия неожиданные: поскольку признак синхронный/асинхронный назначается не интерфейсу а операции то naming convention идёт лесом. Однако! если сделать такой интерфейс с 2 операциями (одной синхронной и одной асинхронной), то появляются неожиданные глюки или система отказывается использовать такой интерфейс в меппингах. Пример вспомнить не могу но было что-то корявое, да.

2. Стало возможным обращаться к аттачментам в меппингах.

Супер-возможность! Правда если создавать аттачмент с 0 на лету, падала джава в Ehp1sp3, но это поправят наверное (потом проверю в sp5).

Следствия в ccBPM: можно делать универсальные интеграционные процессы, основанные на одних интерфейсах. В них полезная нагрузка будет не в payload а в аттачменте. Меньше сущностей в Directory.

3. Advanced Adapter Engine и интеграционные сценарии в нём.

Попробовали, не понравилось. Мониторинга в абапе нет, ошибки искать неудобно, ограничений много, фтопку. Откатили назад на Integration Engine.

4. Новый XML Toolkit.

Удобнее, лучше, однако его xslt движок совсем другой и джавашные вызовы в старом стиле не работают. Вопрос в сап аг ответа не дал. Поэтому использовать лучше всего в джавашных меппингах.

5. Параметры в меппингах.

Однозначно круто. Однако нельзя использовать пустые параметры или параметры по умолчанию. Если меппинг универсальный с 10 параметрами, но по контексту надо использовать 1-2 в каждом случае, заполнять пробелами приходится все 10. Мелкое неудобство.

6. Новый condition editor в ccBPM.

Крайне опасная штука в нём -- локальные переменные. Крайне не рекомендую. Содержит гадкие ошибки, в итоге лучше делать явные контейнеры.

7. Step Group в ccBPM.

Крайне не рекомендую. Запортил 2 процесса из-за SG, пришлось пересоздавать заново. Да и сама идея сомнительна, что-то вроде темплейтов.

8. Monitoring Process в ccBPM

Штука абсолютно неясная, явное баловство маркетоидов.

9. Механизм ввода условий в Interface Determination (ID).

Круто! то, о чём мечтал в 7.0. Теперь стало возможно делать обобщённые ID/RD с кучей условий и там и там, большие возможности. Спасибо авторам. А вместе с операциями ещё больше ортогональности.

10. К Party стало возможным приляпывать коммуникационные каналы напрямую, без Business Component (систем/сервисов). Заманчиво, но пока не использовал.

Upd: 11. в ccBPM появились Alert Categories и удобный способ передачи параметров в алерты. Очень удобно. Так же можно использовать старый способ алертов.

и некоторые значимые изменения в среде разработки:

1. Зависимости между SWCV стало можно разруливать в билдере, не только через SLD
2. Транспорт ченч-листов стал возможен и через клиентскую файловую систему, не только серверную
3. Ченч-листы можно теперь экспортировать в запрос кучей. Но! протЫкать диалог придётся по каждому, о чём напишут.
4. Ченч-листы стало можно закрывать без экспорта кучей! Супер-штука, раньше когда скапливалась сотня незакрытых приходилось каждый протыкивать.
5. Появились отчёты по сценариям -- стало можно в графическом виде просмотреть схему сценария. Хорошо. Правда хочется ещё больше лучше и нагляднее, примерно как http://hixay.googlecode.com/svn/trunk/doc/img/script_dlvry_plan.png
Upd 6. Стало можно группировать объекты ещё по одному признаку -- папке (для сценариев привязки множественные, для папки единственные). Это конечно плюс.

Привет, Илюх!

А как же более новая версия java? ...мне кажется, что это одно из главных преимуществ
>Advanced Adapter Engine и интеграционные сценарии в нём.
но перфоманс немеренно выше, ограничения что нет ресивер детерминейшена, получатель всегда фиксирован, аналогично с интерфейс детерминейшеном ...ну там еще коненчо никакого ccBPM и адаптеры вроде только AE можно использовать.

>9. Механизм ввода условий в Interface Determination (ID).
Вообще в 7.0 можно указывать условия на какой интерфейс идти и чем меппить, конечно не было никаких параметров, потому что их и в меппинге не было.

Как мелкую фичу еще забыл указать про User Decision.

Мне сейчас интересна точная дата релиза версии 7.2 и какие фичи в ней будут, а то что пока только слухи и то неясные.

Саша, привет! У вас сейчас 7.1 или вы сразу на 7.2 целитесь?

Да, про новую джаву я забыл написать, действительно здоровский плюс. И новый XML Toolkit, не САПовский, правда с новым всё плохо в плане документации и совместимости, особенно XSLT. Здорово удручает что XSLT 2.0 никак в джаве не реализуют, в абапе и то мощнее версия.

В AAE с мониторингом всё плохо Прям впору самому дописывать, написали на нём один сценарий для пробы, через пару месяцев перевели в IE так как неудобно показалось.

>Вообще в 7.0 можно указывать условия на какой интерфейс идти и чем меппить, конечно не было никаких параметров, потому что их и в меппинге не было.
Странно, я в 7.0 сложный ID попытался сделать, не получилось условия ввести. Может быть...

Сразу на 7.2, это все заморочки с ЦОДом и прочей бюрократией


А в чем именно не удобство? Я так понимаю, там обычный Message Monitoring из RWB, в котором, кстати, можно редактировать сообщение, в отличие от SXI_MONITOR...

У кого-нибудь в 7.1 в SXI_MONITOR видны операции интерфейсов? В ALV-гриде такие поля есть но они всегда пустые.

Точно такая же фигня. SAP PI 7.11 SP05. Пока не устраненный недочет.

А как же еще одно замечательное и существенное дополнение в 7.1: Моделирование. Теперь принципиально поменялся подход в построении сценариев. Теперь предлагается моделировать сверху вниз, все более и более уточняя схему, в конце концов опустившись до уровня типов данных. Теперь можно сначала проработать архитектуру, а потом уже проработать ее реализацию. И все это визуально.

Опишите Ваш опыт -- это в работе удобно или нет?

Определенно удобная вещь.
Конечно увеличивает время разработки отдельного сценария. Но упрощает понимание процессов в конечном итоге.
Теперь предлагается проработка интеграционного взаимодействия сверху вниз. Т.е. определяете основные объекты(бизнес объекты и сценарии) и постепенно детализируя спускаетесь до интерфейсов и типов данных. В результате вы имеете схематичное представление всего интеграционного взаимодействия на всех уровнях детализации. Тем самым проще разобраться в общей концепции не прибегая к листанию документации.
Одно но с которым пока столкнулся. SAP ввел понятие бизнес-объект. В рамках подхода через моделирование бизнес-процессов интеграции это весьма полезное понятие. Однако у меня не удается создавать бизнес-объекты в своих SWCV(только в SAP BASIS 7.1). Переписка с САПами зашла в тупик. Бизнес компоненты можно создавать только в SWCV типа (No Check), но можно установить значение SAP Netweaver 7.0 или SAP Netweaver 7.1. Дальнейшее общение привело к тому что САПы спросили а зачем вам это вообще, мы не используем их.))

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

САПы ответили. Теперь известно как нужно решить проблему.
В ExchangeProfile надо добавить строковой параметр com.sap.aii.ibrep.core.devmode.additionalBackendCompModes и присвоить ему значение "DEFAULT:UNDEFINED". А так же проверить параметр com.sap.aii.ib.client.properties на предмет присутствия в нем "com.sap.aii.ibrep.core.*"
После этого действительно можно поставить в атрибуте "Use of unterface Objects" в SWCV значение "(No Check)".
Сохраняем. УРА, можно создать бизнес-объект.