Het maken en gebruiken van Bird-webhooks
Bird
27 jan 2022
1 min read
Belangrijkste punten
Bird’s real-time event webhooks laten zenders evenementgegevens direct ontvangen—geen polling, geen cron-jobs, en geen problemen met snelheidslimieten.
Webhooks elimineren de complexiteit van het beheren van tijdvensters, het voorkomen van gemiste evenementen en het omgaan met dubbele records.
Ideaal voor downstream automatisering: het bijwerken van lijsten, het starten van trajecten, het verrijken van dashboards, of het synchroniseren van interne systemen.
De tutorial begeleidt zenders door het bouwen van een volledige AWS-invoerpipeline: S3-opslag, Lambda-verwerking en een application load balancer.
S3 dient als de centrale opslaaglaag voor webhook-payloads, waarbij elke batch wordt geschreven als een platte JSON-bestand.
Lambda-functies behandelen zowel de invoer (het opslaan van ruwe batches) als de transformatie (het omzetten van JSON naar CSV).
Bird batcht evenementen—elke webhook-batch bevat een unieke
x-messagesystems-batch-id, die replay-checks en deduplicatie mogelijk maakt.De consumer Lambda moet efficiënt blijven aangezien Bird batches opnieuw probeert als het eindpunt niet binnen ~10 seconden reageert.
AWS ALB wordt aanbevolen (versus API Gateway) voor eenvoud, kostenefficiëntie en directe afhandeling van HTTP POST-verzoeken.
DNS (Route 53 of externe provider) is geconfigureerd om een vriendelijke hostnaam naar het ALB-eindpunt in kaart te brengen.
Na de installatie stuurt Bird evenementgegevens direct en betrouwbaar naar uw AWS-pipeline voor asynchrone verwerking.
De gids behandelt ook best practices: minst-privilege IAM-toestemmingen, tijdelijke opslagbeperkingen, het vermijden van recursieve triggers, en het organiseren van multi-lambda workflows.
Q&A Hoogtepunten
Wat is het hoofddoel van Bird’s real-time event webhooks?
Om gebeurtenisgegevens direct naar het endpoint van een verzender te sturen in real time, waardoor onmiddellijke automatisering mogelijk wordt zonder polling of API-oproepen met snelheidsbeperkingen.
Waarom zijn webhooks beter dan het ophalen van gegevens via API voor grote verzenders?
Omdat API-pulls tijdvensterbeheer vereisen, risico geven op datagaten of duplicaten, en mogelijk snelheidslimieten bereiken—elimineren webhooks dit allemaal door continu gegevens door te geven.
Welke AWS-services worden gebruikt in de aanbevolen webhook-ingestiepijplijn?
Amazon S3 (opslag), AWS Lambda (verwerking), een Application Load Balancer (HTTP-luisteraar), en optioneel Route 53 (DNS).
Hoe verwerkt Bird batch-gebeurtenisgegevens?
Bird stuurt meerdere gebeurtenissen samen in een payload, die elk een unieke batch-ID (x-messagesystems-batch-id) krijgen toegewezen voor tracking, herproberen en deduplicatie.
Wat triggert de consumer Lambda-functie?
De ALB stuurt inkomende webhook POST-verzoeken rechtstreeks door naar de Lambda, die de payload extraheert en naar S3 schrijft.
Waarom de raw webhook batch in S3 opslaan voordat deze wordt verwerkt?
Om snelle verwerking (<10 seconden) te garanderen, zodat de verbinding niet uitvalt, en om zwaardere verwerking naar een aparte asynchrone pijplijn te verplaatsen.
Wat doet de tweede Lambda-functie?
Het wordt geactiveerd door nieuwe S3-objecten, valideert de JSON, zet het om naar CSV en schrijft de verwerkte output naar een aparte S3-bucket.
Waarom een aparte S3 bucket gebruiken voor verwerkte CSV-bestanden?
Om recursieve triggers te voorkomen (het terugschrijven van een nieuw verwerkte bestand in dezelfde bucket zou de Lambda eindeloos opnieuw activeren).
Welke permissies hebben de Lambda-functies nodig?
De consument Lambda heeft S3 PutObject-rechten nodig; de verwerking Lambda heeft GetObject-rechten nodig voor de bronbucket en PutObject-rechten voor de bestemmingsbucket.
Waarom wordt een AWS ALB aanbevolen boven API Gateway?
ALBs zijn goedkoper, eenvoudiger en ideaal voor eenvoudige HTTPS POST-doorsturing; API Gateway kan het payload-formaat wijzigen en de complexiteit verhogen.
Hoe configureren verzenders de webhook in Bird?
Door het opgeven van het HTTPS-eindpunt (het DNS-record voor de ALB), het selecteren van een subaccount, het kiezen van evenementen en het opslaan van de webhook-configuratie.
Welke downstream-opties bestaan er voor het opslaan of analyseren van de verwerkte data?
Laad in databases (PostgreSQL, DynamoDB, RDS), voed ETL-systemen, of query direct met tools zoals Athena.
Bird’s real-time event webhooks zijn een ongelooflijk waardevol hulpmiddel voor verzenders om gegevens automatisch naar hun systemen te laten pushen. Dit kan downstream-automatisering aandrijven, zoals het bijwerken van mailinglijsten, het activeren van geautomatiseerde e-mailreizen of het vullen van interne dashboards. Hoewel dezelfde gebeurtenisgegevens toegankelijk zijn via de Bird UI met Event Search of programmeerbaar door gebruik te maken van de Bird Events API, kunnen beperkingen op het aantal records dat in één verzoek wordt geretourneerd of snelheidslimieten op het API-eindpunt beide methoden restrictief maken voor grote en geavanceerde verzenders.
Real-time event webhooks stellen een verzender in staat om een eindpunt te configureren waar Bird de gegevens naar verzendt, en de gegevens kunnen worden verwerkt zonder cron-jobs in te plannen die de gegevens ophalen. Er zijn ook logistieke afwegingen bij het ophalen van de gegevens in plaats van deze naar u te laten pushen, zoals het identificeren van welke tijdsperiode en parameters voor elk API-verzoek moeten worden gebruikt. Als de tijdsperioden niet perfect zijn uitgelijnd, riskeert u gegevens te missen, en als de tijdsperioden overlappen, moet u dubbele gegevensrecords verwerken. Met real-time webhooks worden gegevens van gebeurtenissen eenvoudig naar uw eindpunt gepusht zodra deze binnen Bird beschikbaar komen.
Hoewel de voordelen van het ontvangen van gebeurtenisgegevens in real-time om downstream-automatiseringsprocessen aan te drijven voor veel verzenders onmiddellijk begrijpelijk kunnen zijn, kan het daadwerkelijke proces voor het implementeren en verwerken van webhooks intimiderend zijn. Dit kan vooral gelden als u onbekend bent met de technische componenten voor het maken van een eindpunt en het programmatisch verwerken van de gegevens. Er zijn diensten beschikbaar die Bird-webhookgegevens verbruiken en automatisch ETL in uw database - een voorbeeld zou StitchData zijn, waarover we in het verleden hebben geblogd. Als u echter meer controle over het proces wilt, kunt u de componenten gemakkelijk zelf bouwen. Het volgende is een eenvoudige gids om verzenders op hun gemak te laten voelen bij het maken van een Bird events webhook en het verwerken van de gegevens met behulp van de infrastructuur binnen AWS.
Bird’s real-time event webhooks zijn een ongelooflijk waardevol hulpmiddel voor verzenders om gegevens automatisch naar hun systemen te laten pushen. Dit kan downstream-automatisering aandrijven, zoals het bijwerken van mailinglijsten, het activeren van geautomatiseerde e-mailreizen of het vullen van interne dashboards. Hoewel dezelfde gebeurtenisgegevens toegankelijk zijn via de Bird UI met Event Search of programmeerbaar door gebruik te maken van de Bird Events API, kunnen beperkingen op het aantal records dat in één verzoek wordt geretourneerd of snelheidslimieten op het API-eindpunt beide methoden restrictief maken voor grote en geavanceerde verzenders.
Real-time event webhooks stellen een verzender in staat om een eindpunt te configureren waar Bird de gegevens naar verzendt, en de gegevens kunnen worden verwerkt zonder cron-jobs in te plannen die de gegevens ophalen. Er zijn ook logistieke afwegingen bij het ophalen van de gegevens in plaats van deze naar u te laten pushen, zoals het identificeren van welke tijdsperiode en parameters voor elk API-verzoek moeten worden gebruikt. Als de tijdsperioden niet perfect zijn uitgelijnd, riskeert u gegevens te missen, en als de tijdsperioden overlappen, moet u dubbele gegevensrecords verwerken. Met real-time webhooks worden gegevens van gebeurtenissen eenvoudig naar uw eindpunt gepusht zodra deze binnen Bird beschikbaar komen.
Hoewel de voordelen van het ontvangen van gebeurtenisgegevens in real-time om downstream-automatiseringsprocessen aan te drijven voor veel verzenders onmiddellijk begrijpelijk kunnen zijn, kan het daadwerkelijke proces voor het implementeren en verwerken van webhooks intimiderend zijn. Dit kan vooral gelden als u onbekend bent met de technische componenten voor het maken van een eindpunt en het programmatisch verwerken van de gegevens. Er zijn diensten beschikbaar die Bird-webhookgegevens verbruiken en automatisch ETL in uw database - een voorbeeld zou StitchData zijn, waarover we in het verleden hebben geblogd. Als u echter meer controle over het proces wilt, kunt u de componenten gemakkelijk zelf bouwen. Het volgende is een eenvoudige gids om verzenders op hun gemak te laten voelen bij het maken van een Bird events webhook en het verwerken van de gegevens met behulp van de infrastructuur binnen AWS.
Bird’s real-time event webhooks zijn een ongelooflijk waardevol hulpmiddel voor verzenders om gegevens automatisch naar hun systemen te laten pushen. Dit kan downstream-automatisering aandrijven, zoals het bijwerken van mailinglijsten, het activeren van geautomatiseerde e-mailreizen of het vullen van interne dashboards. Hoewel dezelfde gebeurtenisgegevens toegankelijk zijn via de Bird UI met Event Search of programmeerbaar door gebruik te maken van de Bird Events API, kunnen beperkingen op het aantal records dat in één verzoek wordt geretourneerd of snelheidslimieten op het API-eindpunt beide methoden restrictief maken voor grote en geavanceerde verzenders.
Real-time event webhooks stellen een verzender in staat om een eindpunt te configureren waar Bird de gegevens naar verzendt, en de gegevens kunnen worden verwerkt zonder cron-jobs in te plannen die de gegevens ophalen. Er zijn ook logistieke afwegingen bij het ophalen van de gegevens in plaats van deze naar u te laten pushen, zoals het identificeren van welke tijdsperiode en parameters voor elk API-verzoek moeten worden gebruikt. Als de tijdsperioden niet perfect zijn uitgelijnd, riskeert u gegevens te missen, en als de tijdsperioden overlappen, moet u dubbele gegevensrecords verwerken. Met real-time webhooks worden gegevens van gebeurtenissen eenvoudig naar uw eindpunt gepusht zodra deze binnen Bird beschikbaar komen.
Hoewel de voordelen van het ontvangen van gebeurtenisgegevens in real-time om downstream-automatiseringsprocessen aan te drijven voor veel verzenders onmiddellijk begrijpelijk kunnen zijn, kan het daadwerkelijke proces voor het implementeren en verwerken van webhooks intimiderend zijn. Dit kan vooral gelden als u onbekend bent met de technische componenten voor het maken van een eindpunt en het programmatisch verwerken van de gegevens. Er zijn diensten beschikbaar die Bird-webhookgegevens verbruiken en automatisch ETL in uw database - een voorbeeld zou StitchData zijn, waarover we in het verleden hebben geblogd. Als u echter meer controle over het proces wilt, kunt u de componenten gemakkelijk zelf bouwen. Het volgende is een eenvoudige gids om verzenders op hun gemak te laten voelen bij het maken van een Bird events webhook en het verwerken van de gegevens met behulp van de infrastructuur binnen AWS.
Configureren van Webhook Target Endpoint
Wanneer een Bird evenement wordt aangemaakt, willen we dat de evenementgegevens in real-time naar een endpoint in AWS worden gestreamd zodat we deze gegevens programmatisch kunnen gebruiken. De gegevens zullen van Bird naar een doelendpoint worden verzonden, die de payload zal doorsturen naar een lambda-functie die de gegevens zal verwerken en opslaan in een S3-bucket. Een overzichtsdiagram van de beschreven gegevensstroom is hieronder te zien:
Component | Verantwoordelijkheid |
|---|---|
Bird Webhooks | Stuur real-time evenementbatches als HTTP POST-aanvragen |
Application Load Balancer | Ontvang externe webhook-verkeer en routeer aanvragen |
Lambda (Consumer) | Maak efficiënt ruwe webhook-batches persistent naar S3 |
Amazon S3 | Sla gebatchte evenementpayloads op als platte JSON-bestanden |
Lambda (Processor) | Transformeer of laad opgeslagen gegevens asynchroon |
Om deze workflow te implementeren, laten we ze daadwerkelijk in omgekeerde volgorde bouwen te beginnen met het maken van een S3-bucket waar we onze evenementgegevens zullen opslaan en vervolgens achteruit te werken - elke component toe te voegen die ons voedt wat we gebouwd hebben.
Wanneer een Bird evenement wordt aangemaakt, willen we dat de evenementgegevens in real-time naar een endpoint in AWS worden gestreamd zodat we deze gegevens programmatisch kunnen gebruiken. De gegevens zullen van Bird naar een doelendpoint worden verzonden, die de payload zal doorsturen naar een lambda-functie die de gegevens zal verwerken en opslaan in een S3-bucket. Een overzichtsdiagram van de beschreven gegevensstroom is hieronder te zien:
Component | Verantwoordelijkheid |
|---|---|
Bird Webhooks | Stuur real-time evenementbatches als HTTP POST-aanvragen |
Application Load Balancer | Ontvang externe webhook-verkeer en routeer aanvragen |
Lambda (Consumer) | Maak efficiënt ruwe webhook-batches persistent naar S3 |
Amazon S3 | Sla gebatchte evenementpayloads op als platte JSON-bestanden |
Lambda (Processor) | Transformeer of laad opgeslagen gegevens asynchroon |
Om deze workflow te implementeren, laten we ze daadwerkelijk in omgekeerde volgorde bouwen te beginnen met het maken van een S3-bucket waar we onze evenementgegevens zullen opslaan en vervolgens achteruit te werken - elke component toe te voegen die ons voedt wat we gebouwd hebben.
Wanneer een Bird evenement wordt aangemaakt, willen we dat de evenementgegevens in real-time naar een endpoint in AWS worden gestreamd zodat we deze gegevens programmatisch kunnen gebruiken. De gegevens zullen van Bird naar een doelendpoint worden verzonden, die de payload zal doorsturen naar een lambda-functie die de gegevens zal verwerken en opslaan in een S3-bucket. Een overzichtsdiagram van de beschreven gegevensstroom is hieronder te zien:
Component | Verantwoordelijkheid |
|---|---|
Bird Webhooks | Stuur real-time evenementbatches als HTTP POST-aanvragen |
Application Load Balancer | Ontvang externe webhook-verkeer en routeer aanvragen |
Lambda (Consumer) | Maak efficiënt ruwe webhook-batches persistent naar S3 |
Amazon S3 | Sla gebatchte evenementpayloads op als platte JSON-bestanden |
Lambda (Processor) | Transformeer of laad opgeslagen gegevens asynchroon |
Om deze workflow te implementeren, laten we ze daadwerkelijk in omgekeerde volgorde bouwen te beginnen met het maken van een S3-bucket waar we onze evenementgegevens zullen opslaan en vervolgens achteruit te werken - elke component toe te voegen die ons voedt wat we gebouwd hebben.
Maak een S3 Bucket om de Webhook Data te bewaren
Voordat we onze load balancer maken om de data te accepteren, of onze lambda-functie om de data op te slaan, moeten we eerst onze S3-bucket maken waar de data zal worden opgeslagen. Terwijl S3 uitstekende opslag biedt voor webhookdata, moeten organisaties die ook PostgreSQL-databases gebruiken voor evenementenverwerking, juiste back-up- en herstelprocedures implementeren om hun gestructureerde data te beschermen naast hun S3-opslagstrategie. Om dit te doen, navigeert u naar de S3-service binnen AWS en drukt u op "Create Bucket". U wordt gevraagd om een naam aan uw bucket toe te wijzen en de regio in te stellen - zorg ervoor dat u dezelfde regio gebruikt als uw ALB en lambda-functie. Wanneer uw S3-bucket is aangemaakt, zal deze leeg zijn - als u de data in een map wilt organiseren, kunt u nu de beoogde directory maken, of de directory wordt aangemaakt wanneer uw lambda-functie het bestand opslaat. In dit voorbeeld noemden we onze S3-bucket "bird-webhooks" en creëerden we een map genaamd "B Event Data" om onze evenementdata op te slaan - u zult deze namen zien verwijzen in onze lambda-functie hieronder.
Voordat we onze load balancer maken om de data te accepteren, of onze lambda-functie om de data op te slaan, moeten we eerst onze S3-bucket maken waar de data zal worden opgeslagen. Terwijl S3 uitstekende opslag biedt voor webhookdata, moeten organisaties die ook PostgreSQL-databases gebruiken voor evenementenverwerking, juiste back-up- en herstelprocedures implementeren om hun gestructureerde data te beschermen naast hun S3-opslagstrategie. Om dit te doen, navigeert u naar de S3-service binnen AWS en drukt u op "Create Bucket". U wordt gevraagd om een naam aan uw bucket toe te wijzen en de regio in te stellen - zorg ervoor dat u dezelfde regio gebruikt als uw ALB en lambda-functie. Wanneer uw S3-bucket is aangemaakt, zal deze leeg zijn - als u de data in een map wilt organiseren, kunt u nu de beoogde directory maken, of de directory wordt aangemaakt wanneer uw lambda-functie het bestand opslaat. In dit voorbeeld noemden we onze S3-bucket "bird-webhooks" en creëerden we een map genaamd "B Event Data" om onze evenementdata op te slaan - u zult deze namen zien verwijzen in onze lambda-functie hieronder.
Voordat we onze load balancer maken om de data te accepteren, of onze lambda-functie om de data op te slaan, moeten we eerst onze S3-bucket maken waar de data zal worden opgeslagen. Terwijl S3 uitstekende opslag biedt voor webhookdata, moeten organisaties die ook PostgreSQL-databases gebruiken voor evenementenverwerking, juiste back-up- en herstelprocedures implementeren om hun gestructureerde data te beschermen naast hun S3-opslagstrategie. Om dit te doen, navigeert u naar de S3-service binnen AWS en drukt u op "Create Bucket". U wordt gevraagd om een naam aan uw bucket toe te wijzen en de regio in te stellen - zorg ervoor dat u dezelfde regio gebruikt als uw ALB en lambda-functie. Wanneer uw S3-bucket is aangemaakt, zal deze leeg zijn - als u de data in een map wilt organiseren, kunt u nu de beoogde directory maken, of de directory wordt aangemaakt wanneer uw lambda-functie het bestand opslaat. In dit voorbeeld noemden we onze S3-bucket "bird-webhooks" en creëerden we een map genaamd "B Event Data" om onze evenementdata op te slaan - u zult deze namen zien verwijzen in onze lambda-functie hieronder.
Creëer een Lambda Function om de Data te Verbruiken
De daadwerkelijke verwerking en opslag van de gegevens wordt uitgevoerd door een lambda-functie die wordt aangeroepen door onze application load balancer (ALB).
De eerste stap is om je lambda-functie te maken door naar de Lambda-service binnen AWS te navigeren en te klikken op “Create Function.” Je wordt gevraagd om een naam aan je lambda-functie toe te wijzen en de programmeertaal te selecteren waarin je je functie schrijft. Voor dit voorbeeld gebruiken we Python als de runtime-taal.
Nu moeten we onze lambda-functie ontwikkelen. Even aangenomen dat onze application load balancer is geconfigureerd en de webhook-payload doorstuurt naar onze lambda-functie – de lambda ontvangt een payload inclusief de volledige headers en body. De payload wordt doorgestuurd naar onze lambda-functie met behulp van het object “event” als een woordenboek. Je kunt de headers en de body van de payload onafhankelijk benaderen door de “headers” en “body” objecten binnen de payload te openen. In dit voorbeeld gaan we simpelweg de “x-messagesystems-batch-id” header lezen, waarbij de batch-ID een unieke waarde is die door Bird is gecreëerd voor de webhook-batch en deze gebruiken als de bestandsnaam bij het opslaan van de body als een flat-file in S3; echter, je wilt misschien aanvullende functionaliteit toevoegen zoals authenticatiecontroles of foutafhandeling, indien nodig.
Bij het opslaan van de payload naar een flat-file op S3, moeten we de naam van de S3-bucket, de locatie en de bestandsnaam van het bestand waarin de payloadgegevens worden opgeslagen, definiëren. In onze voorbeeld lambda-functie doen we dit binnen de “store_batch” functie. In dit voorbeeld gaan we de gehele batch als één bestand opslaan, wat helpt ervoor te zorgen dat de gegevens worden verzameld en opgeslagen voordat de HTTP-verbinding tussen Bird en je eindpunt verloopt. Hoewel je de verbindingstime-outinstellingen op je load balancer kunt aanpassen, zijn er geen garanties dat de verbinding niet zal verlopen aan de zendzijde (in dit geval Bird) of dat de verbinding niet zal worden beëindigd voordat je lambda-functie is voltooid. Het is een best practice om je consumer-functie zo efficiënt mogelijk te houden en gegevensverwerkingsactiviteiten te reserveren voor downstream-processen waar mogelijk – zoals het converteren van de gebatchte JSON-geformatteerde payload naar een CSV-bestand of het laden van de gebeurtenisgegegevens in een database.
Het is belangrijk op te merken dat je mogelijk de permissies voor je lambda-functie moet bijwerken. Je execution role heeft PutObject- en GetObject-permissies nodig voor S3. Het is een best practice om het principe van minste privilege af te dwingen, dus ik raad aan om deze permissies alleen in te stellen voor de S3-bucket waar de webhook-payloads worden opgeslagen.
Een voorbeeld van onze consumer lambda-functie is te vinden hier.
Als een korte opmerking over de batch-ID: Bird zal gebeurtenissen batchen in een enkele payload, waarbij elke batch 1 tot 350 of meer gebeurtenisrecords kan bevatten. De batch krijgt een unieke batch-ID, die kan worden gebruikt om de batchstatus te bekijken door gebruik te maken van de Event Webhooks API of binnen je Bird-account door te klikken op een webhook-stream en “Batch Status” te selecteren. In het geval dat een webhook-payload niet kon worden afgeleverd, zoals bij een verbindingstime-out, zal Bird de batch automatisch opnieuw proberen met dezelfde batch-ID. Dit kan gebeuren wanneer je lambda-functie dicht bij de maximale roundtrip-tijd van 10 seconden draait en is een reden om de consumer-functie te optimaliseren om de uitvoeringstijd te verminderen.
Om alle gegevensverwerkingsactiviteiten te beheren, raad ik aan om een aparte lambda-functie te maken die wordt uitgevoerd telkens wanneer een nieuw bestand wordt aangemaakt op de S3-bucket – op deze manier wordt de gegevensverwerking asynchroon uitgevoerd met de overdracht van de gegevens, en is er geen risico op gegevensverlies door een beëindigde verbinding. Ik bespreek de verwerkings-lambda-functie in een later gedeelte.
De daadwerkelijke verwerking en opslag van de gegevens wordt uitgevoerd door een lambda-functie die wordt aangeroepen door onze application load balancer (ALB).
De eerste stap is om je lambda-functie te maken door naar de Lambda-service binnen AWS te navigeren en te klikken op “Create Function.” Je wordt gevraagd om een naam aan je lambda-functie toe te wijzen en de programmeertaal te selecteren waarin je je functie schrijft. Voor dit voorbeeld gebruiken we Python als de runtime-taal.
Nu moeten we onze lambda-functie ontwikkelen. Even aangenomen dat onze application load balancer is geconfigureerd en de webhook-payload doorstuurt naar onze lambda-functie – de lambda ontvangt een payload inclusief de volledige headers en body. De payload wordt doorgestuurd naar onze lambda-functie met behulp van het object “event” als een woordenboek. Je kunt de headers en de body van de payload onafhankelijk benaderen door de “headers” en “body” objecten binnen de payload te openen. In dit voorbeeld gaan we simpelweg de “x-messagesystems-batch-id” header lezen, waarbij de batch-ID een unieke waarde is die door Bird is gecreëerd voor de webhook-batch en deze gebruiken als de bestandsnaam bij het opslaan van de body als een flat-file in S3; echter, je wilt misschien aanvullende functionaliteit toevoegen zoals authenticatiecontroles of foutafhandeling, indien nodig.
Bij het opslaan van de payload naar een flat-file op S3, moeten we de naam van de S3-bucket, de locatie en de bestandsnaam van het bestand waarin de payloadgegevens worden opgeslagen, definiëren. In onze voorbeeld lambda-functie doen we dit binnen de “store_batch” functie. In dit voorbeeld gaan we de gehele batch als één bestand opslaan, wat helpt ervoor te zorgen dat de gegevens worden verzameld en opgeslagen voordat de HTTP-verbinding tussen Bird en je eindpunt verloopt. Hoewel je de verbindingstime-outinstellingen op je load balancer kunt aanpassen, zijn er geen garanties dat de verbinding niet zal verlopen aan de zendzijde (in dit geval Bird) of dat de verbinding niet zal worden beëindigd voordat je lambda-functie is voltooid. Het is een best practice om je consumer-functie zo efficiënt mogelijk te houden en gegevensverwerkingsactiviteiten te reserveren voor downstream-processen waar mogelijk – zoals het converteren van de gebatchte JSON-geformatteerde payload naar een CSV-bestand of het laden van de gebeurtenisgegegevens in een database.
Het is belangrijk op te merken dat je mogelijk de permissies voor je lambda-functie moet bijwerken. Je execution role heeft PutObject- en GetObject-permissies nodig voor S3. Het is een best practice om het principe van minste privilege af te dwingen, dus ik raad aan om deze permissies alleen in te stellen voor de S3-bucket waar de webhook-payloads worden opgeslagen.
Een voorbeeld van onze consumer lambda-functie is te vinden hier.
Als een korte opmerking over de batch-ID: Bird zal gebeurtenissen batchen in een enkele payload, waarbij elke batch 1 tot 350 of meer gebeurtenisrecords kan bevatten. De batch krijgt een unieke batch-ID, die kan worden gebruikt om de batchstatus te bekijken door gebruik te maken van de Event Webhooks API of binnen je Bird-account door te klikken op een webhook-stream en “Batch Status” te selecteren. In het geval dat een webhook-payload niet kon worden afgeleverd, zoals bij een verbindingstime-out, zal Bird de batch automatisch opnieuw proberen met dezelfde batch-ID. Dit kan gebeuren wanneer je lambda-functie dicht bij de maximale roundtrip-tijd van 10 seconden draait en is een reden om de consumer-functie te optimaliseren om de uitvoeringstijd te verminderen.
Om alle gegevensverwerkingsactiviteiten te beheren, raad ik aan om een aparte lambda-functie te maken die wordt uitgevoerd telkens wanneer een nieuw bestand wordt aangemaakt op de S3-bucket – op deze manier wordt de gegevensverwerking asynchroon uitgevoerd met de overdracht van de gegevens, en is er geen risico op gegevensverlies door een beëindigde verbinding. Ik bespreek de verwerkings-lambda-functie in een later gedeelte.
De daadwerkelijke verwerking en opslag van de gegevens wordt uitgevoerd door een lambda-functie die wordt aangeroepen door onze application load balancer (ALB).
De eerste stap is om je lambda-functie te maken door naar de Lambda-service binnen AWS te navigeren en te klikken op “Create Function.” Je wordt gevraagd om een naam aan je lambda-functie toe te wijzen en de programmeertaal te selecteren waarin je je functie schrijft. Voor dit voorbeeld gebruiken we Python als de runtime-taal.
Nu moeten we onze lambda-functie ontwikkelen. Even aangenomen dat onze application load balancer is geconfigureerd en de webhook-payload doorstuurt naar onze lambda-functie – de lambda ontvangt een payload inclusief de volledige headers en body. De payload wordt doorgestuurd naar onze lambda-functie met behulp van het object “event” als een woordenboek. Je kunt de headers en de body van de payload onafhankelijk benaderen door de “headers” en “body” objecten binnen de payload te openen. In dit voorbeeld gaan we simpelweg de “x-messagesystems-batch-id” header lezen, waarbij de batch-ID een unieke waarde is die door Bird is gecreëerd voor de webhook-batch en deze gebruiken als de bestandsnaam bij het opslaan van de body als een flat-file in S3; echter, je wilt misschien aanvullende functionaliteit toevoegen zoals authenticatiecontroles of foutafhandeling, indien nodig.
Bij het opslaan van de payload naar een flat-file op S3, moeten we de naam van de S3-bucket, de locatie en de bestandsnaam van het bestand waarin de payloadgegevens worden opgeslagen, definiëren. In onze voorbeeld lambda-functie doen we dit binnen de “store_batch” functie. In dit voorbeeld gaan we de gehele batch als één bestand opslaan, wat helpt ervoor te zorgen dat de gegevens worden verzameld en opgeslagen voordat de HTTP-verbinding tussen Bird en je eindpunt verloopt. Hoewel je de verbindingstime-outinstellingen op je load balancer kunt aanpassen, zijn er geen garanties dat de verbinding niet zal verlopen aan de zendzijde (in dit geval Bird) of dat de verbinding niet zal worden beëindigd voordat je lambda-functie is voltooid. Het is een best practice om je consumer-functie zo efficiënt mogelijk te houden en gegevensverwerkingsactiviteiten te reserveren voor downstream-processen waar mogelijk – zoals het converteren van de gebatchte JSON-geformatteerde payload naar een CSV-bestand of het laden van de gebeurtenisgegegevens in een database.
Het is belangrijk op te merken dat je mogelijk de permissies voor je lambda-functie moet bijwerken. Je execution role heeft PutObject- en GetObject-permissies nodig voor S3. Het is een best practice om het principe van minste privilege af te dwingen, dus ik raad aan om deze permissies alleen in te stellen voor de S3-bucket waar de webhook-payloads worden opgeslagen.
Een voorbeeld van onze consumer lambda-functie is te vinden hier.
Als een korte opmerking over de batch-ID: Bird zal gebeurtenissen batchen in een enkele payload, waarbij elke batch 1 tot 350 of meer gebeurtenisrecords kan bevatten. De batch krijgt een unieke batch-ID, die kan worden gebruikt om de batchstatus te bekijken door gebruik te maken van de Event Webhooks API of binnen je Bird-account door te klikken op een webhook-stream en “Batch Status” te selecteren. In het geval dat een webhook-payload niet kon worden afgeleverd, zoals bij een verbindingstime-out, zal Bird de batch automatisch opnieuw proberen met dezelfde batch-ID. Dit kan gebeuren wanneer je lambda-functie dicht bij de maximale roundtrip-tijd van 10 seconden draait en is een reden om de consumer-functie te optimaliseren om de uitvoeringstijd te verminderen.
Om alle gegevensverwerkingsactiviteiten te beheren, raad ik aan om een aparte lambda-functie te maken die wordt uitgevoerd telkens wanneer een nieuw bestand wordt aangemaakt op de S3-bucket – op deze manier wordt de gegevensverwerking asynchroon uitgevoerd met de overdracht van de gegevens, en is er geen risico op gegevensverlies door een beëindigde verbinding. Ik bespreek de verwerkings-lambda-functie in een later gedeelte.
Creëer een Application Load Balancer
Om een webhook-payload te ontvangen, moeten we een eindpunt voorzien waarnaar de payloads kunnen worden verzonden. Dit doen we door een applicatieloadbalancer binnen AWS te creëren via navigatie naar EC2 > Load Balancers en klikken op "Create Load Balancer." We worden gevraagd te kiezen welk type loadbalancer we willen maken – hiervoor willen we een applicatieloadbalancer maken. We moeten een applicatieloadbalancer (ALB) gebruiken om onze consument te bouwen omdat de event-webhooks worden verzonden als een HTTP-verzoek, en ALB's worden gebruikt voor het routeren van HTTP-verzoeken binnen AWS. We zouden een HTTP Gateway kunnen implementeren als alternatief; echter, we gebruiken een ALB voor dit project omdat het lichter en kosteneffectiever is dan HTTP Gateway. Het is belangrijk op te merken dat als je ervoor kiest een HTTP Gateway te gebruiken, het eventformaat anders kan zijn dan bij een ALB, en daarom moet je lambda-functie het verzoekobject dienovereenkomstig verwerken.
Zodra je ALB is gemaakt, wordt je gevraagd een naam toe te wijzen aan je ALB en het schema en de toegangs-/beveiligingsinstellingen te configureren – aangezien we van plan zijn om eventdata van een externe bron (Bird) te ontvangen, willen we dat onze ALB internet-facing is. Onder "Listeners and routing" moet de ALB naar HTTPS op poort 443 luisteren en willen we een Target-groep creëren die naar onze lambda-functie wijst, zodat onze ALB binnenkomende verzoeken doorstuurt naar de consume lambda-functie die we eerder hebben gemaakt. Je moet er ook voor zorgen dat de beveiligingsgroep toestemming heeft om verkeer via poort 443 te accepteren.
Om een webhook-payload te ontvangen, moeten we een eindpunt voorzien waarnaar de payloads kunnen worden verzonden. Dit doen we door een applicatieloadbalancer binnen AWS te creëren via navigatie naar EC2 > Load Balancers en klikken op "Create Load Balancer." We worden gevraagd te kiezen welk type loadbalancer we willen maken – hiervoor willen we een applicatieloadbalancer maken. We moeten een applicatieloadbalancer (ALB) gebruiken om onze consument te bouwen omdat de event-webhooks worden verzonden als een HTTP-verzoek, en ALB's worden gebruikt voor het routeren van HTTP-verzoeken binnen AWS. We zouden een HTTP Gateway kunnen implementeren als alternatief; echter, we gebruiken een ALB voor dit project omdat het lichter en kosteneffectiever is dan HTTP Gateway. Het is belangrijk op te merken dat als je ervoor kiest een HTTP Gateway te gebruiken, het eventformaat anders kan zijn dan bij een ALB, en daarom moet je lambda-functie het verzoekobject dienovereenkomstig verwerken.
Zodra je ALB is gemaakt, wordt je gevraagd een naam toe te wijzen aan je ALB en het schema en de toegangs-/beveiligingsinstellingen te configureren – aangezien we van plan zijn om eventdata van een externe bron (Bird) te ontvangen, willen we dat onze ALB internet-facing is. Onder "Listeners and routing" moet de ALB naar HTTPS op poort 443 luisteren en willen we een Target-groep creëren die naar onze lambda-functie wijst, zodat onze ALB binnenkomende verzoeken doorstuurt naar de consume lambda-functie die we eerder hebben gemaakt. Je moet er ook voor zorgen dat de beveiligingsgroep toestemming heeft om verkeer via poort 443 te accepteren.
Om een webhook-payload te ontvangen, moeten we een eindpunt voorzien waarnaar de payloads kunnen worden verzonden. Dit doen we door een applicatieloadbalancer binnen AWS te creëren via navigatie naar EC2 > Load Balancers en klikken op "Create Load Balancer." We worden gevraagd te kiezen welk type loadbalancer we willen maken – hiervoor willen we een applicatieloadbalancer maken. We moeten een applicatieloadbalancer (ALB) gebruiken om onze consument te bouwen omdat de event-webhooks worden verzonden als een HTTP-verzoek, en ALB's worden gebruikt voor het routeren van HTTP-verzoeken binnen AWS. We zouden een HTTP Gateway kunnen implementeren als alternatief; echter, we gebruiken een ALB voor dit project omdat het lichter en kosteneffectiever is dan HTTP Gateway. Het is belangrijk op te merken dat als je ervoor kiest een HTTP Gateway te gebruiken, het eventformaat anders kan zijn dan bij een ALB, en daarom moet je lambda-functie het verzoekobject dienovereenkomstig verwerken.
Zodra je ALB is gemaakt, wordt je gevraagd een naam toe te wijzen aan je ALB en het schema en de toegangs-/beveiligingsinstellingen te configureren – aangezien we van plan zijn om eventdata van een externe bron (Bird) te ontvangen, willen we dat onze ALB internet-facing is. Onder "Listeners and routing" moet de ALB naar HTTPS op poort 443 luisteren en willen we een Target-groep creëren die naar onze lambda-functie wijst, zodat onze ALB binnenkomende verzoeken doorstuurt naar de consume lambda-functie die we eerder hebben gemaakt. Je moet er ook voor zorgen dat de beveiligingsgroep toestemming heeft om verkeer via poort 443 te accepteren.
Maak een DNS Record voor de Load Balancer
Om het voor ons gemakkelijker te maken om onze ALB als een eindpunt te gebruiken, zullen we een A-record in DNS creëren dat naar onze ALB wijst. Hiervoor kunnen we de AWS Route 53-service gebruiken (of uw huidige DNS-provider) en een A-record maken voor de hostnaam die u wilt gebruiken voor uw eindpunt (bijv. spevents.<your_domain>). Wanneer u op schaal werkt met DNS op AWS, wees dan bewust van de ongedocumenteerde DNS-limieten die van invloed kunnen zijn op applicaties met een hoog volume, vooral degenen die omgaan met grote hoeveelheden uitgaand verkeer zoals e-mailsystemen. Het A-record moet zo worden geconfigureerd dat het naar de ALB wijst die we hebben aangemaakt. Als u Route 53 gebruikt om de DNS-records te beheren, kunt u direct naar de ALB verwijzen door 'Alias' in te schakelen en de ALB te selecteren; anders, als u een externe DNS-provider gebruikt, moet u het A-record naar het openbare IP-adres van de ALB-instantie wijzen.
Ik raad aan om een tool zoals Postman te gebruiken om te testen of alles correct is geconfigureerd voordat u uw Bird webhook inschakelt. U kunt een POST-verzoek naar uw eindpunt sturen en bevestigen dat u een antwoord ontvangt. Als uw POST-verzoek geen antwoord retourneert, moet u wellicht dubbel controleren of uw ALB naar de juiste poort luistert.
Om het voor ons gemakkelijker te maken om onze ALB als een eindpunt te gebruiken, zullen we een A-record in DNS creëren dat naar onze ALB wijst. Hiervoor kunnen we de AWS Route 53-service gebruiken (of uw huidige DNS-provider) en een A-record maken voor de hostnaam die u wilt gebruiken voor uw eindpunt (bijv. spevents.<your_domain>). Wanneer u op schaal werkt met DNS op AWS, wees dan bewust van de ongedocumenteerde DNS-limieten die van invloed kunnen zijn op applicaties met een hoog volume, vooral degenen die omgaan met grote hoeveelheden uitgaand verkeer zoals e-mailsystemen. Het A-record moet zo worden geconfigureerd dat het naar de ALB wijst die we hebben aangemaakt. Als u Route 53 gebruikt om de DNS-records te beheren, kunt u direct naar de ALB verwijzen door 'Alias' in te schakelen en de ALB te selecteren; anders, als u een externe DNS-provider gebruikt, moet u het A-record naar het openbare IP-adres van de ALB-instantie wijzen.
Ik raad aan om een tool zoals Postman te gebruiken om te testen of alles correct is geconfigureerd voordat u uw Bird webhook inschakelt. U kunt een POST-verzoek naar uw eindpunt sturen en bevestigen dat u een antwoord ontvangt. Als uw POST-verzoek geen antwoord retourneert, moet u wellicht dubbel controleren of uw ALB naar de juiste poort luistert.
Om het voor ons gemakkelijker te maken om onze ALB als een eindpunt te gebruiken, zullen we een A-record in DNS creëren dat naar onze ALB wijst. Hiervoor kunnen we de AWS Route 53-service gebruiken (of uw huidige DNS-provider) en een A-record maken voor de hostnaam die u wilt gebruiken voor uw eindpunt (bijv. spevents.<your_domain>). Wanneer u op schaal werkt met DNS op AWS, wees dan bewust van de ongedocumenteerde DNS-limieten die van invloed kunnen zijn op applicaties met een hoog volume, vooral degenen die omgaan met grote hoeveelheden uitgaand verkeer zoals e-mailsystemen. Het A-record moet zo worden geconfigureerd dat het naar de ALB wijst die we hebben aangemaakt. Als u Route 53 gebruikt om de DNS-records te beheren, kunt u direct naar de ALB verwijzen door 'Alias' in te schakelen en de ALB te selecteren; anders, als u een externe DNS-provider gebruikt, moet u het A-record naar het openbare IP-adres van de ALB-instantie wijzen.
Ik raad aan om een tool zoals Postman te gebruiken om te testen of alles correct is geconfigureerd voordat u uw Bird webhook inschakelt. U kunt een POST-verzoek naar uw eindpunt sturen en bevestigen dat u een antwoord ontvangt. Als uw POST-verzoek geen antwoord retourneert, moet u wellicht dubbel controleren of uw ALB naar de juiste poort luistert.
Maak een Bird Webhook
Nu zijn we klaar om de webhook in Bird te maken en de hostname gedefinieerd door het A-record hierboven als onze doel-eindpunt te gebruiken. Om de webhook te maken, navigeer naar de Webhooks-sectie binnen je Bird account en klik op “Create Webhook.” Je wordt gevraagd om een naam voor je webhook toe te wijzen en een doel-URL op te geven – het doel moet de hostname zijn van het A-record dat je eerder hebt aangemaakt. Houd er rekening mee dat de doel-URL mogelijk "HTTPS://" moet bevatten in de URL.
Eenmaal voltooid, controleer of het correcte subaccount en evenementen zijn geselecteerd, en druk op "Create Webhook” om je configuratie op te slaan. De gebeurtenisgegevens voor alle geselecteerde evenementtypes zullen nu naar onze doel-URL stromen en worden verwerkt door onze ALB voor verdere verwerking.
Nu zijn we klaar om de webhook in Bird te maken en de hostname gedefinieerd door het A-record hierboven als onze doel-eindpunt te gebruiken. Om de webhook te maken, navigeer naar de Webhooks-sectie binnen je Bird account en klik op “Create Webhook.” Je wordt gevraagd om een naam voor je webhook toe te wijzen en een doel-URL op te geven – het doel moet de hostname zijn van het A-record dat je eerder hebt aangemaakt. Houd er rekening mee dat de doel-URL mogelijk "HTTPS://" moet bevatten in de URL.
Eenmaal voltooid, controleer of het correcte subaccount en evenementen zijn geselecteerd, en druk op "Create Webhook” om je configuratie op te slaan. De gebeurtenisgegevens voor alle geselecteerde evenementtypes zullen nu naar onze doel-URL stromen en worden verwerkt door onze ALB voor verdere verwerking.
Nu zijn we klaar om de webhook in Bird te maken en de hostname gedefinieerd door het A-record hierboven als onze doel-eindpunt te gebruiken. Om de webhook te maken, navigeer naar de Webhooks-sectie binnen je Bird account en klik op “Create Webhook.” Je wordt gevraagd om een naam voor je webhook toe te wijzen en een doel-URL op te geven – het doel moet de hostname zijn van het A-record dat je eerder hebt aangemaakt. Houd er rekening mee dat de doel-URL mogelijk "HTTPS://" moet bevatten in de URL.
Eenmaal voltooid, controleer of het correcte subaccount en evenementen zijn geselecteerd, en druk op "Create Webhook” om je configuratie op te slaan. De gebeurtenisgegevens voor alle geselecteerde evenementtypes zullen nu naar onze doel-URL stromen en worden verwerkt door onze ALB voor verdere verwerking.
Verwerken Webhook Event Data
Afhankelijk van het beoogde doel voor het opslaan van de Bird gebeurtenisgegevens, kunnen uw vereisten worden voldaan door simpelweg de JSON-payload als een flat-file op te slaan. U hebt mogelijk ook al een downstream ETL-proces dat in staat is om gegevens in een JSON-formaat te verwerken en te laden. In beide gevallen kunt u de flat-file die is gemaakt door onze verwerking lambda die we hierboven hebben gemaakt, mogelijk gebruiken zoals deze is.
Afwisselend, kunt u de gegevens moeten transformeren - zoals het converteren van JSON naar een CSV-formaat - of de gegevens direct in een database laden. In dit voorbeeld zullen we een eenvoudige lambda-functie creëren die de webhookgegevens van het originele JSON-formaat omzet in een CSV-bestand dat in een database kan worden geladen.
Afhankelijk van het beoogde doel voor het opslaan van de Bird gebeurtenisgegevens, kunnen uw vereisten worden voldaan door simpelweg de JSON-payload als een flat-file op te slaan. U hebt mogelijk ook al een downstream ETL-proces dat in staat is om gegevens in een JSON-formaat te verwerken en te laden. In beide gevallen kunt u de flat-file die is gemaakt door onze verwerking lambda die we hierboven hebben gemaakt, mogelijk gebruiken zoals deze is.
Afwisselend, kunt u de gegevens moeten transformeren - zoals het converteren van JSON naar een CSV-formaat - of de gegevens direct in een database laden. In dit voorbeeld zullen we een eenvoudige lambda-functie creëren die de webhookgegevens van het originele JSON-formaat omzet in een CSV-bestand dat in een database kan worden geladen.
Afhankelijk van het beoogde doel voor het opslaan van de Bird gebeurtenisgegevens, kunnen uw vereisten worden voldaan door simpelweg de JSON-payload als een flat-file op te slaan. U hebt mogelijk ook al een downstream ETL-proces dat in staat is om gegevens in een JSON-formaat te verwerken en te laden. In beide gevallen kunt u de flat-file die is gemaakt door onze verwerking lambda die we hierboven hebben gemaakt, mogelijk gebruiken zoals deze is.
Afwisselend, kunt u de gegevens moeten transformeren - zoals het converteren van JSON naar een CSV-formaat - of de gegevens direct in een database laden. In dit voorbeeld zullen we een eenvoudige lambda-functie creëren die de webhookgegevens van het originele JSON-formaat omzet in een CSV-bestand dat in een database kan worden geladen.
Maak een Lambda om de Data te verwerken
Net zoals bij de lambda-functie om de webhook-gegevens te consumeren, moeten we een nieuwe lambda-functie maken door naar de Lambda-service binnen AWS te navigeren en op 'Function Create' te drukken. Deze nieuwe lambda-functie wordt geactiveerd wanneer een nieuw bestand wordt gemaakt in onze S3 bucket – het zal de gegevens lezen en omzetten in een nieuw csv-bestand.
De lambda-functie accepteert de bestandsinformatie als een gebeurtenis. In de voorbeeldlambda-functie zie je dat we eerst een reeks validatiecontroles hebben om ervoor te zorgen dat de gegevens compleet zijn en zoals verwacht zijn geformatteerd. Vervolgens converteren we de JSON-payload naar een CSV-bestand door gebruik te maken van de “csv” bibliotheek en naar een tijdelijk bestand te schrijven. Lambda-functies kunnen alleen lokale bestanden naar de “/tmp” directory schrijven, dus we maken een tijdelijk csv-bestand en geven het de naam volgens de conventie <batch_id>.csv. De reden dat we hier de batch_id gebruiken, is simpelweg om ervoor te zorgen dat parallelle processen die worden uitgevoerd als gevolg van het ontvangen van meerdere webhook-payloads elkaar niet storen, aangezien elke webhook-batch een unieke batch_id heeft.
Zodra de gegevens volledig zijn omgezet naar CSV, lezen we de CSV-gegevens als een byte stream, verwijderen we het tijdelijke bestand en slaan we de CSV-gegevens op als een nieuw bestand op S3. Het is belangrijk op te merken dat een andere S3 bucket nodig is voor het resultaat, anders lopen we het risico een recursieve lus te creëren die kan resulteren in verhoogd gebruik van lambda en hogere kosten. We zullen moeten identificeren in welke S3 bucket en locatie we ons CSV-bestand willen opslaan binnen onze lambda-functie. Volg dezelfde procedure als hierboven om een nieuwe S3 bucket te maken om ons CSV-bestand op te slaan.
Let op dat de tmp-directory beperkt is tot 512 MB aan ruimte, dus het is belangrijk dat het tijdelijke bestand daarna wordt verwijderd om voldoende ruimte voor toekomstige uitvoeringen te garanderen. De reden dat we een tijdelijk bestand gebruiken, in plaats van direct naar S3 te schrijven, is om de verbinding met S3 te vereenvoudigen door slechts één verzoek te hebben.
Net zoals bij de consumer lambda-functie, kan het nodig zijn om de machtigingen voor je proces lambda-functie bij te werken. Deze lambda-functie vereist dat de uitvoeringsrol GetObject-machtigingen heeft voor de invoer S3 bucket, en zowel PutObject als GetObject voor de uitvoer S3 bucket.
Een voorbeeld van onze verwerkende lambda-functie is te vinden hier.
Net zoals bij de lambda-functie om de webhook-gegevens te consumeren, moeten we een nieuwe lambda-functie maken door naar de Lambda-service binnen AWS te navigeren en op 'Function Create' te drukken. Deze nieuwe lambda-functie wordt geactiveerd wanneer een nieuw bestand wordt gemaakt in onze S3 bucket – het zal de gegevens lezen en omzetten in een nieuw csv-bestand.
De lambda-functie accepteert de bestandsinformatie als een gebeurtenis. In de voorbeeldlambda-functie zie je dat we eerst een reeks validatiecontroles hebben om ervoor te zorgen dat de gegevens compleet zijn en zoals verwacht zijn geformatteerd. Vervolgens converteren we de JSON-payload naar een CSV-bestand door gebruik te maken van de “csv” bibliotheek en naar een tijdelijk bestand te schrijven. Lambda-functies kunnen alleen lokale bestanden naar de “/tmp” directory schrijven, dus we maken een tijdelijk csv-bestand en geven het de naam volgens de conventie <batch_id>.csv. De reden dat we hier de batch_id gebruiken, is simpelweg om ervoor te zorgen dat parallelle processen die worden uitgevoerd als gevolg van het ontvangen van meerdere webhook-payloads elkaar niet storen, aangezien elke webhook-batch een unieke batch_id heeft.
Zodra de gegevens volledig zijn omgezet naar CSV, lezen we de CSV-gegevens als een byte stream, verwijderen we het tijdelijke bestand en slaan we de CSV-gegevens op als een nieuw bestand op S3. Het is belangrijk op te merken dat een andere S3 bucket nodig is voor het resultaat, anders lopen we het risico een recursieve lus te creëren die kan resulteren in verhoogd gebruik van lambda en hogere kosten. We zullen moeten identificeren in welke S3 bucket en locatie we ons CSV-bestand willen opslaan binnen onze lambda-functie. Volg dezelfde procedure als hierboven om een nieuwe S3 bucket te maken om ons CSV-bestand op te slaan.
Let op dat de tmp-directory beperkt is tot 512 MB aan ruimte, dus het is belangrijk dat het tijdelijke bestand daarna wordt verwijderd om voldoende ruimte voor toekomstige uitvoeringen te garanderen. De reden dat we een tijdelijk bestand gebruiken, in plaats van direct naar S3 te schrijven, is om de verbinding met S3 te vereenvoudigen door slechts één verzoek te hebben.
Net zoals bij de consumer lambda-functie, kan het nodig zijn om de machtigingen voor je proces lambda-functie bij te werken. Deze lambda-functie vereist dat de uitvoeringsrol GetObject-machtigingen heeft voor de invoer S3 bucket, en zowel PutObject als GetObject voor de uitvoer S3 bucket.
Een voorbeeld van onze verwerkende lambda-functie is te vinden hier.
Net zoals bij de lambda-functie om de webhook-gegevens te consumeren, moeten we een nieuwe lambda-functie maken door naar de Lambda-service binnen AWS te navigeren en op 'Function Create' te drukken. Deze nieuwe lambda-functie wordt geactiveerd wanneer een nieuw bestand wordt gemaakt in onze S3 bucket – het zal de gegevens lezen en omzetten in een nieuw csv-bestand.
De lambda-functie accepteert de bestandsinformatie als een gebeurtenis. In de voorbeeldlambda-functie zie je dat we eerst een reeks validatiecontroles hebben om ervoor te zorgen dat de gegevens compleet zijn en zoals verwacht zijn geformatteerd. Vervolgens converteren we de JSON-payload naar een CSV-bestand door gebruik te maken van de “csv” bibliotheek en naar een tijdelijk bestand te schrijven. Lambda-functies kunnen alleen lokale bestanden naar de “/tmp” directory schrijven, dus we maken een tijdelijk csv-bestand en geven het de naam volgens de conventie <batch_id>.csv. De reden dat we hier de batch_id gebruiken, is simpelweg om ervoor te zorgen dat parallelle processen die worden uitgevoerd als gevolg van het ontvangen van meerdere webhook-payloads elkaar niet storen, aangezien elke webhook-batch een unieke batch_id heeft.
Zodra de gegevens volledig zijn omgezet naar CSV, lezen we de CSV-gegevens als een byte stream, verwijderen we het tijdelijke bestand en slaan we de CSV-gegevens op als een nieuw bestand op S3. Het is belangrijk op te merken dat een andere S3 bucket nodig is voor het resultaat, anders lopen we het risico een recursieve lus te creëren die kan resulteren in verhoogd gebruik van lambda en hogere kosten. We zullen moeten identificeren in welke S3 bucket en locatie we ons CSV-bestand willen opslaan binnen onze lambda-functie. Volg dezelfde procedure als hierboven om een nieuwe S3 bucket te maken om ons CSV-bestand op te slaan.
Let op dat de tmp-directory beperkt is tot 512 MB aan ruimte, dus het is belangrijk dat het tijdelijke bestand daarna wordt verwijderd om voldoende ruimte voor toekomstige uitvoeringen te garanderen. De reden dat we een tijdelijk bestand gebruiken, in plaats van direct naar S3 te schrijven, is om de verbinding met S3 te vereenvoudigen door slechts één verzoek te hebben.
Net zoals bij de consumer lambda-functie, kan het nodig zijn om de machtigingen voor je proces lambda-functie bij te werken. Deze lambda-functie vereist dat de uitvoeringsrol GetObject-machtigingen heeft voor de invoer S3 bucket, en zowel PutObject als GetObject voor de uitvoer S3 bucket.
Een voorbeeld van onze verwerkende lambda-functie is te vinden hier.
Configureer een Lambda om uit te voeren wanneer nieuwe gegevens worden opgeslagen op S3
Nu onze lambda-functie om het bestand om te zetten van JSON naar CSV-formaat is aangemaakt, moeten we deze configureren zodat deze geactiveerd wordt wanneer er een nieuw bestand wordt gemaakt in onze S3-bucket. Om dit te doen, moeten we een trigger toevoegen aan onze lambda-functie door onze lambda-functie te openen en bovenaan de pagina op "Trigger toevoegen" te klikken. Selecteer "S3" en geef de naam op van de S3-bucket waar de ruwe webhook-payloads worden opgeslagen. Je hebt ook de optie om een bestandsprefix en/of -suffix op te geven om op te filteren. Zodra de instellingen zijn geconfigureerd, kun je de trigger toevoegen door onderaan de pagina op "Toevoegen" te klikken. Nu wordt je verwerkingslambda-functie uitgevoerd wanneer er een nieuw bestand aan je S3-bucket wordt toegevoegd.
Nu onze lambda-functie om het bestand om te zetten van JSON naar CSV-formaat is aangemaakt, moeten we deze configureren zodat deze geactiveerd wordt wanneer er een nieuw bestand wordt gemaakt in onze S3-bucket. Om dit te doen, moeten we een trigger toevoegen aan onze lambda-functie door onze lambda-functie te openen en bovenaan de pagina op "Trigger toevoegen" te klikken. Selecteer "S3" en geef de naam op van de S3-bucket waar de ruwe webhook-payloads worden opgeslagen. Je hebt ook de optie om een bestandsprefix en/of -suffix op te geven om op te filteren. Zodra de instellingen zijn geconfigureerd, kun je de trigger toevoegen door onderaan de pagina op "Toevoegen" te klikken. Nu wordt je verwerkingslambda-functie uitgevoerd wanneer er een nieuw bestand aan je S3-bucket wordt toegevoegd.
Nu onze lambda-functie om het bestand om te zetten van JSON naar CSV-formaat is aangemaakt, moeten we deze configureren zodat deze geactiveerd wordt wanneer er een nieuw bestand wordt gemaakt in onze S3-bucket. Om dit te doen, moeten we een trigger toevoegen aan onze lambda-functie door onze lambda-functie te openen en bovenaan de pagina op "Trigger toevoegen" te klikken. Selecteer "S3" en geef de naam op van de S3-bucket waar de ruwe webhook-payloads worden opgeslagen. Je hebt ook de optie om een bestandsprefix en/of -suffix op te geven om op te filteren. Zodra de instellingen zijn geconfigureerd, kun je de trigger toevoegen door onderaan de pagina op "Toevoegen" te klikken. Nu wordt je verwerkingslambda-functie uitgevoerd wanneer er een nieuw bestand aan je S3-bucket wordt toegevoegd.
De gegevens in een database laden
In dit voorbeeld zal ik niet gedetailleerd bespreken hoe de gegevens in een database worden geladen, maar als je dit voorbeeld hebt gevolgd, heb je een paar opties:
Laad de gegevens rechtstreeks in je database binnen je verwerkings lambda-functie
Gebruik je CSV-bestand met een bestaand ETL-proces
Of je nu een AWS-databaseservice gebruikt, zoals RDS of DynamoDB, of je hebt je eigen PostgreSQL-database (of vergelijkbaar), je kunt rechtstreeks verbinding maken met je databaseservice vanuit je proces lambda-functie. Bijvoorbeeld, op dezelfde manier zoals we de S3-service hebben aangeroepen met "boto3" in onze lambda-functie, zou je ook "boto3" kunnen gebruiken om RDS of DynamoDB aan te roepen. De AWS Athena service kan ook worden gebruikt om de gegevensbestanden rechtstreeks van de platte bestanden te lezen en toegang tot de gegevens te krijgen via een querytaal vergelijkbaar met SQL. Ik raad aan om naar de relevante documentatie van de service die je gebruikt te verwijzen voor meer informatie over hoe je dit het beste in jouw omgeving kunt bereiken.
Op dezelfde manier zijn er veel diensten beschikbaar die kunnen helpen bij het verbruik van CSV-bestanden en het laden van de gegevens in een database. Je hebt mogelijk al een bestaand ETL-proces dat je kunt gebruiken.
We hopen dat je deze gids nuttig vond – veel plezier met verzenden!
In dit voorbeeld zal ik niet gedetailleerd bespreken hoe de gegevens in een database worden geladen, maar als je dit voorbeeld hebt gevolgd, heb je een paar opties:
Laad de gegevens rechtstreeks in je database binnen je verwerkings lambda-functie
Gebruik je CSV-bestand met een bestaand ETL-proces
Of je nu een AWS-databaseservice gebruikt, zoals RDS of DynamoDB, of je hebt je eigen PostgreSQL-database (of vergelijkbaar), je kunt rechtstreeks verbinding maken met je databaseservice vanuit je proces lambda-functie. Bijvoorbeeld, op dezelfde manier zoals we de S3-service hebben aangeroepen met "boto3" in onze lambda-functie, zou je ook "boto3" kunnen gebruiken om RDS of DynamoDB aan te roepen. De AWS Athena service kan ook worden gebruikt om de gegevensbestanden rechtstreeks van de platte bestanden te lezen en toegang tot de gegevens te krijgen via een querytaal vergelijkbaar met SQL. Ik raad aan om naar de relevante documentatie van de service die je gebruikt te verwijzen voor meer informatie over hoe je dit het beste in jouw omgeving kunt bereiken.
Op dezelfde manier zijn er veel diensten beschikbaar die kunnen helpen bij het verbruik van CSV-bestanden en het laden van de gegevens in een database. Je hebt mogelijk al een bestaand ETL-proces dat je kunt gebruiken.
We hopen dat je deze gids nuttig vond – veel plezier met verzenden!
In dit voorbeeld zal ik niet gedetailleerd bespreken hoe de gegevens in een database worden geladen, maar als je dit voorbeeld hebt gevolgd, heb je een paar opties:
Laad de gegevens rechtstreeks in je database binnen je verwerkings lambda-functie
Gebruik je CSV-bestand met een bestaand ETL-proces
Of je nu een AWS-databaseservice gebruikt, zoals RDS of DynamoDB, of je hebt je eigen PostgreSQL-database (of vergelijkbaar), je kunt rechtstreeks verbinding maken met je databaseservice vanuit je proces lambda-functie. Bijvoorbeeld, op dezelfde manier zoals we de S3-service hebben aangeroepen met "boto3" in onze lambda-functie, zou je ook "boto3" kunnen gebruiken om RDS of DynamoDB aan te roepen. De AWS Athena service kan ook worden gebruikt om de gegevensbestanden rechtstreeks van de platte bestanden te lezen en toegang tot de gegevens te krijgen via een querytaal vergelijkbaar met SQL. Ik raad aan om naar de relevante documentatie van de service die je gebruikt te verwijzen voor meer informatie over hoe je dit het beste in jouw omgeving kunt bereiken.
Op dezelfde manier zijn er veel diensten beschikbaar die kunnen helpen bij het verbruik van CSV-bestanden en het laden van de gegevens in een database. Je hebt mogelijk al een bestaand ETL-proces dat je kunt gebruiken.
We hopen dat je deze gids nuttig vond – veel plezier met verzenden!
