Реализация архитектуры бизнес-приложения с процессной составляющей

Flexberry BPMS включает в себя следующие подсистемы:

  • Административный интерфейс, обеспечивающий:
    • синхронизацию моделей и версий базы бизнес-процессов стандартного сервера управления бизнес-процессами с базой моделей процессов Flexberry BPMS;
    • экранный интерфейс по управлению и мониторингу стандартного сервера;
  • Web API обеспечивающий:
    • прием запросов от бизнес-приложения;
    • передачу запросов на выполнение синхронных действий бизнес-приложениям;
    • передачу запросов на выполнение асинхронных действий сервису fftimer.
  • Сервис fftimer обеспечивающий выполнение асинхронных действий либо по запросу от сервиса Flexberry BPMS WebAPI, либо по заданному расписанию.
  • Библиотека сервисов технологических действий (Activity Services) используется для запуска в рамках бизнес-приложения стандартных технологических действий (Activities).

На стороне бизнес-приложения:

  • методы интерфейса Flexberry BPMS обеспечивают передачу запросов от бизнес-приложения на WEB API;
  • прикладные Activity Services (включая технологические Activity Services) обеспечивают прием и обработку синхронных и асинхронных запросов на выполнение действий (Activities) от стандартных серверов управления бизнес-процессами или Flexberry BPMS.

Кроме этого в системе используется сервисная шина для организации взаимодействия между бизнес-приложениями и Flexberry BPMS.
Flexberry BPMS обеспечивает решение следующих задач:

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

Основные функции Flexberry BPMS:

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

Общая архитектура бизнес-приложения с процессной составляющей представлена на рисунке:

Подробное рассмотрение составляющих Flexberry BPMS приводится отдельно в следующих разделах.

Интерфейс администрирования Flexberry BPMS

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

Основные функции подсистемы:

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

База данных для хранения данных о процессах и задачах

Эта база данных содержит сведения об опубликованных процессах внешних систем управления бизнес-процессами, доступных на запуск, информацию об исполняющихся в данный момент процессах, а также исторические сведения, информацию о назначенных пользователям задачах. Модель объектов данных о процессах представлена на рисунке:

Модель объектов данных о задачах и исполнителях представлена на рисунке:

Сервисы Flexberry BPMS Web API

Сервисы Flexberry BPMS Web API предназначены для обеспечения взаимодействия внешних информационных систем с Flexberry BPMS, а также выступают в роли серверной части для интерфейса администрирования Flexberry BPMS.

Основные функции подсистемы:

  • предоставление RESTful API для внешних систем, позволяющего:
    • получить информацию о доступных для запуска процессах;
    • получить информацию об исполняющихся в данный момент процессах;
    • получить информацию о назначенных пользователю задачах;
    • запустить, продолжить, остановить, перезапустить заданный процесс;
    • завершить, отменить, переназначить задачу;
    • добавить, изменить, удалить информацию о замещении одного пользователя системы другим пользователем;
  • предоставление OData API для интерфейса администрирования Flexberry BPMS.

Сервис таймера Flexberry BPMS Timer Service

Сервис таймера Flexberry BPMS Timer Service предназначен для организации асинхронного взаимодействия с системами управления бизнес-процессами, а также для выполнения повторяющихся задач по заданному расписанию.

Основные функции подсистемы:

  • ведение очереди задач на исполнение;
  • исполнение задач по заданному расписанию;
  • организация асинхронного взаимодействия с системами управления бизнес-процессами.

База данных для сервиса таймера

Эта база данных содержит информацию об очереди заданий таймера, а также информацию о заданиях таймера, запускаемых по заданному расписанию.

Модули интеграции с внешними системами управления бизнес-процессами

Модули интеграции с внешними системами управления бизнес-процессами предназначены для реализации единообразного взаимодействия Flexberry BPMS с различными BPMS согласно выбранной в ходе проведённых исследований архитектуре. Системы управления бизнес-процессами от разных производителей имеют разные возможности интеграции с внешними системами, что приводит к необходимости реализации в информационной системе, в которую необходимо добавить возможность запуска бизнес-процессов, модулей для взаимодействия со всеми такими BPMS. Flexberry BPMS уже содержит модули для интеграции с различными BPMS, предоставляя разрабатываемой на платформе Flexberry информационной системе единый API, не зависящий от использующихся BPMS. Реализован модуль для интеграции с jBPM (KIE), которая была выбрана в результате обзора существующих BPM-решений.

