Топик открыт для обсуждения вопросов, заданных здесь . С надеждой на ответ АБ... :)
Привожу копию вопроса:
Garya АБ Vasiliy VladimirovithА чем плох Business Process Execution Language Тем, что в нем не предусмотрены средства для описания шагов бизнес-процесса, выполняемых людьми. Такой вот развесистый bat-файл с приделанным к нему графическим редактором.А можно поинтересоваться, в каком языке описания бизнес-процессов (исполняемых, разымеется) такие средства есть? И если можно, поясните, как Вы себе на практике представляете выполнение иструкций этого языка, описывающих операции, выполняемые людьми.

К сожалению, я знаком с предметом только посредством MS BizTalk Server. Так вот, в нем используется именно BPEL, и нет никаких ограничений по взаимодействию с людьми. Просто между языком и человеком, исполняющим бизнес-процесс, как я понимаю, в любом случае находится какое-то программное обеспечение (иначе просто и быть не может), которое реализует некоторый визуальный интерфейс и функциональность для диалогового взаимодействия. В случае с MS BizTalk Server взаимодейсвтие с людьми осуществляется преимущественно через MS Office InfoPath. Поскольку последняя является программой, то средств взаимодействия с программами в BPEL вполне хватает. Описание визуального интерфейса, его оформление, функциональность, механизмы обращения к данным и т.д. и т.п. закладываются в настраиваемых формах InfoPath, которые могут быть связаны также и друг с другом, образуя некоторую совокупность взаимодействующих форм. В этом смысле четко разграничиваются средства, которыми описывается бизнес-процесс и средства, которыми описываются реакции на шевеления мышкой. Я считаю такой подход вполне оправданным и логичным.

В общем-то суть моего вопроса заключается в следующем. Неужели существуют языки описания бизнес-процессов, в которых можно от и до описать, что и в каком виде должен видеть на экране человек (пользователь) и как эта видимость на экране должна реагировать на шевеления мышкой? Если нет, то поясните, пожалуйста, что же есть такое в этих языках? Или они ориентированы на какие-то конкретные продукты со специфическим для этого продукта настраиваемым пользовательским интерфейсом?

Прежде всего, огромное спасибо за столь обстоятельный ответ. Даже дискутировать после этого как-то неловко... :) Хотя, мне кажется, предполагается даже не дискуссия, а уточнение точек зрения.

Наиболее ценную информацию я почерпнул из видеороликов.
Поскольку речь идет о возможностях языков описания бизнес-процесса (прежде всего - о них), то, как я понял из просмотренных мной видеороликов, визуальный интерфейс (уровень представления - так IT-шникам более понятно) может быть описан собственно в самом языке только в самом примитивном виде - в виде набора полей, их типов, видимости/невидимости и т.п. Во многих реальных ситуациях (по сути, в большинстве из них) этих возможностей совершенно не достаточно. Чаще всего требуется, чтобы в процессе заполнения полей информацией выводились диагностические сообщения и подсказки, происходило изменение доступности одних полей в зависимости от изменения содержимого других полей, производилась подкачка в комбобоксы различных наборов данных в зависимости от значений, выбранных в других полях... Разумеется, для этого можно сгенерить на полуавтомате заготовку WEB-формы и... погнали ваять на скриптовом языке...

Стоп!!! Но мы ведь обсуждаем возможности НЕ СКРИПТОВЫХ языков? А языков описания бизнес-процессов, не так ли? Так какой глубинный смысл заложен в способности в языке описания бизнес-процесса реализовывать куцый кусочек от того, что на самом деле требуется для визуализации, если все равно наверняка придется реализовывать уровень визуального представления совершенно другими средствами? Как поддерживается логическая целостность между полноценной визуализацией и параметрами бизнес-процесса в случае изменения бизнес-процесса (например, в случае удаления одного из его параметров)? Подозреваю, что никак (поправьте меня, если я ошибаюсь). Если это предположение соответствует действительности, то разве по факту не происходит разделения на отдельную разработку собственно бизнес-процесса и визуального интерфейса пользователя?

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

