Чем грозит движок бизнес-процессов программисту на примере Apache Activiti

Словосочетание «бизнес-процессы» давно и прочно будоражат мозг всем бизнес-людям и тем, кто с оными сталкивается. В среде заинтересованных считается, что работа по бизнес-процессам — это «стильно, модно, молодежно». Правда, нет никакой гарантии увидеть четкое понимание того, что же это за зверь в глазах собеседника, даже если он и есть настоящий бизнес-человек. А теперь предлагаю представить, какое болото на эту тему квакало в голове среднестатистического разработчика (на примере автора), когда выяснилось, что следующий продукт будет работать по этим самым бизнес-процессам…

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

Вот начиная с этого момента и началось знакомство с этими слабо понятными сущностями и тем, как они влияют на разработку продукта, зачем они могут быть нужны и чем полезны. Хочу отметить, что программного кода внутри вообще не будет — чего-чего, а технических трудностей там практически нет. Нормальная промышленная разработка. В моем случае — JavaEE и чуть Spring'а.

В чем суть

Итак, бизнес-процессы. Всю жизнь меня интересовал вопрос «зачем?» и только потом — «как». Знакомство с бизнес-процессами не стало исключением. Поэтому первым пунктом давайте посмотрим, в чем суть. Если коротко — бизнес-процесс — это не более чем маршрут прохождения между небольшими кусками работы. Как и в любом маршруте, здесь есть свои пути следования, перекрестки, условия, при которых можно ехать, нужно стоять или разрешено свернуть только налево и на разворот.

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

Практическая польза

Итак: чем же является среднестатистический движок бизнес-процессов, что он может? Первейшая его обязанность — понимать рисунки, нарисованные бизнес-аналитиками (или самими разработчиками, тут смотря как кому повезет) в определенной аннотации (поговорим чуть позже) и выполнять последовательность действий в строго заданном порядке, учитывая все указанные условия и… всё. Нет, действительно всё.

Здесь мы начнем топтать кирзовым сапогом ранимую душу менеджера: нет, движок не нарисует сам нужные формы. Нет, он не выполнит нужные работы за пользователя, если нужен ввод данных. Нет, он даже не напишет сам бизнес-логику и он действительно не знает, где лежит наша база и как к ней обращаться и вызывать нашу уже написанную бизнес логику. Всего этого движки бизнес-процессов из коробки не умеют. Все это нужно писать. Все, что вам гарантируется — что какой-то фреймворк возьмет немного ресурсов и пойдет от одного реализованного вами класса до другого опять реализованного вами класса по нарисованной опять вами схеме. Это может показаться очевидным, но всегда лучше это озвучить. Хуже не будет.

А оно нам точно надо?

Дальше нужно ответить на вопрос — а оно нам надо? Казалось бы — зачем учить еще одну книжку на английском, если простенькую маршрутизацию можно собрать на коленке за неделю-другую. Резон в этом все же есть (сейчас я буду говорить о возможностях Apache Activiti в том числе, но прочие представители в основном не хуже).

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

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

Надо!

Пусть мы решили, что нам оно надо. И встал вопрос — если почти все нужно писать самим — нужно ли заморачиваться еще с одним компонентом системы с сомнительной полезностью? На самом деле, полноценно повторить все, что делает тот же Apache Activiti (далее — просто Activiti) — сложно и долго. По пунктам: основные работы из того, что делает Activiti:

• понимает описание бизнес-процесса в формате BPMN2 — без этого нужно будет придумать что-то свое, что позволит задавать последовательность действий и не факт, что это будет лучше уже готового стандарта;
• сохраняет историю прохождения процессов вместе с временными отсечками*;
• заботится о трансакциях, причем есть возможность настройки и распределенных трансакций;
• поддерживает роли исполнителей (даже может подключаться к LDAP и использовать информацию о пользователях прямо оттуда)*;
• и еще по мелочи пригоршня технологического функционала.