Эффективные методы разворачивания бизнес-приложений с процессной составляющей

Бизнес-приложения с процессной составляющей реализуются в виде нескольких сервисов, что позволяет, с одной стороны, получить гибкость в плане масштабирования и отказоустойчивости, но, с другой стороны, такие приложения сложно разворачивать и обновлять. С целью поиска решения для минимизации трудозатрат, связанных с разворачиванием и обслуживанием инфраструктуры бизнес-приложений, созданных на платформе Flexberry, был проведён обзор источников в Интернете.
Для эффективного разворачивания и поддержки данной инфраструктуры был выбран метод контейнеризации docker с поддержкой кластерного режима разворачивания микросервисов – docker-swarm [42, 43, 44].

Данный режим разворачивания позволяет:

  • Обеспечить функционирование системы в виде множества независимых распределенных по кластеру микросервисов, сгруппированных в стеки сервисов. Тем самым обеспечить равномерное распределение нагрузки по серверам кластера [45].
  • Обеспечить быстрое разворачивание сервисов различных операционных систем в рамках выбранной операционной среды [46].
  • Разворачивать часть или полный набор микросервисов в облачных средах: Microsoft Azure, Docker Cloud, и т. п..
  • Поддерживать функционирование в кластере нескольких версий программного обеспечения (docker микросервисов) с возможностью масштабирования (запуска нескольких идентичных экземпляров) необходимых сервисов для повышения производительности и надежности решения [47].
  • Группировать микросервисы в стеки сервисов, обеспечивающие инкапсуляцию трафика между сервисами стека в рамках выделенной логической сети со встроенным DNS-сервером.
  • Обеспечить отказоустойчивое решение за счет масштабирования части сервисов и перезапуска в случае их отказа или выхода из строя сервера.

В рамках выбранной архитектуры (см. рисунок @Общая архитектура бизнес-приложения…”) можно выделить следующие стеки docker-сервисов (см. рисунок “Набор стеков сервисов проекта”):

  • Cтек сервисов Flexberry BPMS осуществляет как описано выше координацию работы бизнес-приложений и поддерживаемых стандартных серверов управления бизнес-процессами.
  • Cтеки стандартных серверов управления бизнес-процессами. Каждый стек поддерживает работу сервисов в рамках конкретного типа.
  • Стеки бизнес-приложений. Каждый стек обеспечивает работу сервисов конкретного бизнес-приложения.
  • Стек сервисов сервисной шины.

Все стеки сервисов объединены в рамках виртуальной сети, обеспечивающей обмен данными между сервисами, запущенным на узлах docker-swarm-кластера.
Набор стеков сервисов проекта PROJECT1, объединенных виртуальной сетью PROJECT1_Net:

Каждый стек сервисов представляет собой набор сервисов, объединенных внутренней виртуальной сетью.

  • Cтек сервисов Flexberry BPMS включает в свой состав сервисы (см. рисунок “Сервисы стека Flexberry BPMS”):
    • Сервис административного интерфейса FBPMS-admin;
    • Сервис WebAPI-интерфейса FBPMS-api;
    • Сервис асинхронного вызова действий FBPMS-fftimer;
    • Сервис базы данных FBPMS-db.

Сервисы объединены виртуальной сетью, в рамках которой поднимается собственный DNS-сервер, обеспечивающий преобразования имени сервиса (fftimer, WebAPI, admin, db) в IP-адрес сервиса в рамках виртуальной сети. Данный механизм значительно упрощает конфигурирование сервисов, так как в файлах конфигурации указываются имена сервисов, а не IP-адреса сервисов в рамках виртуальной сети, которые могут изменяться.
Для повышения производительности и отказоустойчивости сервисы FBPMS-admin и FBPMS-api могут масштабироваться.
Сервисы стека Flexberry BPMS:

