Langue: Français
ActivityInfo 4.0 a introduit les webhooks : une base de données pouvait enregistrer une URL, et ActivityInfo y publiait un message JSON chaque fois qu'un enregistrement était ajouté, modifié ou supprimé. De nombreuses organisations ont bâti des intégrations sur ce principe — des flux de notification dans Power Automate ou Pipedream, des tâches de synchronisation, et le connecteur Power Automate d'ActivityInfo lui-même.
Le nouveau moteur d'automatisation généralise cette idée, et il est utile de comprendre ce qui a changé, ce qui n'a délibérément pas changé, et comment choisir entre les formats de charge utile des webhooks.
Ce qui a changé
Un webhook 4.0 était un pipeline unique et fixe : un événement, une formule de filtre facultative, et une requête HTTP dans un format fixe unique. Une automatisation est un flux d'étapes : un déclencheur qui produit des données, suivi de n'importe quelle combinaison d'étapes de filtre, d'e-mail et de webhook.
Le nouveau concept central est la donnée d'étape. Chaque déclencheur produit un tableau — pour les déclencheurs d'enregistrement, une seule ligne contenant les champs de l'enregistrement à côté des colonnes réservées _previous, _user et _trigger. Chaque étape ultérieure travaille à partir de cette même ligne : le filtre évalue sa condition par rapport à elle, l'étape d'e-mail l'interpole dans des modèles, et l'étape de webhook peut la sérialiser ou l'interpôler dans un corps personnalisé. Un modèle de données unique, appris une fois, utilisé partout — et c'est le même langage de formule utilisé dans tout ActivityInfo pour les champs calculés et les mesures.
C'est aussi pourquoi les filtres sont devenus plus puissants : une formule de filtre 4.0 ne pouvait voir que l'enregistrement lui-même, alors qu'une étape de filtre peut comparer avec l'instantané avant modification (_previous.STATUS != STATUS), naviguer dans les références (CLINIC.NAME == "Mangina Health Post") et inspecter l'acteur (_user.email).
Les importations déclenchent désormais des déclencheurs
Les webhooks d'ActivityInfo 4.0 ne se déclenchaient pas pour les modifications résultant d'importations. L'exclusion visait à protéger les systèmes récepteurs contre les rafales, mais en pratique, elle a créé de réels problèmes : les enregistrements importés en masse contournaient silencieusement les flux de travail basés sur les webhooks, et les consommateurs ne pouvaient jamais être sûrs d'avoir vu chaque modification. Les automatisations suppriment cette exclusion — les déclencheurs d'enregistrement se déclenchent pour chaque modification, quelle que soit son origine : saisie de données, application mobile, API et importations, avec une exécution par enregistrement.
Il s'agit d'un changement de comportement pour les webhooks migrés : une automatisation migrée depuis un webhook 4.0 commence également à recevoir des événements pour les enregistrements importés. Si votre système récepteur ne peut pas absorber une rafale d'une requête par enregistrement importé, ajoutez une étape de filtre pour limiter les événements qui se poursuivent, ou adaptez le récepteur pour mettre en file d'attente les requêtes entrantes.
Ce qui n'a délibérément pas changé
Les webhooks existants continuent de fonctionner, au bit près. Un webhook créé dans ActivityInfo 4.0 apparaît dans le nouvel éditeur comme une automatisation — un déclencheur d'enregistrement, votre formule de filtre si vous en aviez une, et une étape de webhook — et son format de charge utile est compatible ActivityInfo 4.0 : la forme JSON exacte que produisait la version 4.0, maintenue comme un contrat publié et épinglée par une suite de régression sur un instantané des événements de production. Les intégrations bâties sur les webhooks 4.0, y compris les flux utilisant le connecteur Power Automate, continuent de fonctionner sans modification de la charge utile qu'elles reçoivent — la seule différence de comportement est que les importations déclenchent désormais aussi des événements, comme décrit ci-dessus.
La signature est également conservée sans changement : les mêmes en-têtes standard-webhooks et le même schéma de signature v1 HMAC-SHA256, calculé sur le corps exact de la requête.
Pourquoi de nouveaux formats de charge utile ?
Le format 4.0 est orienté événement : son corps update ne transporte que les champs modifiés par l'événement, et les valeurs de ses champs ont été conçues pour le modèle de données 4.0. Cela le rend précis pour le suivi des modifications, mais peu pratique pour deux cas courants :
« Donnez-moi juste l'enregistrement. » Les consommateurs qui veulent l'état actuel complet de l'enregistrement devaient fusionner eux-mêmes
updatedansprevious— et les champs calculés manquaient complètement, car le format 4.0 est construit à partir des valeurs stockées de l'enregistrement et les champs calculés sont calculés à la lecture. Le format Standard envoie à la place les données de l'étape du déclencheur : chaque champ du formulaire pour chaque événement, champs calculés inclus, dans une forme stable, avec_previous,_useret_triggerà côté — exactement ce que voient les formules, donc ce que vous testez dans un filtre est ce que votre consommateur reçoit.« Le récepteur dicte le format. » Les outils de chat et de nombreuses API exigent un corps spécifique. Auparavant, cela impliquait un service intermédiaire juste pour remodeler le JSON. Le format Personnalisé supprime cette étape : vous écrivez le corps comme un modèle avec des références
${...}, et ActivityInfo remplit les valeurs — échappées en JSON, pour que le document reste valide quelles que soient les données qu'il contient. Une notification Google Chat devient une seule étape de webhook avec un modèle d'une ligne.
Choisir un format
| Vous êtes... | Choisissez ||---|---|| En train de maintenir une intégration construite sur les webhooks 4.0, ou d'utiliser le connecteur Power Automate | Compatible ActivityInfo 4.0 | | En train de construire une nouvelle intégration qui consomme l'état de l'enregistrement | Standard | | En train de publier directement sur un système qui dicte le corps — Google Chat, Slack, une API | Personnalisé |
Les webhooks migrés et les connexions Power Automate conservent le format compatible ActivityInfo 4.0, donc rien ne change pour les intégrations existantes ; les nouvelles étapes de webhook utilisent par défaut le format Standard. Le format est un paramètre par étape, vous pouvez donc ajouter un webhook Standard ou Personnalisé à côté d'un webhook compatible 4.0 existant et migrer les consommateurs à votre propre rythme.