workflow-orchestrator

workflow-orchestrator — главный вход для задач AEM Workflow в AEM 6.5 LTS. Он охватывает две разные зоны: разработку workflow-моделей и production support, где нужно разбирать зависшие, ошибочные или не продвигающиеся экземпляры. Навык сначала классифицирует запрос, а затем направляет к специализированной процедуре: workflow-model-design для структуры модели, workflow-development для собственного WorkflowProcess или ParticipantStepChooser, workflow-triggering для запуска из кода, workflow-launchers для cq:WorkflowLauncher, workflow-debugging для глубокого расследования и workflow-triaging для первичной классификации инцидента. Если одновременно нужны triage и debugging, сначала собираются симптомы и контекст через triaging, затем применяется runbook debugging. Для любого AEM Workflow task сначала загружаются foundation references: обзор архитектуры, справочник API, JCR paths, правила 6.5 LTS и quick-start guide. После этого читается SKILL.md выбранного поднавыка и его тематические references; для разработки workflow-model-design и workflow-development используются вместе с foundation-материалами. Сценарии разработки включают новую approval-модель START → PARTICIPANT → PROCESS → END, кастомный process step, программный запуск через WorkflowSession.startWorkflow(), динамического участника и настройку launcher на добавление узла. Сценарии поддержки включают workflow, который застрял, отсутствие work item в Inbox, ошибки прав, исчерпанный thread pool, очередь Sling Jobs, избыток экземпляров и неработающий purge. В архитектурной схеме автор может запустить workflow через Timeline UI или Manage Publication; код — через OSGi service, event handler или scheduler; launcher реагирует на JCR observation events; replication agent относится к 6.5 LTS. Дальше Granite Workflow Engine ведёт instance в /var/workflow/instances/, а шаги выполняются как Sling Jobs. PROCESS вызывает WorkflowProcess.execute(), PARTICIPANT создаёт задачу для пользователя или группы, DYNAMIC_PARTICIPANT выбирает участника через ParticipantStepChooser, OR_SPLIT выбирает ветку по выражению, а AND_SPLIT запускает параллельные ветки и ждёт их через AND_JOIN. Для production-support навык предлагает проверяемые опорные точки: Felix Console или JMX, countStaleWorkflows для поиска устаревших процессов, restartStaleWorkflows сначала с dryRun=true, retryFailedWorkItems, returnSystemJobInfo и returnWorkflowQueueInfo для очередей, а также error.log, журналы crx-quickstart и config status ZIP при подозрении на thread pool или scheduler. Для инцидента «workflow не двигается» сначала проверяется наличие work item и тип шага, затем рассматриваются очередь, конкретный process step и конфигурация. Для вопроса о сбоях на хосте фиксируются host, временной диапазон, model и instance ID, после чего формируются паттерны поиска для Splunk и JMX. Важный предел — навык адресован AEM 6.5 LTS и не превращает диагностику в безусловное изменение production: опасные действия требуют сначала dry run и подтверждённого контекста. Guardrails запрещают редактировать /libs; оверлеи следует размещать под /apps, а модели — предпочтительно в /conf/global/settings/workflow/models/ с legacy-путём /etc/workflow/models/ только при необходимости. Runtime API использует /var/workflow/models/, launcher-конфигурации — /conf/global/settings/workflow/launcher/config/ или допустимый overlay. Сервисный доступ строится через ResourceResolverFactory.getServiceResourceResolver() и sub-service; deprecated loginAdministrative применять нельзя. Для развёртывания указаны Package Manager, Maven Content Package Plugin или ACS AEM Commons JCR, поэтому конкретный способ зависит от контекста проекта. Этот навык полезен как маршрутизатор: он не подменяет чтение выбранного поднавыка и references, не обещает одну универсальную причину сбоя и не рекомендует менять JCR или OSGi-конфигурацию без подтверждения симптомов, среды и обратимого плана.