Cтек стандартного сервера управления бизнес-процессами включает docker-образ сервера (например, стандартный docker-образ сервера jBPM) и, если необходимо, дополнительные сервисы, например, базы данных.

  • Стек бизнес-приложения включает:
    • Сервис обеспечивающий выполнение действий (Activities) по запросам от Flexberry BPMS или стандартного сервера BPMS по протоколу Web API;
    • Набор сервисов, обеспечивающих WEB-интерфейс для участников бизнес-процесса;
    • Сервис базы данных и других необходимых для функционирования сервисов.

Все сервисы бизнес-приложения объединены виртуальной сетью и доступны в ее рамках по имени сервиса. Для повышения быстродействия и надежности функционирования системы сервисы WEB-интерфейсов участников бизнес-процесса и сервис действий (Activities) могут масштабироваться.
Стек сервисов сервисной шины включает сервис базы данных и сервис самой сервисной шины.
Использование docker-контейнеризации обеспечивает следующие преимущества:

  • разворачивание системы в мультисистемной (Linux, Windows) среде и облачной (Windows Azure, Docker Cloud и др.) среде;
  • переход на новые версии программного обеспечения без приостановки работы всего комплекса ПО;
  • быстрое разворачивание приложений без необходимости настройки файлов конфигурации;
  • возможность быстрого разворачивания нескольких систем в рамках одного кластера;
  • поддержка отказоустойчивости решения путем репликации части сервисов и их перезапуска при выходе из строя серверов на других серверах кластера.

Методы модификации бизнес-приложений с процессной составляющей

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

  • разработка новых версий интерфейсов участников бизнес-процесса или административного интерфейса Flexberry BPMS без изменения структур баз данных;
  • появление новых версий моделей бизнес-процесса без изменения списка действий (Activities) и структур баз данных;
  • появление новых версий моделей бизнес-процесса без изменения списка действий (Activities) или структур баз данных.

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

Метод модификации бизнес-приложений на основе версионирования

В случае, если изменения не затрагивают списка действий (Activities) и структуры базы данных, возможен переход к новым версиям программного обеспечения и моделей бизнес-процессов без приостановки функционирования системы.
Система контейнеризации docker-swarm поддерживает версионирование программного обеспечения (docker-образов) функциорующего в рамках микросервисов docker.
При появлении новой версии образа сервиса в ручном режиме или автоматически docker останавливает функционирование сервисов с устаревшей версий ПО и запускает аналогичные сервисы с новой версией (см. рисунок 24). В этом случае возможны небольшие (десятки секунд) периоды приостановки функционирования сервиса.
Динамическое обновление версий ПО и моделей бизнес-процессов:

Если сервис функционирует не в единственном экземпляре (масштабирован), то docker последовательно обновляет старые версии ПО на новые во всех экземплярах. В этом случае приостановки функционирования сервиса не происходит – в системе на момент перехода функционируют сервисы различных версий.

Метод параллельного динамического перехода к новой модели бизнес-процесса

Если в процессе работы необходимо реализовать новую модель бизнес-процесса с новыми действиями (Activity), то возможно использование предыдущей схемы обновления, но с оговоренным порядком обновления – до запуска первого бизнес-процесса необходимо обновить Web-API сервисы, обеспечивающие реализацию новых действий (Activities).

Метод последовательного перехода к новой модели бизнес-процесса

В процессе функционирования системы возможны ситуации, когда требуется существенным образом обновить структуру баз данных и, возможно, версии функционирующего программного обеспечения. В этой ситуации есть смысл развернуть на существующей или новой инфраструктуре docker-серверов новую версию системы.
Процесс создания новой версии (например, PROJECT1-V2) системы в docker-swarm заключается в создании новой виртуальной сети (например, PROJECT1-V2_Net) и запуске сервисов новой системы с привязкой их к новой созданной сети (см. рисунок 25).
Создание новой версии системы в рамках новой виртуальной сети:

После создания новой системы производится инициализация необходимых схем баз данных, перенос и синхронизация данных из предыдущей версии системы и тестирование функционирования новой системы (PROJECT1-V2).
По окончании тестирования завершаются текущие бизнес-процессы в рамках старой системы и запускаются новые бизнес-процессы в рамках новой версии системы.
После опытной эксплуатации сервисы старой версии системы и виртуальная сеть (PROJECT1_Net) удаляются из системы.

Сравнительный анализ методов модификации бизнес-приложений с процессной составляющей

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