Я, разумеется, IT-шник. И насквозь пронизался догмой о пользе раздельного проектирования бизнес-логики и визуального представления. :) Я вижу в их разделении больше положительного, нежели отрицательного. Поэтому расставленные мной акценты говорят не о вреде подобного разделения, а о том, что такое разделение просто ЕСТЬ . Даже при использовании языков, ориентированых на Human-To-Human взаимодействие. Мне кажется, было бы неправильным утверждать, что эти языки такое разделение устраняют. Возможно, они делают его менее заметным, но не более того.

Запустите InfoPath. Выберите "Файл" -> "Заполнить форму" -> "Запрос на обслуживание" (из категории "Образцы форм"). Попробуйте изменять содержимое поля "Услуга", и понаблюдайте, как изменяются при этом доступные для выбора варианты в поле "Проблема". Реализация, разумеется, на скриптовом языке. Если использовать InfoPath совместно с SharePoint Portal Server и с BizTalk, то идеология работы с ним во многом будет схожа с продемонстрированной в видеоролике. Выберите "Файл" -> "Конструктор форм" - "Настроить образец" -> "Запрос на обслуживание". Поиграйтесь конструктором, чтобы убедиться, какие в нем широкие возможности. Разумеется, там тоже всё базируется на XML - как шаблон сконструированной формы, так и заполненная данными форма - всё это XML.

Но InfoPath позволяет работать людям даже БЕЗ ПОРТАЛА! Например, на основе сообщений с XML-вложениями (или InfoPath-вложениями) по "голой" электронной почте. Не знаю, до какой степени этот аргумент может показаться существенным, но, насколько мне известно, не все любят работать с порталами хотя бы потому, что в них нужно проходить авторизацию. Если пришло сообщение по электронной почте, значит почтовый клиент уже прошел авторизацию (на почтовом сервере), и, вполне возможно, что этого уже достаточно. Однако, я не настаиваю... :)

Вцелом впечатление от ролика очень положительное. Я обратил внимание на некоторые преимущества Unify по сравнению с BizTalk. Любой участник бизнес-процесса может посмотреть в любой момент в графическом виде схему бизнес-процесса и ту стадию, на выполнении которой он сейчас находится. В BizTalk есть мониторинг, трэкинг и отладка, но доступны эти штуки только администратору. Выполняющиеся процессы нельзя мониторить в графическом виде - только в табличном. Для того, чтобы ориентироваться в табличном представлении выполняющихся процессов, нужно сначала приобрести некоторый опыт. Возможно, это связано и со спецификой данных продуктов...

АБвспомнил почему я его в свое время "задвинул": в нем нет пункта меню "Опубликовать как веб-страницу". Может плохо искал?
Файл -> Конструктор форм -> Настроить образец -> (Выберите какую-нибудь форму) -> (Измените ее состав или функциональность в конструкторе) -> Файл -> Сохранить как -> Опубликовать ->
Запускается мастер, который предлагает опубликовать форму:
1) В общей папке на этом компьютере или в сети
2) В библиотеке форм портала SharePoint
3) На web-сервере.

АБДа-да, но это "типичное не то": тонкого клиента нет и не предвидется. Вам улыбается использовать решение нестандартное, поддерживаемое только одним производителем и вдобавок требующее наличия на клиентской машине MS Office?Ну, улыбаться - не улыбается. Но к этому факту, по крайней мере, я отношусь двольно терпимо. Как-то не приходилось еще видеть людей, которые бы прислыли информацию своим партнерам в формате MS Word или MS Excel, и при этом встречались бы с недоуменным вопросом "Что это вы мне такое прислали? И чем это открывать?". Жизнь есть жизнь. MS Office, положа руку на сердце, имеется практически у всех. Ну или почти у всех. По крайней мере, для взаимодействия сотрудников собственного предприятия и его близких партнеров я полагаю это средство вполне приемлемым.

Другое дело - это разработка WEB-форм для потенциальных клиентов, создание портала общего доступа, интернет-магазина и т.п. Размещать на таких ресурсах WEB-формы, требующие наличия установленного MS Office, разумеется, не корректно. В этом плане Unify выглядит более выигрышно. Но поскольку конкретно для нас в этом большой проблемы нет, я отношусь к ней с юмором... :)