Почему я отметил звездочкой пункты о ролях пользователя и истории? Да это же бесконечно интересная информация для бизнес-людей! Можно в реальном времени смотреть, как идут процессы, кто тормозит, где процесс, возможно, нужно распараллелить, сколько времени уходит на каждую фазу и т.п. Эта информация — просто золотая жила для оптимизации процессов! И вот на основе этой информации можно будет перестраивать процессы работы предприятия можно сказать почти на лету.

Подводный камень

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

Т.е. в конечном счете, когда разработчики смирились с написанием фактически stateless-операций, ориентированных на работу в окружении, которое создается движком бизнес-процессов — изменения под потребности заказчика скорее всего будут выполняться быстрее и проще, чем без опоры на возможности какого-нибудь Activiti (при условии, что приложение хорошо дробится на атомарные работы, конечно же).

Стандарт описания BPMN 2

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

На самом деле, стандарт описания бизнес-процессов не один. Даже далеко не один. Есть BPEL, BPMN1.2, BPMN2, а за пределами функционального описания — всякие IDEF0 и EPC. Но здесь мы поговорим о BPMN2. В чем его плюсы? Он достаточно развит, чтобы хорошо описывать очень развесистые процессы, является одновременно и описательным и исполняемым (в одном файле хранится информация не только о работах и их связях, но еще и положении этих элементов в пространстве, если кому-то захочется увидеть живую диаграмму процесса). Ну и это настоящий XML в конце концов, что позволяет его использовать как угодно и править где захочется.

Технически, здесь стоило бы рассказать об элементах, используемых в BPMN 2.0. Но… объем информации там такой, что под это надо писать целую кучу статей. Тем более, что прямо в документации того же Activiti есть краткое описание всех элементов, кроме того есть целиком переведенный на русский язык стандарт. Перевод выполнила компания «EleWis», за что ей большое спасибо от коллег, недолюбливающих языки, отличные от русского, он совершенно спокойно ищется и скачивается.

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

Редактор(ы) схем бизнес-процессов

Да, схемы. Их надо где-то рисовать — не всем нравится писать XML от руки в vim. Если говорить об Activiti — для него (него — потому что движок, м.р.) прямо в поставке идет веб-приложение, вполне работающее на Томкате и предоставляющее довольно комфортный интерфейс просмотра и редактирования процессов. Кроме того есть плагин к Eclipse. Просмотрщик к IDEA. И вообще — стандарт BPMN 2 — это же стандарт и должен поддерживаться целой кучей соответствующих рисовалок. Последнее предложение — это мои наивные мысли, которые не выдержали проверки действительностью.

Во-первых бесплатных инструментов, формирующих нормальный документ в аннотации BPMN 2 и позволяющий сохранять его в корректный XML согласно стандарту (*.bpmn или .bpmn20.xml) практически нет — Aris Express отпал. Неплох Yaoqiang (даже не буду пытаться ЭТО произнести), но он тоже не совсем бесплатен. Всего-то хотелось оффлайновый, в виде отдельного приложения, редактор BPMN, который был бы удобен и не терял время от времени значения из полей, как это любит делать плагин к Eclipse. Но, приличные инструменты были доступны мало того, что за серьезные деньги, так их еще и увидеть было практически невозможно. Только после оплаты. А некоторые поддерживали BPMN. Но очень, очень старый.

Бесконечно забавно было читать форумы бизнес-аналитиков на тему выбора редакторов. Очень много прочитанного сводилось к тому, что им не нужен на выходе XML, а нужна картинка. Т.е. Visio был среди лидеров. А трудности программистов их не интересовали.

Так и получилось, что комплектное веб-приложение к Activiti стало оптимальным выбором. Главное найти свободный сервер под него и, в придачу, можно получить вполне себе рабочий вариант для совместной и удаленной работы над схемами процессов.

А! Еще есть «во-вторых»: все движки бизнес-процессов имеют свои теги, плюс к стандарту, поэтому лучше пользоваться именно созданным под него редактором. Или дописывать теги потом вручную — XSD обычно добыть не проблема.

Трудности перевода

