Clarifier la tâche et la décision
Ce guide transforme les webhooks et le traitement par lots en un flux de travail opérationnel révisable. Il relie les décisions de domaine, la propriété, les preuves et l'acceptation afin que le résultat continue de fonctionner en production.
Sélectionnez la livraison synchrone, webhook ou par lots en fonction du volume, de la latence, des nouvelles tentatives et de la propriété opérationnelle.
Méthode pratique
- 1
Types de sources d'inventaire, identifiants, champs, paramètres régionaux, propriétaires et états de publication.
- 2
Choisissez le modèle de livraison parmi le volume, la latence, le contrôle éditorial et la tolérance aux pannes.
- 3
Mappez l’enregistrement source à un enregistrement de version linguistique distincte avec un lien durable.
- 4
Ajoutez l'authentification, l'idempotence, les nouvelles tentatives, l'invalidation du cache, la journalisation et les contrôles d'accès.
- 5
Testez la publication, les modifications de source, les résultats indisponibles, la restauration, le fonctionnement du clavier et la surveillance avant la publication.
Exemple ou outil
Un diagramme de cycle de vie devient un contrat de mise en œuvre pour les tentatives, l'idempotence, la surveillance et la relecture. Dans l'outil, enregistrez également la référence, le propriétaire, la décision, les preuves, le problème en suspens et la date d'approbation. Utilisez une page ou une transaction réelle pour que l'équipe voie les dépendances, les exceptions et le travail de maintenance qui suit la publication.
| Point de décision | Enregistrer | Critère d'acceptation |
|---|---|---|
| Référence | État actuel observé | Source et date d'enregistrement |
| Décision | Option sélectionnée et justification | Risque et public pris en compte |
| Preuve | Tester, documenter ou mesurer | Révisable et spécifique à la version |
| Approbation | Nom, rôle et date | Tous les critères obligatoires sont remplis |
Choisissez la livraison en fonction de la latence, du volume et de la propriété
Utilisez la livraison synchrone pour les petites requêtes interactives qui se terminent normalement dans le délai d'expiration de l'interface et peuvent signaler un résultat immédiatement. Utilisez des webhooks lorsque le travail est asynchrone, mais chaque résultat doit entrer dans le CMS dès qu'il est prêt. Utilisez le traitement par lots pour les grandes collectes planifiées, les importations contrôlées ou les migrations où le débit et la reproductibilité comptent plus que la livraison immédiate. Les modèles peuvent coexister, mais chaque classe de contenu doit avoir une valeur par défaut documentée.
Estimez le volume quotidien et maximal, la taille de l'article, le délai d'exécution acceptable, la fenêtre de nouvelle tentative, les exigences de commande, la capacité des réviseurs et le propriétaire opérationnel. Un résultat rapide n'a aucune valeur si la file d'attente éditoriale ne peut pas le traiter. Incluez les limites en amont et en aval : exportation CMS, taux API, agents de file d'attente, point de terminaison de rappel, écritures de base de données, invalidation du cache et révision de la charge de travail. Sélectionnez le modèle le plus simple qui répond à l’objectif de service complet.
| Modèle | Utiliser quand | Contrôle essentiel |
|---|---|---|
| Synchrone | Petite requête et latence limitée courte | Délai d'expiration avec nouvelle tentative client sécurisée |
| Webhook | Les emplois indépendants devraient arriver rapidement | Vérification de signature et gestion des événements idempotents |
| Lot | Grand ensemble contrôlé et achèvement programmé | Manifeste, point de contrôle, réconciliation et relecture |
Implémenter un cycle de vie de webhook vérifiable
Acceptez uniquement HTTPS POST, vérifiez la signature par rapport au corps brut, vérifiez la tolérance d'horodatage et rejetez les versions d'événements non prises en charge. Stockez l'ID d'événement sous une contrainte unique avant d'appliquer les modifications métier. Renvoie le succès après une réception durable, puis traite de manière asynchrone. Un événement répété renvoie le succès sans répéter l’effet secondaire. Faites pivoter les secrets de signature avec une période de chevauchement et limitez la sortie de diagnostic afin qu'elle ne révèle pas de signatures ou de contenu.
États du modèle tels que reçu, validé, mis en correspondance, appliqué, ignoré, nouvelle tentative et échec. Faites correspondre le résultat à l'ID de travail, à l'ID source, à la révision source, aux paramètres régionaux et au mode. Si la source actuelle est plus récente, stockez le résultat pour audit, mais n'ouvrez pas et ne remplacez pas le brouillon actuel. Gérez les événements dans le désordre selon les règles de transition d'état plutôt que selon l'ordre d'arrivée. Conservez un outil de relecture qui nécessite une raison, l’identité de l’opérateur et une portée.
- 1
Vérifiez le transport, la signature du corps brut, l'horodatage, le type d'événement et la version du contrat.
- 2
Conserver l’événement unique et accuser réception durable.
- 3
Résolvez le travail et la révision exacte de la source avant de modifier le CMS.
- 4
Appliquez une transition d’état idempotent et créez le brouillon révisable.
- 5
Enregistrez la fin ou acheminez l’événement vers une nouvelle tentative et une relecture contrôlées.
Rendre les lots reproductibles et conciliables
Créez un manifeste immuable avec l'ID de lot, l'heure de création, la règle de requête ou de sélection, l'ID d'élément individuel, la révision source, les paramètres régionaux, le mode, la priorité et la somme de contrôle. Gelez le manifeste avant de le soumettre afin qu'une requête CMS ultérieure ne puisse pas modifier la signification du lot. Divisez-le en morceaux délimités et utilisez des clés d'idempotence stables pour chaque élément. Achèvement du point de contrôle après des écritures durables afin que les travailleurs puissent reprendre sans recommencer.
À la fin, rapprochez les éléments soumis, acceptés, terminés, rejetés, périmés, échoués et intentionnellement ignorés. Les décomptes doivent correspondre au manifeste d'origine, et chaque élément non terminé nécessite une raison et une action suivante. La relecture d'un sous-ensemble crée un nouveau manifeste de relecture lié à l'original. Ne modifiez pas les chefs d’accusation originaux et n’effacez pas les preuves échouées. Publiez les résultats des lots uniquement dans les états de révision, avec des limites de charge de travail qui protègent l'équipe éditoriale.
Le manifeste corrige l’identité de l’élément, la révision source, les paramètres et la somme de contrôle.
Chaque opération sur un élément est idempotente et peut être réessayée indépendamment.
Les points de contrôle reprennent après une interruption sans dupliquer les brouillons.
Les décomptes du statut final correspondent exactement au manifeste.
La relecture est limitée, autorisée, liée et vérifiable.
Surveiller les files d'attente et répéter la récupération
Surveillez le taux d'acceptation, le taux d'achèvement, le taux d'erreur par catégorie, la profondeur de la file d'attente, l'âge des éléments les plus anciens, les centiles de durée de traitement, les échecs de vérification des webhooks, le nombre de nouvelles tentatives, le volume de lettres mortes, le taux de résultats périmés et le temps écoulé entre le résultat et l'approbation éditoriale. Alerte sur l’impact des utilisateurs et le retard croissant plutôt que sur les pannes transitoires isolées. Les tableaux de bord séparent le traitement des fournisseurs, la livraison des rappels, l'application CMS et le temps d'attente éditorial.
Le runbook identifie les propriétaires, la pause sécurisée, les limites de mise à l'échelle, la rotation des informations d'identification, l'approbation de la relecture, la gestion des lettres mortes, la communication avec le fournisseur et la vérification de la récupération. Exercice de rappel perdu, événement répété, événement dans le désordre, panne de fournisseur, panne de CMS, incompatibilité de schéma, secret expiré et achèvement partiel d'un lot. L'acceptation nécessite une récupération sans publication en double, perte silencieuse, modification manuelle de la base de données ou suppression du dernier contenu approuvé.
Rôles, preuves et approbation
Séparez la génération de la publication. Une réponse réussie est un brouillon et non une approbation. Stockez l'identifiant et la version de la source, les paramètres de transformation, l'identifiant du résultat, l'état de révision, l'approbateur et l'heure de publication. Lorsque la source change, marquez la version linguistique pour révision au lieu de remplacer silencieusement le contenu approuvé. Cela rend la restauration et l’audit possibles sur toutes les plateformes.
Opérations et entretien
Le travail ne s'arrête pas à la publication. Liez la version linguistique ou la configuration à sa source, surveillez les mesures de qualité et de service et définissez des déclencheurs de révision concrets. Les déclencheurs incluent les changements de source, les changements juridiques, les nouveaux besoins du public, les questions d'assistance récurrentes, les changements techniques et les incidents. Un propriétaire nommé évalue le déclencheur, ouvre une nouvelle révision si nécessaire et enregistre une nouvelle approbation.
Liste de contrôle avant publication
L'intégration utilise des identifiants de source durables.
Les informations d'identification sont stockées côté serveur et alternées.
Le comportement en matière de délai d'attente, de nouvelle tentative et de limite de débit est défini.
Les demandes répétées sont idempotentes.
Le contenu généré entre dans un état de révision.
Les modifications de source invalident ou rouvrent la version.
La navigation linguistique fonctionne par clavier et technologie d'assistance.
La surveillance couvre les échecs, les files d'attente, la latence et le contenu obsolète.