Хотя, в некоторых смежных вопросах MS ведет себя, как мне кажется, некорректно. Например, InfoPath проверяет, установлен ли MS Outlook из состава MS Office, и если нет, то все возможности обмена InfoPath информацией по электронной почте становятся просто недоступными. А нам не нравится Outlook, мы пользуемся The Bat! Зачем же так насиловать всех своими продуктами? Мне очень нравится BizTalk и InfoPath, но, возможно, его привязка к Outlook и окажется той последней каплей, по которой мы выберем другой продукт.

isfarmВот примерЧто-то у меня не получилось этот пример посмотреть. Смотрелка "знает" только расширения WOT. Если переименовать WRF-файл в WOT-файл, то в нем кроме "голубого экрана" ничего не видно. :)

isfarmОтличается отсутствием диаграммы процессаСкажите честно - это отличие в лучшую или в худшую сторону?

2 АБ. Мне кажется, угодить всем и всегда ну никак не получится. Вот Вы, например, являетесь апологетом XForms. Допустим, Вы с его помощью реализовали "универсальность за исключением", но что Вы скажете тем, кто попал в категорию этого самого исключения? То есть, тем, кто использует браузер от MS? Наверное, их мало утешит утверждение, что MS - такая-сякая?

Вот Вы правильно сказали "Истинный тонкий клиент = браузер без java, плагинов или загружаемых модулей на стороне клиента"... Только у того же Unify все-таки используется Java, и правильно делается. Потому что клиент без возможностей скриптовых языков - это как нарисованная конфета. Смотреть можно сколько угодно, а сделать с ней толкового ничего нельзя.

По большому счету клиенту не интересно знать причины, по которым он не может нормально работать с диалоговыми формами. То ли проблема в том, что он не установил на компьютер продукты MS, то ли проблема в том, что он их, напротив, установил. Он просто ожидает, что предлагающий воспользоваться их услугами предусмотрит интересы множества различных клиентов, и в том числе его собственные.

В то же время до бесконечности прогибаться под клиента не получится. Клиент ведь может захотеть работать с формами в WAP и разгневается, что ему такая возможность не предоставлена. Он также может разгневаться, что от него требуется наличие вообще какого бы то ни было вычислительного устройства для того, чтобы воспользоваться предлагаемой услугой. На каком, собственно основании сделано предположение, что хотя бы какой-нибудь компьютер у него есть? А вдруг он житель тундры, в которой телефон с дисковым номеронабирателем воспринимается как вершина технического прогресса? А может быть, необходимость установки Java-машины на броузер, где он по умолчанию не установлен, кого-то приведет в состояние жуткой ярости? Всем не угодишь, это я вот к чему...

Существуют какие-то разумные компромисы. Точнее, у людей есть понимание, с чем они готовы мириться, а с чем - нет. Причем, у каждого - свое. Мы сейчас живем в странном мире. В котором продуктами MS пользуется подавляющая часть населения. Хотя, разумеется, есть еще очень много других вендоров. И в этом странном мире с точки зрения "демократических ценностей" не совсем понятно, кого считать "большинством". То ли наиболее многочисленную когорту потребителей продуктов одного вендора, то ли проcто число вендоров, выраженное в "штуках"... :)

P.S. Это я не к тому, что InfoPath - лучший выбор (кстати, я и сам так не считаю). Это я к тому, чтобы каждый решал сам, что для него лучше... :)

АБInfoPath для меня лично абсолютно неприемлемое решение, так как не является тонким клиентомТеперь я понял, что Вы подразумевали ранее, говоря о том, что InfoPath не является тонким клиентом. :)
Вы подразумевали необходимость предустановки некоторого программного обеспечения (а именно, InfoPath). Но ведь браузер тоже требует предварительной установки? В этом смысле не совсем корректно утверждать, что InfoPath - это "толстый клиент". Возможно, он еще более тонкий клиент, чем браузер, поскольку позволяет заполнять форму в несколько сеансов, сохраняя на собственном локальном диске ее содержимое до отправки на сервер. Я понимал под "толщиной" клиента объем информации, необходимый для обмена им с сервером - чем он меньше, тем клиент "тоньше". Вы, видимо, говорите немного о другой характеристике - доступности. InfoPath может не оказаться под рукой у заинтересованного лица. Немаловажно также, что за использование этой программой необходимо отдельно заплатить , в то время как браузер можно получить в составе операционной системы.

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

