Реализаций движков, позволяющих создавать процессы с использованием этого языка, мне известно не так уж и много. В частности, можно упомянуть Oracle BPEL Process Manager и продукт, о котором пойдет речь дальше – Serena Business Manager (SBM). SBM позволяет быстро создавать web-приложения, автоматизирующие какой-нибудь процесс. В модели процесса (workflow) предусмотрена возможность в момент изменения состояния вызвать внешнюю web службу. А если нужно реализовать какую-нибудь логику и одного вызова недостаточно? Вот тут и пригодится процедура, написанная на языке BPEL и исполняемая средствами той же платформы BPM.
Подробнее на самом языке я останавливаться не буду, в сети можно найти достаточно информации на эту тему, например, здесь. Я же опишу реализацию конкретной задачи.
Задача была поставлена следующим образом – разработать функционал копирования бизнес-сущностей (в моём процессе – TD Links), но не просто так, а с предварительным опросом стороннего веб-сервиса. Этот сервис (bridge) обладает методом, принимающим на вход некоторые атрибуты объекта TD Link. Затем bridge опрашивает стороннюю систему и в ответ сообщает, может ли объект с такими атрибутами существовать в нашей системе. Как он это делает меня не интересует, bridge для меня является «чёрным ящиком».
Кроме того, мне потребовался ещё один веб-сервис, реализующий функции работы с бизнес-сущностями в нашей системе (чтение, создание и т.д.). Называть его буду AppServices.
Список шагов, из которых может строиться процесс, выглядит следующим образом:
Наиболее важные из них это:
- Service. Позволяет оформить обращение к веб-службе.
- Service. Позволяет оформить обращение к веб-службе.
- Calculate. Используется для работы с переменными, маппинга данных, обработок и т.д.
- Scope, Compensate и Throw. Шаги для обработки ошибок.
Остальные шаги реализуют базовые функции – циклы и условия.
Итоговый worflow выглядит так:
Так как объекты TD Links существуют в системе не сами по себе, а в связи с другими объектами (типа Stagings), для начала мне потребовалось найти в системе нужные мне Stagings.
AppServices обладает методом, позволяющим делать выборку с использованием SQL-запроса. SQL-запрос собран прямо в виде строки:
Да, важное отступление. Движок позволяет определять переменные, которые будут использоваться по ходу процесса, чем я в данном случае и воспользовался:
Сформировав SQL-запрос, можно перейти к вызову нужного метода, выполнив маппинг данных:
Для маппинга могут использоваться как переменные, так и результаты выполнения предыдущих шагов процесса (например, результат запуска веб-службы).
После аналогичным способом (через SQL-запрос) делается выборка объектов для копирования – TD Links и запуск цикла.
И, наконец, этап опроса внешнего веб-сервиса, настраивается также через элемент типа «Service».
Последним шагом выполняем создание копии объекта TD Link, с сохранением в ней результатов, полученных от bridge (в том числе сообщение об ошибке, если оно есть).
Естественно, от отладки никуда не деться, и инструмент разработки обладает для этого довольно неплохими возможностями. В частности, можно посмотреть результат выполнения каждого шага в отдельности и увидеть, на каком из них что-то пошло не так.
Что можно сказать в итоге. Из плюсов предложенной реализации можно отметить следующие моменты:
- Простота разработки. По сути, не потребовалось никакого кодирования.
- Быстрота. Создать и отладить небольшой процесс можно за пару часов. При этом мне не пришлось выходить за рамки штатной среды разработки SBM Composer.
- Удобство отладки. Все логи в одном месте; видно, на каком шаге произошел сбой. Кроме того, существует единый лог, куда сбрасываются ошибки во время работы всех работающих процессов.
- Контролируемая легкость внесения изменений. Обновление описаний веб-служб, переименование переменных, внесение изменений в маппинг данных – всё это делается очень легко. И при этом, мои изменения фиксируются во встроенной системе контроля версий – в любой момент можно откатиться до предыдущей работающей версии.
- Возможность запуска с помощью внешнего события. В моем случае процесс инициирует пользователь, нажимая кнопку на пользовательском интерфейсе, но инициатором процесса может быть и некое внешнее событие.
Минусы, конечно, тоже есть:
- Проблематичность реализации сложных алгоритмов. Всё же, инструмент создания workflow ограничен в своих возможностях. Сложную обработку данных все же лучше оформлять в своей собственной web службе.
- Сложности с маппингом данных. Иногда приходится использовать дополнительные шаги процесса для маппинга данных, что несколько утяжеляет процесс.
- Ограничения, накладываемые на веб-службы. Поддерживается только архитектуры SOAP и REST (через специальную обёртку), также есть ряд ограничений, накладываемые на WSDL-файл.
Спасибо всем, кто дочитал пост до конца. Будем рады ответить на ваши вопросы в комментариях.
Комментарии (6)
AnastasiaPMP
17.12.2015 10:05Поправьте меня, если я ошибаюсь, но экзотический язык для бизнес-критичного приложения (мне нравится именно этот термин) — это залог монополии для производителя системы. Он будет её устанавливать, он будет её обслуживать, он будет диктовать условия. И кого-то другого я ему на замену не найду. Таким образом, я впадаю в ненужную мне зависимость. Так ли это?
aionin
17.12.2015 12:18С этой точки зрения, любые платформы-конструкторы бизнес-приложений, игр, web-сайтов и платные, и бесплатные «привязывают» к себе пользователя. Совершенно невозможно себе представить мягкий быстрый переход, например, с WordPress на Goomla или с Jira на SBM. Но так ли это плохо?! Платформы-конструкторы действительно сильно упрощают многие задачи и операции разработки новых приложений, резко повышают эффективность разработки. Если смотреть на этот вопрос еще шире, то даже чистое программирование на C# на самом деле резко сужает для вас список сред разработки, не так ли?
Ближе к теме статьи, как уже было замечено Throwable, на BPEL никто не автоматизирует процессы. Даже у нас на платформе SBM для этого используется своя простая нотация workflow (не BPMN, к сожалению), а модули, написанные на BPEL, только дополняют основной процесс необходимой функциональностью. Например, до или после действий пользователя на форме приложения, обратиться к внешней системе за информацией в синхронном режиме или записать во внешнюю систему информацию в асинхронном.
Еще один плюс — модуль на BPEL запросто можно переносить из среды разработки в промышленную среду вместе с кодом самого приложения без необходимости менять вручную массу параметров соеднения в коде.
jakobz
А какое принципиальное отличие от того, чтобы написать это же самое на обычном языке программирования? Т.е. кроме того что вместо текста там квадратики и стрелочки — есть какие-либо плюсы?
Throwable
Основная задача — окучить клиента. Если тупо показать ему код, то он почувствует себя дураком и покупать ваше изделие не станет. А схемки нехило поднимут его самооценку.
BPEL вообще мертворожденный язык. Изначально планировался для оркестрации вебсервисов и выполнения примитивной логики. Но внезапно оказалось, что людям требуется делать нечто бОльшее, чем тупые меппинги полей 1-1 при помощи XPath, а стандарт на этот счет молчал. Поэтому каждый кулибин внедряет в свой BPEL специальные нестандартные ноды типа «Compute», которые позволяют выполнять хоть что-то полезное в какой-нибудь среде: sql, java, etc. Сейчас BPEL повсемесно вытесняется BPMN-ом.
Основное отличие от кода на языке — возможность асинхронного выполнения процесса и «засыпания» с сохранением состояния в базе до прихода события извне, ответа вебсервиса, etc… Но это только для «хороших» BPMS.
О косяках концепта BPM как такового я писал здесь.
konsoletyper
Вот интересно, почему тогда первые две буквы BP, это как бы намекает. Однако, в реальных бизнес-процессах помимо веб-сервисов есть ещё и люди. Помню, когда в своё время смотрел в сторону BPEL, возмутился этим фактом и стал рыть. Оказалось, что есть на эту тему какие-то extension's, но на то время ещё в статусе черновика и нигде так не реализованные (с тех пор я больше не интересовался судьбой этого стандарта).
Для этой цели я немного «докрутил» Java, чтобы она могла «засыпать». А именно: взял javaflow из апачевского инкубатора (это такой проект, который может обычный код в Java преобразовывать в корутины) и немного допилил напильником. В частности, оказалось, что ни стандартной сериализации, ни какого-нибудь kryo не хватает для того, чтобы нормально сохранить состояние выполнения. Пришлось писать свой простенький сериализатор с нужными мне фичами. Всё работает нормально, но проблема в том, что даже при малейшем изменении кода бизнес-процесса десериализация старых образов ломается, причём весьма неочевидным образом. Проблему удалось частично решить заменой бинарной сериализации на сериализацию в JSON и написанием дешифратора стека, который порождается javaflow. Короче, идея красивая, но вот эта проблема, в которую я упёрся, кажется, не имеет удовлетворительного решения.
С BPMN в своё время я намучился. Непонятно, для кого это. С одной стороны, аналитик их понимает и умеет редактировать. С другой, он без помощи разработчиков не может понять, почему этот вот "${foo.bar()}" работает, а "$foo.bar". Причём чаще всего бизнес-процессы у разных клиентов похожи до безобразия, и нужно обычно «чуть-чуть поменять вот эту штуку», ради чего приходится плодить кучу похожих диаграмм. По мне, так уж пусть лучше разработчики реализуют бизнес-процессы так, как им угодно, закладывая в них разумную вариативность, и предоставляя возможность тому же внедренцу/аналитику их настроить с помощью параметров. По крайней мере, на моём текущем месте работы этот подход себя вполне зарекомендовал, особенно по сравнению с предыдущей коробочной BPMS.
Throwable
Про все эти BPM я уже ответил здесь: http://habrahabr.ru/post/273025/#comment_8690463 (Хабр мне не дает вставлять нормально ссылку).
С BPEL работал и работаю до сих пор. В самой его наихудшей реализации: IBM Websphere Process Server. Oracle SOA выглядит и работает значительно лучше. Самый лучший и во многом продуманный продукт — это JBoss BPM Suite.
Про асинхронное выполнение. Можно взять уже готовый движок jBPM или Activiti. Они в минимальном окружении весят 50кб и ничего дополнительного не требуют. Для Java есть фреймворк Quasar, который прозрачно для кода заменяет треды файберами, которые в свою очередь suspendable и serializable.