Aller au contenu

Exemple d’ingénierie

Un petit processus. Des décisions explicites.

Suivez une demande synthétique de réapprovisionnement, de sa validation au résultat d’une transmission simulée. Exécutez la même implémentation ici ou avec Node.js, puis examinez ses décisions dans le code et les tests.

Exécuter l’exemple

Exemple synthétique · aucune mission client

La validation, l’état en mémoire et la boucle de nouvelle tentative s’exécutent localement. Le système destinataire et ses réponses sont simulés. Cet exemple ne constitue ni une preuve de mission client ni un résultat en production.

Une demande, plusieurs situations d’erreur utiles

Un système opérationnel fictif demande quatre unités de SKU-ALPHA pour le compte SYN-001. L’adaptateur destinataire renvoie une acceptation, une réponse temporaire ou une réponse permanente. Aucune demande ne quitte cette page ou le processus Node.js local.

  1. Valider le contrat

    Vérifier les quatre champs obligatoires et les valeurs autorisées avant de réserver un identifiant ou d’appeler la fonction d’envoi.

  2. Réserver l’identifiant

    Conserver l’empreinte du contenu dans cette instance du processus. Supprimer une répétition identique et refuser un contenu différent sous le même identifiant.

  3. Classifier et arrêter explicitement

    Réessayer uniquement après une réponse classée temporaire. Consigner chaque tentative, attente programmée et résultat final.

Exécuter un scénario synthétique

Chaque exécution démarre avec une mémoire vide. Les scénarios de doublon et de conflit traitent deux enregistrements dans cette exécution. La transmission est simulée ; rien n’est envoyé.

Entrée synthétique

[
  {
    "requestId": "DEMO-1001",
    "account": "SYN-001",
    "item": "SKU-ALPHA",
    "quantity": 4
  }
]

Résultat local observé

Choisissez et exécutez un scénario pour examiner ses événements.

Des décisions à lire et à tester

Le contrat reste limité pour permettre d’inspecter son comportement sans service, identifiants d’accès ou installation de paquet.

Contrat d’entrée

Exactement requestId, account, item et quantity. Les identifiants utilisent les préfixes DEMO- et SYN- ; l’article est SKU-ALPHA ou SKU-BETA. La quantité est un entier de 1 à 100. Les champs supplémentaires et conversions implicites de type sont refusés.

Doublons et conflits

L’identifiant désigne un seul contenu dans une instance du processus. Une demande déjà terminée renvoie son état précédent sans nouvel envoi. Une répétition en cours est supprimée. Un contenu modifié produit un conflit.

Politique de nouvelle tentative

Trois tentatives au maximum. Une réponse temporaire entraîne une attente de 250ms, puis de 500ms. Une réponse permanente arrête immédiatement le processus. Une exception ou une réponse inconnue produit un échec non classifié, sans nouvelle tentative automatique.

Résultats observables

Le résultat contient un état, le nombre de tentatives et des codes d’événement ordonnés. Les demandes refusées, épuisées ou en échec non classifié restent réservées en mémoire ; répéter la demande ne relance pas implicitement sa transmission.

Télécharger. Exécuter. Lire les vérifications.

Utilisez Node.js 22 ou une version ultérieure. Enregistrez les cinq fichiers ci-dessous dans un même dossier en conservant leurs noms. Le README explique la simulation et les commandes. Aucun npm install n’est nécessaire. Le panneau, la CLI et les vérifications importent la même implémentation workflow.mjs.

node workflow-cli.mjs retry
node workflow-cli.mjs all

Exécuter les vérifications

node --test workflow-checks.mjs

Ce qu’un projet réel doit encore définir

  1. L’état n’existe que dans une instance JavaScript du processus. Une remise à zéro, un rechargement ou un nouveau processus le perd. Les instances séparées ne se coordonnent pas. Il n’existe ni stockage durable, ni verrouillage entre processus, ni nettoyage automatique.
  2. La fonction d’envoi renvoie des réponses simulées fixes. Il n’existe ni API externe, ni authentification, ni file persistante, ni accusé de réception réel, ni traitement d’un effet distant incertain. Cet exemple ne garantit pas une transmission exactement une fois.
  3. Une intégration réelle nécessite des responsabilités convenues, une identité durable, des règles de conservation, une gestion de la concurrence, des délais limites, une réconciliation, une supervision et des procédures de reprise. Ces choix dépendent du système destinataire et du périmètre du projet.
  4. Les données sont synthétiques et les contrôles n’acceptent aucune donnée personnelle ou métier. Cet exemple pédagogique ne remplace pas des preuves client autorisées et ne démontre aucun résultat de sécurité, de conformité ou de performance.

De l’exemple au projet

Quel processus demande un contrat plus clair ?

Un échange sur le projet peut commencer par les systèmes concernés, le contrat de demande, les situations d’erreur et les personnes responsables de la reprise.

Discuter d’un projet de développement