Наше с Вами обсуждение, помогло мне дойти до понимания, почему Microsoft не позиционирует BizTalk Server как BPM-систему. Видимо, это как раз связано с ограничениями в плане доступности инстументов для участников процесса. То "взаимодействие с людьми", которое продекларировано для BizTalk, следует понимать как не с любыми людьми, а только с теми, доступность программных инструментариев которых как минимум известна разработчикам бизнес-приложений и отвечает ряду требований, а в лучшем случае им подконтрольна (то есть, сотрудникам этой же компании или сотрудникам партнеров, факт использования которыми программы InfoPath можно заранее установить). Разумеется, остается еще возможность разработки WEB-форм "своими руками", но поскольку мы говорим об удобстве и скорости разработки, то такой вариант, разумеется, существенно проигрывает тем инструментариям, которые позволяют генерить формы (или по крайней мере их заготовки) автоматически.

Медитируя на обсуждаемую тему, дошел до понимания еще одного нюанса.
Для заполнения форм в браузере требуется непосредственный доступ к WEB-серверу. InfoPath этого НЕ требует. Форма InfoPath может сама отправить информацию, в частности, по электронной почте, непосредственно на некоторый узел ее обработки. Это может быть сервер (я уже говорил о том, что взаимодействие людей через портал, требующий авторизации, может несколько нервировать), но это может быть и просто другой человек, у которого тоже имеется InfoPath.
Если для BPM-системы какой-то шаг бизнес-процесса выполняется группой людей, то InfoPath позволяет взаимодействовать этим людям НЕПОСРЕДСТВЕННО, минуя сервер.

Хорошо это или плохо? Вообще, с точки зрения процессного подхода к управлению, идея контрпродуктивная. Процессный подход подразумевает детализацию всех телодвижений с регистрацией всех фактически произведенных телодвижений движком BPMS. Однако, если я правильно понял по просмотренным материалам на сайте Unify NXJ, некоторые операции при human-to-human взаимодействии там могут назначаться ГРУППЕ людей. В группе неизбежно возникает внутреннее взаимодействие, от которого, если я правильно понял, Unify NXJ позволяет абстрагироваться.

Это я всё не к тому, что InfoPath лучше (уже согласился, что хуже :) ). Просто хочется до конца понять отличия.

А вот по взаимодействию BPMS с группой людей у меня к Вам, АБ, отдельный вопрос. Объясните пожалуйста, всегда ли подразумевается, что любой член группы (они там в группе сами разбираются, какой именно) может выполнить действия, назначенные группе? Или могут быть какие-то другие взаимодействия с группой людей, допустим, с учетом приоритетов ее членов внутри группы?

Представим себе такую ситуацию. Члены некоторой группы в количестве 10 человек задействованы в одной из операций какого-то бизнес-процесса, которая происходит довольно редко (допустим, один раз в несколько месяцев). При этом терриориально они размещаются в разных местах и взаимодействуют друг с другом не визуально, а с с помощью телефонной связи. Когда возникает необходимость в выполнении назначенной в бизнес-процессе на группу операции, нужно чтобы реакция этой группы была молниеносной. Для того, чтобы члены группы узнали о том, что возникла ситуация, требующая их срочного вмешательства, они либо должны часто заходить на портал и смотреть, не появилось ли для них новая информация (судя по всему, не очень удачная идея, если подавляющая часть заходов в портал будет производиться вхолостую), либо получать оповещение (по электронной почте, пейджеру, ICQ или как-либо иначе). Но они получают оповещение одновременно? Каждый из членов группы не в курсе, какова реакция других членов группы. Каждый из них может понадеяться на других и оставить оповещение без внимания. Или начинать обзванивать других членов группы, чтобы узнать, взялся ли кто-нибудь за обработку данной ситуации. Или (что иногда проще всего) просто взять и самому ее обработать. Последний вариант для исполнительных сотрудников может показаться наиболее очевидным и предпочтительным. Теперь представим, что все 10 членов группы - исполнительные сотрудники. Каждый из них, получив оповещение, сразу полез в портал и каждый из них увидел, что в пуле болтается форма, требующая обработки. Все 10 человек пытаются одновременно ее открыть и обработать. Ясное дело, что корректно это сможет сделать только самый первый. Какова будет реакция системы на действия остальных, когда они попытаются отправить на сервер заполненную форму - сообщение об ошибке? Или BPMS в принципе откажется открывать форму тем, кто не успел это сделать первым? Есть ли какие-то возможности управления многопользовательским доступом к информации внутри группы?

