После 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 и удобный способ передачи параметров в алерты. Очень удобно. Так же можно использовать старый способ алертов.
_________________ Telegram-chat: PO, CPI-PI, java, groovy
Последний раз редактировалось chumpa Пт, июл 09 2010, 15:52, всего редактировалось 1 раз.
|