Process Engine API

Java API — наиболее распространённый способ взаимодействия с движком. Центральной точкой входа является ProcessEngine, который может быть создан несколькими способами, как описано в разделе конфигурации. Из ProcessEngine можно получить различные сервисы, содержащие методы workflow/BPM. ProcessEngine и объекты сервисов являются потокобезопасными. Поэтому вы можете хранить ссылку на один из них на протяжении всего времени работы сервера.

ProcessEngines.getDefaultProcessEngine() при первом вызове инициализирует и собирает (build) процессный движок, а затем всегда возвращает тот же самый экземпляр. Корректное создание и закрытие всех процессных движков можно выполнить с помощью ProcessEngines.init() и ProcessEngines.destroy().

Класс ProcessEngines выполняет поиск всех файлов camunda.cfg.xml и activiti.cfg.xml. Для всех файлов camunda.cfg.xml процессный движок будет создан типичным способом:

Для всех файлов activiti.cfg.xml процессный движок будет создан «по Spring-способу»: сначала создаётся контекст Spring-приложения, а затем процессный движок извлекается из этого контекста.

Все сервисы не имеют состояния (stateless). Это означает, что вы можете легко запускать OpenBPM Engine на нескольких узлах в кластере, где все узлы работают с одной и той же базой данных, не беспокоясь о том, какая машина фактически выполняла предыдущие вызовы. Любой вызов любого сервиса является идемпотентным независимо от того, где он выполняется.

RepositoryService — вероятно, первый сервис, который потребуется при работе с движком OpenBPM Engine. Этот сервис предоставляет операции для управления и манипулирования деплоями (deployments) и определениями процессов (process definitions). Не углубляясь здесь в детали: определение процесса — это Java-аналог BPMN 2.0 процесса. Это представление структуры и поведения каждого шага процесса. Деплой — единица упаковки внутри движка. Деплой может содержать несколько BPMN 2.0 XML-файлов и любые другие ресурсы. Что именно включать в один деплой — решает разработчик. Это может варьироваться от одного BPMN 2.0 XML-файла процесса до целого пакета процессов и связанных ресурсов (например, деплой hr-processes может содержать всё, что относится к HR-процессам). RepositoryService позволяет деплоить такие пакеты. Деплой деплоя означает, что он загружается в движок, где все процессы проверяются и парсятся перед сохранением в базе данных. С этого момента деплой известен системе, и любой процесс, включённый в деплой, теперь может быть запущен.

Кроме того, этот сервис позволяет:

Если RepositoryService относится к статической информации (т. е. данным, которые не меняются или меняются незначительно), то RuntimeService — почти полная противоположность. Он занимается запуском новых экземпляров процессов (process instances) по определениям процессов. Как упоминалось выше, определение процесса задаёт структуру и поведение различных шагов процесса. Экземпляр процесса — это одно выполнение такого определения процесса. Для каждого определения процесса обычно одновременно выполняется много экземпляров. RuntimeService также является сервисом, который используется для получения и сохранения переменных процесса. Это данные, специфичные для конкретного экземпляра процесса, и они могут использоваться различными конструкциями в процессе (например, исключающий шлюз часто использует переменные процесса, чтобы определить, по какому пути продолжить выполнение процесса). RuntimeService также позволяет выполнять запросы по экземплярам процессов и выполнениям (executions). Execution — представление BPMN 2.0 концепции «токена». По сути execution — это указатель на то, где сейчас находится экземпляр процесса. Наконец, RuntimeService используется всякий раз, когда экземпляр процесса ожидает внешний триггер и процесс необходимо продолжить. Экземпляр процесса может иметь различные состояния ожидания, и этот сервис содержит различные операции, чтобы «сигнализировать» экземпляру, что внешний триггер получен и выполнение процесса можно продолжить.

Задачи, которые должны выполняться реальными пользователями системы, являются ключевой частью процессного движка. Всё, что связано с задачами, сгруппировано в TaskService, например:

IdentityService довольно прост. Он позволяет управлять (создание, обновление, удаление, запросы, …​) группами и пользователями. Важно понимать, что ядро движка фактически не выполняет никаких проверок пользователей во время выполнения. Например, задача может быть назначена любому пользователю, но движок не проверяет, известен ли этот пользователь системе. Это связано с тем, что движок может использоваться совместно с такими сервисами, как LDAP, Active Directory и т. п.

FormService — необязательный сервис. Это означает, что движок OpenBPM Engine можно прекрасно использовать и без него, не жертвуя функциональностью. Этот сервис вводит понятие стартовой формы (start form) и формы задачи (task form). Стартовая форма — форма, которая показывается пользователю до запуска экземпляра процесса, а форма задачи — форма, которая отображается, когда пользователь хочет завершить задачу. Вы можете определить эти формы в BPMN 2.0 определении процесса. Этот сервис предоставляет эти данные в удобном для работы виде. Но опять же, это опционально, так как формы не обязательно должны быть встроены в определение процесса.

HistoryService предоставляет доступ ко всем историческим данным, собираемым движком. При выполнении процессов движок может сохранять множество данных (это настраивается), таких как время старта экземпляра процесса, кто выполнял какие задачи, сколько времени заняло выполнение задач, какой путь был пройден в каждом экземпляре процесса и т. д. Этот сервис в основном предоставляет возможности запросов для доступа к этим данным.

ManagementService обычно не требуется при разработке пользовательских приложений. Он позволяет получать информацию о таблицах базы данных и их метаданных. Кроме того, он предоставляет возможности запросов и операции управления для jobs. Jobs используются в движке для различных целей, таких как таймеры, асинхронные продолжения, отложенная приостановка/активация и т. п. Позже эти темы будут рассмотрены подробнее.

FilterService позволяет создавать и управлять фильтрами. Фильтры — это сохранённые запросы, например запросы задач. Так, фильтры используются в Tasklist, чтобы фильтровать пользовательские задачи.

ExternalTaskService предоставляет доступ к экземплярам внешних задач link:{{< relref "external-tasks.md" >}}[]. Внешние задачи представляют собой элементы работы, которые обрабатываются внешне и независимо от процессного движка.

CaseService похож на RuntimeService, но для экземпляров кейсов (case instances). Он занимается запуском новых экземпляров кейсов по определениям кейсов и управлением жизненным циклом выполнений кейса (case executions). Сервис также используется для получения и обновления переменных процесса экземпляров кейсов.

DecisionService позволяет выполнять оценку решений (decisions), задеплоенных в движок. Это альтернатива вычислению решения внутри задачи бизнес-правил (business rule task), независимая от определения процесса.

Для выполнения запросов к данным в движке есть несколько вариантов:

Рекомендуемый способ — использовать один из Query API.

Java Query API позволяет программировать полностью типобезопасные (typesafe) запросы с fluent API. Вы можете добавлять различные условия к запросам (все они применяются вместе как логическое AND) и ровно одну сортировку. Следующий код показывает пример:

Дополнительную информацию можно найти в {{< javadocref page="" text="Java Docs" >}}.