АБЧто значит к серверу, реально -- к интету? Ну так и для почты нужно то же самое, не понял в чем разница -- в скорости?В том, что параметры авторизации прописываются в почтовом клиенте, и почтовым клиентом прои соединении с почтовым сервером производится без участия человека. Вы представьте, что Вас, как стороннего участника некоторых бизнес-операциям привлекли к своим бизнес-процессам 10 разных организаций. И в каждой для регистрации нужно набрать логин и пароль. Какова будет Ваша реакция, если это придется делать по множеству раз в день?

АБМожно приучить пользователя не только следить за поступлением новой почты, но и постоянно держать открытым окно браузера, в котором автоматически будет обновляться перечень назначенных ему задач.Каким же образом окно автоматически будет обновляться? У Unify портал автоматически обновляет окно??? Насколько мне известно (не уверен, однако), в MS SharePoint окно автоматически не обновляется. Если оно обновляется автоматически, то не мешает ли это текущей работе при заполнении форм, например?

АБДалее, когда 10 пользователей получают одно и то же задание, движок конечно же помогает им координировать свои действия. Например, на форме могут быть кнопки "захватить задачу" и "освободить задачу". Вначале все пользователи являются как бы кандидатами на выполнение задачи. По нажатию кнопки "захватить" все пользователи, кроме самого шустрого, становятся "запасными игроками", задание исчезает из их списка, а если они уже успели получить форму и пытаются захватить задачу, то это диагностируется как ошибка. Если первый освобождает задачу, ее все снова получают.Спасибо, интересное решение! :)

АБЕсли это выглядит слишком сложным, то есть альтернативный путь. Разбиваем задание на два шага. На первом пользователь видит на форме кнопку "принять задачу". По ее нажатию процесс переходит к следующему шагу, в котором исполнитель прописан не статически, а динамически -- им становится тот, кто выполнил предыдущий шаг. Остальные пользователи, получившие первое задание, при попытке его выполнить получают уведомление "спасибо, данное задание уже выполняется другим пользователем".Предыдущий вариант мне понравился больше.

АБЕсть и совсем другой путь: назначать задание не группе, а одному пользователю, но при этом разрешить делегирование данного задания другому пользователю. Причем делегирование может быть двояким: либо я говорю другому пользователю "сделай это вместо меня", и он полностью за него отвечает; либо я говорю "сделай, а я проверю", и тогда за мной останется подтверждение задания после его выполнения.У такого решения есть недостаток. Может оказаться, что тот, кто должен "говорить", например, заболел.

АБНаконец, есть еще административная функция. Как быть, если задание назначено пользователю, а он по какой-либо причине не может ее выполнить? Администратор системы должен иметь возможность сменить исполнителя любому стартовавшему заданию.В Unify это может сделать только администратор системы? А может, например, руководитель отдела назначить задание подчиненному?

АБВ общем, имеется спектр возможностей, из которых можно выбирать. Примечательно, что эти аспекты в случае human-oriented BPMS задаются на уровне схемы бизнес-процесса. В BPEL места для подобных вещей нет, и это мне представляется концептуальным недостатком. Вы меня убедили... :)

АБ GaryaКаким же образом окно автоматически будет обновляться? С этим вообще нет проблем. Если у вас есть толковый веб-программист, то он сможет сделать веб-страницу, содержимое которой будет обновляться с заданной периодичностью, например, отражая изменившееся содержание базы данных.Мне даже в голову не приходило залезть в исходники стандартного портала, чтобы там править генерируемые им DHTML-коды страниц. Разумеется, так сделать можно.