Lancer les workers

L’application backend se découpe en 4 processus distincts, chacun avec son propre entrypoint. En production, chaque processus tourne dans son propre conteneur (image Docker multi-stage partagée).

Processus disponibles

Commande	Entrypoint	Rôle
dev	src/main.ts	API HTTP (NestJS + Fastify, port 3000)
relay	src/relay-main.ts	OutboxRelay — dépile la table outbox → NATS JetStream
consumer	src/consumer-main.ts	17 consumers NATS durables (voir ci-dessous)
night-audit	src/night-audit-main.ts	Schedules Temporal par établissement (ensureAllSchedules au boot)
allotment-cutoff	src/allotment-cutoff-main.ts	Worker cutoff des allotments (Temporal)

Il n’existe pas de commande npm nommée pour purge-traveler-main.ts (RGPD art. 17) — ce processus est lancé directement via tsx src/purge-traveler-main.ts ou dans un job CI dédié.

Démarrage complet en local

Ouvrir 4 terminaux (ou utiliser un process manager comme pm2 / overmind) :

# Terminal 1 — API HTTP
pnpm --filter @pms/api run dev

# Terminal 2 — OutboxRelay (publie les events domaine vers NATS)
pnpm --filter @pms/api run relay

# Terminal 3 — Consumers NATS (réagit aux events)
pnpm --filter @pms/api run consumer

# Terminal 4 — Night Audit (schedules Temporal, une instance suffit)
pnpm --filter @pms/api run night-audit

Note

En développement, seuls dev et relay sont strictement nécessaires pour les tests manuels API. Le consumer et le night-audit deviennent indispensables dès qu’on teste les scénarios check-in/check-out (housekeeping réactif), la clôture businessDate ou les notifications.

OutboxRelay

Le relay lit la table pms.outbox (entrypoints persistence) et publie les enveloppes Protobuf signées HMAC vers NATS JetStream. Il garantit at-least-once delivery : chaque event est marqué published_at après ACK NATS. En cas de panne, les events non publiés restent dans la table et sont réémis au redémarrage.

17 Consumers NATS durables

Enregistrés dans composition/consumer-worker.ts :

Consumer	Sujet d’écoute	Action
audit	pms.*.>	Alimente la chaîne d’audit NF203
révocation	identity.session_revoked	Invalide les tokens Redis
payment→folio	payment.captured	Poste le règlement sur le folio
deposit-recognition (ACOMPTE)	deposit.recognized	Comptabilité acompte (CGI 269-2-c)
deposit-recognition (ARRHES)	deposit.recognized	Comptabilité arrhes (art. 1590 Cc)
stay→HK	stay.checked_in	Crée la tâche HK de départ
HK→inventory	housekeeping.task_completed	Libère l’unité OOO
WO→inventory	work_order.closed	Libère l’OOO maintenance
cashless-checkout	stay.checked_out	Solde le wallet cashless
debtor→dunning	accounts_receivable.overdue	Déclenche le workflow Temporal de recouvrement
notification (email)	notification.requested	Envoie via SmtpEmailAdapter
notification (SMS)	notification.sms_requested	Stub V1
distribution	reservation.confirmed	Push ARI vers SiteMinder
pos-bridge folio-closed	folio.closed	Synchronise OsmoVente
owner-revenue folio-closed	folio.closed	Calcule la part propriétaire
reporting (3 consumers)	night_audit.completed	Projette les KPIs dans pms.reporting_*
webhook-dispatcher	webhook.outbound_requested	Dispatche les webhooks signés vers les destinataires
traveler	stay.checked_out	Recale la rétention RGPD au départ réel

Workflows Temporal (6)

Démarrés et schedulés via le worker night-audit :

Workflow	Déclencheur	Description
cancel-reservation	API (manual)	Saga d’annulation (libération stock, arrhes si applicable)
night-audit	Schedule par établissement (3h00 heure locale)	Clôture businessDate
dunning	Consumer debtor→dunning	Relances de recouvrement
allotment-cutoff	Schedule quotidien	Libère les contingents non utilisés à la date de cutoff
purge-traveler	Schedule mensuel	Purge RGPD des fiches voyageurs expirées (art. 17)
tenant-provisioning	API control-plane	Provisioning complet d’un nouveau tenant

Fronts (ports de développement)

App	Port	Commande
apps/mobile-staff	4300	pnpm --filter @pms/mobile-staff run start
apps/admin	4301	pnpm --filter @pms/admin run start
apps/tenant	4302	pnpm --filter @pms/tenant run start
apps/reception	4303	pnpm --filter @pms/reception run start
apps/tenant-mobile	4304	pnpm --filter @pms/tenant-mobile run start

Build de production

# Build image Docker (multi-stage, contient API + tous les workers)
docker build -t logmis-api .

# Ou build pnpm de l'api seule
pnpm --filter @pms/api run build

Le Dockerfile multi-stage produit une image unique pour l’API et tous les workers — l’entrypoint est sélectionné via la variable d’environnement WORKER_ENTRYPOINT ou par override de commande.