Сервис обмена сообщениями, управляемый процессами

Рабочий процесс (workflow) в рамках PDMS служит «обёрткой» для триггеров и задач, обеспечивая последовательность действий и событий, которую можно многократно запускать без необходимости повторно её настраивать. Такой процесс выступает в роли контейнера: он группирует статусы и действия — например, переводит запись из одного состояния в другое.^[5]. Помимо триггеров и задач контейнер может содержать группы или артефакты. Все элементы внутри рабочего процесса становятся доступны для всех его триггеров и задач.

Понятие рабочего процесса может рассматриваться как шаблон части или всего бизнес-процесса. Запуск workflow может происходить по самым разным причинам — например, при наступлении события в домене или при явном вызове.

Для стандартизации логики процессов применяется нотация BPMN (стандарт ISO 19510), определяющая семантику элементов рабочих процессов. В конвейерах обработки медиа используется стандарт ISO/IEC 23090-8, который определяет объекты рабочих процессов и документы их описания^[6].

Когда рабочий процесс, его триггеры и задачи активны, он находится в состоянии ожидания исполнения.

При создании workflow последняя задача добавляется первой, то есть задачи перечисляются в обратном порядке их исполнения. Аналогичным образом триггеры и задачи должны указываться в обратном порядке выполнения^[7].

Реализация рабочих процессов может осуществляться через паттерны оркестрации и хореографии. Оркестрация предполагает централизованное управление единым сервисом-координатором и оптимальна для сложных процессов, требующих строгого контроля. Хореография основана на децентрализованном асинхронном обмене сообщениями и применяется для систем малого масштаба^[8][9].

Задача (job) выполняет конкретное действие, например отправку сообщения или изменение объекта — например, изменение метаданных в определённой единице. Это описание того, что система должна выполнить: задачей может быть самый разный набор действий. После активации задача может запускать другие задачи (например, для доставки сообщения). Она определяет, как система работает с данными, и является деятельностью в пределах домена системы.

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

Механизмы обеспечения отказоустойчивости и обработки исключений при выполнении задач включают автоматические повторы (RetryPolicy) с экспоненциальной задержкой для устранения временных ошибок. Для изоляции сбоев применяется ограничение по времени выполнения (TimeoutPolicy), которое отменяет текущую попытку при превышении лимита или отсутствии прогресса. В случае исчерпания лимита повторов процесс переходит к специальному обработчику ошибок, который выполняет компенсирующие действия (паттерн Saga), отменяя ранее успешно завершённые шаги^[10].

Триггер — это механизм, который инициирует или запускает рабочий процесс, активируя выполнение соответствующих действий. Компоненты, определяющие бизнес-логику и поведение, называются триггерами. Можно создать и настроить любое количество триггеров для автоматической или программируемой проверки, уведомлений, обработки данных и других операций в момент создания, изменения или удаления записи^[11]. В современных событийно-ориентированных архитектурах, помимо базовых CRUD-операций, для инициации рабочих процессов применяются следующие типы триггеров^[12]:

• вебхуки (HTTP-колбэки от сторонних провайдеров);
• подписки на шину сообщений (подключение к системам pub/sub);
• запланированный опрос (клиентский pull-запрос по расписанию);
• CDC на уровне логов (чтение журнала транзакций базы данных).

Кроме того, выделяют временные и условные триггеры^[13][14]:

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

Процесс начинается в определённый момент в системе — например, когда триггер запускает экземпляр рабочего процесса.

Сервис обмена сообщениями, управляемый процессами, обычно применяется для управления более или менее сложными бизнес-процессами.

В хорошо развитой платформе такого типа все триггеры и задачи можно сделать доступными через публичный программный интерфейс (API), что даёт возможность строить процессы непосредственно через API.