Création et consommation de Webhooks pour les oiseaux
Oiseau
27 janv. 2022
1 min read
Points Clés
Les webhooks d'événements en temps réel de Bird permettent aux expéditeurs de recevoir des données d'événements instantanément—pas de poll, pas de tâches cron, et pas de soucis de limites de débit.
Les webhooks éliminent la complexité de la gestion des fenêtres temporelles, empêchant les événements manqués et gérant les enregistrements en double.
Idéal pour l'automatisation en aval : mise à jour des listes, démarrage des parcours, enrichissement des tableaux de bord ou synchronisation des systèmes internes.
Le tutoriel guide les expéditeurs à travers la construction d'un pipeline d'ingestion complet AWS : stockage S3, traitement Lambda et un équilibreur de charge d'application.
S3 sert de couche centrale de stockage pour les charges de webhooks, chaque lot étant écrit sous forme de fichier JSON plat.
Les fonctions Lambda gèrent à la fois l'ingestion (stockage des lots bruts) et la transformation (conversion de JSON en CSV).
Bird regroupe les événements—chaque lot de webhook inclut un
x-messagesystems-batch-idunique, permettant les vérifications de relecture et la déduplication.La Lambda consommateur doit rester efficace puisque Bird retente les lots si le point de terminaison ne répond pas dans un délai d'environ 10 secondes.
AWS ALB est recommandé (par rapport à API Gateway) pour sa simplicité, son rapport coût-efficacité, et sa gestion directe des requêtes HTTP POST.
DNS (Route 53 ou fournisseur externe) est configuré pour mapper un nom d'hôte convivial à l'endpoint ALB.
Après configuration, Bird pousse les données d'événements directement et de manière fiable vers votre pipeline AWS pour un traitement asynchrone.
Le guide couvre également les meilleures pratiques : permissions IAM de moindre privilège, contraintes de stockage temporaire, évitement des déclencheurs récursifs, et organisation de workflows multi-lambda.
Points forts des Q&A
Quel est le principal objectif des webhooks d'événements en temps réel de Bird ?
Pour envoyer les données d'événements directement au point de terminaison d'un expéditeur en temps réel, permettant ainsi une automatisation immédiate sans sondage ni appels d'API à débit limité.
Pourquoi les webhooks sont-ils meilleurs que de récupérer des données via API pour les grands expéditeurs ?
Parce que les appels API nécessitent une gestion des fenêtres temporelles, risquent des lacunes ou des doublons de données, et peuvent atteindre des limites de taux—les webhooks éliminent tout cela en poussant les données en continu.
Quels services AWS sont utilisés dans le pipeline d'ingestion webhook recommandé ?
Amazon S3 (storage), AWS Lambda (processing), un Application Load Balancer (HTTP listener), et éventuellement Route 53 (DNS).
Comment Bird regroupe-t-il les données d'événement ?
Bird envoie plusieurs événements ensemble dans une charge utile, chacun étant assigné à un ID de lot unique (x-messagesystems-batch-id) pour le suivi, les tentatives de réenvoi et la déduplication.
Qu'est-ce qui déclenche la fonction Lambda du consommateur ?
Le ALB transfère les requêtes POST de webhook entrantes directement au Lambda, qui extrait la charge utile et l'écrit dans S3.
Pourquoi stocker le lot de webhook brut dans S3 avant de le traiter ?
Pour garantir une ingestion rapide (<10 secondes) afin que la connexion ne dépasse pas le délai d'attente, et transférer les traitements plus lourds vers un pipeline asynchrone séparé.
Que fait la deuxième fonction Lambda?
Il est déclenché par de nouveaux objets S3, valide le JSON, le convertit en CSV, et écrit le résultat traité dans un autre compartiment S3.
Pourquoi utiliser un bucket S3 séparé pour les fichiers CSV traités?
Pour éviter les déclencheurs récursifs (écrire un nouveau fichier traité dans le même bucket relancerait sans fin la fonction Lambda).
Quelles autorisations les fonctions Lambda nécessitent-elles ?
Le Lambda utilisateur a besoin des permissions S3 PutObject; le Lambda de traitement a besoin de GetObject pour le seau source et de PutObject pour le seau de destination.
Pourquoi un AWS ALB est-il recommandé par rapport à l'API Gateway ?
Les ALB sont moins chers, plus simples et idéaux pour le transfert HTTPS POST straightforward ; API Gateway peut altérer le format du payload et augmenter la complexité.
Comment les expéditeurs configurent-ils le webhook dans Bird ?
En fournissant le point de terminaison HTTPS (l'enregistrement DNS pour l'ALB), en sélectionnant un sous-compte, en choisissant des événements et en enregistrant la configuration du webhook.
Quelles options en aval existent pour stocker ou analyser les données traitées ?
Charger dans des bases de données (PostgreSQL, DynamoDB, RDS), alimenter des systèmes ETL, ou interroger directement avec des outils comme Athena.
Le guide suivant est une simple aide pour permettre aux expéditeurs de se sentir à l'aise lors de la création d'un webhook d'événements Bird et de l'utilisation des données via l'infrastructure d'AWS.
Les webhooks d'événements en temps réel de Bird sont un outil incroyablement précieux pour les expéditeurs afin de faire pousser automatiquement les données vers leurs systèmes. Cela peut entraîner des automatisations en aval telles que la mise à jour des listes de diffusion, le déclenchement de parcours de courrier électronique automatisés ou la population de tableaux de bord internes. Bien que les mêmes données d'événement puissent être consultées via l'interface utilisateur de Bird en utilisant Event Search, ou programmatiquement en utilisant l'API Events API de Bird, les limites placées sur le nombre de dossiers renvoyés dans une seule requête ou les limites de débit placées sur le point d'accès API peuvent rendre ces deux méthodes restrictives pour les expéditeurs importants et sophistiqués.
Les webhooks d'événements en temps réel permettent à un expéditeur de configurer un point d'accès où Bird transmet les données, et les données peuvent être consommées sans avoir à programmer des tâches cron qui récupèrent les données. Il y a aussi des compromis logistiques lorsque vous récupérez les données au lieu de les faire pousser vers vous, comme l'identification de la période de temps et des paramètres à utiliser pour chaque requête API. Si les périodes de temps ne sont pas parfaitement alignées, vous risquez de manquer des données, et si les périodes de temps se chevauchent, vous devez gérer les enregistrements de données en double. Avec les webhooks en temps réel, les données d'événement sont simplement poussées vers votre point d'accès au fur et à mesure qu'elles deviennent disponibles dans Bird.
Bien que les avantages de recevoir des données d'événement en temps réel pour faciliter les processus d'automatisation en aval puissent être immédiatement compris par de nombreux expéditeurs, le processus réel d'implémentation et de consommation des webhooks peut être intimidant. Cela peut être particulièrement vrai si vous n'êtes pas familiarisé avec les composants techniques de la création d'un point d'accès et de la gestion des données de manière programmatique. Il existe des services disponibles qui consommeront les données du webhook Bird et les intégreront automatiquement dans votre base de données – un exemple serait StitchData, dont nous avons parlé dans notre blog par le passé. Cependant, si vous souhaitez plus de contrôle sur le processus, vous pouvez facilement construire les composants vous-même. Voici un guide simple pour aider les expéditeurs à se sentir à l'aise lors de la création d'un webhook d'événements Bird et la consommation des données en utilisant l'infrastructure au sein d'AWS.
Les webhooks d'événements en temps réel de Bird sont un outil incroyablement précieux pour les expéditeurs afin de faire pousser automatiquement les données vers leurs systèmes. Cela peut entraîner des automatisations en aval telles que la mise à jour des listes de diffusion, le déclenchement de parcours de courrier électronique automatisés ou la population de tableaux de bord internes. Bien que les mêmes données d'événement puissent être consultées via l'interface utilisateur de Bird en utilisant Event Search, ou programmatiquement en utilisant l'API Events API de Bird, les limites placées sur le nombre de dossiers renvoyés dans une seule requête ou les limites de débit placées sur le point d'accès API peuvent rendre ces deux méthodes restrictives pour les expéditeurs importants et sophistiqués.
Les webhooks d'événements en temps réel permettent à un expéditeur de configurer un point d'accès où Bird transmet les données, et les données peuvent être consommées sans avoir à programmer des tâches cron qui récupèrent les données. Il y a aussi des compromis logistiques lorsque vous récupérez les données au lieu de les faire pousser vers vous, comme l'identification de la période de temps et des paramètres à utiliser pour chaque requête API. Si les périodes de temps ne sont pas parfaitement alignées, vous risquez de manquer des données, et si les périodes de temps se chevauchent, vous devez gérer les enregistrements de données en double. Avec les webhooks en temps réel, les données d'événement sont simplement poussées vers votre point d'accès au fur et à mesure qu'elles deviennent disponibles dans Bird.
Bien que les avantages de recevoir des données d'événement en temps réel pour faciliter les processus d'automatisation en aval puissent être immédiatement compris par de nombreux expéditeurs, le processus réel d'implémentation et de consommation des webhooks peut être intimidant. Cela peut être particulièrement vrai si vous n'êtes pas familiarisé avec les composants techniques de la création d'un point d'accès et de la gestion des données de manière programmatique. Il existe des services disponibles qui consommeront les données du webhook Bird et les intégreront automatiquement dans votre base de données – un exemple serait StitchData, dont nous avons parlé dans notre blog par le passé. Cependant, si vous souhaitez plus de contrôle sur le processus, vous pouvez facilement construire les composants vous-même. Voici un guide simple pour aider les expéditeurs à se sentir à l'aise lors de la création d'un webhook d'événements Bird et la consommation des données en utilisant l'infrastructure au sein d'AWS.
Les webhooks d'événements en temps réel de Bird sont un outil incroyablement précieux pour les expéditeurs afin de faire pousser automatiquement les données vers leurs systèmes. Cela peut entraîner des automatisations en aval telles que la mise à jour des listes de diffusion, le déclenchement de parcours de courrier électronique automatisés ou la population de tableaux de bord internes. Bien que les mêmes données d'événement puissent être consultées via l'interface utilisateur de Bird en utilisant Event Search, ou programmatiquement en utilisant l'API Events API de Bird, les limites placées sur le nombre de dossiers renvoyés dans une seule requête ou les limites de débit placées sur le point d'accès API peuvent rendre ces deux méthodes restrictives pour les expéditeurs importants et sophistiqués.
Les webhooks d'événements en temps réel permettent à un expéditeur de configurer un point d'accès où Bird transmet les données, et les données peuvent être consommées sans avoir à programmer des tâches cron qui récupèrent les données. Il y a aussi des compromis logistiques lorsque vous récupérez les données au lieu de les faire pousser vers vous, comme l'identification de la période de temps et des paramètres à utiliser pour chaque requête API. Si les périodes de temps ne sont pas parfaitement alignées, vous risquez de manquer des données, et si les périodes de temps se chevauchent, vous devez gérer les enregistrements de données en double. Avec les webhooks en temps réel, les données d'événement sont simplement poussées vers votre point d'accès au fur et à mesure qu'elles deviennent disponibles dans Bird.
Bien que les avantages de recevoir des données d'événement en temps réel pour faciliter les processus d'automatisation en aval puissent être immédiatement compris par de nombreux expéditeurs, le processus réel d'implémentation et de consommation des webhooks peut être intimidant. Cela peut être particulièrement vrai si vous n'êtes pas familiarisé avec les composants techniques de la création d'un point d'accès et de la gestion des données de manière programmatique. Il existe des services disponibles qui consommeront les données du webhook Bird et les intégreront automatiquement dans votre base de données – un exemple serait StitchData, dont nous avons parlé dans notre blog par le passé. Cependant, si vous souhaitez plus de contrôle sur le processus, vous pouvez facilement construire les composants vous-même. Voici un guide simple pour aider les expéditeurs à se sentir à l'aise lors de la création d'un webhook d'événements Bird et la consommation des données en utilisant l'infrastructure au sein d'AWS.
Traitement des données d'événement Webhook
Selon l'objectif prévu pour le stockage des données d'événements Bird, vos besoins peuvent être satisfaits en stockant simplement la charge utile JSON en tant que fichier plat. Vous pouvez également avoir déjà un processus ETL en aval établi qui est capable de consommer et de charger des données au format JSON. Dans ces deux cas, vous pourrez peut-être utiliser le fichier plat créé par notre traitement lambda que nous avons créé ci-dessus tel quel.
Alternativement, vous pourriez avoir besoin de transformer les données – par exemple, pour convertir de JSON en format CSV – ou de charger les données directement dans une base de données. Dans cet exemple, nous allons créer une fonction lambda simple qui convertira les données de webhook du format JSON original en un fichier CSV qui pourrait être chargé dans une base de données.
Selon l'objectif prévu pour le stockage des données d'événements Bird, vos besoins peuvent être satisfaits en stockant simplement la charge utile JSON en tant que fichier plat. Vous pouvez également avoir déjà un processus ETL en aval établi qui est capable de consommer et de charger des données au format JSON. Dans ces deux cas, vous pourrez peut-être utiliser le fichier plat créé par notre traitement lambda que nous avons créé ci-dessus tel quel.
Alternativement, vous pourriez avoir besoin de transformer les données – par exemple, pour convertir de JSON en format CSV – ou de charger les données directement dans une base de données. Dans cet exemple, nous allons créer une fonction lambda simple qui convertira les données de webhook du format JSON original en un fichier CSV qui pourrait être chargé dans une base de données.
Selon l'objectif prévu pour le stockage des données d'événements Bird, vos besoins peuvent être satisfaits en stockant simplement la charge utile JSON en tant que fichier plat. Vous pouvez également avoir déjà un processus ETL en aval établi qui est capable de consommer et de charger des données au format JSON. Dans ces deux cas, vous pourrez peut-être utiliser le fichier plat créé par notre traitement lambda que nous avons créé ci-dessus tel quel.
Alternativement, vous pourriez avoir besoin de transformer les données – par exemple, pour convertir de JSON en format CSV – ou de charger les données directement dans une base de données. Dans cet exemple, nous allons créer une fonction lambda simple qui convertira les données de webhook du format JSON original en un fichier CSV qui pourrait être chargé dans une base de données.
Configuration de l'Endpoint de Cible Webhook
Lorsqu'un événement Bird est créé, nous voulons que les données de l'événement soient transmises en temps réel à un point de terminaison dans AWS afin que nous puissions consommer et utiliser ces données de manière programmée. Les données seront envoyées de Bird vers un point de terminaison cible, qui transférera la charge utile à une fonction lambda qui traitera et stockera les données dans un compartiment S3. Un diagramme de haut niveau du flux de données décrit peut être vu ci-dessous :
Pour mettre en œuvre ce flux de travail, construisons-les en fait dans l'ordre inverse en commençant par créer un compartiment S3 où nous stockerons nos données d'événement, puis travaillons à rebours - en ajoutant chaque composant qui alimente ce que nous avons construit.
Lorsqu'un événement Bird est créé, nous voulons que les données de l'événement soient transmises en temps réel à un point de terminaison dans AWS afin que nous puissions consommer et utiliser ces données de manière programmée. Les données seront envoyées de Bird vers un point de terminaison cible, qui transférera la charge utile à une fonction lambda qui traitera et stockera les données dans un compartiment S3. Un diagramme de haut niveau du flux de données décrit peut être vu ci-dessous :
Pour mettre en œuvre ce flux de travail, construisons-les en fait dans l'ordre inverse en commençant par créer un compartiment S3 où nous stockerons nos données d'événement, puis travaillons à rebours - en ajoutant chaque composant qui alimente ce que nous avons construit.
Lorsqu'un événement Bird est créé, nous voulons que les données de l'événement soient transmises en temps réel à un point de terminaison dans AWS afin que nous puissions consommer et utiliser ces données de manière programmée. Les données seront envoyées de Bird vers un point de terminaison cible, qui transférera la charge utile à une fonction lambda qui traitera et stockera les données dans un compartiment S3. Un diagramme de haut niveau du flux de données décrit peut être vu ci-dessous :
Pour mettre en œuvre ce flux de travail, construisons-les en fait dans l'ordre inverse en commençant par créer un compartiment S3 où nous stockerons nos données d'événement, puis travaillons à rebours - en ajoutant chaque composant qui alimente ce que nous avons construit.
Créez un S3 Bucket pour stocker les données du Webhook
Avant de créer notre équilibrage de charge pour accepter les données, ou notre fonction lambda pour stocker les données, nous devons d'abord créer notre bucket S3 où les données seront stockées. Bien que S3 offre un excellent stockage pour les données de webhook, les organisations utilisant également des bases de données PostgreSQL pour le traitement d'événements devraient mettre en œuvre des procédures de sauvegarde et de restauration appropriées pour protéger leurs données structurées parallèlement à leur stratégie de stockage S3. Pour ce faire, accédez au service S3 dans AWS et appuyez sur « Créer un bucket ». Vous serez invité à attribuer un nom à votre bucket et à définir la région – assurez-vous d'utiliser la même région que votre ALB et fonction lambda. Une fois votre bucket S3 créé, il sera vide – si vous souhaitez organiser les données à l'intérieur d'un dossier, vous pouvez soit créer le répertoire souhaité maintenant, soit le répertoire sera créé lorsque votre fonction lambda stockera le fichier. Dans cet exemple, nous avons nommé notre bucket S3 "bird-webhooks" et créé un dossier nommé "B Event Data" pour stocker nos données d'événement – vous verrez ces noms référencés dans notre fonction lambda ci-dessous.
Avant de créer notre équilibrage de charge pour accepter les données, ou notre fonction lambda pour stocker les données, nous devons d'abord créer notre bucket S3 où les données seront stockées. Bien que S3 offre un excellent stockage pour les données de webhook, les organisations utilisant également des bases de données PostgreSQL pour le traitement d'événements devraient mettre en œuvre des procédures de sauvegarde et de restauration appropriées pour protéger leurs données structurées parallèlement à leur stratégie de stockage S3. Pour ce faire, accédez au service S3 dans AWS et appuyez sur « Créer un bucket ». Vous serez invité à attribuer un nom à votre bucket et à définir la région – assurez-vous d'utiliser la même région que votre ALB et fonction lambda. Une fois votre bucket S3 créé, il sera vide – si vous souhaitez organiser les données à l'intérieur d'un dossier, vous pouvez soit créer le répertoire souhaité maintenant, soit le répertoire sera créé lorsque votre fonction lambda stockera le fichier. Dans cet exemple, nous avons nommé notre bucket S3 "bird-webhooks" et créé un dossier nommé "B Event Data" pour stocker nos données d'événement – vous verrez ces noms référencés dans notre fonction lambda ci-dessous.
Avant de créer notre équilibrage de charge pour accepter les données, ou notre fonction lambda pour stocker les données, nous devons d'abord créer notre bucket S3 où les données seront stockées. Bien que S3 offre un excellent stockage pour les données de webhook, les organisations utilisant également des bases de données PostgreSQL pour le traitement d'événements devraient mettre en œuvre des procédures de sauvegarde et de restauration appropriées pour protéger leurs données structurées parallèlement à leur stratégie de stockage S3. Pour ce faire, accédez au service S3 dans AWS et appuyez sur « Créer un bucket ». Vous serez invité à attribuer un nom à votre bucket et à définir la région – assurez-vous d'utiliser la même région que votre ALB et fonction lambda. Une fois votre bucket S3 créé, il sera vide – si vous souhaitez organiser les données à l'intérieur d'un dossier, vous pouvez soit créer le répertoire souhaité maintenant, soit le répertoire sera créé lorsque votre fonction lambda stockera le fichier. Dans cet exemple, nous avons nommé notre bucket S3 "bird-webhooks" et créé un dossier nommé "B Event Data" pour stocker nos données d'événement – vous verrez ces noms référencés dans notre fonction lambda ci-dessous.
Créer une fonction Lambda pour consommer les données
Le traitement et le stockage réels des données seront effectués par une fonction lambda qui est invoquée par notre équilibreur de charge d'application (ALB).
La première étape consiste à créer votre fonction lambda en accédant au service Lambda sur AWS et en cliquant sur “Create Function”. Vous serez invité à attribuer un nom à votre fonction lambda et à choisir le langage de programmation dans lequel écrire votre fonction. Pour cet exemple, nous utilisons Python comme langage d'exécution.
Maintenant, nous devons développer notre fonction lambda. Supposons un instant que notre équilibreur de charge d'application a été configuré et transmet le payload du webhook à notre fonction lambda – la lambda recevra un payload comprenant les en-têtes complets et le corps. Le payload est transmis à notre fonction lambda en utilisant l'objet “event” comme dictionnaire. Vous pouvez référencer indépendamment les en-têtes et le corps du payload en accédant aux objets “headers” et “body” dans le payload. Dans cet exemple, nous allons simplement lire l'en-tête “x-messagesystems-batch-id”, où l'ID de lot est une valeur unique créée par Bird pour le lot de webhook, et l'utiliser comme nom de fichier lors de la sauvegarde du corps en tant que fichier plat dans S3; cependant, vous pouvez vouloir ajouter des fonctionnalités supplémentaires telles que des vérifications d'authentification ou gestion des erreurs, selon les besoins.
Lors de la sauvegarde du payload dans un fichier plat sur S3, nous devrons définir le nom du bucket S3, l'emplacement et le nom du fichier où les données du payload seront stockées. Dans notre fonction lambda d'exemple, nous faisons cela dans la fonction “store_batch”. Dans cet exemple, nous allons stocker l'ensemble du lot comme un seul fichier, ce qui aide à garantir que les données sont collectées et stockées avant que la connexion HTTP entre Bird et votre point de terminaison ne se termine. Bien que vous puissiez ajuster les paramètres de délai d'expiration de connexion sur votre équilibreur de charge, il n'y a aucune garantie que la connexion ne se terminera pas du côté de la transmission (dans ce cas Bird) ou que la connexion ne sera pas interrompue avant que votre fonction lambda ne termine son exécution. Il est une bonne pratique de maintenir votre fonction consommateur aussi efficace que possible et de réserver les activités de traitement des données aux processus en aval lorsque cela est possible – comme convertir le payload JSON formaté par lots en un fichier CSV, ou charger les données d'événements dans une base de données.
Il est important de noter que vous devrez peut-être mettre à jour les autorisations pour votre fonction lambda. Votre rôle d'exécution devra avoir les autorisations PutObject et GetObject pour S3. Il est une bonne pratique d'appliquer le principe du moindre privilège, donc je recommande de définir ces autorisations uniquement pour le bucket S3 où les payloads du webhook seront stockés.
Un échantillon de notre fonction lambda consommateur peut être trouvé ici.
Une petite note sur l'ID de lot: Bird va regrouper les événements dans un seul payload, où chaque lot peut contenir de 1 à 350 ou plus enregistrements d'événements. Le lot sera attribué un ID de lot unique, qui peut être utilisé pour voir le statut du lot en tirant parti de l'Event Webhooks API ou dans votre compte Bird en cliquant sur un flux de webhook et en sélectionnant “Batch Status”. Dans le cas où un payload de webhook ne pourrait pas être livré, comme lors d'un délai d'expiration de connexion, Bird va automatiquement réessayer le lot en utilisant le même ID de lot. Cela peut arriver lorsque votre fonction lambda s'exécute proche du temps de trajet maximal de 10 secondes et est une raison d'optimiser la fonction consommateur pour réduire le temps d'exécution.
Pour gérer toutes les activités de traitement de données, je recommande de créer une fonction lambda distincte qui s'exécute chaque fois qu'un nouveau fichier est créé sur le bucket S3 – de cette manière, le traitement des données est effectué de manière asynchrone par rapport à la transmission des données, et il n'y a aucun risque de perte de données en raison d'une connexion interrompue. Je discute de la fonction lambda de traitement dans une section ultérieure.
Le traitement et le stockage réels des données seront effectués par une fonction lambda qui est invoquée par notre équilibreur de charge d'application (ALB).
La première étape consiste à créer votre fonction lambda en accédant au service Lambda sur AWS et en cliquant sur “Create Function”. Vous serez invité à attribuer un nom à votre fonction lambda et à choisir le langage de programmation dans lequel écrire votre fonction. Pour cet exemple, nous utilisons Python comme langage d'exécution.
Maintenant, nous devons développer notre fonction lambda. Supposons un instant que notre équilibreur de charge d'application a été configuré et transmet le payload du webhook à notre fonction lambda – la lambda recevra un payload comprenant les en-têtes complets et le corps. Le payload est transmis à notre fonction lambda en utilisant l'objet “event” comme dictionnaire. Vous pouvez référencer indépendamment les en-têtes et le corps du payload en accédant aux objets “headers” et “body” dans le payload. Dans cet exemple, nous allons simplement lire l'en-tête “x-messagesystems-batch-id”, où l'ID de lot est une valeur unique créée par Bird pour le lot de webhook, et l'utiliser comme nom de fichier lors de la sauvegarde du corps en tant que fichier plat dans S3; cependant, vous pouvez vouloir ajouter des fonctionnalités supplémentaires telles que des vérifications d'authentification ou gestion des erreurs, selon les besoins.
Lors de la sauvegarde du payload dans un fichier plat sur S3, nous devrons définir le nom du bucket S3, l'emplacement et le nom du fichier où les données du payload seront stockées. Dans notre fonction lambda d'exemple, nous faisons cela dans la fonction “store_batch”. Dans cet exemple, nous allons stocker l'ensemble du lot comme un seul fichier, ce qui aide à garantir que les données sont collectées et stockées avant que la connexion HTTP entre Bird et votre point de terminaison ne se termine. Bien que vous puissiez ajuster les paramètres de délai d'expiration de connexion sur votre équilibreur de charge, il n'y a aucune garantie que la connexion ne se terminera pas du côté de la transmission (dans ce cas Bird) ou que la connexion ne sera pas interrompue avant que votre fonction lambda ne termine son exécution. Il est une bonne pratique de maintenir votre fonction consommateur aussi efficace que possible et de réserver les activités de traitement des données aux processus en aval lorsque cela est possible – comme convertir le payload JSON formaté par lots en un fichier CSV, ou charger les données d'événements dans une base de données.
Il est important de noter que vous devrez peut-être mettre à jour les autorisations pour votre fonction lambda. Votre rôle d'exécution devra avoir les autorisations PutObject et GetObject pour S3. Il est une bonne pratique d'appliquer le principe du moindre privilège, donc je recommande de définir ces autorisations uniquement pour le bucket S3 où les payloads du webhook seront stockés.
Un échantillon de notre fonction lambda consommateur peut être trouvé ici.
Une petite note sur l'ID de lot: Bird va regrouper les événements dans un seul payload, où chaque lot peut contenir de 1 à 350 ou plus enregistrements d'événements. Le lot sera attribué un ID de lot unique, qui peut être utilisé pour voir le statut du lot en tirant parti de l'Event Webhooks API ou dans votre compte Bird en cliquant sur un flux de webhook et en sélectionnant “Batch Status”. Dans le cas où un payload de webhook ne pourrait pas être livré, comme lors d'un délai d'expiration de connexion, Bird va automatiquement réessayer le lot en utilisant le même ID de lot. Cela peut arriver lorsque votre fonction lambda s'exécute proche du temps de trajet maximal de 10 secondes et est une raison d'optimiser la fonction consommateur pour réduire le temps d'exécution.
Pour gérer toutes les activités de traitement de données, je recommande de créer une fonction lambda distincte qui s'exécute chaque fois qu'un nouveau fichier est créé sur le bucket S3 – de cette manière, le traitement des données est effectué de manière asynchrone par rapport à la transmission des données, et il n'y a aucun risque de perte de données en raison d'une connexion interrompue. Je discute de la fonction lambda de traitement dans une section ultérieure.
Le traitement et le stockage réels des données seront effectués par une fonction lambda qui est invoquée par notre équilibreur de charge d'application (ALB).
La première étape consiste à créer votre fonction lambda en accédant au service Lambda sur AWS et en cliquant sur “Create Function”. Vous serez invité à attribuer un nom à votre fonction lambda et à choisir le langage de programmation dans lequel écrire votre fonction. Pour cet exemple, nous utilisons Python comme langage d'exécution.
Maintenant, nous devons développer notre fonction lambda. Supposons un instant que notre équilibreur de charge d'application a été configuré et transmet le payload du webhook à notre fonction lambda – la lambda recevra un payload comprenant les en-têtes complets et le corps. Le payload est transmis à notre fonction lambda en utilisant l'objet “event” comme dictionnaire. Vous pouvez référencer indépendamment les en-têtes et le corps du payload en accédant aux objets “headers” et “body” dans le payload. Dans cet exemple, nous allons simplement lire l'en-tête “x-messagesystems-batch-id”, où l'ID de lot est une valeur unique créée par Bird pour le lot de webhook, et l'utiliser comme nom de fichier lors de la sauvegarde du corps en tant que fichier plat dans S3; cependant, vous pouvez vouloir ajouter des fonctionnalités supplémentaires telles que des vérifications d'authentification ou gestion des erreurs, selon les besoins.
Lors de la sauvegarde du payload dans un fichier plat sur S3, nous devrons définir le nom du bucket S3, l'emplacement et le nom du fichier où les données du payload seront stockées. Dans notre fonction lambda d'exemple, nous faisons cela dans la fonction “store_batch”. Dans cet exemple, nous allons stocker l'ensemble du lot comme un seul fichier, ce qui aide à garantir que les données sont collectées et stockées avant que la connexion HTTP entre Bird et votre point de terminaison ne se termine. Bien que vous puissiez ajuster les paramètres de délai d'expiration de connexion sur votre équilibreur de charge, il n'y a aucune garantie que la connexion ne se terminera pas du côté de la transmission (dans ce cas Bird) ou que la connexion ne sera pas interrompue avant que votre fonction lambda ne termine son exécution. Il est une bonne pratique de maintenir votre fonction consommateur aussi efficace que possible et de réserver les activités de traitement des données aux processus en aval lorsque cela est possible – comme convertir le payload JSON formaté par lots en un fichier CSV, ou charger les données d'événements dans une base de données.
Il est important de noter que vous devrez peut-être mettre à jour les autorisations pour votre fonction lambda. Votre rôle d'exécution devra avoir les autorisations PutObject et GetObject pour S3. Il est une bonne pratique d'appliquer le principe du moindre privilège, donc je recommande de définir ces autorisations uniquement pour le bucket S3 où les payloads du webhook seront stockés.
Un échantillon de notre fonction lambda consommateur peut être trouvé ici.
Une petite note sur l'ID de lot: Bird va regrouper les événements dans un seul payload, où chaque lot peut contenir de 1 à 350 ou plus enregistrements d'événements. Le lot sera attribué un ID de lot unique, qui peut être utilisé pour voir le statut du lot en tirant parti de l'Event Webhooks API ou dans votre compte Bird en cliquant sur un flux de webhook et en sélectionnant “Batch Status”. Dans le cas où un payload de webhook ne pourrait pas être livré, comme lors d'un délai d'expiration de connexion, Bird va automatiquement réessayer le lot en utilisant le même ID de lot. Cela peut arriver lorsque votre fonction lambda s'exécute proche du temps de trajet maximal de 10 secondes et est une raison d'optimiser la fonction consommateur pour réduire le temps d'exécution.
Pour gérer toutes les activités de traitement de données, je recommande de créer une fonction lambda distincte qui s'exécute chaque fois qu'un nouveau fichier est créé sur le bucket S3 – de cette manière, le traitement des données est effectué de manière asynchrone par rapport à la transmission des données, et il n'y a aucun risque de perte de données en raison d'une connexion interrompue. Je discute de la fonction lambda de traitement dans une section ultérieure.
Créer un Application Load Balancer
Pour recevoir une charge utile de webhook, nous devons fournir un point de terminaison pour envoyer les charges utiles. Nous le faisons en créant un équilibre de charge d'application au sein de AWS en naviguant vers EC2 > Load Balancers et en cliquant sur « Créer Load Balancer ». Vous serez invité à choisir le type d'équilibre de charge que vous souhaitez créer – pour cela, nous voulons créer un équilibre de charge d'application. Nous devons utiliser un équilibre de charge d'application (ALB) pour construire notre consommateur car les webhooks d'événements seront envoyés sous forme de requête HTTP, et les ALB sont utilisés pour router les requêtes HTTP au sein de AWS. Nous pourrions mettre en œuvre une passerelle HTTP en alternative ; cependant, nous utilisons un ALB pour ce projet car il est plus léger et plus rentable qu'une passerelle HTTP. Il est important de noter que si vous choisissez d'utiliser une passerelle HTTP, le format d'événement peut être différent de celui d'un ALB, et donc votre fonction lambda devra gérer l'objet de requête en conséquence.
Une fois votre ALB créé, vous serez invité à attribuer un nom à votre ALB et à configurer le schéma et les paramètres d'accès/sécurité – puisque nous prévoyons de recevoir des données d'événement d'une source externe (Bird), nous voulons que notre ALB soit orienté vers Internet. Sous « Auditeurs et routage », l'ALB doit écouter HTTPS sur le port 443, et nous voulons créer un groupe Cible pointant vers notre fonction lambda pour que notre ALB transmette les demandes entrantes à la fonction lambda consommatrice que nous avons créée ci-dessus. Vous devez également vous assurer que le groupe de sécurité dispose de l'autorisation d'accepter le trafic via le port 443.
Pour recevoir une charge utile de webhook, nous devons fournir un point de terminaison pour envoyer les charges utiles. Nous le faisons en créant un équilibre de charge d'application au sein de AWS en naviguant vers EC2 > Load Balancers et en cliquant sur « Créer Load Balancer ». Vous serez invité à choisir le type d'équilibre de charge que vous souhaitez créer – pour cela, nous voulons créer un équilibre de charge d'application. Nous devons utiliser un équilibre de charge d'application (ALB) pour construire notre consommateur car les webhooks d'événements seront envoyés sous forme de requête HTTP, et les ALB sont utilisés pour router les requêtes HTTP au sein de AWS. Nous pourrions mettre en œuvre une passerelle HTTP en alternative ; cependant, nous utilisons un ALB pour ce projet car il est plus léger et plus rentable qu'une passerelle HTTP. Il est important de noter que si vous choisissez d'utiliser une passerelle HTTP, le format d'événement peut être différent de celui d'un ALB, et donc votre fonction lambda devra gérer l'objet de requête en conséquence.
Une fois votre ALB créé, vous serez invité à attribuer un nom à votre ALB et à configurer le schéma et les paramètres d'accès/sécurité – puisque nous prévoyons de recevoir des données d'événement d'une source externe (Bird), nous voulons que notre ALB soit orienté vers Internet. Sous « Auditeurs et routage », l'ALB doit écouter HTTPS sur le port 443, et nous voulons créer un groupe Cible pointant vers notre fonction lambda pour que notre ALB transmette les demandes entrantes à la fonction lambda consommatrice que nous avons créée ci-dessus. Vous devez également vous assurer que le groupe de sécurité dispose de l'autorisation d'accepter le trafic via le port 443.
Pour recevoir une charge utile de webhook, nous devons fournir un point de terminaison pour envoyer les charges utiles. Nous le faisons en créant un équilibre de charge d'application au sein de AWS en naviguant vers EC2 > Load Balancers et en cliquant sur « Créer Load Balancer ». Vous serez invité à choisir le type d'équilibre de charge que vous souhaitez créer – pour cela, nous voulons créer un équilibre de charge d'application. Nous devons utiliser un équilibre de charge d'application (ALB) pour construire notre consommateur car les webhooks d'événements seront envoyés sous forme de requête HTTP, et les ALB sont utilisés pour router les requêtes HTTP au sein de AWS. Nous pourrions mettre en œuvre une passerelle HTTP en alternative ; cependant, nous utilisons un ALB pour ce projet car il est plus léger et plus rentable qu'une passerelle HTTP. Il est important de noter que si vous choisissez d'utiliser une passerelle HTTP, le format d'événement peut être différent de celui d'un ALB, et donc votre fonction lambda devra gérer l'objet de requête en conséquence.
Une fois votre ALB créé, vous serez invité à attribuer un nom à votre ALB et à configurer le schéma et les paramètres d'accès/sécurité – puisque nous prévoyons de recevoir des données d'événement d'une source externe (Bird), nous voulons que notre ALB soit orienté vers Internet. Sous « Auditeurs et routage », l'ALB doit écouter HTTPS sur le port 443, et nous voulons créer un groupe Cible pointant vers notre fonction lambda pour que notre ALB transmette les demandes entrantes à la fonction lambda consommatrice que nous avons créée ci-dessus. Vous devez également vous assurer que le groupe de sécurité dispose de l'autorisation d'accepter le trafic via le port 443.
Créer un enregistrement DNS pour le Load Balancer
Pour nous faciliter l'utilisation de notre ALB en tant que point de terminaison, nous allons créer un enregistrement A dans le DNS qui pointe vers notre ALB. Pour cela, nous pouvons utiliser le service AWS Route 53 (ou votre fournisseur DNS actuel) et créer un enregistrement A pour le nom d'hôte que vous souhaitez utiliser pour votre point de terminaison (par exemple, spevents.<votre_domaine>). Lorsque vous travaillez avec le DNS à grande échelle sur AWS, soyez conscient qu'il existe des limites DNS non documentées qui peuvent affecter les applications à fort volume, en particulier celles traitant de grandes quantités de trafic sortant comme les systèmes de livraison de courriels. L'enregistrement A doit être configuré pour pointer vers l'ALB que nous avons créé. Si vous utilisez Route 53 pour gérer les enregistrements DNS, vous pouvez référencer directement l'instance ALB en activant « Alias » et en sélectionnant l'ALB ; sinon, si vous utilisez un fournisseur DNS externe, vous devez pointer l'enregistrement A vers l'adresse IP publique de l'instance ALB.
Je recommande d'utiliser un outil tel que Postman pour tester que tout a été correctement configuré avant d'activer votre Bird webhook. Vous pouvez effectuer une requête POST vers votre point de terminaison et confirmer qu'une réponse est reçue. Si votre requête POST ne renvoie pas de réponse, vous devrez peut-être vérifier que votre ALB écoute le bon port.
Pour nous faciliter l'utilisation de notre ALB en tant que point de terminaison, nous allons créer un enregistrement A dans le DNS qui pointe vers notre ALB. Pour cela, nous pouvons utiliser le service AWS Route 53 (ou votre fournisseur DNS actuel) et créer un enregistrement A pour le nom d'hôte que vous souhaitez utiliser pour votre point de terminaison (par exemple, spevents.<votre_domaine>). Lorsque vous travaillez avec le DNS à grande échelle sur AWS, soyez conscient qu'il existe des limites DNS non documentées qui peuvent affecter les applications à fort volume, en particulier celles traitant de grandes quantités de trafic sortant comme les systèmes de livraison de courriels. L'enregistrement A doit être configuré pour pointer vers l'ALB que nous avons créé. Si vous utilisez Route 53 pour gérer les enregistrements DNS, vous pouvez référencer directement l'instance ALB en activant « Alias » et en sélectionnant l'ALB ; sinon, si vous utilisez un fournisseur DNS externe, vous devez pointer l'enregistrement A vers l'adresse IP publique de l'instance ALB.
Je recommande d'utiliser un outil tel que Postman pour tester que tout a été correctement configuré avant d'activer votre Bird webhook. Vous pouvez effectuer une requête POST vers votre point de terminaison et confirmer qu'une réponse est reçue. Si votre requête POST ne renvoie pas de réponse, vous devrez peut-être vérifier que votre ALB écoute le bon port.
Pour nous faciliter l'utilisation de notre ALB en tant que point de terminaison, nous allons créer un enregistrement A dans le DNS qui pointe vers notre ALB. Pour cela, nous pouvons utiliser le service AWS Route 53 (ou votre fournisseur DNS actuel) et créer un enregistrement A pour le nom d'hôte que vous souhaitez utiliser pour votre point de terminaison (par exemple, spevents.<votre_domaine>). Lorsque vous travaillez avec le DNS à grande échelle sur AWS, soyez conscient qu'il existe des limites DNS non documentées qui peuvent affecter les applications à fort volume, en particulier celles traitant de grandes quantités de trafic sortant comme les systèmes de livraison de courriels. L'enregistrement A doit être configuré pour pointer vers l'ALB que nous avons créé. Si vous utilisez Route 53 pour gérer les enregistrements DNS, vous pouvez référencer directement l'instance ALB en activant « Alias » et en sélectionnant l'ALB ; sinon, si vous utilisez un fournisseur DNS externe, vous devez pointer l'enregistrement A vers l'adresse IP publique de l'instance ALB.
Je recommande d'utiliser un outil tel que Postman pour tester que tout a été correctement configuré avant d'activer votre Bird webhook. Vous pouvez effectuer une requête POST vers votre point de terminaison et confirmer qu'une réponse est reçue. Si votre requête POST ne renvoie pas de réponse, vous devrez peut-être vérifier que votre ALB écoute le bon port.
Créer un Bird Webhook
Nous sommes maintenant prêts à créer le webhook dans Bird et à utiliser le nom d'hôte défini par l'enregistrement A ci-dessus comme notre point de terminaison cible. Pour créer le webhook, accédez à la section Webhooks de votre compte Bird et cliquez sur « Créer un webhook. » Vous serez invité à attribuer un nom à votre webhook et à fournir une URL cible – la cible doit être le nom d'hôte de l'enregistrement A que vous avez créé précédemment. Notez que l'URL cible peut nécessiter l'inclusion de « HTTPS:// » dans l'URL.
Une fois terminé, vérifiez que le bon sous-compte et les événements sont sélectionnés, puis appuyez sur « Créer un webhook » pour enregistrer votre configuration. Les données d'événement pour tous les types d'événements sélectionnés sont désormais transmises à notre URL cible et consommées par notre ALB pour un traitement en aval.
Nous sommes maintenant prêts à créer le webhook dans Bird et à utiliser le nom d'hôte défini par l'enregistrement A ci-dessus comme notre point de terminaison cible. Pour créer le webhook, accédez à la section Webhooks de votre compte Bird et cliquez sur « Créer un webhook. » Vous serez invité à attribuer un nom à votre webhook et à fournir une URL cible – la cible doit être le nom d'hôte de l'enregistrement A que vous avez créé précédemment. Notez que l'URL cible peut nécessiter l'inclusion de « HTTPS:// » dans l'URL.
Une fois terminé, vérifiez que le bon sous-compte et les événements sont sélectionnés, puis appuyez sur « Créer un webhook » pour enregistrer votre configuration. Les données d'événement pour tous les types d'événements sélectionnés sont désormais transmises à notre URL cible et consommées par notre ALB pour un traitement en aval.
Nous sommes maintenant prêts à créer le webhook dans Bird et à utiliser le nom d'hôte défini par l'enregistrement A ci-dessus comme notre point de terminaison cible. Pour créer le webhook, accédez à la section Webhooks de votre compte Bird et cliquez sur « Créer un webhook. » Vous serez invité à attribuer un nom à votre webhook et à fournir une URL cible – la cible doit être le nom d'hôte de l'enregistrement A que vous avez créé précédemment. Notez que l'URL cible peut nécessiter l'inclusion de « HTTPS:// » dans l'URL.
Une fois terminé, vérifiez que le bon sous-compte et les événements sont sélectionnés, puis appuyez sur « Créer un webhook » pour enregistrer votre configuration. Les données d'événement pour tous les types d'événements sélectionnés sont désormais transmises à notre URL cible et consommées par notre ALB pour un traitement en aval.
Configurer un Lambda pour s'exécuter lorsque de nouvelles données sont stockées sur S3
Maintenant que notre fonction lambda pour convertir le fichier du format JSON au format CSV a été créée, nous devons la configurer pour qu'elle se déclenche lorsqu'un nouveau fichier est créé sur notre bucket S3. Pour ce faire, nous devons ajouter un déclencheur à notre fonction lambda en ouvrant notre fonction lambda et en cliquant sur « Ajouter un déclencheur » en haut de la page. Sélectionnez « S3 » et fournissez le nom du bucket S3 où les charges utiles de webhook brutes sont stockées. Vous avez également la possibilité de spécifier un préfixe et/ou un suffixe de fichier pour filtrer. Une fois les paramètres configurés, vous pouvez ajouter le déclencheur en cliquant sur « Ajouter » en bas de la page. Maintenant, votre fonction lambda de traitement s'exécutera chaque fois qu'un nouveau fichier sera ajouté à votre bucket S3.
Maintenant que notre fonction lambda pour convertir le fichier du format JSON au format CSV a été créée, nous devons la configurer pour qu'elle se déclenche lorsqu'un nouveau fichier est créé sur notre bucket S3. Pour ce faire, nous devons ajouter un déclencheur à notre fonction lambda en ouvrant notre fonction lambda et en cliquant sur « Ajouter un déclencheur » en haut de la page. Sélectionnez « S3 » et fournissez le nom du bucket S3 où les charges utiles de webhook brutes sont stockées. Vous avez également la possibilité de spécifier un préfixe et/ou un suffixe de fichier pour filtrer. Une fois les paramètres configurés, vous pouvez ajouter le déclencheur en cliquant sur « Ajouter » en bas de la page. Maintenant, votre fonction lambda de traitement s'exécutera chaque fois qu'un nouveau fichier sera ajouté à votre bucket S3.
Maintenant que notre fonction lambda pour convertir le fichier du format JSON au format CSV a été créée, nous devons la configurer pour qu'elle se déclenche lorsqu'un nouveau fichier est créé sur notre bucket S3. Pour ce faire, nous devons ajouter un déclencheur à notre fonction lambda en ouvrant notre fonction lambda et en cliquant sur « Ajouter un déclencheur » en haut de la page. Sélectionnez « S3 » et fournissez le nom du bucket S3 où les charges utiles de webhook brutes sont stockées. Vous avez également la possibilité de spécifier un préfixe et/ou un suffixe de fichier pour filtrer. Une fois les paramètres configurés, vous pouvez ajouter le déclencheur en cliquant sur « Ajouter » en bas de la page. Maintenant, votre fonction lambda de traitement s'exécutera chaque fois qu'un nouveau fichier sera ajouté à votre bucket S3.
Chargement des données dans une base de données
Dans cet exemple, je ne couvrirai pas en détail le chargement des données dans une base de données, mais si vous avez suivi cet exemple, vous avez quelques options :
Chargez les données directement dans votre base de données au sein de votre fonction lambda de traitement
Consommez votre fichier CSV en utilisant un processus ETL établi
Que vous utilisiez un service de base de données AWS, tel que RDS ou DynamoDB, ou que vous ayez votre propre base de données PostgreSQL (ou similaire), vous pouvez vous connecter à votre service de base de données directement à partir de votre fonction lambda de processus. Par exemple, de la même manière que nous avons appelé le service S3 en utilisant "boto3" dans notre fonction lambda, vous pourriez également utiliser "boto3" pour appeler RDS ou DynamoDB. Le service AWS Athena pourrait également être utilisé pour lire les fichiers de données directement à partir des fichiers plats et accéder aux données en utilisant un langage de requête similaire à SQL. Je recommande de consulter la documentation respective du service que vous utilisez pour plus d'informations sur la meilleure façon de réaliser cela dans votre environnement.
De même, il existe de nombreux services disponibles qui peuvent aider à consommer des fichiers CSV et à charger les données dans une base de données. Vous avez peut-être déjà un processus ETL établi que vous pouvez exploiter.
Nous espérons que vous avez trouvé ce guide utile – bon envoi !
Dans cet exemple, je ne couvrirai pas en détail le chargement des données dans une base de données, mais si vous avez suivi cet exemple, vous avez quelques options :
Chargez les données directement dans votre base de données au sein de votre fonction lambda de traitement
Consommez votre fichier CSV en utilisant un processus ETL établi
Que vous utilisiez un service de base de données AWS, tel que RDS ou DynamoDB, ou que vous ayez votre propre base de données PostgreSQL (ou similaire), vous pouvez vous connecter à votre service de base de données directement à partir de votre fonction lambda de processus. Par exemple, de la même manière que nous avons appelé le service S3 en utilisant "boto3" dans notre fonction lambda, vous pourriez également utiliser "boto3" pour appeler RDS ou DynamoDB. Le service AWS Athena pourrait également être utilisé pour lire les fichiers de données directement à partir des fichiers plats et accéder aux données en utilisant un langage de requête similaire à SQL. Je recommande de consulter la documentation respective du service que vous utilisez pour plus d'informations sur la meilleure façon de réaliser cela dans votre environnement.
De même, il existe de nombreux services disponibles qui peuvent aider à consommer des fichiers CSV et à charger les données dans une base de données. Vous avez peut-être déjà un processus ETL établi que vous pouvez exploiter.
Nous espérons que vous avez trouvé ce guide utile – bon envoi !
Dans cet exemple, je ne couvrirai pas en détail le chargement des données dans une base de données, mais si vous avez suivi cet exemple, vous avez quelques options :
Chargez les données directement dans votre base de données au sein de votre fonction lambda de traitement
Consommez votre fichier CSV en utilisant un processus ETL établi
Que vous utilisiez un service de base de données AWS, tel que RDS ou DynamoDB, ou que vous ayez votre propre base de données PostgreSQL (ou similaire), vous pouvez vous connecter à votre service de base de données directement à partir de votre fonction lambda de processus. Par exemple, de la même manière que nous avons appelé le service S3 en utilisant "boto3" dans notre fonction lambda, vous pourriez également utiliser "boto3" pour appeler RDS ou DynamoDB. Le service AWS Athena pourrait également être utilisé pour lire les fichiers de données directement à partir des fichiers plats et accéder aux données en utilisant un langage de requête similaire à SQL. Je recommande de consulter la documentation respective du service que vous utilisez pour plus d'informations sur la meilleure façon de réaliser cela dans votre environnement.
De même, il existe de nombreux services disponibles qui peuvent aider à consommer des fichiers CSV et à charger les données dans une base de données. Vous avez peut-être déjà un processus ETL établi que vous pouvez exploiter.
Nous espérons que vous avez trouvé ce guide utile – bon envoi !
