Пройдясь поиском по Хабрахабру, удалось обнаружить не так уж и много информации, посвященной, надо сказать, не очень распространённому языку BPEL (Business Process Execution Language). Если говорить в общем, то BPEL – это язык, основанный на формате XML, который позволяет описывать логику бизнес-процессов через использование веб-служб.
Реализаций движков, позволяющих создавать процессы с использованием этого языка, мне известно не так уж и много. В частности, можно упомянуть 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-файл.
Спасибо всем, кто дочитал пост до конца. Будем рады ответить на ваши вопросы в комментариях.
Автор: Softmart