Итак, мы прошли долгий путь, решились впутаться в бизнес-процессы и здесь, пока не перешли к частностям определенного движка, считаю своим долгом предупредить об одном скользком нюансе. Дело в том, что нигде в спецификации не написано, насколько мелко дробить процесс для того, чтобы полученный результат имел право называться Оптимальным. Если же процессы будут создавать бизнес-аналитики — все станет еще веселее, так как их задача — максимально точно отразить поток выполнения с точки зрения нормального человека, и никто не будет учитывать, что операция «Сохранить» в двух разных процессах для программиста отличается коренным образом, а не является одним и тем же. Разработчикам нужно быть готовым к тому, что придется объяснять на живых примерах, как же должно быть правильно (с их точки зрения) детализирован процесс, чтобы он хорошо «лег» на бизнес-логику приложения.

А где посмотреть, как правильно? Боюсь, что без накопления некоторого опыта самими разработчиками — нигде. Можно просмотреть ряд примеров процессов, сделать свой по аналогии и понять, что дробление было недостаточным или, наоборот, избыточным.

Примеры:

А вот теперь представьте: справа и слева — один и тот же процесс (нарисовано в DIA на скорую руку в чисто иллюстративных целях). И какой из них правильнее?.. А вот здесь уже решать в конкретном случае. Если для общего управления процессом неважно, почему мог произойти сбой сохранения — может пойти и левый вариант. А если важно все — и правого будет мало. Главное, не дойти до предела дробления и не создавать задачи, содержащие по строчке простейшего кода каждая. Обычно, это перебор. Но не всегда, да…

Сложности выбора

Теперь давайте углубимся в выбор конкретной реализации. Мы в свое время остановились на Apache Activiti. Даже не знаю, есть ли смысл приводить полный набор причин. Скорее всего — нет, так как часть из них диктовались именно тем временем и местом, когда и в каких условиях проводился отбор. Но, если кратко — бесплатный, отзывчивый форум, разработка движется, можно подключить практически все, что начинается со слова Apache (а это очень немало: Camel, Karaf, CXF, ...) простым редактированием pom-файла. Хорошая поддержка CDI, легко конфигурируется.

Кроме Activiti есть еще ряд неплохих решений. Это и Intalio (широко известен в узких кругах их платный продукт, но есть и бесплатное ядро), есть решение и от JBoss — BPMSuite, так же есть еще и платные реализации. Если бы пришлось снова выбирать конкретную реализацию — нет уверенности, что это снова был бы Activiti. Возможно, был бы выбран BPM от JBoss. Но не факт. Оба продукта развиваются достаточно динамично и оба предоставляют непаханое поле возможностей. Можно отметить, что сейчас нет никакого сожаления, что был выбран именно Activiti, а не что-то другое. Но если кто-то собирается выбирать прямо сейчас — я бы настоятельно порекомендовал не останавливаться только на Activiti, а хотя бы сравнить функционал приведенных трех реализаций.

Платные движки

Чем же отличаются во всех смыслах платные реализации от бесплатных? Основным отличием (кроме саппорта 24/7 и пр.) можно назвать следующее: в них реализовано то, что в бесплатных нужно писать руками. Например, коннекторы к веб-сервисам. Развитые мониторы, показывающую статистику в удобном человеку, а не DBA, виде. Настройки с помощью удобных инструментов.

Как упоминалось выше, статистику ведет и бесплатный Activiti, причем уровень логирования настраивается. Но, чтобы показать заказчику важную ему информацию для оптимизации процессов и поиска претендентов на премию Самый Медленный Тормоз Предприятия — нужно садить разработчика, чтобы он написал красивую обертку к уже существующей конфетке. В платных реализациях что-то подобное уже обычно есть.

Также некоторые заказчики прямо требуют только коммерческих реализаций продуктов. Если это важно — нужно посмотреть на платные версии. Как пример, можно зайти на сайт Intalio с целью почувствовать разницу.

Внутренние трудности реализации на примере навигации JSF

