Erstellen und Verwenden von Bird Webhooks
Vogel
27.01.2022
1 min read
Wichtige Erkenntnisse
Bird’s Echtzeit-Event-Webhooks ermöglichen es Absendern, Ereignisdaten sofort zu erhalten – keine Abfragen, keine Cron-Jobs und keine Ratenlimit-Probleme.
Webhooks beseitigen die Komplexität der Verwaltung von Zeitfenstern, verhindern verpasste Ereignisse und die Bearbeitung doppelter Datensätze.
Ideal für Downstream-Automatisierung: Aktualisierung von Listen, Starten von Reisewegen, Anreichern von Dashboards oder Synchronisieren interner Systeme.
Das Tutorial führt Absender durch den Aufbau einer vollständigen AWS-Aufnahmepipeline: S3-Speicher, Lambda-Verarbeitung und einen Anwendungslastausgleich.
S3 dient als zentrale Speicherebene für Webhook-Nutzlasten, wobei jede Charge als flache JSON-Datei geschrieben wird.
Lambda-Funktionen übernehmen sowohl die Aufnahme (Speichern roher Chargen) als auch die Transformation (Umwandlung von JSON in CSV).
Bird fasst Ereignisse in Chargen zusammen – jede Webhook-Charge enthält eine eindeutige
x-messagesystems-batch-id, die Wiederholungsprüfungen und Deduplikation ermöglicht.Die Verbraucher-Lambda muss effizient bleiben, da Bird Chargen erneut versucht, wenn der Endpunkt nicht innerhalb von ~10 Sekunden antwortet.
AWS ALB wird empfohlen (vs. API Gateway) für Einfachheit, Kosteneffizienz und direkte Handhabung von HTTP POST-Anfragen.
DNS (Route 53 oder externer Anbieter) wird konfiguriert, um einen benutzerfreundlichen Hostnamen dem ALB-Endpunkt zuzuordnen.
Nach der Einrichtung sendet Bird Ereignisdaten direkt und zuverlässig an Ihre AWS-Pipeline zur asynchronen Verarbeitung.
Der Leitfaden behandelt auch Best Practices: Berechtigungen mit minimalen Rechten für IAM, Einschränkungen beim temporären Speicher, Vermeidung rekursiver Trigger und Organisation von Multi-Lambda-Workflows.
Q&A Highlights
Was ist der Hauptzweck der Echtzeit-Event-Webhooks von Bird?
Um Ereignisdaten in Echtzeit direkt an den Endpunkt eines Senders zu übermitteln, wodurch eine sofortige Automatisierung ohne Abfragen oder durchsatzbegrenzte API-Aufrufe ermöglicht wird.
Warum sind Webhooks besser als das Abrufen von Daten über eine API für große Sender?
Da API-Abrufe eine Verwaltung von Zeitfenstern erfordern, das Risiko von Datenlücken oder Duplikaten bergen und auf Ratenbegrenzungen stoßen können – beseitigen Webhooks all das, indem sie kontinuierlich Daten übertragen.
Welche AWS-Dienste werden in der empfohlenen Webhook-Integrationspipeline verwendet?
Amazon S3 (Speicherung), AWS Lambda (Verarbeitung), ein Application Load Balancer (HTTP-Listener) und optional Route 53 (DNS).
Wie stapelt Bird Ereignisdaten?
Bird sendet mehrere Ereignisse zusammen in einer Nutzlast, wobei jedem eine eindeutige Batch-ID (x-messagesystems-batch-id) für die Verfolgung, Wiederholungen und Deduplizierung zugewiesen wird.
Was löst die Verbraucher Lambda-Funktion aus?
Der ALB leitet eingehende Webhook-POST-Anfragen direkt an die Lambda weiter, die die Nutzlast extrahiert und in S3 schreibt.
Warum den rohen Webhook-Batch in S3 speichern, bevor er verarbeitet wird?
Um eine schnelle Aufnahme (<10 Sekunden) sicherzustellen, damit die Verbindung nicht abläuft, und um aufwendigere Verarbeitung auf eine separate asynchrone Pipeline zu verlagern.
Was macht die zweite Lambda-Funktion?
Es wird durch neue S3-Objekte ausgelöst, validiert das JSON, konvertiert es in CSV und schreibt die verarbeitete Ausgabe in einen separaten S3-Bucket.
Warum einen separaten S3-Bucket für verarbeitete CSV-Dateien verwenden?
Um rekursive Auslöser zu vermeiden (das Zurückschreiben einer neuen verarbeiteten Datei in denselben Bucket würde die Lambda endlos erneut auslösen).
Welche Berechtigungen benötigen die Lambda-Funktionen?
Der Lambda-Verbraucher benötigt S3 PutObject-Berechtigungen; der verarbeitende Lambda benötigt GetObject für den Quell-Bucket und PutObject für den Ziel-Bucket.
Warum wird ein AWS ALB gegenüber API Gateway empfohlen?
ALBs sind günstiger, einfacher und ideal für unkompliziertes HTTPS POST-Weiterleitungen; API Gateway kann das Payload-Format ändern und die Komplexität erhöhen.
Wie konfigurieren Absender den Webhook in Bird?
Durch Bereitstellung des HTTPS-Endpunkts (der DNS-Eintrag für den ALB), Auswahl eines Unterkontos, Auswahl von Ereignissen und Speichern der Webhook-Konfiguration.
Welche nachgelagerten Optionen gibt es zum Speichern oder Analysieren der verarbeiteten Daten?
Laden Sie in Datenbanken (PostgreSQL, DynamoDB, RDS), speisen Sie in ETL-Systeme ein oder führen Sie Abfragen direkt mit Tools wie Athena durch.
Die folgende einfache Anleitung soll Absendern helfen, sich wohl zu fühlen, wenn sie ein Bird-Events-WebHook erstellen und die Daten mit der Infrastruktur von AWS konsumieren.
Bird’s Echtzeit-Event-Webhooks sind ein unglaublich wertvolles Werkzeug für Absender, um Daten automatisch in ihre Systeme übertragen zu lassen. Dies kann nachgelagerte Automatisierungsvorgänge wie das Aktualisieren von Mailinglisten, das Auslösen automatisierter E-Mail-Reisen oder das Befüllen interner Dashboards ermöglichen. Während dieselben Ereignisdaten über das Bird UI mithilfe von Event Search oder programmatisch durch die Nutzung der Bird Events API abgerufen werden können, können Beschränkungen hinsichtlich der Anzahl von Datensätzen, die in einer einzigen Anfrage zurückgegeben werden, oder Geschwindigkeitsbegrenzungen, die für den API-Endpunkt gelten, beide Methoden für große und anspruchsvolle Absender einschränkend machen.
Echtzeit-Event-Webhooks ermöglichen es einem Absender, einen Endpunkt zu konfigurieren, an den Bird die Daten überträgt, und die Daten können konsumiert werden, ohne dass Cron-Jobs geplant werden müssen, die die Daten abrufen. Es gibt auch logistische Kompromisse, wenn Sie die Daten abrufen, anstatt sie an Sie senden zu lassen, wie z. B. die Notwendigkeit festzulegen, welchen Zeitraum und welche Parameter für jede API-Anfrage verwendet werden sollen. Wenn die Zeiträume nicht perfekt übereinstimmen, riskieren Sie, Daten zu verpassen, und wenn die Zeiträume sich überschneiden, müssen Sie doppelte Datensätze handhaben. Mit Echtzeit-Webhooks werden Ereignisdaten einfach an Ihren Endpunkt gesendet, sobald sie innerhalb von Bird verfügbar werden.
Während die Vorteile des Empfangs von Ereignisdaten in Echtzeit zur Steuerung nachgelagerter Automatisierungsprozesse von vielen Absendern sofort verstanden werden, kann der eigentliche Prozess der Implementierung und Nutzung von Webhooks einschüchternd wirken. Dies kann besonders dann zutreffen, wenn Sie mit den technischen Komponenten der Erstellung eines Endpunkts und der programmatischen Verarbeitung der Daten nicht vertraut sind. Es gibt Dienste, die Bird-Webhook-Daten konsumieren und automatisch in Ihre Datenbank ETL durchführen – ein Beispiel wäre StitchData, über das wir in der Vergangenheit gebloggt haben. Wenn Sie jedoch mehr Kontrolle über den Prozess wünschen, können Sie die Komponenten problemlos selbst erstellen. Das Folgende ist ein einfacher Leitfaden, damit sich Absender wohlfühlen, wenn sie einen Bird-Events-Webhook erstellen und die Daten mit der Infrastruktur innerhalb von AWS konsumieren.
Bird’s Echtzeit-Event-Webhooks sind ein unglaublich wertvolles Werkzeug für Absender, um Daten automatisch in ihre Systeme übertragen zu lassen. Dies kann nachgelagerte Automatisierungsvorgänge wie das Aktualisieren von Mailinglisten, das Auslösen automatisierter E-Mail-Reisen oder das Befüllen interner Dashboards ermöglichen. Während dieselben Ereignisdaten über das Bird UI mithilfe von Event Search oder programmatisch durch die Nutzung der Bird Events API abgerufen werden können, können Beschränkungen hinsichtlich der Anzahl von Datensätzen, die in einer einzigen Anfrage zurückgegeben werden, oder Geschwindigkeitsbegrenzungen, die für den API-Endpunkt gelten, beide Methoden für große und anspruchsvolle Absender einschränkend machen.
Echtzeit-Event-Webhooks ermöglichen es einem Absender, einen Endpunkt zu konfigurieren, an den Bird die Daten überträgt, und die Daten können konsumiert werden, ohne dass Cron-Jobs geplant werden müssen, die die Daten abrufen. Es gibt auch logistische Kompromisse, wenn Sie die Daten abrufen, anstatt sie an Sie senden zu lassen, wie z. B. die Notwendigkeit festzulegen, welchen Zeitraum und welche Parameter für jede API-Anfrage verwendet werden sollen. Wenn die Zeiträume nicht perfekt übereinstimmen, riskieren Sie, Daten zu verpassen, und wenn die Zeiträume sich überschneiden, müssen Sie doppelte Datensätze handhaben. Mit Echtzeit-Webhooks werden Ereignisdaten einfach an Ihren Endpunkt gesendet, sobald sie innerhalb von Bird verfügbar werden.
Während die Vorteile des Empfangs von Ereignisdaten in Echtzeit zur Steuerung nachgelagerter Automatisierungsprozesse von vielen Absendern sofort verstanden werden, kann der eigentliche Prozess der Implementierung und Nutzung von Webhooks einschüchternd wirken. Dies kann besonders dann zutreffen, wenn Sie mit den technischen Komponenten der Erstellung eines Endpunkts und der programmatischen Verarbeitung der Daten nicht vertraut sind. Es gibt Dienste, die Bird-Webhook-Daten konsumieren und automatisch in Ihre Datenbank ETL durchführen – ein Beispiel wäre StitchData, über das wir in der Vergangenheit gebloggt haben. Wenn Sie jedoch mehr Kontrolle über den Prozess wünschen, können Sie die Komponenten problemlos selbst erstellen. Das Folgende ist ein einfacher Leitfaden, damit sich Absender wohlfühlen, wenn sie einen Bird-Events-Webhook erstellen und die Daten mit der Infrastruktur innerhalb von AWS konsumieren.
Bird’s Echtzeit-Event-Webhooks sind ein unglaublich wertvolles Werkzeug für Absender, um Daten automatisch in ihre Systeme übertragen zu lassen. Dies kann nachgelagerte Automatisierungsvorgänge wie das Aktualisieren von Mailinglisten, das Auslösen automatisierter E-Mail-Reisen oder das Befüllen interner Dashboards ermöglichen. Während dieselben Ereignisdaten über das Bird UI mithilfe von Event Search oder programmatisch durch die Nutzung der Bird Events API abgerufen werden können, können Beschränkungen hinsichtlich der Anzahl von Datensätzen, die in einer einzigen Anfrage zurückgegeben werden, oder Geschwindigkeitsbegrenzungen, die für den API-Endpunkt gelten, beide Methoden für große und anspruchsvolle Absender einschränkend machen.
Echtzeit-Event-Webhooks ermöglichen es einem Absender, einen Endpunkt zu konfigurieren, an den Bird die Daten überträgt, und die Daten können konsumiert werden, ohne dass Cron-Jobs geplant werden müssen, die die Daten abrufen. Es gibt auch logistische Kompromisse, wenn Sie die Daten abrufen, anstatt sie an Sie senden zu lassen, wie z. B. die Notwendigkeit festzulegen, welchen Zeitraum und welche Parameter für jede API-Anfrage verwendet werden sollen. Wenn die Zeiträume nicht perfekt übereinstimmen, riskieren Sie, Daten zu verpassen, und wenn die Zeiträume sich überschneiden, müssen Sie doppelte Datensätze handhaben. Mit Echtzeit-Webhooks werden Ereignisdaten einfach an Ihren Endpunkt gesendet, sobald sie innerhalb von Bird verfügbar werden.
Während die Vorteile des Empfangs von Ereignisdaten in Echtzeit zur Steuerung nachgelagerter Automatisierungsprozesse von vielen Absendern sofort verstanden werden, kann der eigentliche Prozess der Implementierung und Nutzung von Webhooks einschüchternd wirken. Dies kann besonders dann zutreffen, wenn Sie mit den technischen Komponenten der Erstellung eines Endpunkts und der programmatischen Verarbeitung der Daten nicht vertraut sind. Es gibt Dienste, die Bird-Webhook-Daten konsumieren und automatisch in Ihre Datenbank ETL durchführen – ein Beispiel wäre StitchData, über das wir in der Vergangenheit gebloggt haben. Wenn Sie jedoch mehr Kontrolle über den Prozess wünschen, können Sie die Komponenten problemlos selbst erstellen. Das Folgende ist ein einfacher Leitfaden, damit sich Absender wohlfühlen, wenn sie einen Bird-Events-Webhook erstellen und die Daten mit der Infrastruktur innerhalb von AWS konsumieren.
Konfigurieren des Webhook Target Endpoint
Wenn ein Bird-Ereignis erstellt wird, möchten wir, dass die Ereignisdaten in Echtzeit zu einem Endpunkt in AWS gestreamt werden, damit wir diese Daten programmgesteuert konsumieren und nutzen können. Die Daten werden von Bird an einen Zielendpunkt gesendet, der die Nutzdaten an eine Lambda-Funktion weiterleitet, die die Daten verarbeitet und in einem S3-Bucket speichert. Ein schematisches Diagramm des beschriebenen Datenflusses ist unten zu sehen:
Um diesen Workflow zu implementieren, lassen Sie uns tatsächlich in umgekehrter Reihenfolge beginnen, indem wir einen S3-Bucket erstellen, in dem wir unsere Ereignisdaten speichern, und dann rückwärts arbeiten – jedes Element hinzufügen, das in das von uns Erstellte einspeist.
Wenn ein Bird-Ereignis erstellt wird, möchten wir, dass die Ereignisdaten in Echtzeit zu einem Endpunkt in AWS gestreamt werden, damit wir diese Daten programmgesteuert konsumieren und nutzen können. Die Daten werden von Bird an einen Zielendpunkt gesendet, der die Nutzdaten an eine Lambda-Funktion weiterleitet, die die Daten verarbeitet und in einem S3-Bucket speichert. Ein schematisches Diagramm des beschriebenen Datenflusses ist unten zu sehen:
Um diesen Workflow zu implementieren, lassen Sie uns tatsächlich in umgekehrter Reihenfolge beginnen, indem wir einen S3-Bucket erstellen, in dem wir unsere Ereignisdaten speichern, und dann rückwärts arbeiten – jedes Element hinzufügen, das in das von uns Erstellte einspeist.
Wenn ein Bird-Ereignis erstellt wird, möchten wir, dass die Ereignisdaten in Echtzeit zu einem Endpunkt in AWS gestreamt werden, damit wir diese Daten programmgesteuert konsumieren und nutzen können. Die Daten werden von Bird an einen Zielendpunkt gesendet, der die Nutzdaten an eine Lambda-Funktion weiterleitet, die die Daten verarbeitet und in einem S3-Bucket speichert. Ein schematisches Diagramm des beschriebenen Datenflusses ist unten zu sehen:
Um diesen Workflow zu implementieren, lassen Sie uns tatsächlich in umgekehrter Reihenfolge beginnen, indem wir einen S3-Bucket erstellen, in dem wir unsere Ereignisdaten speichern, und dann rückwärts arbeiten – jedes Element hinzufügen, das in das von uns Erstellte einspeist.
Erstellen Sie einen S3 Bucket, um die Webhook-Daten zu speichern
Bevor wir unseren Load Balancer erstellen, um die Daten zu akzeptieren, oder unsere Lambda-Funktion, um die Daten zu speichern, müssen wir zuerst unseren S3-Bucket erstellen, in dem die Daten gespeichert werden. Während S3 hervorragenden Speicher für Webhook-Daten bietet, sollten Organisationen, die auch PostgreSQL-Datenbanken für die Ereignisverarbeitung verwenden, ordnungsgemäße Backup- und Wiederherstellungsverfahren implementieren, um ihre strukturierten Daten zusammen mit ihrer S3-Speicherstrategie zu schützen. Gehen Sie dazu zum S3-Dienst innerhalb von AWS und drücken Sie „Create Bucket“. Sie werden aufgefordert, Ihrem Bucket einen Namen zuzuweisen und die Region festzulegen – stellen Sie sicher, dass Sie dieselbe Region wie Ihren ALB und die Lambda-Funktion verwenden. Wenn Ihr S3-Bucket erstellt wird, ist er leer – wenn Sie die Daten in einem Ordner organisieren möchten, können Sie entweder das beabsichtigte Verzeichnis jetzt erstellen oder das Verzeichnis wird erstellt, wenn Ihre Lambda-Funktion die Datei speichert. In diesem Beispiel haben wir unseren S3-Bucket „bird-webhooks“ genannt und einen Ordner namens „B Event Data“ erstellt, um unsere Ereignisdaten zu speichern – diese Namen werden in unserer Lambda-Funktion unten referenziert.
Bevor wir unseren Load Balancer erstellen, um die Daten zu akzeptieren, oder unsere Lambda-Funktion, um die Daten zu speichern, müssen wir zuerst unseren S3-Bucket erstellen, in dem die Daten gespeichert werden. Während S3 hervorragenden Speicher für Webhook-Daten bietet, sollten Organisationen, die auch PostgreSQL-Datenbanken für die Ereignisverarbeitung verwenden, ordnungsgemäße Backup- und Wiederherstellungsverfahren implementieren, um ihre strukturierten Daten zusammen mit ihrer S3-Speicherstrategie zu schützen. Gehen Sie dazu zum S3-Dienst innerhalb von AWS und drücken Sie „Create Bucket“. Sie werden aufgefordert, Ihrem Bucket einen Namen zuzuweisen und die Region festzulegen – stellen Sie sicher, dass Sie dieselbe Region wie Ihren ALB und die Lambda-Funktion verwenden. Wenn Ihr S3-Bucket erstellt wird, ist er leer – wenn Sie die Daten in einem Ordner organisieren möchten, können Sie entweder das beabsichtigte Verzeichnis jetzt erstellen oder das Verzeichnis wird erstellt, wenn Ihre Lambda-Funktion die Datei speichert. In diesem Beispiel haben wir unseren S3-Bucket „bird-webhooks“ genannt und einen Ordner namens „B Event Data“ erstellt, um unsere Ereignisdaten zu speichern – diese Namen werden in unserer Lambda-Funktion unten referenziert.
Bevor wir unseren Load Balancer erstellen, um die Daten zu akzeptieren, oder unsere Lambda-Funktion, um die Daten zu speichern, müssen wir zuerst unseren S3-Bucket erstellen, in dem die Daten gespeichert werden. Während S3 hervorragenden Speicher für Webhook-Daten bietet, sollten Organisationen, die auch PostgreSQL-Datenbanken für die Ereignisverarbeitung verwenden, ordnungsgemäße Backup- und Wiederherstellungsverfahren implementieren, um ihre strukturierten Daten zusammen mit ihrer S3-Speicherstrategie zu schützen. Gehen Sie dazu zum S3-Dienst innerhalb von AWS und drücken Sie „Create Bucket“. Sie werden aufgefordert, Ihrem Bucket einen Namen zuzuweisen und die Region festzulegen – stellen Sie sicher, dass Sie dieselbe Region wie Ihren ALB und die Lambda-Funktion verwenden. Wenn Ihr S3-Bucket erstellt wird, ist er leer – wenn Sie die Daten in einem Ordner organisieren möchten, können Sie entweder das beabsichtigte Verzeichnis jetzt erstellen oder das Verzeichnis wird erstellt, wenn Ihre Lambda-Funktion die Datei speichert. In diesem Beispiel haben wir unseren S3-Bucket „bird-webhooks“ genannt und einen Ordner namens „B Event Data“ erstellt, um unsere Ereignisdaten zu speichern – diese Namen werden in unserer Lambda-Funktion unten referenziert.
Erstellen Sie eine Lambda Function, um die Daten zu konsumieren
Die eigentliche Verarbeitung und Speicherung der Daten wird von einer lambda function durchgeführt, die durch unseren Application Load Balancer (ALB) aufgerufen wird.
Der erste Schritt ist das Erstellen Ihrer lambda function, indem Sie zum Lambda-Dienst innerhalb von AWS navigieren und auf „Create Function“ klicken. Sie werden aufgefordert, Ihrer lambda function einen Namen zuzuweisen und die Programmiersprache auszuwählen, in der Sie Ihre Funktion schreiben möchten. In diesem Beispiel verwenden wir Python als Laufzeitsprache.
Nun müssen wir unsere lambda function entwickeln. Nehmen wir für einen Moment an, dass unser Application Load Balancer konfiguriert und das Webhook-Payload an unsere lambda function weiterleitet – die Lambda empfängt ein Payload inklusive der vollständigen Header und des Körpers. Das Payload wird unter Verwendung des Objekts „event“ als Wörterbuch in unsere lambda function übergeben. Sie können unabhängig auf die Header und den Körper des Payloads zugreifen, indem Sie die „headers“- und „body“-Objekte innerhalb des Payloads aufrufen. In diesem Beispiel lesen wir einfach den „x-messagesystems-batch-id“-Header, bei dem die Batch-ID ein eindeutiger Wert ist, der von Bird für den Webhook-Batch erstellt wird, und verwenden ihn als Dateinamen, wenn der Körper als Flat-File in S3 gespeichert wird. Möglicherweise möchten Sie jedoch zusätzliche Funktionen wie Authentifizierungsüberprüfungen oder Fehlerbehandlung hinzufügen, falls erforderlich.
Beim Speichern des Payloads als Flat-File auf S3 müssen wir den Namen des S3-Buckets, den Speicherort und den Dateinamen der Datei definieren, in der die Payload-Daten gespeichert werden. In unserer Beispiel-lambda function machen wir dies innerhalb der „store_batch“-Funktion. In diesem Beispiel speichern wir das gesamte Batch als eine einzige Datei, was dazu beiträgt sicherzustellen, dass die Daten gesammelt und gespeichert werden, bevor die HTTP-Verbindung zwischen Bird und Ihrem Endpunkt abläuft. Während Sie die Verbindungstimeout-Einstellungen auf Ihrem Load Balancer anpassen könnten, gibt es keine Garantie, dass die Verbindung nicht auf der Übertragungsseite (in diesem Fall Bird) abläuft oder dass die Verbindung nicht beendet wird, bevor Ihre lambda function die Ausführung abschließt. Es ist eine bewährte Praxis, Ihre Konsumentenfunktion so effizient wie möglich zu halten und Datenverarbeitungsaktivitäten nach Möglichkeit für nachgelagerte Prozesse zu reservieren – wie das Umwandeln des gebündelten JSON-formatierten Payloads in eine CSV-Datei oder das Laden der Ereignisdaten in eine Datenbank.
Es ist wichtig zu beachten, dass Sie möglicherweise die Berechtigungen für Ihre lambda function aktualisieren müssen. Ihre Ausführungsrolle benötigt PutObject- und GetObject-Berechtigungen für S3. Es ist eine bewährte Praxis, das Prinzip des geringsten Privilegs durchzusetzen, daher empfehle ich, diese Berechtigungen nur für den S3-Bucket einzurichten, in dem die Webhook-Payloads gespeichert werden.
Ein Beispiel unserer Consumer-lambda function finden Sie hier.
Ein kurzer Hinweis zur Batch-ID: Bird wird Ereignisse bündeln in ein einziges Payload, bei dem jeder Batch 1 bis 350 oder mehr Ereignisdatensätze enthalten kann. Der Batch erhält eine eindeutige Batch-ID, die verwendet werden kann, um den Status des Batches anzuzeigen, indem die Event Webhooks API genutzt wird oder indem Sie in Ihrem Bird-Konto auf einen webhook stream klicken und „Batch Status“ auswählen. Falls ein Webhook-Payload nicht zugestellt werden konnte, etwa während einer Verbindungstimeout, wird Bird den Batch automatisch unter Verwendung der gleichen Batch-ID erneut versuchen. Dies kann geschehen, wenn Ihre lambda function nahe an der maximalen Round-Trip-Zeit von 10 Sekunden liegt und ist ein Grund dafür, die Konsumentenfunktion zu optimieren, um die Ausführungszeit zu reduzieren.
Um alle Datenverarbeitungsaktivitäten zu bearbeiten, empfehle ich, eine separate lambda function zu erstellen, die immer dann ausgeführt wird, wenn eine neue Datei im S3-Bucket erstellt wird – auf diese Weise wird die Datenverarbeitung asynchron zur Übertragung der Daten durchgeführt, und es besteht kein Risiko, Daten aufgrund einer unterbrochenen Verbindung zu verlieren. Ich bespreche die Processing-lambda function in einem späteren Abschnitt.
Die eigentliche Verarbeitung und Speicherung der Daten wird von einer lambda function durchgeführt, die durch unseren Application Load Balancer (ALB) aufgerufen wird.
Der erste Schritt ist das Erstellen Ihrer lambda function, indem Sie zum Lambda-Dienst innerhalb von AWS navigieren und auf „Create Function“ klicken. Sie werden aufgefordert, Ihrer lambda function einen Namen zuzuweisen und die Programmiersprache auszuwählen, in der Sie Ihre Funktion schreiben möchten. In diesem Beispiel verwenden wir Python als Laufzeitsprache.
Nun müssen wir unsere lambda function entwickeln. Nehmen wir für einen Moment an, dass unser Application Load Balancer konfiguriert und das Webhook-Payload an unsere lambda function weiterleitet – die Lambda empfängt ein Payload inklusive der vollständigen Header und des Körpers. Das Payload wird unter Verwendung des Objekts „event“ als Wörterbuch in unsere lambda function übergeben. Sie können unabhängig auf die Header und den Körper des Payloads zugreifen, indem Sie die „headers“- und „body“-Objekte innerhalb des Payloads aufrufen. In diesem Beispiel lesen wir einfach den „x-messagesystems-batch-id“-Header, bei dem die Batch-ID ein eindeutiger Wert ist, der von Bird für den Webhook-Batch erstellt wird, und verwenden ihn als Dateinamen, wenn der Körper als Flat-File in S3 gespeichert wird. Möglicherweise möchten Sie jedoch zusätzliche Funktionen wie Authentifizierungsüberprüfungen oder Fehlerbehandlung hinzufügen, falls erforderlich.
Beim Speichern des Payloads als Flat-File auf S3 müssen wir den Namen des S3-Buckets, den Speicherort und den Dateinamen der Datei definieren, in der die Payload-Daten gespeichert werden. In unserer Beispiel-lambda function machen wir dies innerhalb der „store_batch“-Funktion. In diesem Beispiel speichern wir das gesamte Batch als eine einzige Datei, was dazu beiträgt sicherzustellen, dass die Daten gesammelt und gespeichert werden, bevor die HTTP-Verbindung zwischen Bird und Ihrem Endpunkt abläuft. Während Sie die Verbindungstimeout-Einstellungen auf Ihrem Load Balancer anpassen könnten, gibt es keine Garantie, dass die Verbindung nicht auf der Übertragungsseite (in diesem Fall Bird) abläuft oder dass die Verbindung nicht beendet wird, bevor Ihre lambda function die Ausführung abschließt. Es ist eine bewährte Praxis, Ihre Konsumentenfunktion so effizient wie möglich zu halten und Datenverarbeitungsaktivitäten nach Möglichkeit für nachgelagerte Prozesse zu reservieren – wie das Umwandeln des gebündelten JSON-formatierten Payloads in eine CSV-Datei oder das Laden der Ereignisdaten in eine Datenbank.
Es ist wichtig zu beachten, dass Sie möglicherweise die Berechtigungen für Ihre lambda function aktualisieren müssen. Ihre Ausführungsrolle benötigt PutObject- und GetObject-Berechtigungen für S3. Es ist eine bewährte Praxis, das Prinzip des geringsten Privilegs durchzusetzen, daher empfehle ich, diese Berechtigungen nur für den S3-Bucket einzurichten, in dem die Webhook-Payloads gespeichert werden.
Ein Beispiel unserer Consumer-lambda function finden Sie hier.
Ein kurzer Hinweis zur Batch-ID: Bird wird Ereignisse bündeln in ein einziges Payload, bei dem jeder Batch 1 bis 350 oder mehr Ereignisdatensätze enthalten kann. Der Batch erhält eine eindeutige Batch-ID, die verwendet werden kann, um den Status des Batches anzuzeigen, indem die Event Webhooks API genutzt wird oder indem Sie in Ihrem Bird-Konto auf einen webhook stream klicken und „Batch Status“ auswählen. Falls ein Webhook-Payload nicht zugestellt werden konnte, etwa während einer Verbindungstimeout, wird Bird den Batch automatisch unter Verwendung der gleichen Batch-ID erneut versuchen. Dies kann geschehen, wenn Ihre lambda function nahe an der maximalen Round-Trip-Zeit von 10 Sekunden liegt und ist ein Grund dafür, die Konsumentenfunktion zu optimieren, um die Ausführungszeit zu reduzieren.
Um alle Datenverarbeitungsaktivitäten zu bearbeiten, empfehle ich, eine separate lambda function zu erstellen, die immer dann ausgeführt wird, wenn eine neue Datei im S3-Bucket erstellt wird – auf diese Weise wird die Datenverarbeitung asynchron zur Übertragung der Daten durchgeführt, und es besteht kein Risiko, Daten aufgrund einer unterbrochenen Verbindung zu verlieren. Ich bespreche die Processing-lambda function in einem späteren Abschnitt.
Die eigentliche Verarbeitung und Speicherung der Daten wird von einer lambda function durchgeführt, die durch unseren Application Load Balancer (ALB) aufgerufen wird.
Der erste Schritt ist das Erstellen Ihrer lambda function, indem Sie zum Lambda-Dienst innerhalb von AWS navigieren und auf „Create Function“ klicken. Sie werden aufgefordert, Ihrer lambda function einen Namen zuzuweisen und die Programmiersprache auszuwählen, in der Sie Ihre Funktion schreiben möchten. In diesem Beispiel verwenden wir Python als Laufzeitsprache.
Nun müssen wir unsere lambda function entwickeln. Nehmen wir für einen Moment an, dass unser Application Load Balancer konfiguriert und das Webhook-Payload an unsere lambda function weiterleitet – die Lambda empfängt ein Payload inklusive der vollständigen Header und des Körpers. Das Payload wird unter Verwendung des Objekts „event“ als Wörterbuch in unsere lambda function übergeben. Sie können unabhängig auf die Header und den Körper des Payloads zugreifen, indem Sie die „headers“- und „body“-Objekte innerhalb des Payloads aufrufen. In diesem Beispiel lesen wir einfach den „x-messagesystems-batch-id“-Header, bei dem die Batch-ID ein eindeutiger Wert ist, der von Bird für den Webhook-Batch erstellt wird, und verwenden ihn als Dateinamen, wenn der Körper als Flat-File in S3 gespeichert wird. Möglicherweise möchten Sie jedoch zusätzliche Funktionen wie Authentifizierungsüberprüfungen oder Fehlerbehandlung hinzufügen, falls erforderlich.
Beim Speichern des Payloads als Flat-File auf S3 müssen wir den Namen des S3-Buckets, den Speicherort und den Dateinamen der Datei definieren, in der die Payload-Daten gespeichert werden. In unserer Beispiel-lambda function machen wir dies innerhalb der „store_batch“-Funktion. In diesem Beispiel speichern wir das gesamte Batch als eine einzige Datei, was dazu beiträgt sicherzustellen, dass die Daten gesammelt und gespeichert werden, bevor die HTTP-Verbindung zwischen Bird und Ihrem Endpunkt abläuft. Während Sie die Verbindungstimeout-Einstellungen auf Ihrem Load Balancer anpassen könnten, gibt es keine Garantie, dass die Verbindung nicht auf der Übertragungsseite (in diesem Fall Bird) abläuft oder dass die Verbindung nicht beendet wird, bevor Ihre lambda function die Ausführung abschließt. Es ist eine bewährte Praxis, Ihre Konsumentenfunktion so effizient wie möglich zu halten und Datenverarbeitungsaktivitäten nach Möglichkeit für nachgelagerte Prozesse zu reservieren – wie das Umwandeln des gebündelten JSON-formatierten Payloads in eine CSV-Datei oder das Laden der Ereignisdaten in eine Datenbank.
Es ist wichtig zu beachten, dass Sie möglicherweise die Berechtigungen für Ihre lambda function aktualisieren müssen. Ihre Ausführungsrolle benötigt PutObject- und GetObject-Berechtigungen für S3. Es ist eine bewährte Praxis, das Prinzip des geringsten Privilegs durchzusetzen, daher empfehle ich, diese Berechtigungen nur für den S3-Bucket einzurichten, in dem die Webhook-Payloads gespeichert werden.
Ein Beispiel unserer Consumer-lambda function finden Sie hier.
Ein kurzer Hinweis zur Batch-ID: Bird wird Ereignisse bündeln in ein einziges Payload, bei dem jeder Batch 1 bis 350 oder mehr Ereignisdatensätze enthalten kann. Der Batch erhält eine eindeutige Batch-ID, die verwendet werden kann, um den Status des Batches anzuzeigen, indem die Event Webhooks API genutzt wird oder indem Sie in Ihrem Bird-Konto auf einen webhook stream klicken und „Batch Status“ auswählen. Falls ein Webhook-Payload nicht zugestellt werden konnte, etwa während einer Verbindungstimeout, wird Bird den Batch automatisch unter Verwendung der gleichen Batch-ID erneut versuchen. Dies kann geschehen, wenn Ihre lambda function nahe an der maximalen Round-Trip-Zeit von 10 Sekunden liegt und ist ein Grund dafür, die Konsumentenfunktion zu optimieren, um die Ausführungszeit zu reduzieren.
Um alle Datenverarbeitungsaktivitäten zu bearbeiten, empfehle ich, eine separate lambda function zu erstellen, die immer dann ausgeführt wird, wenn eine neue Datei im S3-Bucket erstellt wird – auf diese Weise wird die Datenverarbeitung asynchron zur Übertragung der Daten durchgeführt, und es besteht kein Risiko, Daten aufgrund einer unterbrochenen Verbindung zu verlieren. Ich bespreche die Processing-lambda function in einem späteren Abschnitt.
Erstellen Sie einen Application Load Balancer
Um ein Webhook-Payload zu empfangen, müssen wir einen Endpunkt bereitstellen, an den die Payloads gesendet werden. Dies tun wir, indem wir innerhalb von AWS einen Application Load Balancer erstellen. Dazu navigieren wir zu EC2 > Load Balancers und klicken auf „Create Load Balancer“. Sie werden aufgefordert zu wählen, welche Art von Load Balancer Sie erstellen möchten – dafür wollen wir einen Application Load Balancer erstellen. Wir benötigen einen Application Load Balancer (ALB), um unseren Consumer zu erstellen, da die Event-Webhooks als HTTP-Anfragen gesendet werden und ALBs innerhalb von AWS zum Routing von HTTP-Anfragen verwendet werden. Wir könnten alternativ ein HTTP Gateway implementieren; jedoch verwenden wir für dieses Projekt einen ALB, da er leichter und kostengünstiger als ein HTTP Gateway ist. Es ist wichtig zu beachten, dass, wenn Sie sich entscheiden, ein HTTP Gateway zu verwenden, das Ereignisformat möglicherweise anders ist als bei einem ALB, und daher muss Ihre Lambda-Funktion das Anforderungsobjekt entsprechend verarbeiten.
Sobald Ihr ALB erstellt wurde, werden Sie aufgefordert, einen Namen für Ihren ALB zu vergeben und das Schema sowie die Zugriffs-/Sicherheitseinstellungen zu konfigurieren – da wir planen, Ereignisdaten von einer externen Quelle (Bird) zu empfangen, möchten wir, dass unser ALB internetorientiert ist. Unter „Listeners and routing“ sollte der ALB auf Port 443 auf HTTPS hören, und wir möchten eine Zielgruppe erstellen, die auf unsere Lambda-Funktion verweist, damit unser ALB eingehende Anfragen an die oben erstellte Consume-Lambda-Funktion weiterleiten kann. Sie müssen auch sicherstellen, dass die Sicherheitsgruppe die Berechtigung hat, den Datenverkehr über Port 443 zu akzeptieren.
Um ein Webhook-Payload zu empfangen, müssen wir einen Endpunkt bereitstellen, an den die Payloads gesendet werden. Dies tun wir, indem wir innerhalb von AWS einen Application Load Balancer erstellen. Dazu navigieren wir zu EC2 > Load Balancers und klicken auf „Create Load Balancer“. Sie werden aufgefordert zu wählen, welche Art von Load Balancer Sie erstellen möchten – dafür wollen wir einen Application Load Balancer erstellen. Wir benötigen einen Application Load Balancer (ALB), um unseren Consumer zu erstellen, da die Event-Webhooks als HTTP-Anfragen gesendet werden und ALBs innerhalb von AWS zum Routing von HTTP-Anfragen verwendet werden. Wir könnten alternativ ein HTTP Gateway implementieren; jedoch verwenden wir für dieses Projekt einen ALB, da er leichter und kostengünstiger als ein HTTP Gateway ist. Es ist wichtig zu beachten, dass, wenn Sie sich entscheiden, ein HTTP Gateway zu verwenden, das Ereignisformat möglicherweise anders ist als bei einem ALB, und daher muss Ihre Lambda-Funktion das Anforderungsobjekt entsprechend verarbeiten.
Sobald Ihr ALB erstellt wurde, werden Sie aufgefordert, einen Namen für Ihren ALB zu vergeben und das Schema sowie die Zugriffs-/Sicherheitseinstellungen zu konfigurieren – da wir planen, Ereignisdaten von einer externen Quelle (Bird) zu empfangen, möchten wir, dass unser ALB internetorientiert ist. Unter „Listeners and routing“ sollte der ALB auf Port 443 auf HTTPS hören, und wir möchten eine Zielgruppe erstellen, die auf unsere Lambda-Funktion verweist, damit unser ALB eingehende Anfragen an die oben erstellte Consume-Lambda-Funktion weiterleiten kann. Sie müssen auch sicherstellen, dass die Sicherheitsgruppe die Berechtigung hat, den Datenverkehr über Port 443 zu akzeptieren.
Um ein Webhook-Payload zu empfangen, müssen wir einen Endpunkt bereitstellen, an den die Payloads gesendet werden. Dies tun wir, indem wir innerhalb von AWS einen Application Load Balancer erstellen. Dazu navigieren wir zu EC2 > Load Balancers und klicken auf „Create Load Balancer“. Sie werden aufgefordert zu wählen, welche Art von Load Balancer Sie erstellen möchten – dafür wollen wir einen Application Load Balancer erstellen. Wir benötigen einen Application Load Balancer (ALB), um unseren Consumer zu erstellen, da die Event-Webhooks als HTTP-Anfragen gesendet werden und ALBs innerhalb von AWS zum Routing von HTTP-Anfragen verwendet werden. Wir könnten alternativ ein HTTP Gateway implementieren; jedoch verwenden wir für dieses Projekt einen ALB, da er leichter und kostengünstiger als ein HTTP Gateway ist. Es ist wichtig zu beachten, dass, wenn Sie sich entscheiden, ein HTTP Gateway zu verwenden, das Ereignisformat möglicherweise anders ist als bei einem ALB, und daher muss Ihre Lambda-Funktion das Anforderungsobjekt entsprechend verarbeiten.
Sobald Ihr ALB erstellt wurde, werden Sie aufgefordert, einen Namen für Ihren ALB zu vergeben und das Schema sowie die Zugriffs-/Sicherheitseinstellungen zu konfigurieren – da wir planen, Ereignisdaten von einer externen Quelle (Bird) zu empfangen, möchten wir, dass unser ALB internetorientiert ist. Unter „Listeners and routing“ sollte der ALB auf Port 443 auf HTTPS hören, und wir möchten eine Zielgruppe erstellen, die auf unsere Lambda-Funktion verweist, damit unser ALB eingehende Anfragen an die oben erstellte Consume-Lambda-Funktion weiterleiten kann. Sie müssen auch sicherstellen, dass die Sicherheitsgruppe die Berechtigung hat, den Datenverkehr über Port 443 zu akzeptieren.
Erstellen Sie einen DNS-Eintrag für den Load Balancer
Um es uns zu erleichtern, unser ALB als Endpunkt zu nutzen, werden wir einen A-Eintrag im DNS erstellen, der auf unser ALB verweist. Hierfür können wir den AWS Route 53-Dienst (oder Ihren aktuellen DNS-Anbieter) verwenden und einen A-Eintrag für den Hostnamen erstellen, den Sie für Ihren Endpunkt verwenden möchten (z.B. spevents.<deine_domain>). Bei der Arbeit mit DNS in großem Maßstab auf AWS sollten Sie sich bewusst sein, dass es undokumentierte DNS-Limits gibt, die sich auf Anwendungen mit hohem Volumen auswirken können, insbesondere auf solche, die große Mengen ausgehender Datenströme wie E-Mail-Zustellungssysteme verarbeiten. Der A-Eintrag sollte so konfiguriert werden, dass er auf das von uns erstellte ALB verweist. Wenn Sie Route 53 zur Verwaltung der DNS-Einträge verwenden, können Sie die ALB-Instanz direkt referenzieren, indem Sie „Alias“ aktivieren und das ALB auswählen; andernfalls sollten Sie, wenn Sie einen externen DNS-Anbieter verwenden, den A-Eintrag auf die öffentliche IP-Adresse der ALB-Instanz verweisen lassen.
Ich empfehle, ein Tool wie Postman zu verwenden, um zu testen, ob alles korrekt konfiguriert wurde, bevor Sie Ihren Bird-Webhook aktivieren. Sie können eine POST-Anfrage an Ihren Endpunkt senden und bestätigen, dass eine Antwort empfangen wird. Wenn Ihre POST-Anfrage keine Antwort zurückgibt, müssen Sie möglicherweise überprüfen, ob Ihr ALB auf den richtigen Port hört.
Um es uns zu erleichtern, unser ALB als Endpunkt zu nutzen, werden wir einen A-Eintrag im DNS erstellen, der auf unser ALB verweist. Hierfür können wir den AWS Route 53-Dienst (oder Ihren aktuellen DNS-Anbieter) verwenden und einen A-Eintrag für den Hostnamen erstellen, den Sie für Ihren Endpunkt verwenden möchten (z.B. spevents.<deine_domain>). Bei der Arbeit mit DNS in großem Maßstab auf AWS sollten Sie sich bewusst sein, dass es undokumentierte DNS-Limits gibt, die sich auf Anwendungen mit hohem Volumen auswirken können, insbesondere auf solche, die große Mengen ausgehender Datenströme wie E-Mail-Zustellungssysteme verarbeiten. Der A-Eintrag sollte so konfiguriert werden, dass er auf das von uns erstellte ALB verweist. Wenn Sie Route 53 zur Verwaltung der DNS-Einträge verwenden, können Sie die ALB-Instanz direkt referenzieren, indem Sie „Alias“ aktivieren und das ALB auswählen; andernfalls sollten Sie, wenn Sie einen externen DNS-Anbieter verwenden, den A-Eintrag auf die öffentliche IP-Adresse der ALB-Instanz verweisen lassen.
Ich empfehle, ein Tool wie Postman zu verwenden, um zu testen, ob alles korrekt konfiguriert wurde, bevor Sie Ihren Bird-Webhook aktivieren. Sie können eine POST-Anfrage an Ihren Endpunkt senden und bestätigen, dass eine Antwort empfangen wird. Wenn Ihre POST-Anfrage keine Antwort zurückgibt, müssen Sie möglicherweise überprüfen, ob Ihr ALB auf den richtigen Port hört.
Um es uns zu erleichtern, unser ALB als Endpunkt zu nutzen, werden wir einen A-Eintrag im DNS erstellen, der auf unser ALB verweist. Hierfür können wir den AWS Route 53-Dienst (oder Ihren aktuellen DNS-Anbieter) verwenden und einen A-Eintrag für den Hostnamen erstellen, den Sie für Ihren Endpunkt verwenden möchten (z.B. spevents.<deine_domain>). Bei der Arbeit mit DNS in großem Maßstab auf AWS sollten Sie sich bewusst sein, dass es undokumentierte DNS-Limits gibt, die sich auf Anwendungen mit hohem Volumen auswirken können, insbesondere auf solche, die große Mengen ausgehender Datenströme wie E-Mail-Zustellungssysteme verarbeiten. Der A-Eintrag sollte so konfiguriert werden, dass er auf das von uns erstellte ALB verweist. Wenn Sie Route 53 zur Verwaltung der DNS-Einträge verwenden, können Sie die ALB-Instanz direkt referenzieren, indem Sie „Alias“ aktivieren und das ALB auswählen; andernfalls sollten Sie, wenn Sie einen externen DNS-Anbieter verwenden, den A-Eintrag auf die öffentliche IP-Adresse der ALB-Instanz verweisen lassen.
Ich empfehle, ein Tool wie Postman zu verwenden, um zu testen, ob alles korrekt konfiguriert wurde, bevor Sie Ihren Bird-Webhook aktivieren. Sie können eine POST-Anfrage an Ihren Endpunkt senden und bestätigen, dass eine Antwort empfangen wird. Wenn Ihre POST-Anfrage keine Antwort zurückgibt, müssen Sie möglicherweise überprüfen, ob Ihr ALB auf den richtigen Port hört.
Erstellen Sie einen Bird Webhook
Jetzt sind wir bereit, den Webhook in Bird zu erstellen und den oben definierten Hostnamen als unser Ziel-Endpunkt zu verwenden. Um den Webhook zu erstellen, navigieren Sie zum Webhooks-Bereich in Ihrem Bird-Konto und klicken Sie auf „Create Webhook.“ Sie werden aufgefordert, einen Namen für Ihren Webhook zu vergeben und eine Ziel-URL anzugeben – das Ziel sollte der Hostname des zuvor erstellten A-Eintrags sein. Beachten Sie, dass die Ziel-URL möglicherweise „HTTPS://“ in der URL enthalten muss.
Sobald dies abgeschlossen ist, vergewissern Sie sich, dass das korrekte Unterkonto und die Ereignisse ausgewählt sind, und drücken Sie auf „Create Webhook“, um Ihre Konfiguration zu speichern. Die Ereignisdaten für alle ausgewählten Ereignistypen werden jetzt zu unserer Ziel-URL gestreamt und von unserem ALB für die nachgelagerte Verarbeitung verwendet.
Jetzt sind wir bereit, den Webhook in Bird zu erstellen und den oben definierten Hostnamen als unser Ziel-Endpunkt zu verwenden. Um den Webhook zu erstellen, navigieren Sie zum Webhooks-Bereich in Ihrem Bird-Konto und klicken Sie auf „Create Webhook.“ Sie werden aufgefordert, einen Namen für Ihren Webhook zu vergeben und eine Ziel-URL anzugeben – das Ziel sollte der Hostname des zuvor erstellten A-Eintrags sein. Beachten Sie, dass die Ziel-URL möglicherweise „HTTPS://“ in der URL enthalten muss.
Sobald dies abgeschlossen ist, vergewissern Sie sich, dass das korrekte Unterkonto und die Ereignisse ausgewählt sind, und drücken Sie auf „Create Webhook“, um Ihre Konfiguration zu speichern. Die Ereignisdaten für alle ausgewählten Ereignistypen werden jetzt zu unserer Ziel-URL gestreamt und von unserem ALB für die nachgelagerte Verarbeitung verwendet.
Jetzt sind wir bereit, den Webhook in Bird zu erstellen und den oben definierten Hostnamen als unser Ziel-Endpunkt zu verwenden. Um den Webhook zu erstellen, navigieren Sie zum Webhooks-Bereich in Ihrem Bird-Konto und klicken Sie auf „Create Webhook.“ Sie werden aufgefordert, einen Namen für Ihren Webhook zu vergeben und eine Ziel-URL anzugeben – das Ziel sollte der Hostname des zuvor erstellten A-Eintrags sein. Beachten Sie, dass die Ziel-URL möglicherweise „HTTPS://“ in der URL enthalten muss.
Sobald dies abgeschlossen ist, vergewissern Sie sich, dass das korrekte Unterkonto und die Ereignisse ausgewählt sind, und drücken Sie auf „Create Webhook“, um Ihre Konfiguration zu speichern. Die Ereignisdaten für alle ausgewählten Ereignistypen werden jetzt zu unserer Ziel-URL gestreamt und von unserem ALB für die nachgelagerte Verarbeitung verwendet.
Verarbeitung von Webhook Event Data
Abhängig vom vorgesehenen Zweck für die Speicherung der Bird-Ereignisdaten können Ihre Anforderungen möglicherweise einfach durch die Speicherung der JSON-Nutzlast als Flachdatei erfüllt werden. Sie haben möglicherweise auch bereits einen Downstream-ETL-Prozess etabliert, der fähig ist, Daten im JSON-Format zu konsumieren und zu laden. In beiden dieser Fälle können Sie möglicherweise die durch unser oben erstelltes Verarbeitungslambda erzeugte Flachdatei unverändert verwenden.
Alternativ müssen Sie möglicherweise die Daten transformieren – beispielsweise um von einem JSON-Format in ein CSV-Format zu konvertieren – oder die Daten direkt in eine Datenbank laden. In diesem Beispiel werden wir eine einfache Lambda-Funktion erstellen, die die Webhook-Daten vom ursprünglichen JSON-Format in eine CSV-Datei konvertiert, die in eine Datenbank geladen werden könnte.
Abhängig vom vorgesehenen Zweck für die Speicherung der Bird-Ereignisdaten können Ihre Anforderungen möglicherweise einfach durch die Speicherung der JSON-Nutzlast als Flachdatei erfüllt werden. Sie haben möglicherweise auch bereits einen Downstream-ETL-Prozess etabliert, der fähig ist, Daten im JSON-Format zu konsumieren und zu laden. In beiden dieser Fälle können Sie möglicherweise die durch unser oben erstelltes Verarbeitungslambda erzeugte Flachdatei unverändert verwenden.
Alternativ müssen Sie möglicherweise die Daten transformieren – beispielsweise um von einem JSON-Format in ein CSV-Format zu konvertieren – oder die Daten direkt in eine Datenbank laden. In diesem Beispiel werden wir eine einfache Lambda-Funktion erstellen, die die Webhook-Daten vom ursprünglichen JSON-Format in eine CSV-Datei konvertiert, die in eine Datenbank geladen werden könnte.
Abhängig vom vorgesehenen Zweck für die Speicherung der Bird-Ereignisdaten können Ihre Anforderungen möglicherweise einfach durch die Speicherung der JSON-Nutzlast als Flachdatei erfüllt werden. Sie haben möglicherweise auch bereits einen Downstream-ETL-Prozess etabliert, der fähig ist, Daten im JSON-Format zu konsumieren und zu laden. In beiden dieser Fälle können Sie möglicherweise die durch unser oben erstelltes Verarbeitungslambda erzeugte Flachdatei unverändert verwenden.
Alternativ müssen Sie möglicherweise die Daten transformieren – beispielsweise um von einem JSON-Format in ein CSV-Format zu konvertieren – oder die Daten direkt in eine Datenbank laden. In diesem Beispiel werden wir eine einfache Lambda-Funktion erstellen, die die Webhook-Daten vom ursprünglichen JSON-Format in eine CSV-Datei konvertiert, die in eine Datenbank geladen werden könnte.
Erstellen Sie eine Lambda, um die Daten zu verarbeiten
Wie bei der Lambda-Funktion zur Verarbeitung der Webhook-Daten müssen wir eine neue Lambda-Funktion erstellen, indem wir zum Lambda-Dienst innerhalb von AWS navigieren und auf „Funktion erstellen“ drücken. Diese neue Lambda-Funktion wird ausgelöst, wenn eine neue Datei in unserem S3-Bucket erstellt wird – sie liest die Daten und wandelt sie in eine neue CSV-Datei um.
Die Lambda-Funktion akzeptiert die Dateiinformationen als Ereignis. In der Beispiel-Lambda-Funktion sehen Sie, dass wir zunächst eine Reihe von Validierungsprüfungen durchführen, um sicherzustellen, dass die Daten vollständig sind und wie erwartet formatiert wurden. Anschließend konvertieren wir die JSON-Payload in eine CSV-Datei, indem wir die „csv“-Bibliothek verwenden und in eine temporäre Datei schreiben. Lambda-Funktionen können nur lokale Dateien in das „/tmp“-Verzeichnis schreiben, daher erstellen wir eine temporäre CSV-Datei und benennen sie nach dem Schema <batch_id>.csv. Der Grund, warum wir hier die batch_id verwenden, besteht einfach darin, sicherzustellen, dass parallel laufende Prozesse, die infolge des Empfangs mehrerer Webhook-Payloads ausgeführt werden, sich nicht gegenseitig stören, da jeder Webhook-Batch über eine eindeutige batch_id verfügt.
Sobald die Daten vollständig in CSV umgewandelt wurden, lesen wir die CSV-Daten als Bytestream, löschen die temporäre Datei und speichern die CSV-Daten als neue Datei auf S3. Es ist wichtig zu beachten, dass für die Ausgabe ein anderer S3-Bucket benötigt wird, da wir andernfalls Gefahr laufen, eine rekursive Schleife zu erzeugen, die zu erhöhtem Lambda-Verbrauch und höheren Kosten führen kann. Wir müssen identifizieren, in welchem S3-Bucket und an welchem Ort unsere CSV-Datei innerhalb unserer Lambda-Funktion gespeichert werden soll. Befolgen Sie das gleiche Verfahren wie oben, um einen neuen S3-Bucket zu erstellen, um unsere CSV-Datei zu speichern.
Beachten Sie, dass das tmp-Verzeichnis auf 512 MB Speicherplatz begrenzt ist, daher ist es wichtig, die temporäre Datei anschließend zu löschen, um ausreichend Speicherplatz für künftige Ausführungen sicherzustellen. Der Grund, warum wir eine temporäre Datei verwenden, anstatt direkt auf S3 zu schreiben, liegt darin, die Verbindung zu S3 durch eine einzelne Anfrage zu vereinfachen.
Wie bei der Verbrauchs-Lambda-Funktion müssen Sie möglicherweise die Berechtigungen für Ihre Prozess-Lambda-Funktion aktualisieren. Diese Lambda-Funktion erfordert, dass die Ausführungsrolle GetObject-Berechtigungen für den Eingabe-S3-Bucket sowie PutObject- und GetObject-Berechtigungen für den Ausgabe-S3-Bucket hat.
Ein Beispiel unserer verarbeitenden Lambda-Funktion finden Sie hier.
Wie bei der Lambda-Funktion zur Verarbeitung der Webhook-Daten müssen wir eine neue Lambda-Funktion erstellen, indem wir zum Lambda-Dienst innerhalb von AWS navigieren und auf „Funktion erstellen“ drücken. Diese neue Lambda-Funktion wird ausgelöst, wenn eine neue Datei in unserem S3-Bucket erstellt wird – sie liest die Daten und wandelt sie in eine neue CSV-Datei um.
Die Lambda-Funktion akzeptiert die Dateiinformationen als Ereignis. In der Beispiel-Lambda-Funktion sehen Sie, dass wir zunächst eine Reihe von Validierungsprüfungen durchführen, um sicherzustellen, dass die Daten vollständig sind und wie erwartet formatiert wurden. Anschließend konvertieren wir die JSON-Payload in eine CSV-Datei, indem wir die „csv“-Bibliothek verwenden und in eine temporäre Datei schreiben. Lambda-Funktionen können nur lokale Dateien in das „/tmp“-Verzeichnis schreiben, daher erstellen wir eine temporäre CSV-Datei und benennen sie nach dem Schema <batch_id>.csv. Der Grund, warum wir hier die batch_id verwenden, besteht einfach darin, sicherzustellen, dass parallel laufende Prozesse, die infolge des Empfangs mehrerer Webhook-Payloads ausgeführt werden, sich nicht gegenseitig stören, da jeder Webhook-Batch über eine eindeutige batch_id verfügt.
Sobald die Daten vollständig in CSV umgewandelt wurden, lesen wir die CSV-Daten als Bytestream, löschen die temporäre Datei und speichern die CSV-Daten als neue Datei auf S3. Es ist wichtig zu beachten, dass für die Ausgabe ein anderer S3-Bucket benötigt wird, da wir andernfalls Gefahr laufen, eine rekursive Schleife zu erzeugen, die zu erhöhtem Lambda-Verbrauch und höheren Kosten führen kann. Wir müssen identifizieren, in welchem S3-Bucket und an welchem Ort unsere CSV-Datei innerhalb unserer Lambda-Funktion gespeichert werden soll. Befolgen Sie das gleiche Verfahren wie oben, um einen neuen S3-Bucket zu erstellen, um unsere CSV-Datei zu speichern.
Beachten Sie, dass das tmp-Verzeichnis auf 512 MB Speicherplatz begrenzt ist, daher ist es wichtig, die temporäre Datei anschließend zu löschen, um ausreichend Speicherplatz für künftige Ausführungen sicherzustellen. Der Grund, warum wir eine temporäre Datei verwenden, anstatt direkt auf S3 zu schreiben, liegt darin, die Verbindung zu S3 durch eine einzelne Anfrage zu vereinfachen.
Wie bei der Verbrauchs-Lambda-Funktion müssen Sie möglicherweise die Berechtigungen für Ihre Prozess-Lambda-Funktion aktualisieren. Diese Lambda-Funktion erfordert, dass die Ausführungsrolle GetObject-Berechtigungen für den Eingabe-S3-Bucket sowie PutObject- und GetObject-Berechtigungen für den Ausgabe-S3-Bucket hat.
Ein Beispiel unserer verarbeitenden Lambda-Funktion finden Sie hier.
Wie bei der Lambda-Funktion zur Verarbeitung der Webhook-Daten müssen wir eine neue Lambda-Funktion erstellen, indem wir zum Lambda-Dienst innerhalb von AWS navigieren und auf „Funktion erstellen“ drücken. Diese neue Lambda-Funktion wird ausgelöst, wenn eine neue Datei in unserem S3-Bucket erstellt wird – sie liest die Daten und wandelt sie in eine neue CSV-Datei um.
Die Lambda-Funktion akzeptiert die Dateiinformationen als Ereignis. In der Beispiel-Lambda-Funktion sehen Sie, dass wir zunächst eine Reihe von Validierungsprüfungen durchführen, um sicherzustellen, dass die Daten vollständig sind und wie erwartet formatiert wurden. Anschließend konvertieren wir die JSON-Payload in eine CSV-Datei, indem wir die „csv“-Bibliothek verwenden und in eine temporäre Datei schreiben. Lambda-Funktionen können nur lokale Dateien in das „/tmp“-Verzeichnis schreiben, daher erstellen wir eine temporäre CSV-Datei und benennen sie nach dem Schema <batch_id>.csv. Der Grund, warum wir hier die batch_id verwenden, besteht einfach darin, sicherzustellen, dass parallel laufende Prozesse, die infolge des Empfangs mehrerer Webhook-Payloads ausgeführt werden, sich nicht gegenseitig stören, da jeder Webhook-Batch über eine eindeutige batch_id verfügt.
Sobald die Daten vollständig in CSV umgewandelt wurden, lesen wir die CSV-Daten als Bytestream, löschen die temporäre Datei und speichern die CSV-Daten als neue Datei auf S3. Es ist wichtig zu beachten, dass für die Ausgabe ein anderer S3-Bucket benötigt wird, da wir andernfalls Gefahr laufen, eine rekursive Schleife zu erzeugen, die zu erhöhtem Lambda-Verbrauch und höheren Kosten führen kann. Wir müssen identifizieren, in welchem S3-Bucket und an welchem Ort unsere CSV-Datei innerhalb unserer Lambda-Funktion gespeichert werden soll. Befolgen Sie das gleiche Verfahren wie oben, um einen neuen S3-Bucket zu erstellen, um unsere CSV-Datei zu speichern.
Beachten Sie, dass das tmp-Verzeichnis auf 512 MB Speicherplatz begrenzt ist, daher ist es wichtig, die temporäre Datei anschließend zu löschen, um ausreichend Speicherplatz für künftige Ausführungen sicherzustellen. Der Grund, warum wir eine temporäre Datei verwenden, anstatt direkt auf S3 zu schreiben, liegt darin, die Verbindung zu S3 durch eine einzelne Anfrage zu vereinfachen.
Wie bei der Verbrauchs-Lambda-Funktion müssen Sie möglicherweise die Berechtigungen für Ihre Prozess-Lambda-Funktion aktualisieren. Diese Lambda-Funktion erfordert, dass die Ausführungsrolle GetObject-Berechtigungen für den Eingabe-S3-Bucket sowie PutObject- und GetObject-Berechtigungen für den Ausgabe-S3-Bucket hat.
Ein Beispiel unserer verarbeitenden Lambda-Funktion finden Sie hier.
Konfigurieren Sie eine Lambda, die ausgeführt wird, wenn neue Daten auf S3 gespeichert werden
Nun, da unsere Lambda-Funktion zur Umwandlung der Datei von JSON- in CSV-Format erstellt wurde, müssen wir sie so konfigurieren, dass sie ausgelöst wird, wenn eine neue Datei in unserem S3-Bucket erstellt wird. Dazu müssen wir unserer Lambda-Funktion einen Auslöser hinzufügen, indem wir unsere Lambda-Funktion öffnen und oben auf der Seite „Add Trigger“ klicken. Wählen Sie „S3“ aus und geben Sie den Namen des S3-Buckets an, in dem die rohen Webhook-Payloads gespeichert sind. Sie haben auch die Möglichkeit, Datei-Präfix und/oder Suffix zum Filtern anzugeben. Nachdem die Einstellungen konfiguriert wurden, können Sie den Auslöser hinzufügen, indem Sie unten auf der Seite auf „Add“ klicken. Nun wird Ihre verarbeitende Lambda-Funktion ausgeführt, wann immer eine neue Datei zu Ihrem S3-Bucket hinzugefügt wird.
Nun, da unsere Lambda-Funktion zur Umwandlung der Datei von JSON- in CSV-Format erstellt wurde, müssen wir sie so konfigurieren, dass sie ausgelöst wird, wenn eine neue Datei in unserem S3-Bucket erstellt wird. Dazu müssen wir unserer Lambda-Funktion einen Auslöser hinzufügen, indem wir unsere Lambda-Funktion öffnen und oben auf der Seite „Add Trigger“ klicken. Wählen Sie „S3“ aus und geben Sie den Namen des S3-Buckets an, in dem die rohen Webhook-Payloads gespeichert sind. Sie haben auch die Möglichkeit, Datei-Präfix und/oder Suffix zum Filtern anzugeben. Nachdem die Einstellungen konfiguriert wurden, können Sie den Auslöser hinzufügen, indem Sie unten auf der Seite auf „Add“ klicken. Nun wird Ihre verarbeitende Lambda-Funktion ausgeführt, wann immer eine neue Datei zu Ihrem S3-Bucket hinzugefügt wird.
Nun, da unsere Lambda-Funktion zur Umwandlung der Datei von JSON- in CSV-Format erstellt wurde, müssen wir sie so konfigurieren, dass sie ausgelöst wird, wenn eine neue Datei in unserem S3-Bucket erstellt wird. Dazu müssen wir unserer Lambda-Funktion einen Auslöser hinzufügen, indem wir unsere Lambda-Funktion öffnen und oben auf der Seite „Add Trigger“ klicken. Wählen Sie „S3“ aus und geben Sie den Namen des S3-Buckets an, in dem die rohen Webhook-Payloads gespeichert sind. Sie haben auch die Möglichkeit, Datei-Präfix und/oder Suffix zum Filtern anzugeben. Nachdem die Einstellungen konfiguriert wurden, können Sie den Auslöser hinzufügen, indem Sie unten auf der Seite auf „Add“ klicken. Nun wird Ihre verarbeitende Lambda-Funktion ausgeführt, wann immer eine neue Datei zu Ihrem S3-Bucket hinzugefügt wird.
Laden der Daten in eine Datenbank
In diesem Beispiel werde ich das Laden der Daten in eine Datenbank nicht im Detail behandeln, aber wenn Sie diesem Beispiel gefolgt sind, haben Sie einige Optionen:
Laden Sie die Daten direkt in Ihre Datenbank innerhalb Ihrer Verarbeitungslambda-Funktion
Verwenden Sie eine bestehende ETL-Prozess, um Ihre CSV-Datei zu verarbeiten
Unabhängig davon, ob Sie einen AWS-Datenbankdienst wie RDS oder DynamoDB verwenden oder eine eigene PostgreSQL-Datenbank (oder Ähnliches) besitzen, können Sie direkt von Ihrer Prozess-Lambda-Funktion auf Ihren Datenbankdienst zugreifen. Beispielsweise können Sie, ähnlich wie wir den S3-Dienst mit „boto3“ in unserer Lambda-Funktion aufgerufen haben, auch „boto3“ verwenden, um RDS oder DynamoDB anzusprechen. Der AWS-Dienst Athena könnte ebenfalls verwendet werden, um die Datendateien direkt von den Flat-Files zu lesen und auf die Daten mit einer Abfragesprache ähnlich wie SQL zuzugreifen. Ich empfehle, die jeweilige Dokumentation für den von Ihnen verwendeten Dienst zu Rate zu ziehen, um mehr Informationen darüber zu erhalten, wie Sie dies am besten in Ihrer Umgebung erreichen können.
Ebenso gibt es viele Dienste, die dabei helfen können, CSV-Dateien zu verarbeiten und die Daten in eine Datenbank zu laden. Möglicherweise haben Sie bereits einen etablierten ETL-Prozess, den Sie nutzen können.
Wir hoffen, Sie fanden diesen Leitfaden hilfreich – viel Erfolg beim Versenden!
In diesem Beispiel werde ich das Laden der Daten in eine Datenbank nicht im Detail behandeln, aber wenn Sie diesem Beispiel gefolgt sind, haben Sie einige Optionen:
Laden Sie die Daten direkt in Ihre Datenbank innerhalb Ihrer Verarbeitungslambda-Funktion
Verwenden Sie eine bestehende ETL-Prozess, um Ihre CSV-Datei zu verarbeiten
Unabhängig davon, ob Sie einen AWS-Datenbankdienst wie RDS oder DynamoDB verwenden oder eine eigene PostgreSQL-Datenbank (oder Ähnliches) besitzen, können Sie direkt von Ihrer Prozess-Lambda-Funktion auf Ihren Datenbankdienst zugreifen. Beispielsweise können Sie, ähnlich wie wir den S3-Dienst mit „boto3“ in unserer Lambda-Funktion aufgerufen haben, auch „boto3“ verwenden, um RDS oder DynamoDB anzusprechen. Der AWS-Dienst Athena könnte ebenfalls verwendet werden, um die Datendateien direkt von den Flat-Files zu lesen und auf die Daten mit einer Abfragesprache ähnlich wie SQL zuzugreifen. Ich empfehle, die jeweilige Dokumentation für den von Ihnen verwendeten Dienst zu Rate zu ziehen, um mehr Informationen darüber zu erhalten, wie Sie dies am besten in Ihrer Umgebung erreichen können.
Ebenso gibt es viele Dienste, die dabei helfen können, CSV-Dateien zu verarbeiten und die Daten in eine Datenbank zu laden. Möglicherweise haben Sie bereits einen etablierten ETL-Prozess, den Sie nutzen können.
Wir hoffen, Sie fanden diesen Leitfaden hilfreich – viel Erfolg beim Versenden!
In diesem Beispiel werde ich das Laden der Daten in eine Datenbank nicht im Detail behandeln, aber wenn Sie diesem Beispiel gefolgt sind, haben Sie einige Optionen:
Laden Sie die Daten direkt in Ihre Datenbank innerhalb Ihrer Verarbeitungslambda-Funktion
Verwenden Sie eine bestehende ETL-Prozess, um Ihre CSV-Datei zu verarbeiten
Unabhängig davon, ob Sie einen AWS-Datenbankdienst wie RDS oder DynamoDB verwenden oder eine eigene PostgreSQL-Datenbank (oder Ähnliches) besitzen, können Sie direkt von Ihrer Prozess-Lambda-Funktion auf Ihren Datenbankdienst zugreifen. Beispielsweise können Sie, ähnlich wie wir den S3-Dienst mit „boto3“ in unserer Lambda-Funktion aufgerufen haben, auch „boto3“ verwenden, um RDS oder DynamoDB anzusprechen. Der AWS-Dienst Athena könnte ebenfalls verwendet werden, um die Datendateien direkt von den Flat-Files zu lesen und auf die Daten mit einer Abfragesprache ähnlich wie SQL zuzugreifen. Ich empfehle, die jeweilige Dokumentation für den von Ihnen verwendeten Dienst zu Rate zu ziehen, um mehr Informationen darüber zu erhalten, wie Sie dies am besten in Ihrer Umgebung erreichen können.
Ebenso gibt es viele Dienste, die dabei helfen können, CSV-Dateien zu verarbeiten und die Daten in eine Datenbank zu laden. Möglicherweise haben Sie bereits einen etablierten ETL-Prozess, den Sie nutzen können.
Wir hoffen, Sie fanden diesen Leitfaden hilfreich – viel Erfolg beim Versenden!
