iac/apps/processing/workflows-frontend.ENDPOINTS.md

Эндпоинты, с которыми взаимодействует workflows-frontend

Микрофронтенд workflows-frontend обращается к внешним HTTP-сервисам через тонкий слой API, построенный поверх SDK @sarex-team/sdk-js. В отличие от transmittal-frontend, здесь нет реестра-объекта endpoints с полями service/method/path/body/cache. Вместо этого каждый вызов оформлен отдельной функцией-обёрткой (fetch*), которая напрямую вызывает httpService.getRequest / httpService.postRequest с указанием сервиса, URL и параметров. Все явные запросы фронтенда идут в один сервис — workflows. Хосты sarex и zitadel объявлены в конфигурации, но используются самим SDK (аутентификация через AuthProvider), а не прикладным кодом модуля.

Как устроено взаимодействие

• Слой API-функций — module/shared/api/fetch/workflows.api.ts. Здесь объявлены все обёртки над HTTP-запросами. Каждая функция принимает типизированные аргументы (id, taskId, taskRunId, workflowId, ids, пагинация, фильтры) и возвращает промис от httpService. Ключевые поля запроса:
  • service — логическое имя сервиса (везде "workflows"), по которому SDK выбирает базовый хост;
  • url — путь эндпоинта, собирается через шаблонные строки с подстановкой параметров;
  • data — тело POST-запроса (например, updates при рестарте задачи);
  • axiosConfig.params — query-параметры (limit, offset, company_ids).
• Единая точка запроса — httpService, создаётся в module/shared/api/http-service.ts через createHttpService({ axiosConfig, config, buildEnv, hosts }) из @sarex-team/sdk-js. Методы getRequest/postRequest этого сервиса — единственный способ выполнить внешний вызов. Под капотом SDK использует axios.
• Выбор окружения и хоста — окружение берётся из глобальной константы сборки __BUILD_ENV__ (const endpoint = (__BUILD_ENV__ as TypeEnvironment) || "prod"). Для local дополнительно включается режим setTypeOfHttpService("original"). SDK по имени service и текущему buildEnv находит базовый хост в объекте hosts (module/shared/api/hosts.ts) и подставляет его перед url.
• Реэкспорт — module/shared/api/index.ts реэкспортирует весь набор функций как workflowsApi и сам httpService.
• Использование — вызовы происходят из MobX-стора (module/workflows/store/*.ts: workflows.ts, workflow.ts, task.ts, taskRun.ts, watchList.ts).
• Обработка ошибок — отдельного файла errors.ts в проекте нет; маппинг и перехват ошибок HTTP выполняется внутри SDK @sarex-team/sdk-js и обрабатывается в сторах через try/catch с отображением состояний ошибки (module/components/States/ErrorState.tsx). Аутентификация и редиректы на страницу логина реализованы в module/Auth/AuthProvider.tsx через компонент AuthProvider из SDK.

Базовые хосты по сервисам и окружениям

Источник: module/shared/api/hosts.ts. В коде определены окружения local, stage, prod, preprod и cps (закрытый контур Газпрома). Прикладной код обращается только к сервису workflows; хосты sarex и zitadel используются SDK для основного бэкенда и системы аутентификации (Zitadel).

Сервис (service)	Назначение	local	stage	prod	preprod	cps (контур Газпром)
workflows	API оркестрации воркфлоу и задач	/sarex-workflows	https://stage-api.sarex.io/workflows	https://api.sarex.io/workflows	https://api.preprod.sarex.io/workflows	https://api.aeromonitoring.codm.gazprom.loc/workflows/
sarex	Основной бэкенд Sarex (через SDK)	/sarex-backend	/	/	/	https://aeromonitoring.codm.gazprom.loc/
zitadel	Сервис аутентификации Zitadel (через SDK)	/zitadel	https://idp.dev.stage.sarex.io	https://login.sarex.io	https://login.preprod.sarex.io	— (не задан)

Примечание: в окружении local пути относительные (проксируются через dev-сервер), в stage/prod/preprod — абсолютные URL. Для контура cps сервис zitadel не объявлен.

Эндпоинты по сервисам

workflows — оркестрация воркфлоу и задач

Все функции определены в module/shared/api/fetch/workflows.api.ts, service: "workflows".

Ключ	Метод	Путь	Назначение
fetchGetWorkflows	GET	/api/v1/workflows?limit={limit}&offset={offset}&company_ids={companyIds}	Список воркфлоу с пагинацией и фильтром по компаниям (company_ids — id через запятую)
fetchGetWorkflowById	GET	/api/v1/workflows/{id}	Получить один воркфлоу по идентификатору
fetchGetWorkflowsStates	GET	/api/v1/workflows/{ids}/state	Получить состояния набора воркфлоу (ids — идентификаторы через запятую), используется для отслеживаемого списка
fetchGetWorkflowPosition	GET	/api/v1/workflows/{workflowId}/position	Позиция воркфлоу в очереди обработки
fetchPrioritizeWorkflow	POST	/api/v1/workflows/{workflowId}/prioritize	Повысить приоритет воркфлоу
fetchGetLogs	GET	/api/v1/tasks-runs/{taskRunId}/logs	Получить логи конкретного запуска задачи
fetchCancelTaskRun	POST	/api/v1/tasks-runs/{taskRunId}/cancel	Отменить запуск задачи
fetchRestartTask	POST	/api/v1/tasks/{taskId}/restart	Перезапустить задачу; тело запроса — объект updates (изменённые параметры/объекты/сервис-реквесты)
fetchMoveTaskToSuperHighResources	POST	/api/v1/tasks/{taskId}/move_to_super_high_resources	Перевести задачу на пул сверхвысоких ресурсов

Примечание: фронтенд вызывает GET /api/v1/tasks-runs/{taskRunId}/logs (fetchGetLogs), однако в текущем коде workflows-api соответствующий обработчик отсутствует (см. workflows-api.openapi.yaml, раздел «Замечания»). Это расхождение стоит проверить: либо эндпоинт реализуется другим сервисом/ingress, либо один из репозиториев устарел.