Дальше чуть отойдем от общей информации и заберемся в дебри частностей. Кода все-таки здесь не будет — я считаю, что в этой области нет серьезных технических трудностей; скорее, есть трудности понимания, что же происходит и как с этим жить дальше.

Что такое Activiti с технической точки зрения? Это набор jar-ок, т.е. не более чем библиотека, которую можно использовать как хочешь: можно подключать прямо к веб-приложению, можно выносить на уровень модели, да хоть на отдельный сервер (у него есть REST-интерфейс, да). Что это значит в прикладном смысле: можно уводить нагрузку, связанную с работой движка бизнес-процессов хоть на другой физический сервер. Activiti из коробки хорошо поддерживает кластеризацию, поэтому проблем быть никаких не должно.

Кроме того, активити работает на собственную схему базы данных — и тут снова у нас есть выбор: можно накатить скрипты создания таблиц прямо в свою рабочую базу, а можно опять же вынести отдельную базу на отдельный физический сервер и получить независимость от нагрузок собственно Activiti и самого приложения. Это может быть весьма полезно, если нужно ведение «толстой» истории работы процессов при серьезной нагрузке на основную базу приложения. В общем, как хочешь — так и делай. Можно сказать, что это философия большей части продуктов Apache. Расплачиваться за это приходится, как всегда, чтением документации по конфигурированию. Но, в случае Activiti документации не так и много. Причем половина ее — вообще стандарт BPMN2.

Ну и отдельная песня — пользовательский интерфейс. Мы использовали JSF2, у которого, как у любого UI, есть своя собственная модель навигации. И здесь нужно опять же будет писать приложение с оглядкой на бизнес-процессы. Причина в том, что задачи в BPMN2 в основном можно разделить на две группы: задачи, которые выполняются без участия пользователя (например, ServiceTask) и задачи, в которых нужен пользовательский ввод (UserTask). С первыми все просто: у тебя есть кусок как-то оформенного кода — вплоть до JavaScript или Groovy в случае ScriptTask'ов, в котором можно манипулировать переменными активного процесса. Для ServiceTask'ов это означает реализацию заурядного интерфейса, содержащего один метод, в который будет помещаться объект, из которого можно получить доступ к текущему экземпляру процесса и в который можно цеплять любые CDI-бины. В процесс можно помещать любый объекты, лишь бы они умели сериализоваться. Т.е. нормальная работа с сохранением состояния при необходимости. Ничего сложного.

А вот со вторым типом задач все посложнее. Когда процесс натыкается на UserTask, он… просто останавливается и ничего не делает. Пользовательская задача назначается на конкретного пользователя или их группу. Дальше нужно писать свой движок, который посмотрит, нет ли назначенного на пользователя задания и каким-нибудь образом отрисует форму. Вот здесь и порылась вездессущая собака: нужно решить, как будет работать навигация UI, другими словами, или замещаем модель навигации JSF, перекладывая эту заботу на плечи Activiti или… А «или», наверное, и не будет, так как без возможности перенаправить процесс на форму ввода, возможности управления бизнес-процессами серьезно урежутся. Останутся только небольшие кусочки работ, которые могут выполняться вслепую, без участия пользователя. А ведь основную пользу из бизнес-процессов можно извлечь тогда, когда в процессе участвуют несколько людей. Поэтому мы в свое время решили отдать навигацию между формами, входящими в процесс, на сторону Activiti, оставив модели навигации JSF работу с формами, которые не входят в бизнес-процессы. И, думаю, это было правильным решением.

В остальном — Activiti вполне дружелюбный и очевидный в использовании движок бизнес-процессов, который позволяет максимально наглядно дирижировать взаимодействием работ внутри процесса.

В завершение

Надеюсь, все написанное выше, принесет чуть больше ясности в то, что такое бизнес-процессы с точки зрения разработчика. Ну и еще привести цитату некоего Б. Гейтса, ранее работавшего в MicroSoft:

Первое правило любой технологии заключается в том, что автоматизация эффективно операции повышает эффективность.

Второе правило: автоматизация неэффективной операции увеличивает неэффективность

Автор:

Источник