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.
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.
Configuration du point de terminaison Webhook Target
Lorsqu'un événement Bird est créé, nous souhaitons que les données de cet événement soient diffusées en temps réel vers un point de terminaison dans AWS afin que nous puissions consommer et utiliser ces données de manière programmatique. Les données seront envoyées de Bird à un point de terminaison cible, qui transmettra la charge utile à une fonction lambda qui traitera et stockera les données dans un compartiment S3. Un schéma de haut niveau du flux de données décrit peut être vu ci-dessous :
Composant | Responsabilité |
|---|---|
Bird Webhooks | Émettre des lots d'événements en temps réel sous forme de requêtes HTTP POST |
Application Load Balancer | Recevoir le trafic des webhooks externes et acheminer les requêtes |
Lambda (Consumer) | Conserver efficacement les lots de webhooks bruts dans S3 |
Amazon S3 | Stocker les charges utiles des événements en lots sous forme de fichiers JSON plats |
Lambda (Processor) | Transformer ou charger les données stockées de manière asynchrone |
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énements et ensuite travailler à rebours - en ajoutant chaque composant qui alimente ce que nous avons construit.
Lorsqu'un événement Bird est créé, nous souhaitons que les données de cet événement soient diffusées en temps réel vers un point de terminaison dans AWS afin que nous puissions consommer et utiliser ces données de manière programmatique. Les données seront envoyées de Bird à un point de terminaison cible, qui transmettra la charge utile à une fonction lambda qui traitera et stockera les données dans un compartiment S3. Un schéma de haut niveau du flux de données décrit peut être vu ci-dessous :
Composant | Responsabilité |
|---|---|
Bird Webhooks | Émettre des lots d'événements en temps réel sous forme de requêtes HTTP POST |
Application Load Balancer | Recevoir le trafic des webhooks externes et acheminer les requêtes |
Lambda (Consumer) | Conserver efficacement les lots de webhooks bruts dans S3 |
Amazon S3 | Stocker les charges utiles des événements en lots sous forme de fichiers JSON plats |
Lambda (Processor) | Transformer ou charger les données stockées de manière asynchrone |
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énements et ensuite travailler à rebours - en ajoutant chaque composant qui alimente ce que nous avons construit.
Lorsqu'un événement Bird est créé, nous souhaitons que les données de cet événement soient diffusées en temps réel vers un point de terminaison dans AWS afin que nous puissions consommer et utiliser ces données de manière programmatique. Les données seront envoyées de Bird à un point de terminaison cible, qui transmettra la charge utile à une fonction lambda qui traitera et stockera les données dans un compartiment S3. Un schéma de haut niveau du flux de données décrit peut être vu ci-dessous :
Composant | Responsabilité |
|---|---|
Bird Webhooks | Émettre des lots d'événements en temps réel sous forme de requêtes HTTP POST |
Application Load Balancer | Recevoir le trafic des webhooks externes et acheminer les requêtes |
Lambda (Consumer) | Conserver efficacement les lots de webhooks bruts dans S3 |
Amazon S3 | Stocker les charges utiles des événements en lots sous forme de fichiers JSON plats |
Lambda (Processor) | Transformer ou charger les données stockées de manière asynchrone |
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énements et ensuite travailler à rebours - en ajoutant chaque composant qui alimente ce que nous avons construit.
Créer un S3 Bucket pour stocker les données Webhook
Avant de créer notre load balancer 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. Alors 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 des é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 au sein d'AWS et appuyez sur « Create Bucket ». Il vous sera demandé d'attribuer un nom à votre bucket et de définir la région – assurez-vous d'utiliser la même région que votre ALB et votre fonction lambda. Lorsque votre bucket S3 est 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 voulu 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 load balancer 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. Alors 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 des é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 au sein d'AWS et appuyez sur « Create Bucket ». Il vous sera demandé d'attribuer un nom à votre bucket et de définir la région – assurez-vous d'utiliser la même région que votre ALB et votre fonction lambda. Lorsque votre bucket S3 est 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 voulu 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 load balancer 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. Alors 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 des é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 au sein d'AWS et appuyez sur « Create Bucket ». Il vous sera demandé d'attribuer un nom à votre bucket et de définir la région – assurez-vous d'utiliser la même région que votre ALB et votre fonction lambda. Lorsque votre bucket S3 est 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 voulu 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 Lambda Function 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 naviguant vers le service Lambda dans AWS et en cliquant sur “Create Function.” Vous serez invité à attribuer un nom à votre fonction lambda et à choisir dans quel langage de programmation écrire votre fonction. Pour cet exemple, nous utilisons Python comme langage d'exécution.
Nous devons maintenant développer notre fonction lambda. Supposons un instant que notre équilibreur de charge d'application a été configuré et qu'il transmet la charge utile du webhook à notre fonction lambda – la lambda recevra une charge utile comprenant les en-têtes et le corps complets. La charge utile est transmise à notre fonction lambda en utilisant l'objet “event” en tant que dictionnaire. Vous pouvez référencer les en-têtes et le corps de la charge utile indépendamment en accédant aux objets “headers” et “body” dans la charge utile. 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 du stockage du corps en tant que fichier plat dans S3 ; cependant, vous souhaiterez peut-être ajouter des fonctionnalités supplémentaires comme des vérifications d'authentification ou une gestion des erreurs, selon les besoins.
Lors du stockage de la charge utile dans un fichier plat sur S3, nous devrons définir le nom du compartiment S3, l'emplacement et le nom du fichier où les données de la charge utile seront stockées. Dans notre exemple de fonction lambda, nous faisons cela dans la fonction “store_batch”. Dans cet exemple, nous allons stocker l'ensemble du lot en un seul fichier, ce qui aide à s'assurer que les données sont collectées et stockées avant que la connexion HTTP entre Bird et votre point de terminaison n'expire. Bien que vous puissiez ajuster les paramètres d'expiration de la connexion sur votre équilibreur de charge, il n'y a aucune garantie que la connexion ne s'arrêtera pas du côté de la transmission (dans ce cas Bird) ou que la connexion ne sera pas terminée avant que votre fonction lambda ne termine son exécution. Il est recommandé de garder votre fonction consommateur aussi efficace que possible et de réserver les activités de traitement des données pour les processus en aval si possible - comme convertir la charge utile formatée en JSON en fichier CSV, ou charger les données de l'événement dans une base de données.
Il est important de noter que vous devrez peut-être mettre à jour les autorisations de votre fonction lambda. Votre rôle d'exécution devra avoir des autorisations PutObject et GetObject pour S3. Il est conseillé d'appliquer le principe de moindre privilège, je recommande donc de définir ces autorisations uniquement pour le compartiment S3 où les charges utiles du webhook seront stockées.
Un échantillon de notre fonction lambda consommateur peut être trouvé ici.
Un mot rapide sur l'ID de lot : Bird regroupera les événements dans une seule charge utile, où chaque lot peut contenir de 1 à 350 enregistrements d'événements ou plus. Le lot recevra un ID de lot unique, qui peut être utilisé pour voir l'état du lot en utilisant l'API Event Webhooks ou dans votre compte Bird en cliquant sur un flux de webhook et en sélectionnant “Batch Status.” Dans le cas où une charge utile de webhook ne pourrait pas être livrée, par exemple, lors d'un délai d'expiration de connexion, Bird tentera automatiquement de relancer le lot en utilisant le même ID de lot. Cela peut se produire lorsque votre fonction lambda fonctionne proche du temps maximum de l'aller-retour de 10 secondes et est une raison pour optimiser la fonction consommateur afin de 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éé dans le compartiment S3 – de cette façon, le traitement des données est effectué de manière asynchrone à la transmission des données, et il n'y a aucun risque de perdre des données en raison d'une connexion terminée. Je discute de la fonction de traitement lambda 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 naviguant vers le service Lambda dans AWS et en cliquant sur “Create Function.” Vous serez invité à attribuer un nom à votre fonction lambda et à choisir dans quel langage de programmation écrire votre fonction. Pour cet exemple, nous utilisons Python comme langage d'exécution.
Nous devons maintenant développer notre fonction lambda. Supposons un instant que notre équilibreur de charge d'application a été configuré et qu'il transmet la charge utile du webhook à notre fonction lambda – la lambda recevra une charge utile comprenant les en-têtes et le corps complets. La charge utile est transmise à notre fonction lambda en utilisant l'objet “event” en tant que dictionnaire. Vous pouvez référencer les en-têtes et le corps de la charge utile indépendamment en accédant aux objets “headers” et “body” dans la charge utile. 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 du stockage du corps en tant que fichier plat dans S3 ; cependant, vous souhaiterez peut-être ajouter des fonctionnalités supplémentaires comme des vérifications d'authentification ou une gestion des erreurs, selon les besoins.
Lors du stockage de la charge utile dans un fichier plat sur S3, nous devrons définir le nom du compartiment S3, l'emplacement et le nom du fichier où les données de la charge utile seront stockées. Dans notre exemple de fonction lambda, nous faisons cela dans la fonction “store_batch”. Dans cet exemple, nous allons stocker l'ensemble du lot en un seul fichier, ce qui aide à s'assurer que les données sont collectées et stockées avant que la connexion HTTP entre Bird et votre point de terminaison n'expire. Bien que vous puissiez ajuster les paramètres d'expiration de la connexion sur votre équilibreur de charge, il n'y a aucune garantie que la connexion ne s'arrêtera pas du côté de la transmission (dans ce cas Bird) ou que la connexion ne sera pas terminée avant que votre fonction lambda ne termine son exécution. Il est recommandé de garder votre fonction consommateur aussi efficace que possible et de réserver les activités de traitement des données pour les processus en aval si possible - comme convertir la charge utile formatée en JSON en fichier CSV, ou charger les données de l'événement dans une base de données.
Il est important de noter que vous devrez peut-être mettre à jour les autorisations de votre fonction lambda. Votre rôle d'exécution devra avoir des autorisations PutObject et GetObject pour S3. Il est conseillé d'appliquer le principe de moindre privilège, je recommande donc de définir ces autorisations uniquement pour le compartiment S3 où les charges utiles du webhook seront stockées.
Un échantillon de notre fonction lambda consommateur peut être trouvé ici.
Un mot rapide sur l'ID de lot : Bird regroupera les événements dans une seule charge utile, où chaque lot peut contenir de 1 à 350 enregistrements d'événements ou plus. Le lot recevra un ID de lot unique, qui peut être utilisé pour voir l'état du lot en utilisant l'API Event Webhooks ou dans votre compte Bird en cliquant sur un flux de webhook et en sélectionnant “Batch Status.” Dans le cas où une charge utile de webhook ne pourrait pas être livrée, par exemple, lors d'un délai d'expiration de connexion, Bird tentera automatiquement de relancer le lot en utilisant le même ID de lot. Cela peut se produire lorsque votre fonction lambda fonctionne proche du temps maximum de l'aller-retour de 10 secondes et est une raison pour optimiser la fonction consommateur afin de 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éé dans le compartiment S3 – de cette façon, le traitement des données est effectué de manière asynchrone à la transmission des données, et il n'y a aucun risque de perdre des données en raison d'une connexion terminée. Je discute de la fonction de traitement lambda 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 naviguant vers le service Lambda dans AWS et en cliquant sur “Create Function.” Vous serez invité à attribuer un nom à votre fonction lambda et à choisir dans quel langage de programmation écrire votre fonction. Pour cet exemple, nous utilisons Python comme langage d'exécution.
Nous devons maintenant développer notre fonction lambda. Supposons un instant que notre équilibreur de charge d'application a été configuré et qu'il transmet la charge utile du webhook à notre fonction lambda – la lambda recevra une charge utile comprenant les en-têtes et le corps complets. La charge utile est transmise à notre fonction lambda en utilisant l'objet “event” en tant que dictionnaire. Vous pouvez référencer les en-têtes et le corps de la charge utile indépendamment en accédant aux objets “headers” et “body” dans la charge utile. 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 du stockage du corps en tant que fichier plat dans S3 ; cependant, vous souhaiterez peut-être ajouter des fonctionnalités supplémentaires comme des vérifications d'authentification ou une gestion des erreurs, selon les besoins.
Lors du stockage de la charge utile dans un fichier plat sur S3, nous devrons définir le nom du compartiment S3, l'emplacement et le nom du fichier où les données de la charge utile seront stockées. Dans notre exemple de fonction lambda, nous faisons cela dans la fonction “store_batch”. Dans cet exemple, nous allons stocker l'ensemble du lot en un seul fichier, ce qui aide à s'assurer que les données sont collectées et stockées avant que la connexion HTTP entre Bird et votre point de terminaison n'expire. Bien que vous puissiez ajuster les paramètres d'expiration de la connexion sur votre équilibreur de charge, il n'y a aucune garantie que la connexion ne s'arrêtera pas du côté de la transmission (dans ce cas Bird) ou que la connexion ne sera pas terminée avant que votre fonction lambda ne termine son exécution. Il est recommandé de garder votre fonction consommateur aussi efficace que possible et de réserver les activités de traitement des données pour les processus en aval si possible - comme convertir la charge utile formatée en JSON en fichier CSV, ou charger les données de l'événement dans une base de données.
Il est important de noter que vous devrez peut-être mettre à jour les autorisations de votre fonction lambda. Votre rôle d'exécution devra avoir des autorisations PutObject et GetObject pour S3. Il est conseillé d'appliquer le principe de moindre privilège, je recommande donc de définir ces autorisations uniquement pour le compartiment S3 où les charges utiles du webhook seront stockées.
Un échantillon de notre fonction lambda consommateur peut être trouvé ici.
Un mot rapide sur l'ID de lot : Bird regroupera les événements dans une seule charge utile, où chaque lot peut contenir de 1 à 350 enregistrements d'événements ou plus. Le lot recevra un ID de lot unique, qui peut être utilisé pour voir l'état du lot en utilisant l'API Event Webhooks ou dans votre compte Bird en cliquant sur un flux de webhook et en sélectionnant “Batch Status.” Dans le cas où une charge utile de webhook ne pourrait pas être livrée, par exemple, lors d'un délai d'expiration de connexion, Bird tentera automatiquement de relancer le lot en utilisant le même ID de lot. Cela peut se produire lorsque votre fonction lambda fonctionne proche du temps maximum de l'aller-retour de 10 secondes et est une raison pour optimiser la fonction consommateur afin de 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éé dans le compartiment S3 – de cette façon, le traitement des données est effectué de manière asynchrone à la transmission des données, et il n'y a aucun risque de perdre des données en raison d'une connexion terminée. Je discute de la fonction de traitement lambda 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 auquel envoyer les charges utiles. Nous le faisons en créant un équilibreur de charge d'application au sein d'AWS en naviguant vers EC2 > Load Balancers et en cliquant sur « Créer un Load Balancer ». Vous serez invité à choisir le type d'équilibreur de charge que vous souhaitez créer – pour cela, nous voulons créer un équilibreur de charge d'application. Nous devons utiliser un équilibreur de charge d'application (ALB) pour construire notre consommateur car les webhooks d'événements seront envoyés en tant que requête HTTP, et les ALB sont utilisés pour acheminer les requêtes HTTP au sein d'AWS. Nous pourrions mettre en œuvre une passerelle HTTP en tant qu'alternative; cependant, nous utilisons un ALB pour ce projet car il est plus léger et plus économique qu'une passerelle HTTP. Il est important de noter que si vous choisissez d'utiliser une passerelle HTTP, le format de l'événement peut être différent de celui d'un ALB, et donc votre fonction lambda devra traiter l'objet de la requête en conséquence.
Une fois que votre ALB a été 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 voudrons que notre ALB soit accessible depuis Internet. Sous « Auditeurs et routage », l'ALB doit écouter HTTPS sur le port 443, et nous voulons créer un groupe cible qui pointe vers notre fonction lambda afin que notre ALB transfère les requêtes entrantes à la fonction lambda de consommation que nous avons créée ci-dessus. Vous devez également vous assurer que le groupe de sécurité a la permission d'accepter le trafic via le port 443.
Pour recevoir une charge utile de webhook, nous devons fournir un point de terminaison auquel envoyer les charges utiles. Nous le faisons en créant un équilibreur de charge d'application au sein d'AWS en naviguant vers EC2 > Load Balancers et en cliquant sur « Créer un Load Balancer ». Vous serez invité à choisir le type d'équilibreur de charge que vous souhaitez créer – pour cela, nous voulons créer un équilibreur de charge d'application. Nous devons utiliser un équilibreur de charge d'application (ALB) pour construire notre consommateur car les webhooks d'événements seront envoyés en tant que requête HTTP, et les ALB sont utilisés pour acheminer les requêtes HTTP au sein d'AWS. Nous pourrions mettre en œuvre une passerelle HTTP en tant qu'alternative; cependant, nous utilisons un ALB pour ce projet car il est plus léger et plus économique qu'une passerelle HTTP. Il est important de noter que si vous choisissez d'utiliser une passerelle HTTP, le format de l'événement peut être différent de celui d'un ALB, et donc votre fonction lambda devra traiter l'objet de la requête en conséquence.
Une fois que votre ALB a été 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 voudrons que notre ALB soit accessible depuis Internet. Sous « Auditeurs et routage », l'ALB doit écouter HTTPS sur le port 443, et nous voulons créer un groupe cible qui pointe vers notre fonction lambda afin que notre ALB transfère les requêtes entrantes à la fonction lambda de consommation que nous avons créée ci-dessus. Vous devez également vous assurer que le groupe de sécurité a la permission d'accepter le trafic via le port 443.
Pour recevoir une charge utile de webhook, nous devons fournir un point de terminaison auquel envoyer les charges utiles. Nous le faisons en créant un équilibreur de charge d'application au sein d'AWS en naviguant vers EC2 > Load Balancers et en cliquant sur « Créer un Load Balancer ». Vous serez invité à choisir le type d'équilibreur de charge que vous souhaitez créer – pour cela, nous voulons créer un équilibreur de charge d'application. Nous devons utiliser un équilibreur de charge d'application (ALB) pour construire notre consommateur car les webhooks d'événements seront envoyés en tant que requête HTTP, et les ALB sont utilisés pour acheminer les requêtes HTTP au sein d'AWS. Nous pourrions mettre en œuvre une passerelle HTTP en tant qu'alternative; cependant, nous utilisons un ALB pour ce projet car il est plus léger et plus économique qu'une passerelle HTTP. Il est important de noter que si vous choisissez d'utiliser une passerelle HTTP, le format de l'événement peut être différent de celui d'un ALB, et donc votre fonction lambda devra traiter l'objet de la requête en conséquence.
Une fois que votre ALB a été 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 voudrons que notre ALB soit accessible depuis Internet. Sous « Auditeurs et routage », l'ALB doit écouter HTTPS sur le port 443, et nous voulons créer un groupe cible qui pointe vers notre fonction lambda afin que notre ALB transfère les requêtes entrantes à la fonction lambda de consommation que nous avons créée ci-dessus. Vous devez également vous assurer que le groupe de sécurité a la permission 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 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 à haut volume, en particulier celles qui gèrent de grandes quantités de trafic sortant comme les systèmes de livraison d'e-mails. 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 devriez pointer l'enregistrement A vers l'adresse IP publique de l'instance ALB.
Je recommande d'utiliser un outil tel que Postman pour vérifier que tout a été configuré correctement avant d'activer votre webhook Bird. Vous pouvez faire une requête POST à votre point de terminaison et confirmer qu'une réponse est reçue. Si votre requête POST ne retourne pas de réponse, vous devrez peut-être vérifier que votre ALB écoute sur 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 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 à haut volume, en particulier celles qui gèrent de grandes quantités de trafic sortant comme les systèmes de livraison d'e-mails. 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 devriez pointer l'enregistrement A vers l'adresse IP publique de l'instance ALB.
Je recommande d'utiliser un outil tel que Postman pour vérifier que tout a été configuré correctement avant d'activer votre webhook Bird. Vous pouvez faire une requête POST à votre point de terminaison et confirmer qu'une réponse est reçue. Si votre requête POST ne retourne pas de réponse, vous devrez peut-être vérifier que votre ALB écoute sur 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 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 à haut volume, en particulier celles qui gèrent de grandes quantités de trafic sortant comme les systèmes de livraison d'e-mails. 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 devriez pointer l'enregistrement A vers l'adresse IP publique de l'instance ALB.
Je recommande d'utiliser un outil tel que Postman pour vérifier que tout a été configuré correctement avant d'activer votre webhook Bird. Vous pouvez faire une requête POST à votre point de terminaison et confirmer qu'une réponse est reçue. Si votre requête POST ne retourne pas de réponse, vous devrez peut-être vérifier que votre ALB écoute sur 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 seront maintenant transmises à notre URL cible et consommées par notre ALB pour le 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 seront maintenant transmises à notre URL cible et consommées par notre ALB pour le 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 seront maintenant transmises à notre URL cible et consommées par notre ALB pour le traitement en aval.
Traitement des données d'événement Webhook
Selon le but visé pour le stockage des données d'événement Bird, vos besoins peuvent être satisfaits en stockant simplement la charge utile JSON comme un fichier plat. Vous pouvez également avoir un processus ETL en aval déjà établi, capable de consommer et de charger des données au format JSON. Dans ces deux cas, vous pouvez utiliser le fichier plat créé par notre lambda de traitement que nous avons créé ci-dessus tel quel.
Alternativement, vous pourriez avoir besoin de transformer les données – par exemple, pour convertir d'un format JSON à un format CSV – ou de charger les données directement dans une base de données. Dans cet exemple, nous créerons une fonction lambda simple qui convertira les données du webhook du format JSON original en un fichier CSV qui pourrait être chargé dans une base de données.
Selon le but visé pour le stockage des données d'événement Bird, vos besoins peuvent être satisfaits en stockant simplement la charge utile JSON comme un fichier plat. Vous pouvez également avoir un processus ETL en aval déjà établi, capable de consommer et de charger des données au format JSON. Dans ces deux cas, vous pouvez utiliser le fichier plat créé par notre lambda de traitement que nous avons créé ci-dessus tel quel.
Alternativement, vous pourriez avoir besoin de transformer les données – par exemple, pour convertir d'un format JSON à un format CSV – ou de charger les données directement dans une base de données. Dans cet exemple, nous créerons une fonction lambda simple qui convertira les données du webhook du format JSON original en un fichier CSV qui pourrait être chargé dans une base de données.
Selon le but visé pour le stockage des données d'événement Bird, vos besoins peuvent être satisfaits en stockant simplement la charge utile JSON comme un fichier plat. Vous pouvez également avoir un processus ETL en aval déjà établi, capable de consommer et de charger des données au format JSON. Dans ces deux cas, vous pouvez utiliser le fichier plat créé par notre lambda de traitement que nous avons créé ci-dessus tel quel.
Alternativement, vous pourriez avoir besoin de transformer les données – par exemple, pour convertir d'un format JSON à un format CSV – ou de charger les données directement dans une base de données. Dans cet exemple, nous créerons une fonction lambda simple qui convertira les données du webhook du format JSON original en un fichier CSV qui pourrait être chargé dans une base de données.
Créez un Lambda pour traiter les données
Comme avec la fonction lambda pour consommer les données du webhook, nous devons créer une nouvelle fonction lambda en naviguant vers le service Lambda au sein de AWS et en appuyant sur « Créer une fonction ». Cette nouvelle fonction lambda sera déclenchée lorsqu'un nouveau fichier sera créé dans notre bucket S3 – elle lira les données et les convertira en un nouveau fichier CSV.
La fonction lambda accepte les informations de fichier comme un événement. Dans l'exemple de fonction lambda, vous verrez que nous avons d'abord une série de contrôles de validation pour garantir que les données sont complètes et formatées comme attendu. Ensuite, nous convertissons la charge utile JSON en un fichier CSV en utilisant la bibliothèque « csv » et en écrivant dans un fichier temporaire. Les fonctions lambda peuvent seulement écrire des fichiers locaux dans le répertoire « /tmp », nous créons donc un fichier CSV temporaire et le nommons selon la convention <batch_id>.csv. La raison pour laquelle nous utilisons le batch_id ici est simplement pour garantir que tous les processus parallèles exécutés en raison de la réception de multiples charges utiles du webhook ne se gênent pas entre eux, car chaque lot de webhook aura un batch_id unique.
Une fois que les données ont été entièrement converties en CSV, nous lisons les données CSV sous forme de flux d'octets, supprimons le fichier temporaire et enregistrons les données CSV sous forme de nouveau fichier sur S3. Il est important de noter qu'un autre bucket S3 est nécessaire pour la sortie, sinon, nous risquons de créer une boucle récursive qui peut entraîner une utilisation accrue de lambda et des coûts accrus. Nous devrons identifier dans quel bucket et emplacement S3 nous voulons que notre fichier CSV soit stocké dans notre fonction lambda. Suivez la même procédure que ci-dessus pour créer un nouveau bucket S3 pour stocker notre fichier CSV.
Notez que le répertoire tmp est limité à 512 Mo d'espace, il est donc important que le fichier temporaire soit supprimé par la suite pour garantir un espace suffisant pour les exécutions futures. La raison pour laquelle nous utilisons un fichier temporaire, au lieu d'écrire directement sur S3, est de simplifier la connexion à S3 en ayant une seule requête.
Tout comme avec la fonction lambda pour consommer, vous devrez peut-être mettre à jour les autorisations pour votre fonction lambda de traitement. Cette fonction lambda nécessite que le rôle d'exécution possède les permissions GetObject pour le bucket S3 d'entrée, et à la fois PutObject et GetObject pour le bucket S3 de sortie.
Un exemple de notre fonction lambda de traitement peut être trouvé ici.
Comme avec la fonction lambda pour consommer les données du webhook, nous devons créer une nouvelle fonction lambda en naviguant vers le service Lambda au sein de AWS et en appuyant sur « Créer une fonction ». Cette nouvelle fonction lambda sera déclenchée lorsqu'un nouveau fichier sera créé dans notre bucket S3 – elle lira les données et les convertira en un nouveau fichier CSV.
La fonction lambda accepte les informations de fichier comme un événement. Dans l'exemple de fonction lambda, vous verrez que nous avons d'abord une série de contrôles de validation pour garantir que les données sont complètes et formatées comme attendu. Ensuite, nous convertissons la charge utile JSON en un fichier CSV en utilisant la bibliothèque « csv » et en écrivant dans un fichier temporaire. Les fonctions lambda peuvent seulement écrire des fichiers locaux dans le répertoire « /tmp », nous créons donc un fichier CSV temporaire et le nommons selon la convention <batch_id>.csv. La raison pour laquelle nous utilisons le batch_id ici est simplement pour garantir que tous les processus parallèles exécutés en raison de la réception de multiples charges utiles du webhook ne se gênent pas entre eux, car chaque lot de webhook aura un batch_id unique.
Une fois que les données ont été entièrement converties en CSV, nous lisons les données CSV sous forme de flux d'octets, supprimons le fichier temporaire et enregistrons les données CSV sous forme de nouveau fichier sur S3. Il est important de noter qu'un autre bucket S3 est nécessaire pour la sortie, sinon, nous risquons de créer une boucle récursive qui peut entraîner une utilisation accrue de lambda et des coûts accrus. Nous devrons identifier dans quel bucket et emplacement S3 nous voulons que notre fichier CSV soit stocké dans notre fonction lambda. Suivez la même procédure que ci-dessus pour créer un nouveau bucket S3 pour stocker notre fichier CSV.
Notez que le répertoire tmp est limité à 512 Mo d'espace, il est donc important que le fichier temporaire soit supprimé par la suite pour garantir un espace suffisant pour les exécutions futures. La raison pour laquelle nous utilisons un fichier temporaire, au lieu d'écrire directement sur S3, est de simplifier la connexion à S3 en ayant une seule requête.
Tout comme avec la fonction lambda pour consommer, vous devrez peut-être mettre à jour les autorisations pour votre fonction lambda de traitement. Cette fonction lambda nécessite que le rôle d'exécution possède les permissions GetObject pour le bucket S3 d'entrée, et à la fois PutObject et GetObject pour le bucket S3 de sortie.
Un exemple de notre fonction lambda de traitement peut être trouvé ici.
Comme avec la fonction lambda pour consommer les données du webhook, nous devons créer une nouvelle fonction lambda en naviguant vers le service Lambda au sein de AWS et en appuyant sur « Créer une fonction ». Cette nouvelle fonction lambda sera déclenchée lorsqu'un nouveau fichier sera créé dans notre bucket S3 – elle lira les données et les convertira en un nouveau fichier CSV.
La fonction lambda accepte les informations de fichier comme un événement. Dans l'exemple de fonction lambda, vous verrez que nous avons d'abord une série de contrôles de validation pour garantir que les données sont complètes et formatées comme attendu. Ensuite, nous convertissons la charge utile JSON en un fichier CSV en utilisant la bibliothèque « csv » et en écrivant dans un fichier temporaire. Les fonctions lambda peuvent seulement écrire des fichiers locaux dans le répertoire « /tmp », nous créons donc un fichier CSV temporaire et le nommons selon la convention <batch_id>.csv. La raison pour laquelle nous utilisons le batch_id ici est simplement pour garantir que tous les processus parallèles exécutés en raison de la réception de multiples charges utiles du webhook ne se gênent pas entre eux, car chaque lot de webhook aura un batch_id unique.
Une fois que les données ont été entièrement converties en CSV, nous lisons les données CSV sous forme de flux d'octets, supprimons le fichier temporaire et enregistrons les données CSV sous forme de nouveau fichier sur S3. Il est important de noter qu'un autre bucket S3 est nécessaire pour la sortie, sinon, nous risquons de créer une boucle récursive qui peut entraîner une utilisation accrue de lambda et des coûts accrus. Nous devrons identifier dans quel bucket et emplacement S3 nous voulons que notre fichier CSV soit stocké dans notre fonction lambda. Suivez la même procédure que ci-dessus pour créer un nouveau bucket S3 pour stocker notre fichier CSV.
Notez que le répertoire tmp est limité à 512 Mo d'espace, il est donc important que le fichier temporaire soit supprimé par la suite pour garantir un espace suffisant pour les exécutions futures. La raison pour laquelle nous utilisons un fichier temporaire, au lieu d'écrire directement sur S3, est de simplifier la connexion à S3 en ayant une seule requête.
Tout comme avec la fonction lambda pour consommer, vous devrez peut-être mettre à jour les autorisations pour votre fonction lambda de traitement. Cette fonction lambda nécessite que le rôle d'exécution possède les permissions GetObject pour le bucket S3 d'entrée, et à la fois PutObject et GetObject pour le bucket S3 de sortie.
Un exemple de notre fonction lambda de traitement peut être trouvé ici.
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 !
