VESICA
PQSYS_PQ_4Brouillon

SYS_PQ_4 — Procédure de notification Mattermost

Procédure· Direction des Systèmes d'Information (DSI) — Système & Infrastructure IA· émetteur VESICA SYS_PRO_4

SYS_PQ_4 — Procédure de notification Mattermost

Procédure légère. Mécanique détaillée dans les workflows Lot 5 + ADR. [CORPUS]

Objet

Décrire comment un workflow émet une notification homogène vers Mattermost, comment l'event_type est routé, et comment le message est mis en forme (template dédié ou passthrough). [CORPUS]

Domaine d'application

Tous les workflows (SYS + métier). Deux familles : system (erreurs/infra → canaux système permanents) et business (événements de dossier → canal du dossier). [CORPUS]

Références

  • Workflows : 07 §B2.6 (notify_system), §B2.7 (notify_business), §B2.4 (mattermost_post_message), §B2.5 (mattermost_channel_create), §B2.2 (get_routage_notif_config). [CORPUS]
  • ADR-040 — deux modes : template dédié nom_event.md (forme fixe, masquage ligne-à-ligne du vide) ou passthrough default.md ({{payload.corps}}, corps formaté dans le nœud Code émetteur). [CORPUS]
  • ADR-034 — la chaîne de livraison de notif ne porte jamais error_handler (anti-récursion). [CORPUS]
  • ADR-023 — routage externalisé dans routage_notifs.json. [CORPUS]
  • Convention mise en forme riche : _CONFIG/templates_notifs/README.md (filet --- + titre #### + horodatage Paris + liste markdown imbriquée + masquage du vide). [CORPUS]
  • Pas de norme externe applicable. [STANDARD]

Définitions

  • Famille : system (canaux system-*) ou business (canal du dossier). [CORPUS]
  • event_type : identifiant logique de l'événement (ex. workflow_error, dossier_etape, model_expiring). Routé via routage_notifs.json. [CORPUS]
  • RÈGLE D'OR : chaque clé de payload{} ↔ un {{payload.xxx}} du template. Clé manquante = placeholder non substitué silencieusement. [CORPUS]
  • Passthrough (default.md) : template générique qui rend {{payload.corps}} (corps markdown préformaté côté émetteur, pour payloads dynamiques). [CORPUS]

Responsabilités (RACI)

ActivitéWorkflow appelantnotify_system/businessget_routage_notif_configmattermost_post_messageGérant
Fournir event_type + payload alignéRC——C
Router event→canal/severity/templateARR——
Charger + interpoler le template—R———
Poster le messageAA—R—
Maintenir routage + templatesC—C—R/A

Déroulement (qui/quoi/quand/où)

  1. Appelant construit { event_type, payload{} } (aligné au template), appelle notify_system (ou notify_business avec dossier_id+channel_id). [CORPUS]
  2. notify_* résout le routage via get_routage_notif_config (lit .data, ADR-023 amendée). [CORPUS]
  3. notify_* charge le template (.md) selon le mode (dédié ou default.md), interpole les variables. [CORPUS]
  4. notify_* poste via mattermost_post_message (toujours channel_id en expression — bug dropdown natif). [CORPUS]
  5. Retourne { success, channel_id, post_id, error }. [CORPUS]
  6. Création de canal dossier (si besoin) : mattermost_channel_create (Search idempotent → création → ajout membres → message bienvenue avec @username → INSERT canaux_mattermost). ⚠️ le dossier parent doit exister dans registre_dossiers avant (FK). [CORPUS]

Enregistrements associés

  • Table de routage routage_notifs.json (cf. SYS_FQ_4). [CORPUS]
  • dossiers.canaux_mattermost (écrit par mattermost_channel_create). [CORPUS]
  • Messages Mattermost. [CORPUS]

Annexes

  • event_types déclarés : voir SYS_FQ_4. [CORPUS]
  • Anti-récursion (ADR-034) : Coupe 1 (retrait errorWorkflow sur la chaîne de livraison) + Coupe 2 (onError:continueRegularOutput sur le nœud notif d'error_handler). [CORPUS]