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

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


    Спасибо всем, кто дочитал пост до конца. Будем рады ответить на ваши вопросы в комментариях.
    Softmart 75,78
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 6
    • +1
      А какое принципиальное отличие от того, чтобы написать это же самое на обычном языке программирования? Т.е. кроме того что вместо текста там квадратики и стрелочки — есть какие-либо плюсы?
      • +4
        Основная задача — окучить клиента. Если тупо показать ему код, то он почувствует себя дураком и покупать ваше изделие не станет. А схемки нехило поднимут его самооценку.

        BPEL вообще мертворожденный язык. Изначально планировался для оркестрации вебсервисов и выполнения примитивной логики. Но внезапно оказалось, что людям требуется делать нечто бОльшее, чем тупые меппинги полей 1-1 при помощи XPath, а стандарт на этот счет молчал. Поэтому каждый кулибин внедряет в свой BPEL специальные нестандартные ноды типа «Compute», которые позволяют выполнять хоть что-то полезное в какой-нибудь среде: sql, java, etc. Сейчас BPEL повсемесно вытесняется BPMN-ом.

        Основное отличие от кода на языке — возможность асинхронного выполнения процесса и «засыпания» с сохранением состояния в базе до прихода события извне, ответа вебсервиса, etc… Но это только для «хороших» BPMS.
        О косяках концепта BPM как такового я писал здесь.
        • 0
          Изначально планировался для оркестрации вебсервисов и выполнения примитивной логики.

          Вот интересно, почему тогда первые две буквы BP, это как бы намекает. Однако, в реальных бизнес-процессах помимо веб-сервисов есть ещё и люди. Помню, когда в своё время смотрел в сторону BPEL, возмутился этим фактом и стал рыть. Оказалось, что есть на эту тему какие-то extension's, но на то время ещё в статусе черновика и нигде так не реализованные (с тех пор я больше не интересовался судьбой этого стандарта).
          Основное отличие от кода на языке — возможность асинхронного выполнения процесса и «засыпания» с сохранением состояния в базе до прихода события извне, ответа вебсервиса, etc…

          Для этой цели я немного «докрутил» Java, чтобы она могла «засыпать». А именно: взял javaflow из апачевского инкубатора (это такой проект, который может обычный код в Java преобразовывать в корутины) и немного допилил напильником. В частности, оказалось, что ни стандартной сериализации, ни какого-нибудь kryo не хватает для того, чтобы нормально сохранить состояние выполнения. Пришлось писать свой простенький сериализатор с нужными мне фичами. Всё работает нормально, но проблема в том, что даже при малейшем изменении кода бизнес-процесса десериализация старых образов ломается, причём весьма неочевидным образом. Проблему удалось частично решить заменой бинарной сериализации на сериализацию в JSON и написанием дешифратора стека, который порождается javaflow. Короче, идея красивая, но вот эта проблема, в которую я упёрся, кажется, не имеет удовлетворительного решения.

          С BPMN в своё время я намучился. Непонятно, для кого это. С одной стороны, аналитик их понимает и умеет редактировать. С другой, он без помощи разработчиков не может понять, почему этот вот "${foo.bar()}" работает, а "$foo.bar". Причём чаще всего бизнес-процессы у разных клиентов похожи до безобразия, и нужно обычно «чуть-чуть поменять вот эту штуку», ради чего приходится плодить кучу похожих диаграмм. По мне, так уж пусть лучше разработчики реализуют бизнес-процессы так, как им угодно, закладывая в них разумную вариативность, и предоставляя возможность тому же внедренцу/аналитику их настроить с помощью параметров. По крайней мере, на моём текущем месте работы этот подход себя вполне зарекомендовал, особенно по сравнению с предыдущей коробочной BPMS.
          • 0
            Про все эти 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.
      • 0
        Поправьте меня, если я ошибаюсь, но экзотический язык для бизнес-критичного приложения (мне нравится именно этот термин) — это залог монополии для производителя системы. Он будет её устанавливать, он будет её обслуживать, он будет диктовать условия. И кого-то другого я ему на замену не найду. Таким образом, я впадаю в ненужную мне зависимость. Так ли это?
        • 0
          С этой точки зрения, любые платформы-конструкторы бизнес-приложений, игр, web-сайтов и платные, и бесплатные «привязывают» к себе пользователя. Совершенно невозможно себе представить мягкий быстрый переход, например, с WordPress на Goomla или с Jira на SBM. Но так ли это плохо?! Платформы-конструкторы действительно сильно упрощают многие задачи и операции разработки новых приложений, резко повышают эффективность разработки. Если смотреть на этот вопрос еще шире, то даже чистое программирование на C# на самом деле резко сужает для вас список сред разработки, не так ли?
          Ближе к теме статьи, как уже было замечено Throwable, на BPEL никто не автоматизирует процессы. Даже у нас на платформе SBM для этого используется своя простая нотация workflow (не BPMN, к сожалению), а модули, написанные на BPEL, только дополняют основной процесс необходимой функциональностью. Например, до или после действий пользователя на форме приложения, обратиться к внешней системе за информацией в синхронном режиме или записать во внешнюю систему информацию в асинхронном.
          Еще один плюс — модуль на BPEL запросто можно переносить из среды разработки в промышленную среду вместе с кодом самого приложения без необходимости менять вручную массу параметров соеднения в коде.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое