Intégration des processus / 11
Recevoir les webhooks. Exécuter les opérations métier de manière fiable.
Un événement arrive et doit déclencher une action dans le système suivant. Livraisons multiples, retards ou panne de l’API cible en font un processus d’exploitation. Nous le développons avec des événements explicites et des effets vérifiables.
La situation initiale
HTTP 200 ne prouve pas, à lui seul, l’exécution d’un processus métier.
Une boutique envoie un événement de commande. L’ERP est temporairement indisponible. Si tout le traitement est effectué pendant la requête webhook, un timeout peut provoquer de nouvelles livraisons ; si la réception est confirmée immédiatement, la commande risque d’être perdue.
Nous séparons la réception vérifiée du traitement ultérieur. L’émetteur définit le format de signature et les règles de livraison. L’intégration définit la déduplication, la rétention et la signification d’une confirmation réussie.
Ce que DataSource prend en charge
Séparer réception, persistance et action cible.
Sécuriser l’entrée
Vérifier la signature sur les octets originaux de la requête conformément à la documentation de l’émetteur. Limiter la taille, le Content-Type et les types d’événements pris en charge.
Recevoir durablement
Enregistrer l’événement dans un stockage protégé convenu ou une queue. Renvoyer le code HTTP de succès approprié uniquement après une réception réussie.
Traiter
Utiliser des identifiants uniques, rendre les effets idempotents et vérifier les réponses cibles. Traiter séparément les erreurs permanentes et permettre un replay contrôlé.
Scénario technique / Exemple illustratif
Confirmer la réception, suivre le traitement séparément.
Payload illustratif. eventId et orderId désignent des identités différentes. Une livraison répétée ne doit pas créer une nouvelle commande ; le succès du traitement constitue un état distinct.
Données d’exemple et règles proposées. Les interfaces et règles métier concrètes seront examinées pour votre projet.
{
"eventId": "evt-1042",
"type": "order.approved",
"orderId": "ORD-8421",
"version": 3
}
verified → persisted → accepted
worker → effect checked → processedGestion des erreurs, sécurité et exploitation
Livraisons en double et erreurs partielles.
Doublons et interruption
Un identifiant d’événement ne suffit pas si le worker s’interrompt entre l’action cible et sa confirmation. L’effet métier nécessite également une protection contre les répétitions ou un rapprochement avec la cible.
Ordre
Tous les émetteurs ne garantissent pas l’ordre. Des versions ou l’état cible actuel empêchent un événement tardif de remplacer un état plus récent.
Replay
Assurer la traçabilité de l’erreur, de sa correction et de la nouvelle exécution. Les payloads peuvent contenir des données personnelles ; leur stockage et leur accès sont délibérément limités.
Questions métier
Les détails qui comptent avant la mise en œuvre.
Webhooks · HMAC · Queue · Déduplication · Replay · État d’exploitation
Le traitement exactly-once est-il garanti ?
Ce n’est pas une garantie générale entre plusieurs systèmes. Nous prévoyons les livraisons répétées et un traitement dont l’effet métier peut être rapproché de manière fiable.
Faut-il toujours enregistrer l’ensemble des données ?
Uniquement les données nécessaires au traitement et au diagnostic convenu. La rétention et les accès font partie du dispositif d’exploitation.
Que faire si l’émetteur ne fournit pas d’identifiant d’événement ?
Une clé fiable peut être composée de la ressource, de la version et du type d’événement. Un simple hash du payload ne constitue pas automatiquement un événement métier unique.
Pour la clarification technique
Partir de votre processus concret.
Préparez la documentation de l’émetteur sur les signatures, retries et événements, des payloads anonymisés et les actions cibles souhaitées. Les livraisons multiples déjà observées facilitent la conception de la gestion des erreurs.
Le premier échange clarifie les accès disponibles, la responsabilité des données et un premier flux limité. Nous convenons ensuite du périmètre, des responsabilités et des conditions.
Des exemples anonymisés suffisent pour commencer. Merci de ne pas envoyer de mots de passe, tokens ou données personnelles de production dans la première demande.
Problématiques associées
La prochaine connexion dans son contexte.
Intégration REST API
La documentation est disponible et une requête de test fonctionne. Au quotidien, des données manquent pourtant ou des doublons apparaissent. DataSource relie votre API REST au processus métier concret et prévoit aussi les réponses qui n’arrivent pas.
Synchroniser les commandes & les statuts
La boutique signale le paiement, l’ERP n’a pas encore de commande et le service d’expédition dispose déjà d’un numéro de suivi. Nous relions ces étapes avec des états définis, des références de commande uniques et une reprise planifiée.
Automatiser les utilisateurs & les droits d’accès
Un nouveau collaborateur nécessite des accès dans plusieurs applications. Un changement d’équipe modifie les rôles et un départ exige leur révocation. Nous connectons les données RH de référence à un processus maîtrisé pour ces changements.
Références techniques
Documentation officielle vérifiée le 6 octobre 2026. L’adéquation dépend de l’installation et de la version concernées.