Pull to refresh
0

Создание бизнес-процесса на языке BPEL с использованием платформы Serena Business Manager

Reading time 3 min
Views 13K
Пройдясь поиском по Хабрахабру, удалось обнаружить не так уж и много информации, посвященной, надо сказать, не очень распространённому языку 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.

Список шагов, из которых может строиться процесс, выглядит следующим образом:



Наиболее важные из них это:

  1. Service. Позволяет оформить обращение к веб-службе.
  2. Service. Позволяет оформить обращение к веб-службе.
  3. Calculate. Используется для работы с переменными, маппинга данных, обработок и т.д.
  4. 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-файл.


Спасибо всем, кто дочитал пост до конца. Будем рады ответить на ваши вопросы в комментариях.
Tags:
Hubs:
+6
Comments 6
Comments Comments 6

Articles

Information

Website
www.softmart.ru
Registered
Founded
Employees
2–10 employees
Location
Россия