Automatisation et intégrations
Traitez les webhooks durablement, accusez-en réception rapidement, dédupliquez les livraisons, reprenez le travail en sécurité et interrogez périodiquement la source pour récupérer les événements manqués.
Comment le flux de travail s’articule
Un point de terminaison webhook ne devrait pas tenter l'ensemble du flux de travail d'affaires avant de répondre. Les fournisseurs réessaient, les événements arrivent dans le désordre et les systèmes en aval deviennent indisponibles. Une boîte de réception de l'événement sépare la réception du traitement et permet à un processus d’interrogation ou de rapprochement de récupérer ce que la livraison ne peut à elle seule garantir.
Vérifier la signature par rapport à la demande brute, saisir l'identificateur du fournisseur et de l'événement, stocker la charge utile ou le sous-ensemble autorisé, et retourner dans la fenêtre prévue du fournisseur. Utilisez une contrainte unique sur le fournisseur, la connexion et l'identifiant d'événement pour rendre la livraison répétée inoffensive.
Les charges utiles sensibles nécessitent des règles de conservation et d'accès. Entreposez seulement ce que les exigences de traitement et de vérification justifient.
Les travailleurs peuvent revendiquer des événements en cours avec une tentative de comptage et de location, puis les marquer traitées, réessayer, ou examen des besoins. Conservez le dossier d'entreprise ou l'identificateur d'action à côté de l'événement. Un travailleur défaillant peut libérer le bail sans perdre la livraison originale.
Un événement mis à jour par le client peut arriver avant la création du client, ou un événement financé par paiement peut se répéter après l'achèvement. Chargez l'état actuel faisant autorité et appliquez les transitions de façon idempotente. Lorsque la séquence est importante, comparez les versions du fournisseur ou récupérez la dernière ressource au lieu de faire confiance à l'ordre d'arrivée.
Exécutez une requête programmée pour les enregistrements modifiés depuis un point de contrôle sûr, avec une fenêtre de chevauchement. Comparez-les avec les versions traitées localement et demandez le travail manquant à travers le même gestionnaire. Signalez aussi les événements qui restent en attente au-delà de la fenêtre de traitement normale.
Un fournisseur de paiement envoie un événement indiquant qu'une facture a été payée. Le paramètre vérifie la signature de la requête en utilisant le corps brut, écrit l'événement dans une boîte de réception sous l'identifiant de l'événement fournisseur, et répond. Un travailleur demande par la suite l'événement, récupère le paiement actuel au besoin, vérifie si la facture est déjà payée et applique la transition une fois.
Si le système de comptabilité n'est pas disponible, l'événement reste réutilisable sans demander au fournisseur de le renouveler. Si le même webhook arrive à nouveau, la règle d'unicité indique l'enregistrement de la boîte de réception existante. Si un événement de remboursement est arrivé en premier, la validation de l'état actuel et la recherche d'un fournisseur empêchent l'événement de paiement ultérieur de rouvrir la facture.
Repère visuel
Le critère public ne fait que le travail nécessaire pour faire confiance à l'événement et le conserver; le traitement des affaires se fait derrière une frontière durable.
Vérifier
Vérifiez la signature, la source, l'horodatage et la taille autorisée de la charge utile.
A conserver
Persistez l'événement brut ou le sous-ensemble approuvé sous un ID unique.
Remerciements
Retournez rapidement après réception durable plutôt qu'après chaque action en aval.
Processus
Réclamation, validation de l'état actuel et application de la transition d'affaires de façon idempotente.
Récupérer
Réessayez les échecs temporaires et interrogez la source pour retrouver les changements manquants.
La vérification de la signature n'est qu'un contrôle. Limiter la taille de la demande, accepter les types de contenu attendus, rejeter les types d'événements non pris en charge, protéger les secrets et éviter l'enregistrement des charges utiles sensibles par défaut. Si les événements contiennent des informations personnelles ou liées au paiement, définir qui peut les voir et quand les corps bruts sont expurgés ou supprimés.
Les rapports opérationnels devraient faire la distinction entre les livraisons non valides, les événements acceptés, les échecs de traitement, les reprises, les événements en file d’échec et les découvertes de rapprochement. Alerte sur un arriéré ou un événement qui dépasse sa cible de traitement; n’alertez pas une personne à chaque nouvelle tentative. Un écran d'examen devrait fournir l'événement, le dossier d'affaires lié, la dernière erreur, l'historique des tentatives et les prochaines actions sécuritaires.
Questions pratiques
Retourner le succès lorsque la vérification et la réception durable réussissent. Retourner une erreur appropriée lorsque la demande ne peut pas être fiable ou stockée afin que le fournisseur puisse suivre sa politique de ré-essai documentée.
La conservation dépend du débogage, de la vérification, de la confidentialité et des conditions du fournisseur. Définir une période et supprimer ou effacer des données sensibles qui ne sont plus nécessaires.
Poursuivre l’exploration
Collaborer avec Sun Cluster
Sun Cluster construit des intégrations API et webhook avec un traitement durable, des récupérations sûres, une observabilité et des chemins de récupération.
