Aller au contenu principal

Process Validation multi-niveaux

Fiche spécifique Client A

Ce workflow n'existe pas dans l'API standard. Il est exposé par la gateway Client A qui orchestre la validation métier avant de redescendre vers les services partagés. En dehors de Client A, aucune de ces mutations n'est disponible.

Cette fiche décrit le process complet de validation hiérarchique à deux niveaux. Typiquement utilisé quand un payload (demande, mouvement de fonds, changement de périmètre...) doit être revu par un manager, puis contre-validé par la direction, avant d'être poussé au pipeline aval.

Cas d'usage guide : une demande de reclassification budgétaire saisie par un chef de projet, relue par son manager (N1), puis contre-signée par le directeur métier (N2) avant que le mouvement ne soit comptabilisé.

Vue d'ensemble​

┌─────────┐  submit  ┌──────────────┐  approveN1  ┌──────────────┐  approveN2  ┌─────────┐
│ auteur  │ ───────▶ │  N1 pending  │ ─────────▶  │  N2 pending  │ ─────────▶  │  DONE   │
└─────────┘          └──────┬───────┘             └──────┬───────┘             └─────────┘
                            │                            │
                            │ reject                     │ reject
                            ▼                            ▼
                         ┌──────────────────────────────────┐
                         │           REJECTED               │
                         └──────────────────────────────────┘

Règles métier à retenir :

  • Un payload submit sans validation N1 au bout de 5 jours remonte une alerte (subscription reviewStateChanged).
  • Un reject à N1 renvoie l'auteur en édition ; à N2, le payload est définitivement clos.
  • Les approbations sont idempotentes : un second appel avec le même reviewId retourne la review dans son état courant sans la muter.

Étape 1 — Soumettre pour revue​

L'auteur finalise son payload côté UI puis déclenche la soumission. L'événement crée une review rattachée au payload et la positionne en PENDING_N1.

▶ EssayersubmitForReviewPOST https://graphqlzero.almansi.me/api
Crée la review et la met en attente de validation niveau 1.
Query
Variables
Réponse
Cliquez sur Exécuter pour lancer la requête.

Champs de la réponse​

  • id : identifiant de la review (distinct du payload). À conserver pour les étapes suivantes.
  • state : PENDING_N1 à ce stade.
  • level : 1 tant que N1 n'a pas statué.
astuce

Côté UI, basculer immédiatement le payload en lecture seule dès que la mutation réussit — toute édition doit repasser par un reject → edit → submit.

Étape 2 — Revue niveau 1 (manager)​

Le manager reçoit une notification (push, mail, ou subscription GraphQL). Il peut approuver ou refuser ; dans les deux cas, un commentaire peut accompagner la décision pour tracer le "pourquoi".

▶ EssayerapproveLevel1POST https://graphqlzero.almansi.me/api
Valide l'étape manager. Le payload passe à PENDING_N2.
Query
Variables
Réponse
Cliquez sur Exécuter pour lancer la requête.

Pièges courants​

  • Appelé par un non-manager → erreur FORBIDDEN. Vérifier la matrice d'habilitations côté front avant d'afficher le bouton Valider.
  • State ≠ PENDING_N1 → erreur INVALID_STATE. Ne jamais parier sur l'état côté UI, toujours le relire depuis la subscription.

Étape 3 — Revue niveau 2 (direction)​

Contre-validation par la direction métier. C'est le point de non-retour : à partir d'ici, le payload sera effectivement appliqué en aval.

▶ EssayerapproveLevel2POST https://graphqlzero.almansi.me/api
Clôture la review. Le payload est envoyé au pipeline aval.
Query
Variables
Réponse
Cliquez sur Exécuter pour lancer la requête.

Étape 4 — Suivi temps réel​

Plutôt que de poller, abonnez l'écran à reviewStateChanged : chaque transition émet un événement pour rafraîchir la liste des reviews en attente.

subscription ReviewFeed($reviewId: ID!) {
  reviewStateChanged(reviewId: $reviewId) {
    id state level by at
  }
}
astuce

Pour un dashboard manager listant toutes les reviews assignées à un user, remplacer $reviewId par un filtre sur $assigneeId si la gateway l'expose.

Scénario complet dans l'IDE​

⚡ IDE intégréReview lifecyclePOST https://graphqlzero.almansi.me/api
4 onglets : submit, approve N1, approve N2, subscribe. Réutilisez l'ID retourné à l'étape 1 dans les suivantes.
Chargement de GraphiQL...

Voir aussi​

  • Hub API — signatures et types dépliés inline pour chaque mutation de ce workflow
  • Process Utilisateurs — matrice d'habilitations Client A consommée par ce process