Руководство пользователя Менеджера Сценариев

5.Эксплуатация.

5.1.Работа с расписаниями.

5.1.9.Работа с подзаданиями в системе запуска расписаний.

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

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

Основные характеристики подзаданий.

• автоматическое создание: система сама создает подзадания, пользователь не может создать подзадание вручную — это делает интеграционный сценарий;
• иерархическая структура: каждое подзадание имеет parentId — ID непосредственного родительского задания и rootId — ID корневого (основного) задания;
• параллельное и последовательное выполнение: в рамках одного сценария подзадания выполняются последовательно от источника к приёмнику, но подзадания источников, если их несколько, выполняются параллельно. Аналогично и для приёмников: их подзадания выполняются параллельно. Такой подход обеспечивает оптимальный баланс между упорядоченностью процесса и производительностью: этапы выполняются строго последовательно (источник - приёмник), но обработка данных внутри этапа — максимально параллельно.
• архитектура системы поддерживает и более глубокое распараллеливание, например, за счёт использования нескольких потребителей (consumers) из одного топика Kafka, что позволяет обрабатывать данные в реальном времени с высокой пропускной способностью;
• независимое выполнение: подзадания выполняются изолированно друг от друга;
• специализация: каждое подзадание обрабатывает одну систему-источник или систему-приёмник;
• автономный жизненный цикл: подзадание имеет собственные статусы, параметры и время выполнения.

Важное! Пользователь не может создавать подзадания вручную: их создание инициируется интеграционным сценарием (ESB) в процессе выполнения основного задания. Если ESB-сценарий запрограммирован на создание подзаданий, он сделает это при любом способе запуска (ручном, по расписанию, активатором БД и так далее).

Пользователь может просматривать подзадания, мониторить и при необходимости вмешиваться в их выполнение.

Типы подзаданий.

Система различает два типа подзаданий по логике выполнения:

1. Подзадания источника создаются при выполнении основного задания. Они предназначены для первичной обработки входных данных: чтение, фильтрация, трансформация и тому подобных.

   Выполняют операции извлечения данных из внешних систем. В интерфейсе отображаются в группе «Подзадания источника».

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

   Подзадание-приёмник создаётся асинхронно в момент, когда сообщение, отправленное подзаданием-источником в топик Kafka, прочитывается конкретным потребителем, отвечающим за данный приёмник.

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

   В интерфейсе они отображаются в группе «Подзадания приёмника».

Где найти подзадания в пользовательском интерфейсе.

В разделе «Очередь заданий» (рисунок 29) необходимо осуществить выборку по фильтру для поля «Тип запуска (кем запущено)» и выбрать тип запуска «Подзадания» — в таблице отобразятся все подзадания системы.

Кликнуть по ID задания — система осуществит переход на конкретное задание:

• основное задание отображается с иконкой «+» в колонке «ID задания»;
• кликните на «+» чтобы раскрыть список подзаданий.

{
  "textContent": "получены данные из системы `registry`
                  для обработки в системе `esbdb`"
}

Полный алгоритм работы подзаданий.

Шаг 1: создание и запуск основного задания.

Основное задание может быть создано пользователем вручную, по расписанию, активатором или событием. При создании заданию присваивается уникальный идентификатор и начальный статус «Новое». После создания система автоматически переводит задание в статус «Исполняется» и начинает выполнение бизнес-логики.

Шаг 2: вызов интеграционного сценария (ESB).

Основное задание делегирует обработку данных внешнему интеграционному сервису через REST API. Выполняется вызов заранее настроенного сценария в Enterprise Service Bus, который будет управлять дальнейшей обработкой данных и созданием подзаданий.

Шаг 3: создание подзаданий источника.

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

Шаг 4: выполнение подзаданий источника.

Подзадания источника выполняются независимо от основного задания и друг от друга. В ходе выполнения происходит следующее:

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

Определение итогового статуса происходит следующим образом:

• подзадание источника получает статус «Выполнено» только после того, как все связанные с ним подзадания-приёмники достигнут финальных статусов («Выполнено», «Ошибка», «Пропущено» и так далее).
• если хотя бы одно подзадание-приёмник завершится со статусом «Ошибка», то подзадание источника (а также основное задание) переводится в статус «Ошибка», даже если ранее уже имело статус «Выполнено».

При этом возможна ситуация, когда:

• все подзадания-приёмники изначально завершились успешно, и основное задание получило статус «Выполнено»;
• позже, например, при повторной обработке (из-за задержек или ретраев), один из приёмников повторно обрабатывает то же сообщение и завершается с ошибкой;
• в этом случае система корректирует статус: подзадание источника и основное задание автоматически переводятся в статус «Ошибка».

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

Шаг 5: автоматическое создание подзаданий приёмника.

Подзадания приёмника создаются независимо и асинхронно:

• подзадание-источник завершает свою работу и отправляет сообщение с данными в топик Kafka;
• для каждого приёмника, настроенного в сервисе, существует отдельный потребитель (consumer), который постоянно опрашивает этот топик;
• как только конкретный consumer для приёмника получает сообщение, он немедленно создаёт одно новое подзадание-приёмник и запускает его на выполнение. Это означает, что подзадания для разных приёмников могут создаваться и выполняться в разное время, полностью независимо друг от друга. Задержка между созданием составляет обычно около 1 секунды (время опроса топика) плюс время обработки предыдущего задания этим же потребителем.

Важно: Основное задание и подзадания-источники не ждут завершения подзаданий-приёмников. Вся координация происходит реактивно, через события об изменении статусов.

Шаг 6: получение ответа и завершение.

Подзадания приёмника выполняют свои операции и возвращают результаты в систему. Каждое подзадание может сохранять внешние данные и метаинформацию о выполнении операции. Система фиксирует успешное завершение операций и подготавливает данные для финальной агрегации статусов. Если какое-либо подзадание «зависло» в статусе «Исполняется»:

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

Шаг 7: финальная обработка и агрегация статуса.

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

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

• пропуск — это ожидаемое поведение (фильтрация по условиям);
• ошибка — это непредвиденная ситуация, требующая внимания;
• прервано — это преднамеренная остановка процесса.

Для отслеживания прогресса выполнения группы подзаданий:

• используйте массовый выбор и фильтрацию по полю «Тип запуска (кем запущено)»;
• отфильтруйте подзадания по ID основного задания;
• отслеживайте колонку «Статус» для понимания общего прогресса выполнения;
• используйте колонку «Длительность» для выявления «зависших» подзаданий.
• всегда проверяйте «Данные запроса» для понимания контекста выполнения.

Управление подзаданиями.

1. Просмотр и диагностика.
   • Данные запроса — кликните по иконке для просмотра JSON-данных подзадания.
   • Логи выполнения — используйте три типа логов для полной диагностики:
     • «Лог задания» — технический лог системы;
     • «Мониторинг исполнения» — графики и метрики выполнения;
     • «Лог исполнения» — бизнес-операции подзадания.
2. Операции управления.
   • Изменение статуса: кликните на текущий статус — выберите новый:
     • «Повтор» — возобновить выполнение;
     • «Прервано» — остановить выполнение.
   • Изменение приоритета: кликните на цифру приоритета — выберите значение от 0 (низкий) до 9 (высокий).
3. Массовые операции.
   • Отметьте чекбоксы у нужных подзаданий.
   • Используйте кнопки:
     • «Удалить» — удаление выбранных подзаданий;
     • «Сменить статус» — массовое изменение статуса группы заданий/подзаданий.

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

Без подзаданий пришлось бы строить монолитные последовательные процессы, которые были бы более медленными, менее надежными и сложными в управлении.