osFoundry / Platform
Change-data capture
Streamez chaque changement de ligne depuis toute base d'application. Câblez le CDC vers agents, canaux ou webhooks.
Présentation
Le change data capture (CDC) dans osFoundry transforme la base de données derrière l'une de vos apps en un flux d'événements en direct. Au lieu d'interroger une table selon un calendrier et d'en comparer les résultats, le CDC observe la base directement et émet un événement pour chaque ligne insérée, mise à jour ou supprimée, avec les données de la ligne modifiée jointes. Chacun de ces événements de changement devient quelque chose sur quoi le reste de votre espace de travail peut agir à l'instant même où il se produit, et non des minutes ou des heures plus tard, quand la synchronisation suivante aurait été lancée.
L'intérêt du CDC réside dans la destination de ces événements. Dans osFoundry, la base d'une app n'est pas un silo hermétique : vous reliez ses changements de lignes à trois destinations. Vous pouvez les transmettre à des agents, de sorte qu'un changement sur un enregistrement déclenche un raisonnement ou une action au lieu d'attendre que quelqu'un le remarque. Vous pouvez les acheminer vers des canaux, de sorte qu'un flux de modifications apparaisse comme une activité en direct que votre chat, votre base de connaissances et vos autres apps peuvent tous lire. Et vous pouvez les transférer vers des webhooks, de sorte qu'un système externe reçoive chaque changement dès qu'il arrive. Une seule base, trois sorties, toutes pilotées par les écritures réelles qui atteignent la table, et non par une copie qui devient obsolète à l'instant même où elle est faite.
Cela compte parce qu'osFoundry est bring-your-own-key et local-first. Le CDC réagit aux données de votre propre app avec vos propres identifiants, sans revendeur entre vous et les événements, et le flux de changements reste à l'intérieur de l'espace de travail que vous contrôlez. Résultat : les chiffres sur lesquels les agents raisonnent et les événements que reçoivent les systèmes en aval sont les écritures réelles telles qu'elles surviennent, et non un export périodique que vous devez penser à rafraîchir. Cela comble l'écart entre « la donnée a changé » et « quelque chose y a réagi ».
Fonctionnalités clés
- Émet un événement pour chaque insert, update et delete sur une base d'app, avec les données de la ligne modifiée jointes à chaque événement
- Diffuse les changements de lignes dès qu'ils arrivent, au lieu d'interroger une table selon un calendrier et de comparer des instantanés
- Relie les changements à des agents pour qu'une modification de ligne déclenche un raisonnement ou une action en quasi temps réel
- Achemine les changements vers des canaux pour que le chat, la connaissance et les autres apps lisent l'activité en direct, ou les transfère vers des webhooks sortants pour des systèmes externes
- Réagissez aux données de votre propre app avec vos propres clés : aucun revendeur entre vous et le flux de changements, et le flux reste dans l'espace de travail que vous contrôlez
Cas d’usage
- Ingénieur produit : diffuse les inserts de la table des commandes d'une app vers un webhook pour qu'un système de fulfillment externe réagisse à l'instant où une commande est écrite, sans boucle d'interrogation à maintenir
- Responsable des opérations : achemine les mises à jour d'une table de statuts vers un canal pour que l'équipe et les agents qui l'observent voient les changements d'état comme une activité en direct plutôt qu'un tableau de bord obsolète
- Créateur d'automatisations : relie les suppressions et les modifications d'une table d'enregistrements à un agent pour qu'il revérifie les données en aval au moment où une ligne change, et non selon un minuteur fixe
Questions fréquentes
Qu'est-ce que le change data capture et en quoi diffère-t-il d'une synchronisation planifiée ?
Le change data capture observe une base de données et émet un événement pour chaque ligne insérée, mise à jour ou supprimée, à l'instant où cela se produit. Une synchronisation planifiée relit au contraire toute la source toutes les quelques minutes et la compare, elle manque donc les changements intermédiaires et accuse toujours un retard égal à l'intervalle. Le CDC d'osFoundry réagit aux écritures réelles telles qu'elles arrivent, il n'y a donc pas de boucle d'interrogation ni de fenêtre d'obsolescence entre le changement et la réponse.
Où puis-je envoyer les changements de lignes ?
Trois destinations. Vous pouvez transmettre les changements à des agents pour qu'un changement de ligne déclenche un raisonnement ou une action ; les acheminer vers des canaux pour que le flux de modifications soit lisible par le chat, la connaissance et les autres apps de l'espace de travail ; et les transférer vers des webhooks pour qu'un système externe reçoive chaque changement dès qu'il survient. Vous pouvez les combiner : le même flux de changements peut piloter un agent et atteindre un webhook.
Depuis quelles bases de données le CDC peut-il diffuser, et les données restent-elles privées ?
Le CDC diffuse les changements de lignes depuis la propre base de données d'une app dans votre espace de travail osFoundry. Parce qu'osFoundry est bring-your-own-key et local-first, vous réagissez aux données de votre propre app avec vos propres identifiants, aucun revendeur ne s'interpose entre vous et les événements de changement, et le flux reste à l'intérieur de l'espace de travail que vous contrôlez plutôt que de passer par un tiers.