Creare e utilizzare i webhook di Bird
Uccello
27 gen 2022
1 min read
Punti Chiave
I webhook in tempo reale di Bird consentono ai mittenti di ricevere i dati sugli eventi istantaneamente—niente polling, niente lavori cron e nessun mal di testa legato ai limiti di frequenza.
I webhook eliminano la complessità di gestione delle finestre temporali, prevenendo eventi mancati e gestendo record duplicati.
Ideale per l'automazione a valle: aggiornamento delle liste, avvio di viaggi, arricchimento dei cruscotti o sincronizzazione dei sistemi interni.
Il tutorial guida i mittenti nella creazione di un'intera pipeline di ingestione AWS: archiviazione S3, elaborazione Lambda e un bilanciatore di carico per applicazioni.
S3 funge da strato di archiviazione centrale per i payload dei webhook, con ogni batch scritto come un file JSON piatto.
Le funzioni Lambda gestiscono sia l'ingestione (memorizzazione di batch grezzi) sia la trasformazione (conversione da JSON a CSV).
Bird batch-a gli eventi: ogni batch di webhook include un
x-messagesystems-batch-idunico, consentendo controlli di ripetizione e deduplicazione.Il Lambda del consumatore deve rimanere efficiente poiché Bird ritenta i batch se il punto di fine non risponde entro ~10 secondi.
È consigliato AWS ALB (rispetto ad API Gateway) per semplicità, convenienza economica e gestione diretta delle richieste HTTP POST.
Il DNS (Route 53 o fornitore esterno) è configurato per mappare un nome host amichevole all'endpoint ALB.
Dopo la configurazione, Bird invia i dati degli eventi direttamente e in modo affidabile alla tua pipeline AWS per l'elaborazione asincrona.
La guida copre anche le migliori pratiche: permessi IAM con il minor privilegio, vincoli di archiviazione temporanea, evitare trigger ricorsivi e organizzare flussi di lavoro multi-lambda.
Punti salienti del Q&A
Qual è lo scopo principale dei webhook degli eventi in tempo reale di Bird?
Per inviare i dati degli eventi direttamente all'endpoint di un mittente in tempo reale, consentendo un'automazione immediata senza polling o chiamate API limitate dalla frequenza.
Perché i webhook sono migliori rispetto al recupero dei dati tramite API per i grandi mittenti?
Poiché i pull API richiedono la gestione della finestra temporale, i dati di rischio possono avere lacune o duplicati e potrebbero raggiungere i limiti di frequenza—i webhook eliminano tutto ciò inviando continuamente i dati.
Quali servizi AWS vengono utilizzati nel pipeline di ingestione webhook raccomandato?
Amazon S3 (archiviazione), AWS Lambda (elaborazione), un Application Load Balancer (ascoltatore HTTP) e, facoltativamente, Route 53 (DNS).
Come gestisce Bird i dati degli eventi in batch?
Bird invia più eventi insieme in un payload, ciascuno assegnato a un ID batch unico (x-messagesystems-batch-id) per il tracciamento, i tentativi di riinvio e la deduplicazione.
Cosa attiva la funzione Lambda del consumatore?
ALB inoltra le richieste POST dei webhook in arrivo direttamente al Lambda, che estrae il payload e lo scrive in S3.
Perché memorizzare il batch raw del webhook in S3 prima di elaborarlo?
Per garantire un'ingestione rapida (<10 secondi) in modo che la connessione non scada e per scaricare elaborazioni più pesanti su una pipeline async separata.
Cosa fa la seconda funzione Lambda?
Viene attivato da nuovi oggetti S3, convalida il JSON, lo converte in CSV e scrive l'output elaborato in un bucket S3 separato.
Perché utilizzare un bucket S3 separato per i file CSV elaborati?
Per evitare trigger ricorsivi (scrivere un nuovo file elaborato nello stesso bucket riattiverebbe continuamente la Lambda).
Quali permessi richiedono le funzioni Lambda?
Il consumer Lambda ha bisogno di permessi S3 PutObject; il processing Lambda ha bisogno di GetObject per il bucket sorgente e PutObject per il bucket di destinazione.
Perché si consiglia un AWS ALB rispetto all'API Gateway?
ALB sono più economici, più semplici e ideali per il forwarding di HTTPS POST diretto; API Gateway può alterare il formato del payload e aumentare la complessità.
Come fanno i mittenti a configurare il webhook in Bird?
Fornendo l'endpoint HTTPS (il record DNS per l'ALB), selezionando un sottoconto, scegliendo eventi e salvando la configurazione del webhook.
Quali opzioni a valle esistono per memorizzare o analizzare i dati elaborati?
Carica nelle banche dati (PostgreSQL, DynamoDB, RDS), alimenta i sistemi ETL o interroga direttamente con strumenti come Athena.
I webhooks in tempo reale di Bird sono uno strumento incredibilmente prezioso per i mittenti per avere dati automaticamente inviati ai loro sistemi. Questo può guidare l'automazione downstream come l'aggiornamento delle liste di distribuzione, l'attivazione di viaggi email automatizzati o la popolazione di dashboard interne. Sebbene gli stessi dati sugli eventi possano essere accessibili tramite l'interfaccia utente di Bird utilizzando Event Search, o programmaticamente sfruttando il Events API di Bird, le limitazioni imposte sul numero di record restituiti in una singola richiesta o i limiti di frequenza imposti sull'endpoint API possono rendere entrambi questi metodi restrittivi per i mittenti grandi e sofisticati.
I webhooks di eventi in tempo reale consentono a un mittente di configurare un endpoint dove Bird trasmette i dati, e i dati possono essere consumati senza dover pianificare lavori cron che estraggono i dati. Ci sono anche compromessi logistici quando si estraggono i dati rispetto all'avere i dati inviati, come dover identificare quale periodo di tempo e quali parametri utilizzare per ogni richiesta API. Se i periodi di tempo non sono allineati perfettamente, si rischia di perdere dati, e se i periodi di tempo si sovrappongono, è necessario gestire record di dati duplicati. Con i webhooks in tempo reale, i dati sugli eventi vengono semplicemente inviati al tuo endpoint man mano che diventano disponibili all'interno di Bird.
Sebbene i vantaggi di ricevere dati sugli eventi in tempo reale per guidare i processi di automazione downstream possano essere immediatamente compresi da molti mittenti, il processo effettivo per implementare e consumare i webhooks può essere intimidatorio. Questo può essere particolarmente vero se non si è familiari con i componenti tecnici per creare un endpoint e gestire i dati programmaticamente. Ci sono servizi disponibili che consumeranno i dati dei webhook di Bird e li ETL nel tuo database automaticamente – un esempio sarebbe StitchData, di cui abbiamo parlato nel passato. Tuttavia, se desideri avere più controllo sul processo, puoi facilmente costruire i componenti da solo. La seguente è una guida semplice per aiutare i mittenti a sentirsi a proprio agio nella creazione di un webhook di eventi Bird e nella consulenza dei dati utilizzando l'infrastruttura all'interno di AWS.
I webhooks in tempo reale di Bird sono uno strumento incredibilmente prezioso per i mittenti per avere dati automaticamente inviati ai loro sistemi. Questo può guidare l'automazione downstream come l'aggiornamento delle liste di distribuzione, l'attivazione di viaggi email automatizzati o la popolazione di dashboard interne. Sebbene gli stessi dati sugli eventi possano essere accessibili tramite l'interfaccia utente di Bird utilizzando Event Search, o programmaticamente sfruttando il Events API di Bird, le limitazioni imposte sul numero di record restituiti in una singola richiesta o i limiti di frequenza imposti sull'endpoint API possono rendere entrambi questi metodi restrittivi per i mittenti grandi e sofisticati.
I webhooks di eventi in tempo reale consentono a un mittente di configurare un endpoint dove Bird trasmette i dati, e i dati possono essere consumati senza dover pianificare lavori cron che estraggono i dati. Ci sono anche compromessi logistici quando si estraggono i dati rispetto all'avere i dati inviati, come dover identificare quale periodo di tempo e quali parametri utilizzare per ogni richiesta API. Se i periodi di tempo non sono allineati perfettamente, si rischia di perdere dati, e se i periodi di tempo si sovrappongono, è necessario gestire record di dati duplicati. Con i webhooks in tempo reale, i dati sugli eventi vengono semplicemente inviati al tuo endpoint man mano che diventano disponibili all'interno di Bird.
Sebbene i vantaggi di ricevere dati sugli eventi in tempo reale per guidare i processi di automazione downstream possano essere immediatamente compresi da molti mittenti, il processo effettivo per implementare e consumare i webhooks può essere intimidatorio. Questo può essere particolarmente vero se non si è familiari con i componenti tecnici per creare un endpoint e gestire i dati programmaticamente. Ci sono servizi disponibili che consumeranno i dati dei webhook di Bird e li ETL nel tuo database automaticamente – un esempio sarebbe StitchData, di cui abbiamo parlato nel passato. Tuttavia, se desideri avere più controllo sul processo, puoi facilmente costruire i componenti da solo. La seguente è una guida semplice per aiutare i mittenti a sentirsi a proprio agio nella creazione di un webhook di eventi Bird e nella consulenza dei dati utilizzando l'infrastruttura all'interno di AWS.
I webhooks in tempo reale di Bird sono uno strumento incredibilmente prezioso per i mittenti per avere dati automaticamente inviati ai loro sistemi. Questo può guidare l'automazione downstream come l'aggiornamento delle liste di distribuzione, l'attivazione di viaggi email automatizzati o la popolazione di dashboard interne. Sebbene gli stessi dati sugli eventi possano essere accessibili tramite l'interfaccia utente di Bird utilizzando Event Search, o programmaticamente sfruttando il Events API di Bird, le limitazioni imposte sul numero di record restituiti in una singola richiesta o i limiti di frequenza imposti sull'endpoint API possono rendere entrambi questi metodi restrittivi per i mittenti grandi e sofisticati.
I webhooks di eventi in tempo reale consentono a un mittente di configurare un endpoint dove Bird trasmette i dati, e i dati possono essere consumati senza dover pianificare lavori cron che estraggono i dati. Ci sono anche compromessi logistici quando si estraggono i dati rispetto all'avere i dati inviati, come dover identificare quale periodo di tempo e quali parametri utilizzare per ogni richiesta API. Se i periodi di tempo non sono allineati perfettamente, si rischia di perdere dati, e se i periodi di tempo si sovrappongono, è necessario gestire record di dati duplicati. Con i webhooks in tempo reale, i dati sugli eventi vengono semplicemente inviati al tuo endpoint man mano che diventano disponibili all'interno di Bird.
Sebbene i vantaggi di ricevere dati sugli eventi in tempo reale per guidare i processi di automazione downstream possano essere immediatamente compresi da molti mittenti, il processo effettivo per implementare e consumare i webhooks può essere intimidatorio. Questo può essere particolarmente vero se non si è familiari con i componenti tecnici per creare un endpoint e gestire i dati programmaticamente. Ci sono servizi disponibili che consumeranno i dati dei webhook di Bird e li ETL nel tuo database automaticamente – un esempio sarebbe StitchData, di cui abbiamo parlato nel passato. Tuttavia, se desideri avere più controllo sul processo, puoi facilmente costruire i componenti da solo. La seguente è una guida semplice per aiutare i mittenti a sentirsi a proprio agio nella creazione di un webhook di eventi Bird e nella consulenza dei dati utilizzando l'infrastruttura all'interno di AWS.
Configurare l'endpoint di destinazione del Webhook
Quando viene creato un evento Bird, vogliamo che i dati di quell'evento vengano trasmessi in tempo reale a un endpoint in AWS in modo da poter consumare e utilizzare quei dati programmaticamente. I dati verranno inviati da Bird a un endpoint di destinazione, che inoltrerà il payload a una funzione lambda che elaborerà e memorizzerà i dati in un bucket S3. Un diagramma generale del flusso di dati descritto è riportato di seguito:
Componente | Responsabilità |
|---|---|
Webhook di Bird | Generare batch di eventi in tempo reale come richieste HTTP POST |
Application Load Balancer | Ricevere traffico webhook esterno e instradare le richieste |
Lambda (Consumatore) | Memorizzare batch di webhook raw su S3 in modo efficiente |
Amazon S3 | Memorizzare i payload di eventi in batch come file JSON piatti |
Lambda (Elaboratore) | Trasformare o caricare dati memorizzati in modo asincrono |
Per implementare questo flusso di lavoro, iniziamo a costruirli in ordine inverso, cominciando con la creazione di un bucket S3 dove memorizzeremo i dati dei nostri eventi e poi procedendo all'indietro, aggiungendo ciascun componente che alimenta ciò che abbiamo costruito.
Quando viene creato un evento Bird, vogliamo che i dati di quell'evento vengano trasmessi in tempo reale a un endpoint in AWS in modo da poter consumare e utilizzare quei dati programmaticamente. I dati verranno inviati da Bird a un endpoint di destinazione, che inoltrerà il payload a una funzione lambda che elaborerà e memorizzerà i dati in un bucket S3. Un diagramma generale del flusso di dati descritto è riportato di seguito:
Componente | Responsabilità |
|---|---|
Webhook di Bird | Generare batch di eventi in tempo reale come richieste HTTP POST |
Application Load Balancer | Ricevere traffico webhook esterno e instradare le richieste |
Lambda (Consumatore) | Memorizzare batch di webhook raw su S3 in modo efficiente |
Amazon S3 | Memorizzare i payload di eventi in batch come file JSON piatti |
Lambda (Elaboratore) | Trasformare o caricare dati memorizzati in modo asincrono |
Per implementare questo flusso di lavoro, iniziamo a costruirli in ordine inverso, cominciando con la creazione di un bucket S3 dove memorizzeremo i dati dei nostri eventi e poi procedendo all'indietro, aggiungendo ciascun componente che alimenta ciò che abbiamo costruito.
Quando viene creato un evento Bird, vogliamo che i dati di quell'evento vengano trasmessi in tempo reale a un endpoint in AWS in modo da poter consumare e utilizzare quei dati programmaticamente. I dati verranno inviati da Bird a un endpoint di destinazione, che inoltrerà il payload a una funzione lambda che elaborerà e memorizzerà i dati in un bucket S3. Un diagramma generale del flusso di dati descritto è riportato di seguito:
Componente | Responsabilità |
|---|---|
Webhook di Bird | Generare batch di eventi in tempo reale come richieste HTTP POST |
Application Load Balancer | Ricevere traffico webhook esterno e instradare le richieste |
Lambda (Consumatore) | Memorizzare batch di webhook raw su S3 in modo efficiente |
Amazon S3 | Memorizzare i payload di eventi in batch come file JSON piatti |
Lambda (Elaboratore) | Trasformare o caricare dati memorizzati in modo asincrono |
Per implementare questo flusso di lavoro, iniziamo a costruirli in ordine inverso, cominciando con la creazione di un bucket S3 dove memorizzeremo i dati dei nostri eventi e poi procedendo all'indietro, aggiungendo ciascun componente che alimenta ciò che abbiamo costruito.
Crea un bucket S3 per memorizzare i dati del webhook
Prima di creare il nostro bilanciatore di carico per accettare i dati, o la nostra funzione lambda per memorizzare i dati, dobbiamo prima creare il nostro bucket S3 dove i dati saranno archiviati. Sebbene S3 offra eccellenti capacità di archiviazione per i dati del webhook, le organizzazioni che utilizzano anche database PostgreSQL per l'elaborazione degli eventi dovrebbero implementare adeguate procedure di backup e ripristino per proteggere i propri dati strutturati insieme alla loro strategia di archiviazione S3. Per fare questo, naviga nel servizio S3 all'interno di AWS e premi “Crea Bucket.” Ti verrà chiesto di assegnare un nome al tuo bucket e impostare la regione – assicurati di utilizzare la stessa regione del tuo ALB e della funzione lambda. Quando il tuo bucket S3 viene creato, sarà vuoto – se desideri organizzare i dati all'interno di una cartella, puoi creare ora la directory desiderata, oppure la directory verrà creata quando la tua funzione lambda memorizza il file. In questo esempio, abbiamo nominato il nostro bucket S3 “bird-webhooks” e creato una cartella chiamata “B Event Data” per archiviare i nostri dati degli eventi – vedrai questi nomi riportati nella nostra funzione lambda qui sotto.
Prima di creare il nostro bilanciatore di carico per accettare i dati, o la nostra funzione lambda per memorizzare i dati, dobbiamo prima creare il nostro bucket S3 dove i dati saranno archiviati. Sebbene S3 offra eccellenti capacità di archiviazione per i dati del webhook, le organizzazioni che utilizzano anche database PostgreSQL per l'elaborazione degli eventi dovrebbero implementare adeguate procedure di backup e ripristino per proteggere i propri dati strutturati insieme alla loro strategia di archiviazione S3. Per fare questo, naviga nel servizio S3 all'interno di AWS e premi “Crea Bucket.” Ti verrà chiesto di assegnare un nome al tuo bucket e impostare la regione – assicurati di utilizzare la stessa regione del tuo ALB e della funzione lambda. Quando il tuo bucket S3 viene creato, sarà vuoto – se desideri organizzare i dati all'interno di una cartella, puoi creare ora la directory desiderata, oppure la directory verrà creata quando la tua funzione lambda memorizza il file. In questo esempio, abbiamo nominato il nostro bucket S3 “bird-webhooks” e creato una cartella chiamata “B Event Data” per archiviare i nostri dati degli eventi – vedrai questi nomi riportati nella nostra funzione lambda qui sotto.
Prima di creare il nostro bilanciatore di carico per accettare i dati, o la nostra funzione lambda per memorizzare i dati, dobbiamo prima creare il nostro bucket S3 dove i dati saranno archiviati. Sebbene S3 offra eccellenti capacità di archiviazione per i dati del webhook, le organizzazioni che utilizzano anche database PostgreSQL per l'elaborazione degli eventi dovrebbero implementare adeguate procedure di backup e ripristino per proteggere i propri dati strutturati insieme alla loro strategia di archiviazione S3. Per fare questo, naviga nel servizio S3 all'interno di AWS e premi “Crea Bucket.” Ti verrà chiesto di assegnare un nome al tuo bucket e impostare la regione – assicurati di utilizzare la stessa regione del tuo ALB e della funzione lambda. Quando il tuo bucket S3 viene creato, sarà vuoto – se desideri organizzare i dati all'interno di una cartella, puoi creare ora la directory desiderata, oppure la directory verrà creata quando la tua funzione lambda memorizza il file. In questo esempio, abbiamo nominato il nostro bucket S3 “bird-webhooks” e creato una cartella chiamata “B Event Data” per archiviare i nostri dati degli eventi – vedrai questi nomi riportati nella nostra funzione lambda qui sotto.
Crea una funzione Lambda per consumare i dati
Il trattamento e l'archiviazione dei dati verranno effettuati da una funzione lambda che è invocata dal nostro bilanciatore di carico applicativo (ALB).
Il primo passo è creare la tua funzione lambda navigando al servizio Lambda all'interno di AWS e cliccando su “Crea Funzione.” Ti verrà chiesto di assegnare un nome alla tua funzione lambda e di selezionare in quale linguaggio di programmazione scrivere la tua funzione. Per questo esempio, utilizziamo Python come linguaggio di runtime.
Ora dobbiamo sviluppare la nostra funzione lambda. Per un momento, supponiamo che il nostro bilanciatore di carico applicativo sia stato configurato e stia inoltrando il payload del webhook alla nostra funzione lambda – la lambda riceverà un payload contenente le intestazioni e il corpo completi. Il payload viene passato alla nostra funzione lambda utilizzando l'oggetto “event” come dizionario. Puoi fare riferimento alle intestazioni e al corpo del payload in modo indipendente accedendo agli oggetti “headers” e “body” all'interno del payload. In questo esempio stiamo semplicemente per leggere l'intestazione “x-messagesystems-batch-id”, dove l'ID del lotto è un valore unico creato da Bird per il lotto del webhook, e usarlo come nome del file quando si memorizza il corpo come un file flat in S3; tuttavia, potresti voler aggiungere ulteriori funzionalità come controlli di autenticazione o gestione degli errori, se necessario.
Quando memorizzi il payload in un file flat su S3, dovremo definire il nome del bucket S3, la posizione e il nome del file in cui i dati del payload verranno archiviati. Nella nostra funzione lambda di esempio, lo facciamo all'interno della funzione “store_batch”. In questo esempio, stiamo per memorizzare l'intero lotto come un singolo file, il che aiuta a garantire che i dati vengano raccolti e memorizzati prima che la connessione HTTP tra Bird e il tuo endpoint scada. Anche se potresti regolare le impostazioni del timeout della connessione sul tuo bilanciatore di carico, non ci sono garanzie che la connessione non scadrà sul lato della trasmissione (in questo caso Bird) o che la connessione non venga interrotta prima che la tua funzione lambda finisca di eseguire. È una buona pratica mantenere la tua funzione consumatrice il più efficiente possibile e riservare le attività di elaborazione dei dati per i processi downstream quando possibile – come convertire il payload in formato JSON a un file CSV, o caricare i dati dell'evento in un database.
È importante notare che potresti dover aggiornare i permessi per la tua funzione lambda. Il tuo ruolo di esecuzione avrà bisogno dei permessi PutObject e GetObject per S3. È buona prassi applicare il principio del minimo privilegio, quindi ti consiglio di impostare questi permessi solo per il bucket S3 in cui verranno archiviati i payload del webhook.
Un campione della nostra funzione lambda consumatrice può essere trovato qui.
Una nota veloce sull'ID del lotto: Bird raggruppa eventi in un singolo payload, dove ogni lotto può contenere da 1 a 350 o più record di eventi. Al lotto verrà assegnato un ID lotto unico, che può essere utilizzato per visualizzare lo stato del lotto sfruttando l'API Webhook degli Eventi o all'interno del tuo account Bird cliccando su uno stream di webhook e selezionando “Stato del Lotto.” Nel caso in cui un payload del webhook non possa essere consegnato, ad esempio durante un timeout di connessione, Bird tenterà automaticamente di ritentare il lotto utilizzando lo stesso ID lotto. Questo può accadere quando la tua funzione lambda sta eseguendo vicino al tempo massimo di andata e ritorno di 10 secondi ed è un motivo per ottimizzare la funzione consumatrice per ridurre il tempo di esecuzione.
Per gestire tutte le attività di elaborazione dei dati, ti consiglio di creare una funzione lambda separata che venga eseguita ogni volta che viene creato un nuovo file nel bucket S3 – in questo modo, l'elaborazione dei dati viene eseguita in modo asincrono rispetto alla trasmissione dei dati e non c'è rischio di perdere dati a causa di una connessione interrotta. Discuterò la funzione lambda di elaborazione in una sezione successiva.
Il trattamento e l'archiviazione dei dati verranno effettuati da una funzione lambda che è invocata dal nostro bilanciatore di carico applicativo (ALB).
Il primo passo è creare la tua funzione lambda navigando al servizio Lambda all'interno di AWS e cliccando su “Crea Funzione.” Ti verrà chiesto di assegnare un nome alla tua funzione lambda e di selezionare in quale linguaggio di programmazione scrivere la tua funzione. Per questo esempio, utilizziamo Python come linguaggio di runtime.
Ora dobbiamo sviluppare la nostra funzione lambda. Per un momento, supponiamo che il nostro bilanciatore di carico applicativo sia stato configurato e stia inoltrando il payload del webhook alla nostra funzione lambda – la lambda riceverà un payload contenente le intestazioni e il corpo completi. Il payload viene passato alla nostra funzione lambda utilizzando l'oggetto “event” come dizionario. Puoi fare riferimento alle intestazioni e al corpo del payload in modo indipendente accedendo agli oggetti “headers” e “body” all'interno del payload. In questo esempio stiamo semplicemente per leggere l'intestazione “x-messagesystems-batch-id”, dove l'ID del lotto è un valore unico creato da Bird per il lotto del webhook, e usarlo come nome del file quando si memorizza il corpo come un file flat in S3; tuttavia, potresti voler aggiungere ulteriori funzionalità come controlli di autenticazione o gestione degli errori, se necessario.
Quando memorizzi il payload in un file flat su S3, dovremo definire il nome del bucket S3, la posizione e il nome del file in cui i dati del payload verranno archiviati. Nella nostra funzione lambda di esempio, lo facciamo all'interno della funzione “store_batch”. In questo esempio, stiamo per memorizzare l'intero lotto come un singolo file, il che aiuta a garantire che i dati vengano raccolti e memorizzati prima che la connessione HTTP tra Bird e il tuo endpoint scada. Anche se potresti regolare le impostazioni del timeout della connessione sul tuo bilanciatore di carico, non ci sono garanzie che la connessione non scadrà sul lato della trasmissione (in questo caso Bird) o che la connessione non venga interrotta prima che la tua funzione lambda finisca di eseguire. È una buona pratica mantenere la tua funzione consumatrice il più efficiente possibile e riservare le attività di elaborazione dei dati per i processi downstream quando possibile – come convertire il payload in formato JSON a un file CSV, o caricare i dati dell'evento in un database.
È importante notare che potresti dover aggiornare i permessi per la tua funzione lambda. Il tuo ruolo di esecuzione avrà bisogno dei permessi PutObject e GetObject per S3. È buona prassi applicare il principio del minimo privilegio, quindi ti consiglio di impostare questi permessi solo per il bucket S3 in cui verranno archiviati i payload del webhook.
Un campione della nostra funzione lambda consumatrice può essere trovato qui.
Una nota veloce sull'ID del lotto: Bird raggruppa eventi in un singolo payload, dove ogni lotto può contenere da 1 a 350 o più record di eventi. Al lotto verrà assegnato un ID lotto unico, che può essere utilizzato per visualizzare lo stato del lotto sfruttando l'API Webhook degli Eventi o all'interno del tuo account Bird cliccando su uno stream di webhook e selezionando “Stato del Lotto.” Nel caso in cui un payload del webhook non possa essere consegnato, ad esempio durante un timeout di connessione, Bird tenterà automaticamente di ritentare il lotto utilizzando lo stesso ID lotto. Questo può accadere quando la tua funzione lambda sta eseguendo vicino al tempo massimo di andata e ritorno di 10 secondi ed è un motivo per ottimizzare la funzione consumatrice per ridurre il tempo di esecuzione.
Per gestire tutte le attività di elaborazione dei dati, ti consiglio di creare una funzione lambda separata che venga eseguita ogni volta che viene creato un nuovo file nel bucket S3 – in questo modo, l'elaborazione dei dati viene eseguita in modo asincrono rispetto alla trasmissione dei dati e non c'è rischio di perdere dati a causa di una connessione interrotta. Discuterò la funzione lambda di elaborazione in una sezione successiva.
Il trattamento e l'archiviazione dei dati verranno effettuati da una funzione lambda che è invocata dal nostro bilanciatore di carico applicativo (ALB).
Il primo passo è creare la tua funzione lambda navigando al servizio Lambda all'interno di AWS e cliccando su “Crea Funzione.” Ti verrà chiesto di assegnare un nome alla tua funzione lambda e di selezionare in quale linguaggio di programmazione scrivere la tua funzione. Per questo esempio, utilizziamo Python come linguaggio di runtime.
Ora dobbiamo sviluppare la nostra funzione lambda. Per un momento, supponiamo che il nostro bilanciatore di carico applicativo sia stato configurato e stia inoltrando il payload del webhook alla nostra funzione lambda – la lambda riceverà un payload contenente le intestazioni e il corpo completi. Il payload viene passato alla nostra funzione lambda utilizzando l'oggetto “event” come dizionario. Puoi fare riferimento alle intestazioni e al corpo del payload in modo indipendente accedendo agli oggetti “headers” e “body” all'interno del payload. In questo esempio stiamo semplicemente per leggere l'intestazione “x-messagesystems-batch-id”, dove l'ID del lotto è un valore unico creato da Bird per il lotto del webhook, e usarlo come nome del file quando si memorizza il corpo come un file flat in S3; tuttavia, potresti voler aggiungere ulteriori funzionalità come controlli di autenticazione o gestione degli errori, se necessario.
Quando memorizzi il payload in un file flat su S3, dovremo definire il nome del bucket S3, la posizione e il nome del file in cui i dati del payload verranno archiviati. Nella nostra funzione lambda di esempio, lo facciamo all'interno della funzione “store_batch”. In questo esempio, stiamo per memorizzare l'intero lotto come un singolo file, il che aiuta a garantire che i dati vengano raccolti e memorizzati prima che la connessione HTTP tra Bird e il tuo endpoint scada. Anche se potresti regolare le impostazioni del timeout della connessione sul tuo bilanciatore di carico, non ci sono garanzie che la connessione non scadrà sul lato della trasmissione (in questo caso Bird) o che la connessione non venga interrotta prima che la tua funzione lambda finisca di eseguire. È una buona pratica mantenere la tua funzione consumatrice il più efficiente possibile e riservare le attività di elaborazione dei dati per i processi downstream quando possibile – come convertire il payload in formato JSON a un file CSV, o caricare i dati dell'evento in un database.
È importante notare che potresti dover aggiornare i permessi per la tua funzione lambda. Il tuo ruolo di esecuzione avrà bisogno dei permessi PutObject e GetObject per S3. È buona prassi applicare il principio del minimo privilegio, quindi ti consiglio di impostare questi permessi solo per il bucket S3 in cui verranno archiviati i payload del webhook.
Un campione della nostra funzione lambda consumatrice può essere trovato qui.
Una nota veloce sull'ID del lotto: Bird raggruppa eventi in un singolo payload, dove ogni lotto può contenere da 1 a 350 o più record di eventi. Al lotto verrà assegnato un ID lotto unico, che può essere utilizzato per visualizzare lo stato del lotto sfruttando l'API Webhook degli Eventi o all'interno del tuo account Bird cliccando su uno stream di webhook e selezionando “Stato del Lotto.” Nel caso in cui un payload del webhook non possa essere consegnato, ad esempio durante un timeout di connessione, Bird tenterà automaticamente di ritentare il lotto utilizzando lo stesso ID lotto. Questo può accadere quando la tua funzione lambda sta eseguendo vicino al tempo massimo di andata e ritorno di 10 secondi ed è un motivo per ottimizzare la funzione consumatrice per ridurre il tempo di esecuzione.
Per gestire tutte le attività di elaborazione dei dati, ti consiglio di creare una funzione lambda separata che venga eseguita ogni volta che viene creato un nuovo file nel bucket S3 – in questo modo, l'elaborazione dei dati viene eseguita in modo asincrono rispetto alla trasmissione dei dati e non c'è rischio di perdere dati a causa di una connessione interrotta. Discuterò la funzione lambda di elaborazione in una sezione successiva.
Crea un Bilanciatore di Carico per Applicazioni
Per ricevere un payload webhook, dobbiamo fornire un endpoint a cui inviare i payload. Facciamo questo creando un bilanciatore di carico applicativo all'interno di AWS navigando su EC2 > Bilanciatori di carico e facendo clic su “Crea bilanciatore di carico.” Ti verrà chiesto di scegliere quale tipo di bilanciatore di carico desideri creare: per questo, vogliamo creare un bilanciatore di carico applicativo. Dobbiamo usare un bilanciatore di carico applicativo (ALB) per costruire il nostro consumatore poiché i webhook degli eventi verranno inviati come una richiesta HTTP, e gli ALB sono utilizzati per instradare le richieste HTTP all'interno di AWS. Potremmo implementare un Gateway HTTP come alternativa; tuttavia, utilizziamo un ALB per questo progetto perché è più leggero e conveniente rispetto a un Gateway HTTP. È importante notare che se scegli di utilizzare un Gateway HTTP, il formato dell'evento potrebbe essere diverso rispetto a un ALB, e pertanto la tua funzione lambda dovrà gestire l'oggetto della richiesta di conseguenza.
Una volta creato il tuo ALB, ti verrà chiesto di assegnare un nome al tuo ALB e configurare il schema e le impostazioni di accesso/sicurezza: poiché intendiamo ricevere dati evento da una fonte esterna (Bird), vorremmo che il nostro ALB sia orientato ad internet. Sotto “Listener e instradamento,” l'ALB dovrebbe ascoltare HTTPS sulla porta 443, e vogliamo creare un gruppo di destinazione che punti alla nostra funzione lambda affinché il nostro ALB inoltri le richieste in entrata alla funzione lambda consumatrice che abbiamo creato sopra. Devi anche assicurarti che il gruppo di sicurezza abbia il permesso di accettare traffico attraverso la porta 443.
Per ricevere un payload webhook, dobbiamo fornire un endpoint a cui inviare i payload. Facciamo questo creando un bilanciatore di carico applicativo all'interno di AWS navigando su EC2 > Bilanciatori di carico e facendo clic su “Crea bilanciatore di carico.” Ti verrà chiesto di scegliere quale tipo di bilanciatore di carico desideri creare: per questo, vogliamo creare un bilanciatore di carico applicativo. Dobbiamo usare un bilanciatore di carico applicativo (ALB) per costruire il nostro consumatore poiché i webhook degli eventi verranno inviati come una richiesta HTTP, e gli ALB sono utilizzati per instradare le richieste HTTP all'interno di AWS. Potremmo implementare un Gateway HTTP come alternativa; tuttavia, utilizziamo un ALB per questo progetto perché è più leggero e conveniente rispetto a un Gateway HTTP. È importante notare che se scegli di utilizzare un Gateway HTTP, il formato dell'evento potrebbe essere diverso rispetto a un ALB, e pertanto la tua funzione lambda dovrà gestire l'oggetto della richiesta di conseguenza.
Una volta creato il tuo ALB, ti verrà chiesto di assegnare un nome al tuo ALB e configurare il schema e le impostazioni di accesso/sicurezza: poiché intendiamo ricevere dati evento da una fonte esterna (Bird), vorremmo che il nostro ALB sia orientato ad internet. Sotto “Listener e instradamento,” l'ALB dovrebbe ascoltare HTTPS sulla porta 443, e vogliamo creare un gruppo di destinazione che punti alla nostra funzione lambda affinché il nostro ALB inoltri le richieste in entrata alla funzione lambda consumatrice che abbiamo creato sopra. Devi anche assicurarti che il gruppo di sicurezza abbia il permesso di accettare traffico attraverso la porta 443.
Per ricevere un payload webhook, dobbiamo fornire un endpoint a cui inviare i payload. Facciamo questo creando un bilanciatore di carico applicativo all'interno di AWS navigando su EC2 > Bilanciatori di carico e facendo clic su “Crea bilanciatore di carico.” Ti verrà chiesto di scegliere quale tipo di bilanciatore di carico desideri creare: per questo, vogliamo creare un bilanciatore di carico applicativo. Dobbiamo usare un bilanciatore di carico applicativo (ALB) per costruire il nostro consumatore poiché i webhook degli eventi verranno inviati come una richiesta HTTP, e gli ALB sono utilizzati per instradare le richieste HTTP all'interno di AWS. Potremmo implementare un Gateway HTTP come alternativa; tuttavia, utilizziamo un ALB per questo progetto perché è più leggero e conveniente rispetto a un Gateway HTTP. È importante notare che se scegli di utilizzare un Gateway HTTP, il formato dell'evento potrebbe essere diverso rispetto a un ALB, e pertanto la tua funzione lambda dovrà gestire l'oggetto della richiesta di conseguenza.
Una volta creato il tuo ALB, ti verrà chiesto di assegnare un nome al tuo ALB e configurare il schema e le impostazioni di accesso/sicurezza: poiché intendiamo ricevere dati evento da una fonte esterna (Bird), vorremmo che il nostro ALB sia orientato ad internet. Sotto “Listener e instradamento,” l'ALB dovrebbe ascoltare HTTPS sulla porta 443, e vogliamo creare un gruppo di destinazione che punti alla nostra funzione lambda affinché il nostro ALB inoltri le richieste in entrata alla funzione lambda consumatrice che abbiamo creato sopra. Devi anche assicurarti che il gruppo di sicurezza abbia il permesso di accettare traffico attraverso la porta 443.
Crea un record DNS per il bilanciatore di carico
Per facilitarci l'utilizzo del nostro ALB come endpoint, creeremo un record A nel DNS che punta al nostro ALB. Per questo, possiamo utilizzare il servizio AWS Route 53 (o il tuo attuale fornitore DNS) e creare un record A per il nome host che desideri utilizzare per il tuo endpoint (ad es. spevents.<tuo_dominio>). Quando lavori con DNS su larga scala su AWS, sii consapevole che ci sono limiti DNS non documentati che possono influenzare le applicazioni ad alto volume, specialmente quelle che gestiscono grandi quantità di traffico in uscita, come i sistemi di consegna email. Il record A dovrebbe essere configurato per puntare all'ALB che abbiamo creato. Se stai utilizzando Route 53 per gestire i record DNS, puoi fare riferimento direttamente all'istanza ALB abilitando "Alias" e selezionando l'ALB; in caso contrario, se stai utilizzando un fornitore DNS esterno, dovresti puntare il record A all'indirizzo IP pubblico dell'istanza ALB.
Ti consiglio di utilizzare uno strumento come Postman per verificare che tutto sia stato configurato correttamente prima di abilitare il tuo webhook Bird. Puoi effettuare una richiesta POST al tuo endpoint e confermare che viene ricevuta una risposta. Se la tua richiesta POST non restituisce una risposta, potresti dover ricontrollare che il tuo ALB stia ascoltando sulla porta corretta.
Per facilitarci l'utilizzo del nostro ALB come endpoint, creeremo un record A nel DNS che punta al nostro ALB. Per questo, possiamo utilizzare il servizio AWS Route 53 (o il tuo attuale fornitore DNS) e creare un record A per il nome host che desideri utilizzare per il tuo endpoint (ad es. spevents.<tuo_dominio>). Quando lavori con DNS su larga scala su AWS, sii consapevole che ci sono limiti DNS non documentati che possono influenzare le applicazioni ad alto volume, specialmente quelle che gestiscono grandi quantità di traffico in uscita, come i sistemi di consegna email. Il record A dovrebbe essere configurato per puntare all'ALB che abbiamo creato. Se stai utilizzando Route 53 per gestire i record DNS, puoi fare riferimento direttamente all'istanza ALB abilitando "Alias" e selezionando l'ALB; in caso contrario, se stai utilizzando un fornitore DNS esterno, dovresti puntare il record A all'indirizzo IP pubblico dell'istanza ALB.
Ti consiglio di utilizzare uno strumento come Postman per verificare che tutto sia stato configurato correttamente prima di abilitare il tuo webhook Bird. Puoi effettuare una richiesta POST al tuo endpoint e confermare che viene ricevuta una risposta. Se la tua richiesta POST non restituisce una risposta, potresti dover ricontrollare che il tuo ALB stia ascoltando sulla porta corretta.
Per facilitarci l'utilizzo del nostro ALB come endpoint, creeremo un record A nel DNS che punta al nostro ALB. Per questo, possiamo utilizzare il servizio AWS Route 53 (o il tuo attuale fornitore DNS) e creare un record A per il nome host che desideri utilizzare per il tuo endpoint (ad es. spevents.<tuo_dominio>). Quando lavori con DNS su larga scala su AWS, sii consapevole che ci sono limiti DNS non documentati che possono influenzare le applicazioni ad alto volume, specialmente quelle che gestiscono grandi quantità di traffico in uscita, come i sistemi di consegna email. Il record A dovrebbe essere configurato per puntare all'ALB che abbiamo creato. Se stai utilizzando Route 53 per gestire i record DNS, puoi fare riferimento direttamente all'istanza ALB abilitando "Alias" e selezionando l'ALB; in caso contrario, se stai utilizzando un fornitore DNS esterno, dovresti puntare il record A all'indirizzo IP pubblico dell'istanza ALB.
Ti consiglio di utilizzare uno strumento come Postman per verificare che tutto sia stato configurato correttamente prima di abilitare il tuo webhook Bird. Puoi effettuare una richiesta POST al tuo endpoint e confermare che viene ricevuta una risposta. Se la tua richiesta POST non restituisce una risposta, potresti dover ricontrollare che il tuo ALB stia ascoltando sulla porta corretta.
Crea un Webhook per uccelli
Ora siamo pronti per creare il webhook in Bird e utilizzare il nome host definito dal record A sopra come nostro endpoint di destinazione. Per creare il webhook, naviga nella sezione Webhooks all'interno del tuo account Bird e clicca su “Crea Webhook.” Sarai invitato ad assegnare un nome al tuo webhook e fornire un'URL di destinazione – l'obiettivo dovrebbe essere il nome host del record A che hai creato in precedenza. Nota che l'URL di destinazione potrebbe richiedere che sia incluso “HTTPS://” nell'URL.
Una volta completato, verifica che il sottoaccount e gli eventi corretti siano selezionati, e premi “Crea Webhook” per salvare la tua configurazione. I dati degli eventi per tutti i tipi di eventi selezionati ora verranno trasmessi al nostro URL di destinazione e saranno consumati dal nostro ALB per l'elaborazione a valle.
Ora siamo pronti per creare il webhook in Bird e utilizzare il nome host definito dal record A sopra come nostro endpoint di destinazione. Per creare il webhook, naviga nella sezione Webhooks all'interno del tuo account Bird e clicca su “Crea Webhook.” Sarai invitato ad assegnare un nome al tuo webhook e fornire un'URL di destinazione – l'obiettivo dovrebbe essere il nome host del record A che hai creato in precedenza. Nota che l'URL di destinazione potrebbe richiedere che sia incluso “HTTPS://” nell'URL.
Una volta completato, verifica che il sottoaccount e gli eventi corretti siano selezionati, e premi “Crea Webhook” per salvare la tua configurazione. I dati degli eventi per tutti i tipi di eventi selezionati ora verranno trasmessi al nostro URL di destinazione e saranno consumati dal nostro ALB per l'elaborazione a valle.
Ora siamo pronti per creare il webhook in Bird e utilizzare il nome host definito dal record A sopra come nostro endpoint di destinazione. Per creare il webhook, naviga nella sezione Webhooks all'interno del tuo account Bird e clicca su “Crea Webhook.” Sarai invitato ad assegnare un nome al tuo webhook e fornire un'URL di destinazione – l'obiettivo dovrebbe essere il nome host del record A che hai creato in precedenza. Nota che l'URL di destinazione potrebbe richiedere che sia incluso “HTTPS://” nell'URL.
Una volta completato, verifica che il sottoaccount e gli eventi corretti siano selezionati, e premi “Crea Webhook” per salvare la tua configurazione. I dati degli eventi per tutti i tipi di eventi selezionati ora verranno trasmessi al nostro URL di destinazione e saranno consumati dal nostro ALB per l'elaborazione a valle.
Elaborazione dei dati dell'evento Webhook
A seconda dello scopo previsto per l'archiviazione dei dati dell'evento Bird, le tue esigenze possono essere soddisfatte semplicemente memorizzando il payload JSON come un file flat. Potresti anche avere un processo ETL downstream già stabilito, in grado di consumare e caricare dati in formato JSON. In entrambi questi casi, potresti essere in grado di utilizzare il file flat creato dal nostro lambda di elaborazione che abbiamo creato sopra così com'è.
In alternativa, potresti dover trasformare i dati - ad esempio, convertire da JSON a un formato CSV - o caricare i dati direttamente in un database. In questo esempio, creeremo una semplice funzione lambda che convertirà i dati del webhook dal formato JSON originale in un file CSV che potrebbe essere caricato in un database.
A seconda dello scopo previsto per l'archiviazione dei dati dell'evento Bird, le tue esigenze possono essere soddisfatte semplicemente memorizzando il payload JSON come un file flat. Potresti anche avere un processo ETL downstream già stabilito, in grado di consumare e caricare dati in formato JSON. In entrambi questi casi, potresti essere in grado di utilizzare il file flat creato dal nostro lambda di elaborazione che abbiamo creato sopra così com'è.
In alternativa, potresti dover trasformare i dati - ad esempio, convertire da JSON a un formato CSV - o caricare i dati direttamente in un database. In questo esempio, creeremo una semplice funzione lambda che convertirà i dati del webhook dal formato JSON originale in un file CSV che potrebbe essere caricato in un database.
A seconda dello scopo previsto per l'archiviazione dei dati dell'evento Bird, le tue esigenze possono essere soddisfatte semplicemente memorizzando il payload JSON come un file flat. Potresti anche avere un processo ETL downstream già stabilito, in grado di consumare e caricare dati in formato JSON. In entrambi questi casi, potresti essere in grado di utilizzare il file flat creato dal nostro lambda di elaborazione che abbiamo creato sopra così com'è.
In alternativa, potresti dover trasformare i dati - ad esempio, convertire da JSON a un formato CSV - o caricare i dati direttamente in un database. In questo esempio, creeremo una semplice funzione lambda che convertirà i dati del webhook dal formato JSON originale in un file CSV che potrebbe essere caricato in un database.
Crea un Lambda per elaborare i dati
Come con la funzione lambda per consumare i dati del webhook, dobbiamo creare una nuova funzione lambda navigando al servizio Lambda all'interno di AWS e premendo “Crea Funzione.” Questa nuova funzione lambda verrà attivata quando viene creato un nuovo file nel nostro bucket S3 – leggerà i dati e li convertirà in un nuovo file csv.
La funzione lambda accetta le informazioni del file come evento. Nella funzione lambda di esempio, vedrai che prima abbiamo una serie di controlli di convalida per assicurarci che i dati siano completi e formattati come previsto. Successivamente, convertiamo il payload JSON in un file CSV utilizzando la libreria “csv” e scrivendo in un file temporaneo. Le funzioni lambda possono scrivere solo file locali nella directory “/tmp”, quindi creiamo un file csv temporaneo e lo nominiamo secondo la convenzione <batch_id>.csv. Il motivo per cui utilizziamo il batch_id qui è semplicemente per assicurarci che eventuali processi paralleli che stanno girando a seguito della ricezione di più payload di webhook non interferiscano tra loro, poiché ciascun batch di webhook avrà un batch_id unico.
Una volta che i dati sono stati completamente convertiti in CSV, leggiamo i dati CSV come uno stream di byte, eliminiamo il file temporaneo e salviamo i dati CSV come un nuovo file su S3. È importante notare che è necessario un bucket S3 diverso per l'output; in caso contrario, rischiamo di creare un ciclo ricorsivo che può comportare un aumento dell'uso della lambda e costi maggiori. Dobbiamo identificare in quale bucket S3 e posizione vogliamo che il nostro file CSV venga memorizzato all'interno della nostra funzione lambda. Segui la stessa procedura di sopra per creare un nuovo bucket S3 per memorizzare il nostro file CSV.
Nota che la directory tmp è limitata a 512 MB di spazio, quindi è importante che il file temporaneo venga eliminato successivamente per garantire spazio sufficiente per le esecuzioni future. Il motivo per cui utilizziamo un file temporaneo, invece di scrivere direttamente su S3, è per semplificare la connessione a S3 avendo una singola richiesta.
Proprio come con la funzione lambda di consumo, potresti dover aggiornare i permessi per la tua funzione lambda di processo. Questa funzione lambda richiede che il ruolo di esecuzione abbia permessi GetObject per il bucket S3 di input, e sia PutObject che GetObject per il bucket S3 di output.
Un esempio della nostra funzione lambda di elaborazione può essere trovato qui.
Come con la funzione lambda per consumare i dati del webhook, dobbiamo creare una nuova funzione lambda navigando al servizio Lambda all'interno di AWS e premendo “Crea Funzione.” Questa nuova funzione lambda verrà attivata quando viene creato un nuovo file nel nostro bucket S3 – leggerà i dati e li convertirà in un nuovo file csv.
La funzione lambda accetta le informazioni del file come evento. Nella funzione lambda di esempio, vedrai che prima abbiamo una serie di controlli di convalida per assicurarci che i dati siano completi e formattati come previsto. Successivamente, convertiamo il payload JSON in un file CSV utilizzando la libreria “csv” e scrivendo in un file temporaneo. Le funzioni lambda possono scrivere solo file locali nella directory “/tmp”, quindi creiamo un file csv temporaneo e lo nominiamo secondo la convenzione <batch_id>.csv. Il motivo per cui utilizziamo il batch_id qui è semplicemente per assicurarci che eventuali processi paralleli che stanno girando a seguito della ricezione di più payload di webhook non interferiscano tra loro, poiché ciascun batch di webhook avrà un batch_id unico.
Una volta che i dati sono stati completamente convertiti in CSV, leggiamo i dati CSV come uno stream di byte, eliminiamo il file temporaneo e salviamo i dati CSV come un nuovo file su S3. È importante notare che è necessario un bucket S3 diverso per l'output; in caso contrario, rischiamo di creare un ciclo ricorsivo che può comportare un aumento dell'uso della lambda e costi maggiori. Dobbiamo identificare in quale bucket S3 e posizione vogliamo che il nostro file CSV venga memorizzato all'interno della nostra funzione lambda. Segui la stessa procedura di sopra per creare un nuovo bucket S3 per memorizzare il nostro file CSV.
Nota che la directory tmp è limitata a 512 MB di spazio, quindi è importante che il file temporaneo venga eliminato successivamente per garantire spazio sufficiente per le esecuzioni future. Il motivo per cui utilizziamo un file temporaneo, invece di scrivere direttamente su S3, è per semplificare la connessione a S3 avendo una singola richiesta.
Proprio come con la funzione lambda di consumo, potresti dover aggiornare i permessi per la tua funzione lambda di processo. Questa funzione lambda richiede che il ruolo di esecuzione abbia permessi GetObject per il bucket S3 di input, e sia PutObject che GetObject per il bucket S3 di output.
Un esempio della nostra funzione lambda di elaborazione può essere trovato qui.
Come con la funzione lambda per consumare i dati del webhook, dobbiamo creare una nuova funzione lambda navigando al servizio Lambda all'interno di AWS e premendo “Crea Funzione.” Questa nuova funzione lambda verrà attivata quando viene creato un nuovo file nel nostro bucket S3 – leggerà i dati e li convertirà in un nuovo file csv.
La funzione lambda accetta le informazioni del file come evento. Nella funzione lambda di esempio, vedrai che prima abbiamo una serie di controlli di convalida per assicurarci che i dati siano completi e formattati come previsto. Successivamente, convertiamo il payload JSON in un file CSV utilizzando la libreria “csv” e scrivendo in un file temporaneo. Le funzioni lambda possono scrivere solo file locali nella directory “/tmp”, quindi creiamo un file csv temporaneo e lo nominiamo secondo la convenzione <batch_id>.csv. Il motivo per cui utilizziamo il batch_id qui è semplicemente per assicurarci che eventuali processi paralleli che stanno girando a seguito della ricezione di più payload di webhook non interferiscano tra loro, poiché ciascun batch di webhook avrà un batch_id unico.
Una volta che i dati sono stati completamente convertiti in CSV, leggiamo i dati CSV come uno stream di byte, eliminiamo il file temporaneo e salviamo i dati CSV come un nuovo file su S3. È importante notare che è necessario un bucket S3 diverso per l'output; in caso contrario, rischiamo di creare un ciclo ricorsivo che può comportare un aumento dell'uso della lambda e costi maggiori. Dobbiamo identificare in quale bucket S3 e posizione vogliamo che il nostro file CSV venga memorizzato all'interno della nostra funzione lambda. Segui la stessa procedura di sopra per creare un nuovo bucket S3 per memorizzare il nostro file CSV.
Nota che la directory tmp è limitata a 512 MB di spazio, quindi è importante che il file temporaneo venga eliminato successivamente per garantire spazio sufficiente per le esecuzioni future. Il motivo per cui utilizziamo un file temporaneo, invece di scrivere direttamente su S3, è per semplificare la connessione a S3 avendo una singola richiesta.
Proprio come con la funzione lambda di consumo, potresti dover aggiornare i permessi per la tua funzione lambda di processo. Questa funzione lambda richiede che il ruolo di esecuzione abbia permessi GetObject per il bucket S3 di input, e sia PutObject che GetObject per il bucket S3 di output.
Un esempio della nostra funzione lambda di elaborazione può essere trovato qui.
Configura un Lambda per eseguire quando nuovi dati vengono archiviati su S3
Ora che la nostra funzione lambda per convertire il file da JSON a formato CSV è stata creata, dobbiamo configurarla per attivarsi quando viene creato un nuovo file nel nostro bucket S3. Per fare ciò, dobbiamo aggiungere un trigger alla nostra funzione lambda aprendo la nostra funzione lambda e facendo clic su “Aggiungi Trigger” in cima alla pagina. Seleziona “S3” e fornisci il nome del bucket S3 dove sono memorizzati i payload webhook grezzi. Hai anche la possibilità di specificare un prefisso e/o un suffisso del file su cui filtrare. Una volta configurate le impostazioni, puoi aggiungere il trigger facendo clic su “Aggiungi” in fondo alla pagina. Ora la tua funzione lambda di elaborazione verrà eseguita ogni volta che un nuovo file viene aggiunto al tuo bucket S3.
Ora che la nostra funzione lambda per convertire il file da JSON a formato CSV è stata creata, dobbiamo configurarla per attivarsi quando viene creato un nuovo file nel nostro bucket S3. Per fare ciò, dobbiamo aggiungere un trigger alla nostra funzione lambda aprendo la nostra funzione lambda e facendo clic su “Aggiungi Trigger” in cima alla pagina. Seleziona “S3” e fornisci il nome del bucket S3 dove sono memorizzati i payload webhook grezzi. Hai anche la possibilità di specificare un prefisso e/o un suffisso del file su cui filtrare. Una volta configurate le impostazioni, puoi aggiungere il trigger facendo clic su “Aggiungi” in fondo alla pagina. Ora la tua funzione lambda di elaborazione verrà eseguita ogni volta che un nuovo file viene aggiunto al tuo bucket S3.
Ora che la nostra funzione lambda per convertire il file da JSON a formato CSV è stata creata, dobbiamo configurarla per attivarsi quando viene creato un nuovo file nel nostro bucket S3. Per fare ciò, dobbiamo aggiungere un trigger alla nostra funzione lambda aprendo la nostra funzione lambda e facendo clic su “Aggiungi Trigger” in cima alla pagina. Seleziona “S3” e fornisci il nome del bucket S3 dove sono memorizzati i payload webhook grezzi. Hai anche la possibilità di specificare un prefisso e/o un suffisso del file su cui filtrare. Una volta configurate le impostazioni, puoi aggiungere il trigger facendo clic su “Aggiungi” in fondo alla pagina. Ora la tua funzione lambda di elaborazione verrà eseguita ogni volta che un nuovo file viene aggiunto al tuo bucket S3.
Caricamento dei dati in un database
In questo esempio, non tratterò in dettaglio il caricamento dei dati in un database, ma se hai seguito questo esempio hai un paio di opzioni:
Carica i dati direttamente nel tuo database all'interno della funzione lambda di elaborazione
Consuma il tuo file CSV utilizzando un processo ETL consolidato
Che tu stia utilizzando un servizio di database AWS, come RDS o DynamoDB, o hai il tuo database PostgreSQL (o simile), puoi connetterti direttamente al tuo servizio di database dalla tua funzione lambda di processo. Ad esempio, nello stesso modo in cui abbiamo chiamato il servizio S3 utilizzando “boto3” nella nostra funzione lambda, potresti anche utilizzare “boto3” per chiamare RDS o DynamoDB. Il servizio AWS Athena potrebbe essere utilizzato anche per leggere i file di dati direttamente dai file flat, e accedere ai dati utilizzando un linguaggio di query simile a SQL. Ti consiglio di fare riferimento alla documentazione pertinente per il servizio che stai utilizzando per maggiori informazioni su come meglio realizzare questo all'interno del tuo ambiente.
Allo stesso modo, ci sono molti servizi disponibili che possono aiutare a consumare file CSV e caricare i dati in un database. Potresti già avere un processo ETL consolidato su cui puoi fare affidamento.
Ci auguriamo che tu abbia trovato utile questa guida - buon invio!
In questo esempio, non tratterò in dettaglio il caricamento dei dati in un database, ma se hai seguito questo esempio hai un paio di opzioni:
Carica i dati direttamente nel tuo database all'interno della funzione lambda di elaborazione
Consuma il tuo file CSV utilizzando un processo ETL consolidato
Che tu stia utilizzando un servizio di database AWS, come RDS o DynamoDB, o hai il tuo database PostgreSQL (o simile), puoi connetterti direttamente al tuo servizio di database dalla tua funzione lambda di processo. Ad esempio, nello stesso modo in cui abbiamo chiamato il servizio S3 utilizzando “boto3” nella nostra funzione lambda, potresti anche utilizzare “boto3” per chiamare RDS o DynamoDB. Il servizio AWS Athena potrebbe essere utilizzato anche per leggere i file di dati direttamente dai file flat, e accedere ai dati utilizzando un linguaggio di query simile a SQL. Ti consiglio di fare riferimento alla documentazione pertinente per il servizio che stai utilizzando per maggiori informazioni su come meglio realizzare questo all'interno del tuo ambiente.
Allo stesso modo, ci sono molti servizi disponibili che possono aiutare a consumare file CSV e caricare i dati in un database. Potresti già avere un processo ETL consolidato su cui puoi fare affidamento.
Ci auguriamo che tu abbia trovato utile questa guida - buon invio!
In questo esempio, non tratterò in dettaglio il caricamento dei dati in un database, ma se hai seguito questo esempio hai un paio di opzioni:
Carica i dati direttamente nel tuo database all'interno della funzione lambda di elaborazione
Consuma il tuo file CSV utilizzando un processo ETL consolidato
Che tu stia utilizzando un servizio di database AWS, come RDS o DynamoDB, o hai il tuo database PostgreSQL (o simile), puoi connetterti direttamente al tuo servizio di database dalla tua funzione lambda di processo. Ad esempio, nello stesso modo in cui abbiamo chiamato il servizio S3 utilizzando “boto3” nella nostra funzione lambda, potresti anche utilizzare “boto3” per chiamare RDS o DynamoDB. Il servizio AWS Athena potrebbe essere utilizzato anche per leggere i file di dati direttamente dai file flat, e accedere ai dati utilizzando un linguaggio di query simile a SQL. Ti consiglio di fare riferimento alla documentazione pertinente per il servizio che stai utilizzando per maggiori informazioni su come meglio realizzare questo all'interno del tuo ambiente.
Allo stesso modo, ci sono molti servizi disponibili che possono aiutare a consumare file CSV e caricare i dati in un database. Potresti già avere un processo ETL consolidato su cui puoi fare affidamento.
Ci auguriamo che tu abbia trovato utile questa guida - buon invio!
