Files
MobilityOps/docs/11-n8n-integration.md
T
NuklearRabbitandClaude Sonnet 5 e0c107a94a n8n: store cleaned workflow definitions as repo source of truth
Move the two live-validated workflows into n8n/workflows/ (credential-
based auth referenced by name only, no secret values), add a manifest
covering all 4 canonical workflows and a read-only drift-check script
against n8n's Public API. Retire the pre-integration root-level starter
files that still carried the literal-token pattern, and repoint the
Unraid deploy scripts, Makefile targets and runbook at the new files.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-04 13:34:51 +02:00

70 lines
3.2 KiB
Markdown

# n8n integration
## Role
n8n orchestrates secondary cross-system work after MobilityOps commits canonical state. It is not the domain engine.
## Required live workflow: return processing
Input: `vehicle.returned.v1` webhook event.
Steps:
1. validate event type and schema;
2. derive a follow-up category from the already-calculated state;
3. call the narrow MobilityOps callback endpoint with event ID and follow-up summary;
4. return a stable workflow result;
5. on errors, fail visibly so the outbox dispatcher can retry.
The canonical, live-validated definition is `n8n/workflows/fleet-ops-vehicle-return.json` (see `n8n/workflows/MANIFEST.md`); it authenticates via named Header Auth credentials rather than a literal token, per the live-hardening pass documented in `docs/live-ai-integration/n8n-current-state.md`.
## Second live workflow: scheduled quality scan
RAGcore is not connected in this environment, so the originally sketched "knowledge sync"
workflow below remains deferred (see "Deferred: knowledge sync"). The second implemented
workflow does not depend on RAGcore or MCP Hub, so it is not blocked by them.
Input: hourly schedule trigger, or a manual trigger for on-demand testing.
Steps:
1. call the narrow, service-token-protected `POST
/api/v1/integrations/n8n/scheduled-scan` endpoint;
2. the endpoint runs the same deterministic `run_scan()` domain function the manual
"Run quality scan" UI action uses, and records a `data_quality_scan_run` audit event
with `actor_type=service`;
3. return counts of newly created issues per rule type.
`run_scan()` only ever creates an issue for a condition that does not already have one
open, so a duplicate or overlapping trigger (a manual test run firing close to the
scheduled one, or a retried HTTP call) does no duplicate domain work.
The canonical, live-validated definition is `n8n/workflows/fleet-ops-data-quality-scan.json`
(see `n8n/workflows/MANIFEST.md`), imported and published the same way as the return
workflow (see `deploy/unraid/setup-scheduled-scan.sh` and `docs/17-runbook.md`). It is
active on the live instance; a fresh import ships inactive until credentials are wired up
and it is deliberately published.
## RAGcore procedure sync (in progress)
RAGcore is now reachable in this environment; a live inspection of its real contract is
recorded in `docs/live-ai-integration/n8n-current-state.md`. Workflow 3, "Fleet Ops —
RAGcore Procedure Sync", is being built against that real contract (not the sketch
originally in this section) — see `n8n/workflows/MANIFEST.md` for current status.
## Workflow error handler (in progress)
Workflow 4, "Fleet Ops — Workflow Error Handler", is a central technical workflow attached
to workflows 1-3 via n8n's per-workflow "Error Workflow" setting, reporting bounded,
secret-free failure details to Fleet Ops. See `n8n/workflows/MANIFEST.md` for status.
## Outbox dispatcher
- polls pending records;
- claims with `FOR UPDATE SKIP LOCKED` or equivalent;
- sends event with timeout;
- exponential backoff with a small maximum attempt count;
- supports explicit manual retry;
- preserves last error and response metadata;
- does not hold a database transaction open during network I/O.