À la fin, vous pouvez rédiger le contrat d'intégration
Vous serez en mesure de planifier une intégration qui ne crée pas d'actions en double, d'échecs silencieux ou de dossiers clients impossibles à reconstruire.
Une prompt peut décider de ce qu'il faut recommander, mais les intégrations déplacent des données et des actions réelles.
Une prompt peut décider de ce qu'il faut recommander, mais les intégrations déplacent des données et des actions réelles. Un webhook retardé, une livraison en double, des informations d'identification expirées ou un schéma modifié peut créer un problème client même lorsque le langage de l'agent est parfait.
Valider, agir, enregistrer et récupérer
Termes clés : Webhook, Idempotence, Validation et Dead-letter ou file d'attente d'examen
Comment rédiger le contrat d'intégration
Décrivez le contrat d'événement
Liste de la source, nom de l'événement, identifiant stable, champs obligatoires, authentification et action attendue.
Protéger contre les doublons
Enregistrez l'identifiant de l'événement ou la transition d'état avant d'entreprendre une action en contact avec le client.
Choisissez un échec sûr
Si la validation ou un outil dépendant échoue, conservez le dossier, alertez le responsable et conservez suffisamment de contexte pour réessayer.
Journal du résultat
Capturez quand l'événement est arrivé, ce qui a été validé, quelle action s'est produite et toute erreur ou réessai.
Cas travaillé : connectez les API et les webhooks avec des garde-fous
Une plate-forme de webinaire envoie un événement d'inscription à un espace de travail client. Le flux de travail valide la signature de l'événement, vérifie un identifiant d'enregistrement stable, crée ou met à jour le contact et stocke l'ID d'événement source.
Si l'événement est livré à nouveau, le contact n'est pas inscrit deux fois dans la même séquence. Si l'enregistrement de contact ne peut pas être créé, l'événement entre dans une file d'attente d'examen avec la référence de charge utile d'origine et un responsable nommé.
L'agent peut plus tard utiliser le contexte d'enregistrement vérifié, mais l'intégration elle-même reste déterministe et vérifiable.
Laboratoire appliqué
Briser l'intégration avant qu'un client ne le fasse
Construisez un petit harnais d'échec autour d'une action d'écriture. L'objectif n'est pas une démo réussie. C'est la preuve que les tentatives, les doublons, les mauvaises charges utiles et les événements tardifs ne peuvent pas créer de dommages silencieux.
- Étape 1
Définir le contrat d'événement
Enregistrez l'ID de l'événement, le locataire, l'acteur, la version du schéma, l'horodatage, la destination autorisée et la charge utile minimale. Rejetez les champs inconnus au lieu de les traverser tranquillement.
- Étape 2
Rendre l'écriture idempotente
Stockez une clé d'idempotence avec le résultat. Envoyez le même événement deux fois et prouvez que la deuxième demande renvoie le résultat enregistré sans créer une deuxième réservation, un message ou une mise à jour CRM.
- Étape 3
Forcer quatre modes d'échec
Exécutez un délai d'attente après que le fournisseur ait accepté l'écriture, un événement hors ordre, une information d'identification expirée et une charge utile mal formée. Enregistrez si le système réessaie, met en pause, compense ou envoie le dossier à une personne.
- Étape 4
Se réconcilier à partir des preuves
Comparez l'enregistrement source, l'enregistrement du fournisseur, le journal des événements et l'état visible par le client. Rédigez la requête ou le rapport qu'un opérateur utiliserait pour trouver et réparer le désaccord.
Modèle de travail
event_id: evt_1042
tenant_id: client_acme
actor: agent_followup_v3
schema_version: 2
idempotency_key: client_acme:booking:lead_781:2026-08-13
action: create_booking
expected_result: one booking and one audit record
failure_injected: provider timeout after acceptance
observed_result:
recovery_decision:
evidence_link:Preuve à soumettre
Soumettez le contrat d'événement, quatre enregistrements de test, les journaux résultants et une vue de rapprochement. Une affirmation en prose selon laquelle l'intégration est fiable n'est pas une preuve.
Critères de passage
- Un événement répété ne peut pas répéter l'action commerciale.
- Chaque échec se termine dans un état visible avec un responsable.
- Les journaux identifient l'acteur et le locataire sans révéler de secrets.
Rédiger le contrat d'intégration
Supposons que chaque appel externe puisse échouer deux fois.
Un délai d'attente ne vous indique pas si le système distant n'a rien fait ou a terminé l'action et a perdu la réponse. La conception tente à nouveau de contourner cette ambiguïté. Persister l'état du flux de travail en dehors du modèle et donner à chaque demande conséquente une clé d'idémpotence ou un autre mécanisme de contrôle en double.
- Définir des délais d'attente et des tentatives limitées avec recul.
- Distinguer les réessais sûrs, l'examen manuel, la compensation et l'échec du terminal.
- Testez un plantage après l'action externe, mais avant la confirmation locale.
Sources utilisées pour cette vérification
Avant de passer à autre chose
- Rédigez le contrat pour un événement entrant.
- Simulez la livraison en double et les champs manquants.
- Décidez de ce qu'un humain voit lorsque l'intégration ne peut pas se terminer.
- L'événement a un identifiant stable.
- La validation précède l'action en contact avec le client.
- La livraison en double est sans danger.
- Les échecs restent visibles et détenus.
Progression de la leçon
Vous avez terminé cette leçon ?
Enregistrez votre progression sur cet appareil pour reprendre facilement là où vous vous êtes arrêté.
Cette leçon n'est pas encore marquée comme terminée.