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.
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-Endpoints
Wenn ein Bird-Ereignis erstellt wird, möchten wir, dass diese Ereignisdaten in Echtzeit zu einem Endpunkt in AWS gestreamt werden, damit wir diese Daten programmgesteuert verwenden und nutzen können. Die Daten werden von Bird zu einem Zielendpunkt gesendet, der die Nutzdaten an eine Lambda-Funktion weiterleitet, die die Daten verarbeitet und in einem S3-Bucket speichert. Ein Übersichtsschema des beschriebenen Datenflusses ist unten zu sehen:
Komponente | Verantwortlichkeit |
|---|---|
Bird Webhooks | Senden von Echtzeit-Ereignisgruppen als HTTP-POST-Anfragen |
Application Load Balancer | Empfange externen Webhook-Verkehr und leite Anfragen weiter |
Lambda (Consumer) | Speicherung roher Webhook-Batches effizient in S3 |
Amazon S3 | Speichere gruppierte Ereignisdaten als flache JSON-Dateien |
Lambda (Prozessor) | Asynchrones Transformieren oder Laden gespeicherter Daten |
Um diesen Arbeitsablauf umzusetzen, bauen wir diese Komponenten tatsächlich in umgekehrter Reihenfolge auf, beginnend mit der Erstellung eines S3-Buckets, in dem wir unsere Ereignisdaten speichern, und dann rückwärts arbeitend – jede Komponente hinzufügen, die in das einfließt, was wir aufgebaut haben.
Wenn ein Bird-Ereignis erstellt wird, möchten wir, dass diese Ereignisdaten in Echtzeit zu einem Endpunkt in AWS gestreamt werden, damit wir diese Daten programmgesteuert verwenden und nutzen können. Die Daten werden von Bird zu einem Zielendpunkt gesendet, der die Nutzdaten an eine Lambda-Funktion weiterleitet, die die Daten verarbeitet und in einem S3-Bucket speichert. Ein Übersichtsschema des beschriebenen Datenflusses ist unten zu sehen:
Komponente | Verantwortlichkeit |
|---|---|
Bird Webhooks | Senden von Echtzeit-Ereignisgruppen als HTTP-POST-Anfragen |
Application Load Balancer | Empfange externen Webhook-Verkehr und leite Anfragen weiter |
Lambda (Consumer) | Speicherung roher Webhook-Batches effizient in S3 |
Amazon S3 | Speichere gruppierte Ereignisdaten als flache JSON-Dateien |
Lambda (Prozessor) | Asynchrones Transformieren oder Laden gespeicherter Daten |
Um diesen Arbeitsablauf umzusetzen, bauen wir diese Komponenten tatsächlich in umgekehrter Reihenfolge auf, beginnend mit der Erstellung eines S3-Buckets, in dem wir unsere Ereignisdaten speichern, und dann rückwärts arbeitend – jede Komponente hinzufügen, die in das einfließt, was wir aufgebaut haben.
Wenn ein Bird-Ereignis erstellt wird, möchten wir, dass diese Ereignisdaten in Echtzeit zu einem Endpunkt in AWS gestreamt werden, damit wir diese Daten programmgesteuert verwenden und nutzen können. Die Daten werden von Bird zu einem Zielendpunkt gesendet, der die Nutzdaten an eine Lambda-Funktion weiterleitet, die die Daten verarbeitet und in einem S3-Bucket speichert. Ein Übersichtsschema des beschriebenen Datenflusses ist unten zu sehen:
Komponente | Verantwortlichkeit |
|---|---|
Bird Webhooks | Senden von Echtzeit-Ereignisgruppen als HTTP-POST-Anfragen |
Application Load Balancer | Empfange externen Webhook-Verkehr und leite Anfragen weiter |
Lambda (Consumer) | Speicherung roher Webhook-Batches effizient in S3 |
Amazon S3 | Speichere gruppierte Ereignisdaten als flache JSON-Dateien |
Lambda (Prozessor) | Asynchrones Transformieren oder Laden gespeicherter Daten |
Um diesen Arbeitsablauf umzusetzen, bauen wir diese Komponenten tatsächlich in umgekehrter Reihenfolge auf, beginnend mit der Erstellung eines S3-Buckets, in dem wir unsere Ereignisdaten speichern, und dann rückwärts arbeitend – jede Komponente hinzufügen, die in das einfließt, was wir aufgebaut haben.
Erstellen Sie einen S3 Bucket, um die Webhook-Daten zu speichern
Bevor wir unseren Load Balancer erstellen, um die Daten anzunehmen, 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 ausgezeichnete Speicheroptionen 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 neben ihrer S3-Speicherstrategie zu schützen. Um dies zu tun, navigieren Sie 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 Ihre ALB und Lambda-Funktion verwenden. Nachdem Ihr S3-Bucket erstellt wurde, wird er leer sein – wenn Sie die Daten innerhalb eines Ordners organisieren möchten, können Sie entweder jetzt das beabsichtigte Verzeichnis erstellen, oder das Verzeichnis wird erstellt, wenn Ihre Lambda-Funktion die Datei speichert. In diesem Beispiel haben wir unserem S3-Bucket den Namen „bird-webhooks“ gegeben und einen Ordner mit dem Namen „B Event Data“ erstellt, um unsere Ereignisdaten zu speichern – Sie werden diese Namen in unserer Lambda-Funktion unten sehen.
Bevor wir unseren Load Balancer erstellen, um die Daten anzunehmen, 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 ausgezeichnete Speicheroptionen 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 neben ihrer S3-Speicherstrategie zu schützen. Um dies zu tun, navigieren Sie 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 Ihre ALB und Lambda-Funktion verwenden. Nachdem Ihr S3-Bucket erstellt wurde, wird er leer sein – wenn Sie die Daten innerhalb eines Ordners organisieren möchten, können Sie entweder jetzt das beabsichtigte Verzeichnis erstellen, oder das Verzeichnis wird erstellt, wenn Ihre Lambda-Funktion die Datei speichert. In diesem Beispiel haben wir unserem S3-Bucket den Namen „bird-webhooks“ gegeben und einen Ordner mit dem Namen „B Event Data“ erstellt, um unsere Ereignisdaten zu speichern – Sie werden diese Namen in unserer Lambda-Funktion unten sehen.
Bevor wir unseren Load Balancer erstellen, um die Daten anzunehmen, 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 ausgezeichnete Speicheroptionen 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 neben ihrer S3-Speicherstrategie zu schützen. Um dies zu tun, navigieren Sie 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 Ihre ALB und Lambda-Funktion verwenden. Nachdem Ihr S3-Bucket erstellt wurde, wird er leer sein – wenn Sie die Daten innerhalb eines Ordners organisieren möchten, können Sie entweder jetzt das beabsichtigte Verzeichnis erstellen, oder das Verzeichnis wird erstellt, wenn Ihre Lambda-Funktion die Datei speichert. In diesem Beispiel haben wir unserem S3-Bucket den Namen „bird-webhooks“ gegeben und einen Ordner mit dem Namen „B Event Data“ erstellt, um unsere Ereignisdaten zu speichern – Sie werden diese Namen in unserer Lambda-Funktion unten sehen.
Erstellen Sie eine Lambda Function, um die Data zu konsumieren
Die eigentliche Verarbeitung und Speicherung der Daten erfolgt durch eine Lambda-Funktion, die von unserem Application Load Balancer (ALB) aufgerufen wird.
Der erste Schritt besteht darin, Ihre Lambda-Funktion zu erstellen, indem Sie zum Lambda-Service innerhalb von AWS navigieren und auf „Function erstellen“ klicken. Sie werden aufgefordert, Ihrer Lambda-Funktion einen Namen zuzuweisen und die Programmiersprache auszuwählen, in der Sie Ihre Funktion schreiben möchten. In diesem Beispiel verwenden wir Python als Laufzeitsprache.
Jetzt müssen wir unsere Lambda-Funktion entwickeln. Nehmen wir einen Moment an, dass unser Application Load Balancer konfiguriert wurde und die Webhook-Nutzlast an unsere Lambda-Funktion weiterleitet – die Lambda erhält eine Nutzlast, die die vollständigen Header und den Body enthält. Die Nutzlast wird unter Verwendung des Objekts „event“ als Wörterbuch an unsere Lambda-Funktion übergeben. Sie können auf die Header und den Body der Nutzlast unabhängig zugreifen, indem Sie auf die Objekte „headers“ und „body“ innerhalb der Nutzlast zugreifen. In diesem Beispiel werden wir einfach den „x-messagesystems-batch-id“-Header lesen, wobei die Batch-ID ein eindeutiger Wert ist, der von Bird für den Webhook-Batch erstellt wird, und ihn als Dateinamen verwenden, wenn der Body als Flachdatei in S3 gespeichert wird; Sie möchten jedoch möglicherweise zusätzliche Funktionen wie Authentifizierungsprüfungen oder Fehlerbehandlung hinzufügen, je nach Bedarf.
Beim Speichern der Nutzlast als Flachdatei auf S3 müssen wir den Namen des S3-Buckets, den Speicherort und den Dateinamen der Datei definieren, in der die Nutzlastdaten gespeichert werden. In unserer Lambda-Beispielfunktion erledigen wir dies innerhalb der Funktion „store_batch“. In diesem Beispiel speichern wir den gesamten Batch als einzelne Datei, was dazu beiträgt, sicherzustellen, dass die Daten erfasst 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 dafür, dass die Verbindung auf der Übertragungsseite (in diesem Fall Bird) nicht abläuft oder dass die Verbindung nicht beendet wird, bevor Ihre Lambda-Funktion die Ausführung beendet hat. Es ist best practice, Ihre Consumer-Funktion so effizient wie möglich zu halten und Datenverarbeitungsaktivitäten nach Möglichkeit für nachgelagerte Prozesse zu reservieren – wie das Umwandeln der gebündelten JSON-formatierten Nutzlast 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-Funktion aktualisieren müssen. Ihre Ausführungsrolle benötigt PutObject- und GetObject-Berechtigungen für S3. Es ist eine best practice, das Prinzip der minimalen Rechte durchzusetzen, daher empfehle ich, diese Berechtigungen nur für den S3-Bucket festzulegen, in dem die Webhook-Nutzlasten gespeichert werden.
Ein Beispiel unserer Consumer-Lambda-Funktion finden Sie hier.
Ein kurzer Hinweis zur Batch-ID: Bird wird Events zu einer einzigen Nutzlast bündeln, wobei jeder Batch 1 bis 350 oder mehr Ereignisdatensätze enthalten kann. Dem Batch wird eine eindeutige Batch-ID zugewiesen, die genutzt werden kann, um den Batch-Status mithilfe der Event Webhooks API oder innerhalb Ihres Bird-Kontos anzuzeigen, indem Sie auf einen Webhook-Stream klicken und „Batch Status“ auswählen. Für den Fall, dass eine Webhook-Nutzlast nicht zugestellt werden konnte, z. B. während eines Verbindungstimeouts, wird Bird automatisch die Batch erneut versuchen, dieselbe Batch-ID zu verwenden. Dies kann passieren, wenn Ihre Lambda-Funktion nahe an der maximalen Rundreisezeit von 10 Sekunden läuft, und ist ein Grund, die Consumer-Funktion zu optimieren, um die Ausführungszeit zu verkürzen.
Um alle Datenverarbeitungsaktivitäten zu handhaben, empfehle ich, eine separate Lambda-Funktion zu erstellen, die ausgeführt wird, wann immer eine neue Datei im S3-Bucket erstellt wird – auf diese Weise wird die Datenverarbeitung asynchron zur Datenübertragung durchgeführt, und es besteht kein Risiko für Datenverlust aufgrund einer beendeten Verbindung. Ich diskutiere die Verarbeitung der Lambda-Funktion in einem späteren Abschnitt.
Die eigentliche Verarbeitung und Speicherung der Daten erfolgt durch eine Lambda-Funktion, die von unserem Application Load Balancer (ALB) aufgerufen wird.
Der erste Schritt besteht darin, Ihre Lambda-Funktion zu erstellen, indem Sie zum Lambda-Service innerhalb von AWS navigieren und auf „Function erstellen“ klicken. Sie werden aufgefordert, Ihrer Lambda-Funktion einen Namen zuzuweisen und die Programmiersprache auszuwählen, in der Sie Ihre Funktion schreiben möchten. In diesem Beispiel verwenden wir Python als Laufzeitsprache.
Jetzt müssen wir unsere Lambda-Funktion entwickeln. Nehmen wir einen Moment an, dass unser Application Load Balancer konfiguriert wurde und die Webhook-Nutzlast an unsere Lambda-Funktion weiterleitet – die Lambda erhält eine Nutzlast, die die vollständigen Header und den Body enthält. Die Nutzlast wird unter Verwendung des Objekts „event“ als Wörterbuch an unsere Lambda-Funktion übergeben. Sie können auf die Header und den Body der Nutzlast unabhängig zugreifen, indem Sie auf die Objekte „headers“ und „body“ innerhalb der Nutzlast zugreifen. In diesem Beispiel werden wir einfach den „x-messagesystems-batch-id“-Header lesen, wobei die Batch-ID ein eindeutiger Wert ist, der von Bird für den Webhook-Batch erstellt wird, und ihn als Dateinamen verwenden, wenn der Body als Flachdatei in S3 gespeichert wird; Sie möchten jedoch möglicherweise zusätzliche Funktionen wie Authentifizierungsprüfungen oder Fehlerbehandlung hinzufügen, je nach Bedarf.
Beim Speichern der Nutzlast als Flachdatei auf S3 müssen wir den Namen des S3-Buckets, den Speicherort und den Dateinamen der Datei definieren, in der die Nutzlastdaten gespeichert werden. In unserer Lambda-Beispielfunktion erledigen wir dies innerhalb der Funktion „store_batch“. In diesem Beispiel speichern wir den gesamten Batch als einzelne Datei, was dazu beiträgt, sicherzustellen, dass die Daten erfasst 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 dafür, dass die Verbindung auf der Übertragungsseite (in diesem Fall Bird) nicht abläuft oder dass die Verbindung nicht beendet wird, bevor Ihre Lambda-Funktion die Ausführung beendet hat. Es ist best practice, Ihre Consumer-Funktion so effizient wie möglich zu halten und Datenverarbeitungsaktivitäten nach Möglichkeit für nachgelagerte Prozesse zu reservieren – wie das Umwandeln der gebündelten JSON-formatierten Nutzlast 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-Funktion aktualisieren müssen. Ihre Ausführungsrolle benötigt PutObject- und GetObject-Berechtigungen für S3. Es ist eine best practice, das Prinzip der minimalen Rechte durchzusetzen, daher empfehle ich, diese Berechtigungen nur für den S3-Bucket festzulegen, in dem die Webhook-Nutzlasten gespeichert werden.
Ein Beispiel unserer Consumer-Lambda-Funktion finden Sie hier.
Ein kurzer Hinweis zur Batch-ID: Bird wird Events zu einer einzigen Nutzlast bündeln, wobei jeder Batch 1 bis 350 oder mehr Ereignisdatensätze enthalten kann. Dem Batch wird eine eindeutige Batch-ID zugewiesen, die genutzt werden kann, um den Batch-Status mithilfe der Event Webhooks API oder innerhalb Ihres Bird-Kontos anzuzeigen, indem Sie auf einen Webhook-Stream klicken und „Batch Status“ auswählen. Für den Fall, dass eine Webhook-Nutzlast nicht zugestellt werden konnte, z. B. während eines Verbindungstimeouts, wird Bird automatisch die Batch erneut versuchen, dieselbe Batch-ID zu verwenden. Dies kann passieren, wenn Ihre Lambda-Funktion nahe an der maximalen Rundreisezeit von 10 Sekunden läuft, und ist ein Grund, die Consumer-Funktion zu optimieren, um die Ausführungszeit zu verkürzen.
Um alle Datenverarbeitungsaktivitäten zu handhaben, empfehle ich, eine separate Lambda-Funktion zu erstellen, die ausgeführt wird, wann immer eine neue Datei im S3-Bucket erstellt wird – auf diese Weise wird die Datenverarbeitung asynchron zur Datenübertragung durchgeführt, und es besteht kein Risiko für Datenverlust aufgrund einer beendeten Verbindung. Ich diskutiere die Verarbeitung der Lambda-Funktion in einem späteren Abschnitt.
Die eigentliche Verarbeitung und Speicherung der Daten erfolgt durch eine Lambda-Funktion, die von unserem Application Load Balancer (ALB) aufgerufen wird.
Der erste Schritt besteht darin, Ihre Lambda-Funktion zu erstellen, indem Sie zum Lambda-Service innerhalb von AWS navigieren und auf „Function erstellen“ klicken. Sie werden aufgefordert, Ihrer Lambda-Funktion einen Namen zuzuweisen und die Programmiersprache auszuwählen, in der Sie Ihre Funktion schreiben möchten. In diesem Beispiel verwenden wir Python als Laufzeitsprache.
Jetzt müssen wir unsere Lambda-Funktion entwickeln. Nehmen wir einen Moment an, dass unser Application Load Balancer konfiguriert wurde und die Webhook-Nutzlast an unsere Lambda-Funktion weiterleitet – die Lambda erhält eine Nutzlast, die die vollständigen Header und den Body enthält. Die Nutzlast wird unter Verwendung des Objekts „event“ als Wörterbuch an unsere Lambda-Funktion übergeben. Sie können auf die Header und den Body der Nutzlast unabhängig zugreifen, indem Sie auf die Objekte „headers“ und „body“ innerhalb der Nutzlast zugreifen. In diesem Beispiel werden wir einfach den „x-messagesystems-batch-id“-Header lesen, wobei die Batch-ID ein eindeutiger Wert ist, der von Bird für den Webhook-Batch erstellt wird, und ihn als Dateinamen verwenden, wenn der Body als Flachdatei in S3 gespeichert wird; Sie möchten jedoch möglicherweise zusätzliche Funktionen wie Authentifizierungsprüfungen oder Fehlerbehandlung hinzufügen, je nach Bedarf.
Beim Speichern der Nutzlast als Flachdatei auf S3 müssen wir den Namen des S3-Buckets, den Speicherort und den Dateinamen der Datei definieren, in der die Nutzlastdaten gespeichert werden. In unserer Lambda-Beispielfunktion erledigen wir dies innerhalb der Funktion „store_batch“. In diesem Beispiel speichern wir den gesamten Batch als einzelne Datei, was dazu beiträgt, sicherzustellen, dass die Daten erfasst 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 dafür, dass die Verbindung auf der Übertragungsseite (in diesem Fall Bird) nicht abläuft oder dass die Verbindung nicht beendet wird, bevor Ihre Lambda-Funktion die Ausführung beendet hat. Es ist best practice, Ihre Consumer-Funktion so effizient wie möglich zu halten und Datenverarbeitungsaktivitäten nach Möglichkeit für nachgelagerte Prozesse zu reservieren – wie das Umwandeln der gebündelten JSON-formatierten Nutzlast 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-Funktion aktualisieren müssen. Ihre Ausführungsrolle benötigt PutObject- und GetObject-Berechtigungen für S3. Es ist eine best practice, das Prinzip der minimalen Rechte durchzusetzen, daher empfehle ich, diese Berechtigungen nur für den S3-Bucket festzulegen, in dem die Webhook-Nutzlasten gespeichert werden.
Ein Beispiel unserer Consumer-Lambda-Funktion finden Sie hier.
Ein kurzer Hinweis zur Batch-ID: Bird wird Events zu einer einzigen Nutzlast bündeln, wobei jeder Batch 1 bis 350 oder mehr Ereignisdatensätze enthalten kann. Dem Batch wird eine eindeutige Batch-ID zugewiesen, die genutzt werden kann, um den Batch-Status mithilfe der Event Webhooks API oder innerhalb Ihres Bird-Kontos anzuzeigen, indem Sie auf einen Webhook-Stream klicken und „Batch Status“ auswählen. Für den Fall, dass eine Webhook-Nutzlast nicht zugestellt werden konnte, z. B. während eines Verbindungstimeouts, wird Bird automatisch die Batch erneut versuchen, dieselbe Batch-ID zu verwenden. Dies kann passieren, wenn Ihre Lambda-Funktion nahe an der maximalen Rundreisezeit von 10 Sekunden läuft, und ist ein Grund, die Consumer-Funktion zu optimieren, um die Ausführungszeit zu verkürzen.
Um alle Datenverarbeitungsaktivitäten zu handhaben, empfehle ich, eine separate Lambda-Funktion zu erstellen, die ausgeführt wird, wann immer eine neue Datei im S3-Bucket erstellt wird – auf diese Weise wird die Datenverarbeitung asynchron zur Datenübertragung durchgeführt, und es besteht kein Risiko für Datenverlust aufgrund einer beendeten Verbindung. Ich diskutiere die Verarbeitung der Lambda-Funktion in einem späteren Abschnitt.
Ein Application Load Balancer erstellen
Um einen Webhook-Payload zu empfangen, müssen wir einen Endpunkt bereitstellen, an den die Payloads gesendet werden. Dies tun wir, indem wir einen Application Load Balancer innerhalb von AWS erstellen, indem wir zu EC2 > Load Balancers navigieren und auf „Create Load Balancer“ klicken. Sie werden aufgefordert, den Typ des Load Balancers auszuwählen, den Sie erstellen möchten – hierfür möchten wir einen Application Load Balancer erstellen. Wir müssen einen Application Load Balancer (ALB) verwenden, um unseren Consumer zu erstellen, da die Event-Webhooks als HTTP-Anfrage gesendet werden und ALBs verwendet werden, um HTTP-Anfragen innerhalb von AWS zu routen. Wir könnten alternativ ein HTTP-Gateway implementieren; Wir verwenden jedoch einen ALB für dieses Projekt, da er leichter und kostengünstiger als das HTTP-Gateway ist. Es ist wichtig zu beachten, dass, wenn Sie sich entscheiden, ein HTTP-Gateway zu verwenden, das Event-Format möglicherweise anders ist als bei einem ALB, und daher muss Ihre Lambda-Funktion das Request-Objekt entsprechend verarbeiten.
Sobald Ihr ALB erstellt wurde, werden Sie aufgefordert, Ihrem ALB einen Namen zuzuweisen 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 internetfähig ist. Unter „Listeners and routing“ sollte der ALB HTTPS auf Port 443 abhö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 weiterleitet. Sie müssen auch sicherstellen, dass die Sicherheitsgruppe die Erlaubnis hat, Datenverkehr über Port 443 zu akzeptieren.
Um einen Webhook-Payload zu empfangen, müssen wir einen Endpunkt bereitstellen, an den die Payloads gesendet werden. Dies tun wir, indem wir einen Application Load Balancer innerhalb von AWS erstellen, indem wir zu EC2 > Load Balancers navigieren und auf „Create Load Balancer“ klicken. Sie werden aufgefordert, den Typ des Load Balancers auszuwählen, den Sie erstellen möchten – hierfür möchten wir einen Application Load Balancer erstellen. Wir müssen einen Application Load Balancer (ALB) verwenden, um unseren Consumer zu erstellen, da die Event-Webhooks als HTTP-Anfrage gesendet werden und ALBs verwendet werden, um HTTP-Anfragen innerhalb von AWS zu routen. Wir könnten alternativ ein HTTP-Gateway implementieren; Wir verwenden jedoch einen ALB für dieses Projekt, da er leichter und kostengünstiger als das HTTP-Gateway ist. Es ist wichtig zu beachten, dass, wenn Sie sich entscheiden, ein HTTP-Gateway zu verwenden, das Event-Format möglicherweise anders ist als bei einem ALB, und daher muss Ihre Lambda-Funktion das Request-Objekt entsprechend verarbeiten.
Sobald Ihr ALB erstellt wurde, werden Sie aufgefordert, Ihrem ALB einen Namen zuzuweisen 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 internetfähig ist. Unter „Listeners and routing“ sollte der ALB HTTPS auf Port 443 abhö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 weiterleitet. Sie müssen auch sicherstellen, dass die Sicherheitsgruppe die Erlaubnis hat, Datenverkehr über Port 443 zu akzeptieren.
Um einen Webhook-Payload zu empfangen, müssen wir einen Endpunkt bereitstellen, an den die Payloads gesendet werden. Dies tun wir, indem wir einen Application Load Balancer innerhalb von AWS erstellen, indem wir zu EC2 > Load Balancers navigieren und auf „Create Load Balancer“ klicken. Sie werden aufgefordert, den Typ des Load Balancers auszuwählen, den Sie erstellen möchten – hierfür möchten wir einen Application Load Balancer erstellen. Wir müssen einen Application Load Balancer (ALB) verwenden, um unseren Consumer zu erstellen, da die Event-Webhooks als HTTP-Anfrage gesendet werden und ALBs verwendet werden, um HTTP-Anfragen innerhalb von AWS zu routen. Wir könnten alternativ ein HTTP-Gateway implementieren; Wir verwenden jedoch einen ALB für dieses Projekt, da er leichter und kostengünstiger als das HTTP-Gateway ist. Es ist wichtig zu beachten, dass, wenn Sie sich entscheiden, ein HTTP-Gateway zu verwenden, das Event-Format möglicherweise anders ist als bei einem ALB, und daher muss Ihre Lambda-Funktion das Request-Objekt entsprechend verarbeiten.
Sobald Ihr ALB erstellt wurde, werden Sie aufgefordert, Ihrem ALB einen Namen zuzuweisen 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 internetfähig ist. Unter „Listeners and routing“ sollte der ALB HTTPS auf Port 443 abhö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 weiterleitet. Sie müssen auch sicherstellen, dass die Sicherheitsgruppe die Erlaubnis hat, Datenverkehr über Port 443 zu akzeptieren.
Erstellen Sie einen DNS Record für den Load Balancer
Um es uns zu erleichtern, unseren ALB als Endpunkt zu verwenden, erstellen wir einen A-Datensatz im DNS, der auf unseren ALB verweist. Dazu können wir den AWS Route 53 Service (oder Ihren aktuellen DNS-Anbieter) nutzen und einen A-Datensatz für den Hostnamen erstellen, den Sie für Ihren Endpunkt verwenden möchten (z.B. spevents.<your_domain>). Wenn man mit DNS in großem Maßstab auf AWS arbeitet, sollte man sich bewusst sein, dass es nicht dokumentierte DNS-Grenzen gibt, die hochvolumige Anwendungen beeinträchtigen können, insbesondere solche, die große Mengen an ausgehendem Datenverkehr wie E-Mail-Zustellsysteme verarbeiten. Der A-Datensatz sollte so konfiguriert werden, dass er auf den von uns erstellten ALB verweist. Wenn Sie Route 53 zur Verwaltung der DNS-Datensätze verwenden, können Sie die ALB-Instanz direkt referenzieren, indem Sie „Alias“ aktivieren und den ALB auswählen; andernfalls, wenn Sie einen externen DNS-Anbieter verwenden, sollten Sie den A-Datensatz auf die öffentliche IP-Adresse der ALB-Instanz verweisen.
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, unseren ALB als Endpunkt zu verwenden, erstellen wir einen A-Datensatz im DNS, der auf unseren ALB verweist. Dazu können wir den AWS Route 53 Service (oder Ihren aktuellen DNS-Anbieter) nutzen und einen A-Datensatz für den Hostnamen erstellen, den Sie für Ihren Endpunkt verwenden möchten (z.B. spevents.<your_domain>). Wenn man mit DNS in großem Maßstab auf AWS arbeitet, sollte man sich bewusst sein, dass es nicht dokumentierte DNS-Grenzen gibt, die hochvolumige Anwendungen beeinträchtigen können, insbesondere solche, die große Mengen an ausgehendem Datenverkehr wie E-Mail-Zustellsysteme verarbeiten. Der A-Datensatz sollte so konfiguriert werden, dass er auf den von uns erstellten ALB verweist. Wenn Sie Route 53 zur Verwaltung der DNS-Datensätze verwenden, können Sie die ALB-Instanz direkt referenzieren, indem Sie „Alias“ aktivieren und den ALB auswählen; andernfalls, wenn Sie einen externen DNS-Anbieter verwenden, sollten Sie den A-Datensatz auf die öffentliche IP-Adresse der ALB-Instanz verweisen.
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, unseren ALB als Endpunkt zu verwenden, erstellen wir einen A-Datensatz im DNS, der auf unseren ALB verweist. Dazu können wir den AWS Route 53 Service (oder Ihren aktuellen DNS-Anbieter) nutzen und einen A-Datensatz für den Hostnamen erstellen, den Sie für Ihren Endpunkt verwenden möchten (z.B. spevents.<your_domain>). Wenn man mit DNS in großem Maßstab auf AWS arbeitet, sollte man sich bewusst sein, dass es nicht dokumentierte DNS-Grenzen gibt, die hochvolumige Anwendungen beeinträchtigen können, insbesondere solche, die große Mengen an ausgehendem Datenverkehr wie E-Mail-Zustellsysteme verarbeiten. Der A-Datensatz sollte so konfiguriert werden, dass er auf den von uns erstellten ALB verweist. Wenn Sie Route 53 zur Verwaltung der DNS-Datensätze verwenden, können Sie die ALB-Instanz direkt referenzieren, indem Sie „Alias“ aktivieren und den ALB auswählen; andernfalls, wenn Sie einen externen DNS-Anbieter verwenden, sollten Sie den A-Datensatz auf die öffentliche IP-Adresse der ALB-Instanz verweisen.
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, das webhook in Bird zu erstellen und den oben definierten Hostnamen als unser Zielendpunkt zu verwenden. Um das Webhook zu erstellen, navigieren Sie zum Webhooks section in Ihrem Bird Konto und klicken Sie auf „Create Webhook“. Sie werden aufgefordert, einen Namen für Ihr Webhook zu vergeben und eine Ziel-URL bereitzustellen – das Ziel sollte der Hostname des zuvor erstellten A Records sein. Beachten Sie, dass die Ziel-URL möglicherweise „HTTPS://“ im URL enthalten sein muss.
Nach Abschluss überprüfen Sie, ob das richtige Subkonto und die richtigen Ereignisse ausgewählt sind, und drücken Sie „Create Webhook“, um Ihre Konfiguration zu speichern. Die Ereignisdaten für alle ausgewählten Ereignistypen werden jetzt an unsere Ziel-URL gestreamt und von unserem ALB für die nachgelagerte Verarbeitung konsumiert.
Jetzt sind wir bereit, das webhook in Bird zu erstellen und den oben definierten Hostnamen als unser Zielendpunkt zu verwenden. Um das Webhook zu erstellen, navigieren Sie zum Webhooks section in Ihrem Bird Konto und klicken Sie auf „Create Webhook“. Sie werden aufgefordert, einen Namen für Ihr Webhook zu vergeben und eine Ziel-URL bereitzustellen – das Ziel sollte der Hostname des zuvor erstellten A Records sein. Beachten Sie, dass die Ziel-URL möglicherweise „HTTPS://“ im URL enthalten sein muss.
Nach Abschluss überprüfen Sie, ob das richtige Subkonto und die richtigen Ereignisse ausgewählt sind, und drücken Sie „Create Webhook“, um Ihre Konfiguration zu speichern. Die Ereignisdaten für alle ausgewählten Ereignistypen werden jetzt an unsere Ziel-URL gestreamt und von unserem ALB für die nachgelagerte Verarbeitung konsumiert.
Jetzt sind wir bereit, das webhook in Bird zu erstellen und den oben definierten Hostnamen als unser Zielendpunkt zu verwenden. Um das Webhook zu erstellen, navigieren Sie zum Webhooks section in Ihrem Bird Konto und klicken Sie auf „Create Webhook“. Sie werden aufgefordert, einen Namen für Ihr Webhook zu vergeben und eine Ziel-URL bereitzustellen – das Ziel sollte der Hostname des zuvor erstellten A Records sein. Beachten Sie, dass die Ziel-URL möglicherweise „HTTPS://“ im URL enthalten sein muss.
Nach Abschluss überprüfen Sie, ob das richtige Subkonto und die richtigen Ereignisse ausgewählt sind, und drücken Sie „Create Webhook“, um Ihre Konfiguration zu speichern. Die Ereignisdaten für alle ausgewählten Ereignistypen werden jetzt an unsere Ziel-URL gestreamt und von unserem ALB für die nachgelagerte Verarbeitung konsumiert.
Verarbeiten von Webhook Event Data
Abhängig vom beabsichtigten Zweck für die Speicherung der Bird-Ereignisdaten können Ihre Anforderungen möglicherweise durch einfaches Speichern der JSON-Nutzlast als Flachdatei erfüllt werden. Möglicherweise haben Sie auch bereits einen nachgelagerten ETL-Prozess eingerichtet, der in der Lage ist, Daten im JSON-Format zu konsumieren und zu laden. In beiden Fällen können Sie möglicherweise die von unserer oben erstellten Verarbeitungslambda erstellte Flachdatei unverändert verwenden.
Alternativ müssen Sie die Daten möglicherweise transformieren – z.B. um sie von einem JSON- 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 aus dem ursprünglichen JSON-Format in eine CSV-Datei konvertiert, die in eine Datenbank geladen werden könnte.
Abhängig vom beabsichtigten Zweck für die Speicherung der Bird-Ereignisdaten können Ihre Anforderungen möglicherweise durch einfaches Speichern der JSON-Nutzlast als Flachdatei erfüllt werden. Möglicherweise haben Sie auch bereits einen nachgelagerten ETL-Prozess eingerichtet, der in der Lage ist, Daten im JSON-Format zu konsumieren und zu laden. In beiden Fällen können Sie möglicherweise die von unserer oben erstellten Verarbeitungslambda erstellte Flachdatei unverändert verwenden.
Alternativ müssen Sie die Daten möglicherweise transformieren – z.B. um sie von einem JSON- 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 aus dem ursprünglichen JSON-Format in eine CSV-Datei konvertiert, die in eine Datenbank geladen werden könnte.
Abhängig vom beabsichtigten Zweck für die Speicherung der Bird-Ereignisdaten können Ihre Anforderungen möglicherweise durch einfaches Speichern der JSON-Nutzlast als Flachdatei erfüllt werden. Möglicherweise haben Sie auch bereits einen nachgelagerten ETL-Prozess eingerichtet, der in der Lage ist, Daten im JSON-Format zu konsumieren und zu laden. In beiden Fällen können Sie möglicherweise die von unserer oben erstellten Verarbeitungslambda erstellte Flachdatei unverändert verwenden.
Alternativ müssen Sie die Daten möglicherweise transformieren – z.B. um sie von einem JSON- 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 aus dem 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 zum Konsumieren 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 konvertiert sie in eine neue CSV-Datei.
Die Lambda-Funktion akzeptiert die Dateiinformationen als ein Ereignis. In der Beispiel-Lambda-Funktion werden Sie sehen, dass wir zunächst eine Reihe von Validierungsprüfungen durchführen, um sicherzustellen, dass die Daten vollständig und wie erwartet formatiert sind. Anschließend konvertieren wir das JSON-Payload mithilfe der „csv“-Bibliothek in eine CSV-Datei und schreiben es in eine temporäre Datei. Lambda-Funktionen können nur lokale Dateien in das „/tmp“-Verzeichnis schreiben, also erstellen wir eine temporäre CSV-Datei und benennen sie mit der Konvention <batch_id>.csv. Der Grund, warum wir hier die batch_id verwenden, besteht einfach darin, sicherzustellen, dass parallele Prozesse, die durch den Empfang mehrerer Webhook-Payloads laufen, sich nicht gegenseitig stören, da jedes Webhook-Batch eine eindeutige batch_id hat.
Sobald die Daten vollständig in CSV konvertiert 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 ein anderer S3-Bucket für die Ausgabe erforderlich ist, andernfalls riskieren wir die Erstellung einer rekursiven Schleife, die zu erhöhter Lambda-Nutzung und höheren Kosten führen kann. Wir müssen festlegen, in welchem S3-Bucket und an welchem Ort unsere CSV-Datei innerhalb unserer Lambda-Funktion gespeichert werden soll. Folgen Sie dem gleichen Verfahren wie oben, um einen neuen S3-Bucket zu erstellen, in dem wir unsere CSV-Datei speichern.
Beachten Sie, dass das tmp-Verzeichnis auf 512 MB Speicherplatz begrenzt ist, daher ist es wichtig, dass die temporäre Datei danach gelöscht wird, um ausreichend Speicherplatz für zukünftige Ausführungen sicherzustellen. Der Grund, warum wir eine temporäre Datei verwenden, anstatt direkt auf S3 zu schreiben, besteht darin, die Verbindung zu S3 durch eine einzelne Anfrage zu vereinfachen.
Genauso wie bei der Konsum-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 hat, sowie sowohl PutObject als auch GetObject für den Ausgabe-S3-Bucket.
Ein Beispiel unserer Verarbeitungs-Lambda-Funktion finden Sie hier.
Wie bei der Lambda-Funktion zum Konsumieren 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 konvertiert sie in eine neue CSV-Datei.
Die Lambda-Funktion akzeptiert die Dateiinformationen als ein Ereignis. In der Beispiel-Lambda-Funktion werden Sie sehen, dass wir zunächst eine Reihe von Validierungsprüfungen durchführen, um sicherzustellen, dass die Daten vollständig und wie erwartet formatiert sind. Anschließend konvertieren wir das JSON-Payload mithilfe der „csv“-Bibliothek in eine CSV-Datei und schreiben es in eine temporäre Datei. Lambda-Funktionen können nur lokale Dateien in das „/tmp“-Verzeichnis schreiben, also erstellen wir eine temporäre CSV-Datei und benennen sie mit der Konvention <batch_id>.csv. Der Grund, warum wir hier die batch_id verwenden, besteht einfach darin, sicherzustellen, dass parallele Prozesse, die durch den Empfang mehrerer Webhook-Payloads laufen, sich nicht gegenseitig stören, da jedes Webhook-Batch eine eindeutige batch_id hat.
Sobald die Daten vollständig in CSV konvertiert 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 ein anderer S3-Bucket für die Ausgabe erforderlich ist, andernfalls riskieren wir die Erstellung einer rekursiven Schleife, die zu erhöhter Lambda-Nutzung und höheren Kosten führen kann. Wir müssen festlegen, in welchem S3-Bucket und an welchem Ort unsere CSV-Datei innerhalb unserer Lambda-Funktion gespeichert werden soll. Folgen Sie dem gleichen Verfahren wie oben, um einen neuen S3-Bucket zu erstellen, in dem wir unsere CSV-Datei speichern.
Beachten Sie, dass das tmp-Verzeichnis auf 512 MB Speicherplatz begrenzt ist, daher ist es wichtig, dass die temporäre Datei danach gelöscht wird, um ausreichend Speicherplatz für zukünftige Ausführungen sicherzustellen. Der Grund, warum wir eine temporäre Datei verwenden, anstatt direkt auf S3 zu schreiben, besteht darin, die Verbindung zu S3 durch eine einzelne Anfrage zu vereinfachen.
Genauso wie bei der Konsum-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 hat, sowie sowohl PutObject als auch GetObject für den Ausgabe-S3-Bucket.
Ein Beispiel unserer Verarbeitungs-Lambda-Funktion finden Sie hier.
Wie bei der Lambda-Funktion zum Konsumieren 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 konvertiert sie in eine neue CSV-Datei.
Die Lambda-Funktion akzeptiert die Dateiinformationen als ein Ereignis. In der Beispiel-Lambda-Funktion werden Sie sehen, dass wir zunächst eine Reihe von Validierungsprüfungen durchführen, um sicherzustellen, dass die Daten vollständig und wie erwartet formatiert sind. Anschließend konvertieren wir das JSON-Payload mithilfe der „csv“-Bibliothek in eine CSV-Datei und schreiben es in eine temporäre Datei. Lambda-Funktionen können nur lokale Dateien in das „/tmp“-Verzeichnis schreiben, also erstellen wir eine temporäre CSV-Datei und benennen sie mit der Konvention <batch_id>.csv. Der Grund, warum wir hier die batch_id verwenden, besteht einfach darin, sicherzustellen, dass parallele Prozesse, die durch den Empfang mehrerer Webhook-Payloads laufen, sich nicht gegenseitig stören, da jedes Webhook-Batch eine eindeutige batch_id hat.
Sobald die Daten vollständig in CSV konvertiert 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 ein anderer S3-Bucket für die Ausgabe erforderlich ist, andernfalls riskieren wir die Erstellung einer rekursiven Schleife, die zu erhöhter Lambda-Nutzung und höheren Kosten führen kann. Wir müssen festlegen, in welchem S3-Bucket und an welchem Ort unsere CSV-Datei innerhalb unserer Lambda-Funktion gespeichert werden soll. Folgen Sie dem gleichen Verfahren wie oben, um einen neuen S3-Bucket zu erstellen, in dem wir unsere CSV-Datei speichern.
Beachten Sie, dass das tmp-Verzeichnis auf 512 MB Speicherplatz begrenzt ist, daher ist es wichtig, dass die temporäre Datei danach gelöscht wird, um ausreichend Speicherplatz für zukünftige Ausführungen sicherzustellen. Der Grund, warum wir eine temporäre Datei verwenden, anstatt direkt auf S3 zu schreiben, besteht darin, die Verbindung zu S3 durch eine einzelne Anfrage zu vereinfachen.
Genauso wie bei der Konsum-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 hat, sowie sowohl PutObject als auch GetObject für den Ausgabe-S3-Bucket.
Ein Beispiel unserer Verarbeitungs-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!
