ну что, господа теоретики, может пора обратиться к практике? а то уж пять лет прошло.
есть чем похвастаться?

WJ,

"мэйнстрим"... эк вы замахнулись)
ну а по делу есть что сказать? об успехах шествия bpm-систем по просторам it-сообщества))
а то продажников я тоже уже наслушался, презентаций с довольными рожами насмотрелся и даже с bpm-ом наигрался.
хотелось бы предметно по инструментарию - каким образом решаются конкретные проблемы.
или вы только по "высоким материям" специализируетесь?

WJleader,
По инструментарию: конкретные проблемы решаются хорошо.

супер! это радует))
Ну вот допустим... вполне себе несложная проблемка - найти задачу из списка тасков с определенным набором параметров связанного с ней документа в payload
С учетом того, что данные payload'а хранятся во внутреннем репозитории метаданных в виде plain text xml, скорость отбора падает пропорционально числу задач - оптимизировать этот процесс невозможно

АБНу это стандартные грабли. Данные надо хранить в базах данных, а не в xml. Даже если это данные (атрибуты) процесса. С некоторыми BPMS это сделать легко, с другими посложнее, но заведомо можно.
BPMS не отменяет DBMS, хотя некоторые презентации вендоров и могут создавать такую иллюзию.

Вот товарищ АБ понял о чем речь..
То, что данные должны храниться в базе данных, а не во внутренностях bpm-платформы - это факт.
Но платформа должна уметь оперировать этими данными - тоже факт.
И почему-то по умолчанию считается, что управлять персистенцией этих данных bpm-платформа не должна - это у меня и вызывает недоумение. Типа, хотите сохранить ваш бизнес-объект - рисуйте к нему сервис и дергайте его из бизнес-процесса. И в итоге бизнес-процесс вкупе с полноценными бизнес-активностями получается разбавлен вызовами технологических сервисов сохранения в БД, изменения статуса документа и т.п.
Я приложил картинку как это выглядит на простом примере. И чем сложнее получается workflow - тем большее количество технологических операций сохранения данных приходится в него вставлять. Наглядность от этого естественно не улучшается.
Все платформы, которые я просмотрел (IBM Lombardi, Oracle BPM Suite, SAP Netweaver BPM), в этом плане концептуально работают абсолютно одинаково - хранят содержимое data object'ов процесса только в виде xml и напрямую работать с RDBMS не умеют. Причем параметризованный поиск по содержимому задачи можно делать только в Lombardi (работает он через XPath), BPMSuite и Netweaver вообще искать по внутренностям human task'ов не умеют. Т.е. если бухгалтер говорит "хочу отобрать все задачи на обработку, у которых сумма заказа больше 1000$" - все приехали. Отправляем в сад.
Воот...
Поэтому мне кажется, если грамотно соединить BPM-платформу и RDBM-систему удалось бы решить много проблем, не только с поиском/отбором тасков, но и такие как аудит изменения данных на уровне пользователей, соотнесение инстанции процесса с экземпляром документа и др.

Другая проблема - это асинхронность работы пользователей. Для них это вообще взрыв мозга. Тетка всю жизнь оформляла какую-нибудь платежку, давила на кнопку ОК в документе и считала, что если экран закрылся без ошибок - то все действительно прошло без ошибок. Тут она начинает тихо сходить с ума, когда ей объясняют, что если экран закрылся - это означает лишь то, что он закрылся и управление было передано на следующий шаг процесса и абсолютно не значит, что ошибок не было. И не дай бог где-то там, после ее human task'а далеко-глубоко по цепочке вызовов automated activity вдруг возникла проблема - пиши пропало. Задача падает в очередь с ошибками, тетка идет курить/пить чай/менять прокладку, забывает про нее, процесс останавливается.. Клиент звонит - "где мое бабло", менеджеры в бешенстве, руководство в панике - а с тетки какой спрос? Она ж честно надавила ОК и пошла заниматься своими делами..