Creando y Consumando Webhooks de Aves
Pájaro
27 ene 2022
Correo electrónico
1 min read
Puntos clave
Las webhooks de eventos en tiempo real de Bird permiten a los remitentes recibir datos de eventos instantáneamente—sin sondeo, sin tareas programadas, y sin problemas de límites de tasa.
Los webhooks eliminan la complejidad de gestionar ventanas de tiempo, prevenir eventos perdidos y manejar registros duplicados.
Ideal para la automatización downstream: actualizar listas, iniciar recorridos, enriquecer dashboards o sincronizar sistemas internos.
El tutorial guía a los remitentes a través de la construcción de un canal completo de ingestión de AWS: almacenamiento en S3, procesamiento con Lambda y balanceador de carga de aplicaciones.
S3 sirve como la capa de almacenamiento central para los payloads de webhook, con cada lote escrito como un archivo JSON plano.
Las funciones Lambda manejan tanto la ingestión (almacenando lotes en bruto) como la transformación (convirtiendo JSON a CSV).
Bird agrupa eventos—cada lote de webhook incluye un único
x-messagesystems-batch-id, permitiendo verificaciones de repetición y deduplicación.La Lambda de consumo debe permanecer eficiente ya que Bird reintenta lotes si el endpoint no responde dentro de ~10 segundos.
Se recomienda AWS ALB (vs. API Gateway) por su simplicidad, rentabilidad y manejo directo de solicitudes HTTP POST.
DNS (Route 53 o proveedor externo) se configura para mapear un nombre de host amigable al endpoint de ALB.
Después de la configuración, Bird envía datos de eventos directa y confiablemente a tu canal de AWS para procesamiento asincrónico.
La guía también cubre mejores prácticas: permisos IAM con el menor privilegio, limitaciones de almacenamiento temporal, evitando disparadores recursivos y organización de flujos de trabajo con múltiples lambdas.
Destacados de Q&A
¿Cuál es el propósito principal de los webhooks de eventos en tiempo real de Bird?
Para enviar datos de eventos directamente al punto final de un remitente en tiempo real, permitiendo la automatización inmediata sin llamadas a API con límite de frecuencia o sondeo.
¿Por qué son los webhooks mejores que obtener datos a través de API para grandes remitentes?
Debido a que las solicitudes de extracción de API requieren gestión de ventanas temporales, corren el riesgo de tener brechas de datos o duplicados, y pueden alcanzar los límites de velocidad—los webhooks eliminan todo eso al enviar datos continuamente.
¿Qué servicios de AWS se utilizan en el pipeline de ingesta de webhooks recomendado?
Amazon S3 (almacenamiento), AWS Lambda (procesamiento), un Application Load Balancer (escucha HTTP), y opcionalmente Route 53 (DNS).
¿Cómo procesa Bird los datos de eventos por lotes?
Bird envía múltiples eventos juntos en una carga, cada uno asignado con un ID de lote único (x-messagesystems-batch-id) para el seguimiento, reintentos y eliminación de duplicados.
¿Qué desencadena la función Lambda del consumidor?
El ALB reenvía solicitudes POST de webhook entrantes directamente a la Lambda, que extrae la carga útil y la escribe en S3.
¿Por qué almacenar el lote de webhook sin procesar en S3 antes de procesarlo?
Para garantizar una ingesta rápida (<10 segundos) para que la conexión no se agote, y para trasladar el procesamiento más pesado a una canalización asincrónica separada.
¿Qué hace la segunda función Lambda?
Se activa por nuevos objetos S3, valida el JSON, lo convierte a CSV, y escribe el resultado procesado en un bucket S3 separado.
¿Por qué usar un bucket diferente de S3 para archivos CSV procesados?
Para evitar activadores recursivos (escribir un nuevo archivo procesado nuevamente en el mismo bucket volvería a activar el Lambda indefinidamente).
¿Qué permisos requieren las funciones Lambda?
El consumidor Lambda necesita permisos S3 PutObject; el procesamiento Lambda necesita GetObject para el bucket de origen y PutObject para el bucket de destino.
¿Por qué se recomienda un AWS ALB sobre API Gateway?
ALBs son más baratos, más simples y ideales para el reenvío directo de HTTPS POST; API Gateway puede alterar el formato de la carga útil y aumentar la complejidad.
¿Cómo configuran los remitentes el webhook en Bird?
Al proporcionar el punto final HTTPS (el registro DNS para el ALB), seleccionar una subcuenta, elegir eventos y guardar la configuración del webhook.
¿Qué opciones descendentes existen para almacenar o analizar los datos procesados?
Cargar en bases de datos (PostgreSQL, DynamoDB, RDS), alimentar en sistemas ETL o consultar directamente con herramientas como Athena.
Los webhooks de eventos en tiempo real de Bird son una herramienta increíblemente valiosa para que los remitentes tengan datos automáticamente enviados a sus sistemas. Esto puede impulsar la automatización posterior, como actualizar listas de correo, activar recorridos de correo electrónico automatizados o poblar paneles internos. Aunque los mismos datos de eventos pueden accederse a través de la UI de Bird usando Event Search, o programáticamente utilizando la Events API de Bird, las limitaciones impuestas en el número de registros devueltos en una sola solicitud o los límites de tasa impuestos en el punto final de la API pueden hacer que ambos métodos sean restrictivos para remitentes grandes y sofisticados.
Los webhooks de eventos en tiempo real permiten a un remitente configurar un punto final al que Bird transmite los datos, y los datos pueden ser consumidos sin tener que programar trabajos cron que extraigan los datos. También hay compromisos logísticos al extraer los datos en lugar de recibirlos, como tener que identificar qué período de tiempo y parámetros usar para cada solicitud de API. Si los períodos de tiempo no están perfectamente alineados, corres el riesgo de perder datos, y si los períodos de tiempo se superponen, entonces necesitas manejar registros de datos duplicados. Con los webhooks en tiempo real, los datos de eventos simplemente se envían a tu punto final a medida que están disponibles dentro de Bird.
Aunque los beneficios de recibir datos de eventos en tiempo real para impulsar procesos de automatización posterior pueden ser comprendidos inmediatamente por muchos remitentes, el proceso real para implementar y consumir webhooks puede ser intimidante. Esto puede ser especialmente cierto si no estás familiarizado con los componentes técnicos de crear un punto final y manejar los datos programáticamente. Hay servicios disponibles que consumen los datos del webhook de Bird y ejecutan ETL en tu base de datos automáticamente, un ejemplo sería StitchData, sobre lo cual hemos escrito en el pasado. Sin embargo, si prefieres tener más control sobre el proceso, puedes fácilmente construir los componentes tú mismo. Lo siguiente es una guía sencilla para ayudar a los remitentes a sentirse cómodos al crear un webhook de eventos de Bird y consumir los datos utilizando la infraestructura dentro de AWS.
Los webhooks de eventos en tiempo real de Bird son una herramienta increíblemente valiosa para que los remitentes tengan datos automáticamente enviados a sus sistemas. Esto puede impulsar la automatización posterior, como actualizar listas de correo, activar recorridos de correo electrónico automatizados o poblar paneles internos. Aunque los mismos datos de eventos pueden accederse a través de la UI de Bird usando Event Search, o programáticamente utilizando la Events API de Bird, las limitaciones impuestas en el número de registros devueltos en una sola solicitud o los límites de tasa impuestos en el punto final de la API pueden hacer que ambos métodos sean restrictivos para remitentes grandes y sofisticados.
Los webhooks de eventos en tiempo real permiten a un remitente configurar un punto final al que Bird transmite los datos, y los datos pueden ser consumidos sin tener que programar trabajos cron que extraigan los datos. También hay compromisos logísticos al extraer los datos en lugar de recibirlos, como tener que identificar qué período de tiempo y parámetros usar para cada solicitud de API. Si los períodos de tiempo no están perfectamente alineados, corres el riesgo de perder datos, y si los períodos de tiempo se superponen, entonces necesitas manejar registros de datos duplicados. Con los webhooks en tiempo real, los datos de eventos simplemente se envían a tu punto final a medida que están disponibles dentro de Bird.
Aunque los beneficios de recibir datos de eventos en tiempo real para impulsar procesos de automatización posterior pueden ser comprendidos inmediatamente por muchos remitentes, el proceso real para implementar y consumir webhooks puede ser intimidante. Esto puede ser especialmente cierto si no estás familiarizado con los componentes técnicos de crear un punto final y manejar los datos programáticamente. Hay servicios disponibles que consumen los datos del webhook de Bird y ejecutan ETL en tu base de datos automáticamente, un ejemplo sería StitchData, sobre lo cual hemos escrito en el pasado. Sin embargo, si prefieres tener más control sobre el proceso, puedes fácilmente construir los componentes tú mismo. Lo siguiente es una guía sencilla para ayudar a los remitentes a sentirse cómodos al crear un webhook de eventos de Bird y consumir los datos utilizando la infraestructura dentro de AWS.
Los webhooks de eventos en tiempo real de Bird son una herramienta increíblemente valiosa para que los remitentes tengan datos automáticamente enviados a sus sistemas. Esto puede impulsar la automatización posterior, como actualizar listas de correo, activar recorridos de correo electrónico automatizados o poblar paneles internos. Aunque los mismos datos de eventos pueden accederse a través de la UI de Bird usando Event Search, o programáticamente utilizando la Events API de Bird, las limitaciones impuestas en el número de registros devueltos en una sola solicitud o los límites de tasa impuestos en el punto final de la API pueden hacer que ambos métodos sean restrictivos para remitentes grandes y sofisticados.
Los webhooks de eventos en tiempo real permiten a un remitente configurar un punto final al que Bird transmite los datos, y los datos pueden ser consumidos sin tener que programar trabajos cron que extraigan los datos. También hay compromisos logísticos al extraer los datos en lugar de recibirlos, como tener que identificar qué período de tiempo y parámetros usar para cada solicitud de API. Si los períodos de tiempo no están perfectamente alineados, corres el riesgo de perder datos, y si los períodos de tiempo se superponen, entonces necesitas manejar registros de datos duplicados. Con los webhooks en tiempo real, los datos de eventos simplemente se envían a tu punto final a medida que están disponibles dentro de Bird.
Aunque los beneficios de recibir datos de eventos en tiempo real para impulsar procesos de automatización posterior pueden ser comprendidos inmediatamente por muchos remitentes, el proceso real para implementar y consumir webhooks puede ser intimidante. Esto puede ser especialmente cierto si no estás familiarizado con los componentes técnicos de crear un punto final y manejar los datos programáticamente. Hay servicios disponibles que consumen los datos del webhook de Bird y ejecutan ETL en tu base de datos automáticamente, un ejemplo sería StitchData, sobre lo cual hemos escrito en el pasado. Sin embargo, si prefieres tener más control sobre el proceso, puedes fácilmente construir los componentes tú mismo. Lo siguiente es una guía sencilla para ayudar a los remitentes a sentirse cómodos al crear un webhook de eventos de Bird y consumir los datos utilizando la infraestructura dentro de AWS.
Configurando Webhook Target Endpoint
Cuando se crea un evento de Bird, queremos que esos datos de eventos se transmitan en tiempo real a un endpoint en AWS para que podamos consumir y usar esos datos programáticamente. Los datos se enviarán de Bird a un endpoint objetivo, que reenviará la carga útil a una función lambda que procesará y almacenará los datos en un bucket S3. Un diagrama a alto nivel del flujo de datos descrito se puede ver a continuación:
Componente | Responsabilidad |
|---|---|
Webhooks de Bird | Emitir lotes de eventos en tiempo real como solicitudes HTTP POST |
Application Load Balancer | Recibir tráfico de webhooks externos y enrutar solicitudes |
Lambda (Consumidor) | Persistir lotes de webhooks en bruto en S3 de manera eficiente |
Amazon S3 | Almacenar cargas útiles de eventos en lotes como archivos JSON planos |
Lambda (Procesador) | Transformar o cargar datos almacenados de manera asíncrona |
Para implementar este flujo de trabajo, vamos a construirlos en el orden inverso comenzando con la creación de un bucket S3 donde almacenaremos nuestros datos de eventos y luego trabajaremos hacia atrás, agregando cada componente que alimenta lo que hemos construido.
Cuando se crea un evento de Bird, queremos que esos datos de eventos se transmitan en tiempo real a un endpoint en AWS para que podamos consumir y usar esos datos programáticamente. Los datos se enviarán de Bird a un endpoint objetivo, que reenviará la carga útil a una función lambda que procesará y almacenará los datos en un bucket S3. Un diagrama a alto nivel del flujo de datos descrito se puede ver a continuación:
Componente | Responsabilidad |
|---|---|
Webhooks de Bird | Emitir lotes de eventos en tiempo real como solicitudes HTTP POST |
Application Load Balancer | Recibir tráfico de webhooks externos y enrutar solicitudes |
Lambda (Consumidor) | Persistir lotes de webhooks en bruto en S3 de manera eficiente |
Amazon S3 | Almacenar cargas útiles de eventos en lotes como archivos JSON planos |
Lambda (Procesador) | Transformar o cargar datos almacenados de manera asíncrona |
Para implementar este flujo de trabajo, vamos a construirlos en el orden inverso comenzando con la creación de un bucket S3 donde almacenaremos nuestros datos de eventos y luego trabajaremos hacia atrás, agregando cada componente que alimenta lo que hemos construido.
Cuando se crea un evento de Bird, queremos que esos datos de eventos se transmitan en tiempo real a un endpoint en AWS para que podamos consumir y usar esos datos programáticamente. Los datos se enviarán de Bird a un endpoint objetivo, que reenviará la carga útil a una función lambda que procesará y almacenará los datos en un bucket S3. Un diagrama a alto nivel del flujo de datos descrito se puede ver a continuación:
Componente | Responsabilidad |
|---|---|
Webhooks de Bird | Emitir lotes de eventos en tiempo real como solicitudes HTTP POST |
Application Load Balancer | Recibir tráfico de webhooks externos y enrutar solicitudes |
Lambda (Consumidor) | Persistir lotes de webhooks en bruto en S3 de manera eficiente |
Amazon S3 | Almacenar cargas útiles de eventos en lotes como archivos JSON planos |
Lambda (Procesador) | Transformar o cargar datos almacenados de manera asíncrona |
Para implementar este flujo de trabajo, vamos a construirlos en el orden inverso comenzando con la creación de un bucket S3 donde almacenaremos nuestros datos de eventos y luego trabajaremos hacia atrás, agregando cada componente que alimenta lo que hemos construido.
Crea un Bucket S3 para almacenar los datos del Webhook
Antes de crear nuestro balanceador de carga para aceptar los datos, o nuestra función lambda para almacenar los datos, primero necesitamos crear nuestro S3 bucket donde se almacenarán los datos. Aunque S3 proporciona un excelente almacenamiento para datos de webhook, las organizaciones que también utilizan bases de datos PostgreSQL para el procesamiento de eventos deben implementar procedimientos adecuados de copia de seguridad y restauración para proteger sus datos estructurados junto con su estrategia de almacenamiento en S3. Para hacer esto, navegue al servicio S3 dentro de AWS y presione “Create Bucket”. Se le pedirá que asigne un nombre a su bucket y configure la región - asegúrese de usar la misma región que su ALB y función lambda. Cuando se crea su S3 bucket estará vacío - si desea organizar los datos dentro de una carpeta, puede crear el directorio deseado ahora, o el directorio se creará cuando su función lambda almacene el archivo. En este ejemplo, nombramos nuestro S3 bucket “bird-webhooks” y creamos una carpeta llamada “B Event Data” para almacenar nuestros datos de eventos – verá estos nombres referenciados en nuestra función lambda a continuación.
Antes de crear nuestro balanceador de carga para aceptar los datos, o nuestra función lambda para almacenar los datos, primero necesitamos crear nuestro S3 bucket donde se almacenarán los datos. Aunque S3 proporciona un excelente almacenamiento para datos de webhook, las organizaciones que también utilizan bases de datos PostgreSQL para el procesamiento de eventos deben implementar procedimientos adecuados de copia de seguridad y restauración para proteger sus datos estructurados junto con su estrategia de almacenamiento en S3. Para hacer esto, navegue al servicio S3 dentro de AWS y presione “Create Bucket”. Se le pedirá que asigne un nombre a su bucket y configure la región - asegúrese de usar la misma región que su ALB y función lambda. Cuando se crea su S3 bucket estará vacío - si desea organizar los datos dentro de una carpeta, puede crear el directorio deseado ahora, o el directorio se creará cuando su función lambda almacene el archivo. En este ejemplo, nombramos nuestro S3 bucket “bird-webhooks” y creamos una carpeta llamada “B Event Data” para almacenar nuestros datos de eventos – verá estos nombres referenciados en nuestra función lambda a continuación.
Antes de crear nuestro balanceador de carga para aceptar los datos, o nuestra función lambda para almacenar los datos, primero necesitamos crear nuestro S3 bucket donde se almacenarán los datos. Aunque S3 proporciona un excelente almacenamiento para datos de webhook, las organizaciones que también utilizan bases de datos PostgreSQL para el procesamiento de eventos deben implementar procedimientos adecuados de copia de seguridad y restauración para proteger sus datos estructurados junto con su estrategia de almacenamiento en S3. Para hacer esto, navegue al servicio S3 dentro de AWS y presione “Create Bucket”. Se le pedirá que asigne un nombre a su bucket y configure la región - asegúrese de usar la misma región que su ALB y función lambda. Cuando se crea su S3 bucket estará vacío - si desea organizar los datos dentro de una carpeta, puede crear el directorio deseado ahora, o el directorio se creará cuando su función lambda almacene el archivo. En este ejemplo, nombramos nuestro S3 bucket “bird-webhooks” y creamos una carpeta llamada “B Event Data” para almacenar nuestros datos de eventos – verá estos nombres referenciados en nuestra función lambda a continuación.
Crear una función Lambda para consumir los datos
El procesamiento y almacenamiento actual de los datos serán realizados por una función lambda que es invocada por nuestro balanceador de carga de aplicación (ALB).
El primer paso es crear tu función lambda navegando al servicio Lambda dentro de AWS y haciendo clic en "Create Function". Se te pedirá que asignes un nombre a tu función lambda y selecciones en qué lenguaje de programación escribirás tu función. Para este ejemplo, usamos Python como el lenguaje de ejecución.
Ahora necesitamos desarrollar nuestra función lambda. Por un momento, asumamos que nuestro balanceador de carga de aplicación ha sido configurado y está reenviando la carga útil del webhook a nuestra función lambda – el lambda recibirá una carga útil que incluye los encabezados completos y el cuerpo. La carga útil se pasa a nuestra función lambda usando el objeto "event" como un diccionario. Puedes referenciar los encabezados y el cuerpo de la carga útil de manera independiente accediendo a los objetos "headers" y "body" dentro de la carga útil. En este ejemplo, simplemente vamos a leer el encabezado "x-messagesystems-batch-id", donde el identificador de lote es un valor único creado por Bird para el lote de webhook, y lo usaremos como nombre de archivo al almacenar el cuerpo como un archivo plano en S3; sin embargo, es posible que desees agregar funcionalidad adicional como verificaciones de autenticación o manejo de errores, según sea necesario.
Al almacenar la carga útil en un archivo plano en S3, necesitaremos definir el nombre del bucket de S3, la ubicación y el nombre del archivo donde se almacenarán los datos de la carga útil. En nuestra función lambda de ejemplo, hacemos esto dentro de la función "store_batch". En este ejemplo, vamos a almacenar todo el lote como un único archivo, lo que ayuda a garantizar que los datos se recopilen y almacenen antes de que la conexión HTTP entre Bird y tu endpoint se agote. Aunque podrías ajustar la configuración de tiempo de espera de la conexión en tu balanceador de carga, no hay garantía de que la conexión no se agote en el lado de la transmisión (en este caso Bird) o que la conexión no se termine antes de que tu función lambda termine de ejecutarse. Es una buena práctica mantener tu función consumidora lo más eficiente posible y reservar las actividades de procesamiento de datos para procesos posteriores cuando sea posible, como convertir la carga útil en formato JSON agrupado en un archivo CSV, o cargar los datos del evento en una base de datos.
Es importante tener en cuenta que es posible que necesites actualizar los permisos para tu función lambda. Tu rol de ejecución necesitará permisos PutObject y GetObject para S3. Es una buena práctica aplicar el principio de privilegio mínimo, por lo que recomiendo establecer estos permisos solo para el bucket de S3 donde se almacenarán las cargas útiles del webhook.
Un ejemplo de nuestra función lambda consumidora se puede encontrar aquí.
Una nota rápida sobre el identificador de lote: Bird agrupará eventos en una única carga útil, donde cada lote puede contener de 1 a 350 o más registros de eventos. Al lote se le dará un identificador de lote único, que se puede usar para ver el estado del lote aprovechando la Event Webhooks API o dentro de tu cuenta Bird haciendo clic en un webhook stream y seleccionando "Batch Status". En caso de que una carga útil de webhook no pueda ser entregada, como durante un tiempo de espera de conexión, Bird reintentará automáticamente el lote usando el mismo identificador de lote. Esto puede suceder cuando tu función lambda está ejecutándose cerca del tiempo máximo de ida y vuelta de 10 segundos y es una razón para optimizar la función consumidora para reducir el tiempo de ejecución.
Para manejar todas las actividades de procesamiento de datos, recomiendo crear una función lambda separada que se ejecute cada vez que se crea un nuevo archivo en el bucket de S3 – de esta manera, el procesamiento de datos se realiza de manera asincrónica con la transmisión de los datos, y no hay riesgo de perder datos debido a una conexión terminada. Discuto la función de procesamiento lambda en una sección posterior.
El procesamiento y almacenamiento actual de los datos serán realizados por una función lambda que es invocada por nuestro balanceador de carga de aplicación (ALB).
El primer paso es crear tu función lambda navegando al servicio Lambda dentro de AWS y haciendo clic en "Create Function". Se te pedirá que asignes un nombre a tu función lambda y selecciones en qué lenguaje de programación escribirás tu función. Para este ejemplo, usamos Python como el lenguaje de ejecución.
Ahora necesitamos desarrollar nuestra función lambda. Por un momento, asumamos que nuestro balanceador de carga de aplicación ha sido configurado y está reenviando la carga útil del webhook a nuestra función lambda – el lambda recibirá una carga útil que incluye los encabezados completos y el cuerpo. La carga útil se pasa a nuestra función lambda usando el objeto "event" como un diccionario. Puedes referenciar los encabezados y el cuerpo de la carga útil de manera independiente accediendo a los objetos "headers" y "body" dentro de la carga útil. En este ejemplo, simplemente vamos a leer el encabezado "x-messagesystems-batch-id", donde el identificador de lote es un valor único creado por Bird para el lote de webhook, y lo usaremos como nombre de archivo al almacenar el cuerpo como un archivo plano en S3; sin embargo, es posible que desees agregar funcionalidad adicional como verificaciones de autenticación o manejo de errores, según sea necesario.
Al almacenar la carga útil en un archivo plano en S3, necesitaremos definir el nombre del bucket de S3, la ubicación y el nombre del archivo donde se almacenarán los datos de la carga útil. En nuestra función lambda de ejemplo, hacemos esto dentro de la función "store_batch". En este ejemplo, vamos a almacenar todo el lote como un único archivo, lo que ayuda a garantizar que los datos se recopilen y almacenen antes de que la conexión HTTP entre Bird y tu endpoint se agote. Aunque podrías ajustar la configuración de tiempo de espera de la conexión en tu balanceador de carga, no hay garantía de que la conexión no se agote en el lado de la transmisión (en este caso Bird) o que la conexión no se termine antes de que tu función lambda termine de ejecutarse. Es una buena práctica mantener tu función consumidora lo más eficiente posible y reservar las actividades de procesamiento de datos para procesos posteriores cuando sea posible, como convertir la carga útil en formato JSON agrupado en un archivo CSV, o cargar los datos del evento en una base de datos.
Es importante tener en cuenta que es posible que necesites actualizar los permisos para tu función lambda. Tu rol de ejecución necesitará permisos PutObject y GetObject para S3. Es una buena práctica aplicar el principio de privilegio mínimo, por lo que recomiendo establecer estos permisos solo para el bucket de S3 donde se almacenarán las cargas útiles del webhook.
Un ejemplo de nuestra función lambda consumidora se puede encontrar aquí.
Una nota rápida sobre el identificador de lote: Bird agrupará eventos en una única carga útil, donde cada lote puede contener de 1 a 350 o más registros de eventos. Al lote se le dará un identificador de lote único, que se puede usar para ver el estado del lote aprovechando la Event Webhooks API o dentro de tu cuenta Bird haciendo clic en un webhook stream y seleccionando "Batch Status". En caso de que una carga útil de webhook no pueda ser entregada, como durante un tiempo de espera de conexión, Bird reintentará automáticamente el lote usando el mismo identificador de lote. Esto puede suceder cuando tu función lambda está ejecutándose cerca del tiempo máximo de ida y vuelta de 10 segundos y es una razón para optimizar la función consumidora para reducir el tiempo de ejecución.
Para manejar todas las actividades de procesamiento de datos, recomiendo crear una función lambda separada que se ejecute cada vez que se crea un nuevo archivo en el bucket de S3 – de esta manera, el procesamiento de datos se realiza de manera asincrónica con la transmisión de los datos, y no hay riesgo de perder datos debido a una conexión terminada. Discuto la función de procesamiento lambda en una sección posterior.
El procesamiento y almacenamiento actual de los datos serán realizados por una función lambda que es invocada por nuestro balanceador de carga de aplicación (ALB).
El primer paso es crear tu función lambda navegando al servicio Lambda dentro de AWS y haciendo clic en "Create Function". Se te pedirá que asignes un nombre a tu función lambda y selecciones en qué lenguaje de programación escribirás tu función. Para este ejemplo, usamos Python como el lenguaje de ejecución.
Ahora necesitamos desarrollar nuestra función lambda. Por un momento, asumamos que nuestro balanceador de carga de aplicación ha sido configurado y está reenviando la carga útil del webhook a nuestra función lambda – el lambda recibirá una carga útil que incluye los encabezados completos y el cuerpo. La carga útil se pasa a nuestra función lambda usando el objeto "event" como un diccionario. Puedes referenciar los encabezados y el cuerpo de la carga útil de manera independiente accediendo a los objetos "headers" y "body" dentro de la carga útil. En este ejemplo, simplemente vamos a leer el encabezado "x-messagesystems-batch-id", donde el identificador de lote es un valor único creado por Bird para el lote de webhook, y lo usaremos como nombre de archivo al almacenar el cuerpo como un archivo plano en S3; sin embargo, es posible que desees agregar funcionalidad adicional como verificaciones de autenticación o manejo de errores, según sea necesario.
Al almacenar la carga útil en un archivo plano en S3, necesitaremos definir el nombre del bucket de S3, la ubicación y el nombre del archivo donde se almacenarán los datos de la carga útil. En nuestra función lambda de ejemplo, hacemos esto dentro de la función "store_batch". En este ejemplo, vamos a almacenar todo el lote como un único archivo, lo que ayuda a garantizar que los datos se recopilen y almacenen antes de que la conexión HTTP entre Bird y tu endpoint se agote. Aunque podrías ajustar la configuración de tiempo de espera de la conexión en tu balanceador de carga, no hay garantía de que la conexión no se agote en el lado de la transmisión (en este caso Bird) o que la conexión no se termine antes de que tu función lambda termine de ejecutarse. Es una buena práctica mantener tu función consumidora lo más eficiente posible y reservar las actividades de procesamiento de datos para procesos posteriores cuando sea posible, como convertir la carga útil en formato JSON agrupado en un archivo CSV, o cargar los datos del evento en una base de datos.
Es importante tener en cuenta que es posible que necesites actualizar los permisos para tu función lambda. Tu rol de ejecución necesitará permisos PutObject y GetObject para S3. Es una buena práctica aplicar el principio de privilegio mínimo, por lo que recomiendo establecer estos permisos solo para el bucket de S3 donde se almacenarán las cargas útiles del webhook.
Un ejemplo de nuestra función lambda consumidora se puede encontrar aquí.
Una nota rápida sobre el identificador de lote: Bird agrupará eventos en una única carga útil, donde cada lote puede contener de 1 a 350 o más registros de eventos. Al lote se le dará un identificador de lote único, que se puede usar para ver el estado del lote aprovechando la Event Webhooks API o dentro de tu cuenta Bird haciendo clic en un webhook stream y seleccionando "Batch Status". En caso de que una carga útil de webhook no pueda ser entregada, como durante un tiempo de espera de conexión, Bird reintentará automáticamente el lote usando el mismo identificador de lote. Esto puede suceder cuando tu función lambda está ejecutándose cerca del tiempo máximo de ida y vuelta de 10 segundos y es una razón para optimizar la función consumidora para reducir el tiempo de ejecución.
Para manejar todas las actividades de procesamiento de datos, recomiendo crear una función lambda separada que se ejecute cada vez que se crea un nuevo archivo en el bucket de S3 – de esta manera, el procesamiento de datos se realiza de manera asincrónica con la transmisión de los datos, y no hay riesgo de perder datos debido a una conexión terminada. Discuto la función de procesamiento lambda en una sección posterior.
Crear un Application Load Balancer
Para recibir una carga útil de webhook, necesitamos proporcionar un endpoint al que enviar las cargas útiles. Hacemos esto creando un balanceador de carga de aplicación dentro de AWS navegando a EC2 > Load Balancers y haciendo clic en "Create Load Balancer." Se te pedirá que elijas qué tipo de balanceador de carga deseas crear: para esto, queremos crear un balanceador de carga de aplicación. Necesitamos usar un balanceador de carga de aplicación (ALB) para construir nuestro consumidor porque los webhooks de evento se enviarán como una solicitud HTTP y los ALBs se utilizan para enrutar solicitudes HTTP dentro de AWS. Podríamos implementar un HTTP Gateway como alternativa; sin embargo, usamos un ALB para este proyecto porque es más liviano y rentable que HTTP Gateway. Es importante notar que si decides usar un HTTP Gateway, el formato del evento puede ser diferente que con un ALB, y por lo tanto tu función lambda necesitará manejar el objeto de solicitud en consecuencia.
Una vez que tu ALB ha sido creado, se te pedirá asignar un nombre a tu ALB y configurar el esquema y las configuraciones de acceso/seguridad —como planeamos recibir datos de eventos de una fuente externa (Bird), queremos que nuestro ALB sea de cara al internet. Bajo "Listeners and routing," el ALB debe escuchar a HTTPS en el puerto 443, y queremos crear un grupo de destino que apunte a nuestra función lambda para que nuestro ALB reenvíe las solicitudes entrantes a la función lambda consumidor que creamos arriba. También necesitas asegurarte de que el grupo de seguridad tenga permiso para aceptar tráfico a través del puerto 443.
Para recibir una carga útil de webhook, necesitamos proporcionar un endpoint al que enviar las cargas útiles. Hacemos esto creando un balanceador de carga de aplicación dentro de AWS navegando a EC2 > Load Balancers y haciendo clic en "Create Load Balancer." Se te pedirá que elijas qué tipo de balanceador de carga deseas crear: para esto, queremos crear un balanceador de carga de aplicación. Necesitamos usar un balanceador de carga de aplicación (ALB) para construir nuestro consumidor porque los webhooks de evento se enviarán como una solicitud HTTP y los ALBs se utilizan para enrutar solicitudes HTTP dentro de AWS. Podríamos implementar un HTTP Gateway como alternativa; sin embargo, usamos un ALB para este proyecto porque es más liviano y rentable que HTTP Gateway. Es importante notar que si decides usar un HTTP Gateway, el formato del evento puede ser diferente que con un ALB, y por lo tanto tu función lambda necesitará manejar el objeto de solicitud en consecuencia.
Una vez que tu ALB ha sido creado, se te pedirá asignar un nombre a tu ALB y configurar el esquema y las configuraciones de acceso/seguridad —como planeamos recibir datos de eventos de una fuente externa (Bird), queremos que nuestro ALB sea de cara al internet. Bajo "Listeners and routing," el ALB debe escuchar a HTTPS en el puerto 443, y queremos crear un grupo de destino que apunte a nuestra función lambda para que nuestro ALB reenvíe las solicitudes entrantes a la función lambda consumidor que creamos arriba. También necesitas asegurarte de que el grupo de seguridad tenga permiso para aceptar tráfico a través del puerto 443.
Para recibir una carga útil de webhook, necesitamos proporcionar un endpoint al que enviar las cargas útiles. Hacemos esto creando un balanceador de carga de aplicación dentro de AWS navegando a EC2 > Load Balancers y haciendo clic en "Create Load Balancer." Se te pedirá que elijas qué tipo de balanceador de carga deseas crear: para esto, queremos crear un balanceador de carga de aplicación. Necesitamos usar un balanceador de carga de aplicación (ALB) para construir nuestro consumidor porque los webhooks de evento se enviarán como una solicitud HTTP y los ALBs se utilizan para enrutar solicitudes HTTP dentro de AWS. Podríamos implementar un HTTP Gateway como alternativa; sin embargo, usamos un ALB para este proyecto porque es más liviano y rentable que HTTP Gateway. Es importante notar que si decides usar un HTTP Gateway, el formato del evento puede ser diferente que con un ALB, y por lo tanto tu función lambda necesitará manejar el objeto de solicitud en consecuencia.
Una vez que tu ALB ha sido creado, se te pedirá asignar un nombre a tu ALB y configurar el esquema y las configuraciones de acceso/seguridad —como planeamos recibir datos de eventos de una fuente externa (Bird), queremos que nuestro ALB sea de cara al internet. Bajo "Listeners and routing," el ALB debe escuchar a HTTPS en el puerto 443, y queremos crear un grupo de destino que apunte a nuestra función lambda para que nuestro ALB reenvíe las solicitudes entrantes a la función lambda consumidor que creamos arriba. También necesitas asegurarte de que el grupo de seguridad tenga permiso para aceptar tráfico a través del puerto 443.
Crear un registro DNS para el Load Balancer
Para facilitar el uso de nuestro ALB como un endpoint, crearemos un registro A en DNS que apunte a nuestro ALB. Para esto, podemos utilizar el servicio AWS Route 53 (o su proveedor de DNS actual) y crear un registro A para el nombre de host que desea usar para su endpoint (por ejemplo, spevents.<your_domain>). Cuando trabaje con DNS a gran escala en AWS, tenga en cuenta que hay límites de DNS no documentados que pueden afectar a aplicaciones de alto volumen, especialmente aquellas que manejan grandes cantidades de tráfico saliente como los sistemas de entrega de correo electrónico. El registro A debe configurarse para apuntar al ALB que creamos. Si está utilizando Route 53 para administrar los registros DNS, puede hacer referencia a la instancia de ALB directamente habilitando "Alias" y seleccionando el ALB; de lo contrario, si utiliza un proveedor de DNS externo, debe apuntar el registro A a la dirección IP pública de la instancia de ALB.
Recomiendo utilizar una herramienta como Postman para verificar que todo se ha configurado correctamente antes de habilitar su webhook de Bird. Puede realizar una solicitud POST a su endpoint y confirmar que se recibe una respuesta. Si su solicitud POST no devuelve una respuesta, es posible que deba verificar nuevamente que su ALB esté escuchando en el puerto correcto.
Para facilitar el uso de nuestro ALB como un endpoint, crearemos un registro A en DNS que apunte a nuestro ALB. Para esto, podemos utilizar el servicio AWS Route 53 (o su proveedor de DNS actual) y crear un registro A para el nombre de host que desea usar para su endpoint (por ejemplo, spevents.<your_domain>). Cuando trabaje con DNS a gran escala en AWS, tenga en cuenta que hay límites de DNS no documentados que pueden afectar a aplicaciones de alto volumen, especialmente aquellas que manejan grandes cantidades de tráfico saliente como los sistemas de entrega de correo electrónico. El registro A debe configurarse para apuntar al ALB que creamos. Si está utilizando Route 53 para administrar los registros DNS, puede hacer referencia a la instancia de ALB directamente habilitando "Alias" y seleccionando el ALB; de lo contrario, si utiliza un proveedor de DNS externo, debe apuntar el registro A a la dirección IP pública de la instancia de ALB.
Recomiendo utilizar una herramienta como Postman para verificar que todo se ha configurado correctamente antes de habilitar su webhook de Bird. Puede realizar una solicitud POST a su endpoint y confirmar que se recibe una respuesta. Si su solicitud POST no devuelve una respuesta, es posible que deba verificar nuevamente que su ALB esté escuchando en el puerto correcto.
Para facilitar el uso de nuestro ALB como un endpoint, crearemos un registro A en DNS que apunte a nuestro ALB. Para esto, podemos utilizar el servicio AWS Route 53 (o su proveedor de DNS actual) y crear un registro A para el nombre de host que desea usar para su endpoint (por ejemplo, spevents.<your_domain>). Cuando trabaje con DNS a gran escala en AWS, tenga en cuenta que hay límites de DNS no documentados que pueden afectar a aplicaciones de alto volumen, especialmente aquellas que manejan grandes cantidades de tráfico saliente como los sistemas de entrega de correo electrónico. El registro A debe configurarse para apuntar al ALB que creamos. Si está utilizando Route 53 para administrar los registros DNS, puede hacer referencia a la instancia de ALB directamente habilitando "Alias" y seleccionando el ALB; de lo contrario, si utiliza un proveedor de DNS externo, debe apuntar el registro A a la dirección IP pública de la instancia de ALB.
Recomiendo utilizar una herramienta como Postman para verificar que todo se ha configurado correctamente antes de habilitar su webhook de Bird. Puede realizar una solicitud POST a su endpoint y confirmar que se recibe una respuesta. Si su solicitud POST no devuelve una respuesta, es posible que deba verificar nuevamente que su ALB esté escuchando en el puerto correcto.
Crear un Bird Webhook
Ahora estamos listos para crear el webhook en Bird y usar el nombre de host definido por el registro A mencionado antes como nuestro punto final objetivo. Para crear el webhook, navega a la sección de Webhooks dentro de tu cuenta de Bird y haz clic en “Create Webhook”. Se te pedirá que asignes un nombre a tu webhook y que proporciones una URL objetivo: el objetivo debe ser el nombre de host del registro A que creaste previamente. Ten en cuenta que la URL objetivo puede requerir que "HTTPS://" sea incluido en la URL.
Una vez completado, verifica que la subcuenta correcta y los eventos estén seleccionados, y presiona “Create Webhook” para guardar tu configuración. Los datos de eventos para todos los tipos de eventos seleccionados ahora se transmitirán a nuestra URL objetivo y serán procesados por nuestro ALB para el procesamiento posterior.
Ahora estamos listos para crear el webhook en Bird y usar el nombre de host definido por el registro A mencionado antes como nuestro punto final objetivo. Para crear el webhook, navega a la sección de Webhooks dentro de tu cuenta de Bird y haz clic en “Create Webhook”. Se te pedirá que asignes un nombre a tu webhook y que proporciones una URL objetivo: el objetivo debe ser el nombre de host del registro A que creaste previamente. Ten en cuenta que la URL objetivo puede requerir que "HTTPS://" sea incluido en la URL.
Una vez completado, verifica que la subcuenta correcta y los eventos estén seleccionados, y presiona “Create Webhook” para guardar tu configuración. Los datos de eventos para todos los tipos de eventos seleccionados ahora se transmitirán a nuestra URL objetivo y serán procesados por nuestro ALB para el procesamiento posterior.
Ahora estamos listos para crear el webhook en Bird y usar el nombre de host definido por el registro A mencionado antes como nuestro punto final objetivo. Para crear el webhook, navega a la sección de Webhooks dentro de tu cuenta de Bird y haz clic en “Create Webhook”. Se te pedirá que asignes un nombre a tu webhook y que proporciones una URL objetivo: el objetivo debe ser el nombre de host del registro A que creaste previamente. Ten en cuenta que la URL objetivo puede requerir que "HTTPS://" sea incluido en la URL.
Una vez completado, verifica que la subcuenta correcta y los eventos estén seleccionados, y presiona “Create Webhook” para guardar tu configuración. Los datos de eventos para todos los tipos de eventos seleccionados ahora se transmitirán a nuestra URL objetivo y serán procesados por nuestro ALB para el procesamiento posterior.
Procesando Webhook Event Data
Dependiendo del propósito previsto para almacenar los datos del evento Bird, es posible que sus requisitos se satisfagan simplemente almacenando la carga útil JSON como un archivo plano. También puede tener ya establecido un proceso ETL downstream que sea capaz de consumir y cargar datos en formato JSON. En ambos casos, puede utilizar el archivo plano creado por nuestra lambda de procesamiento que creamos anteriormente tal cual.
Alternativamente, puede necesitar transformar los datos, como convertirlos de un formato JSON a un formato CSV, o cargar los datos directamente en una base de datos. En este ejemplo, crearemos una función lambda simple que convertirá los datos del webhook del formato JSON original a un archivo CSV que podría cargarse en una base de datos.
Dependiendo del propósito previsto para almacenar los datos del evento Bird, es posible que sus requisitos se satisfagan simplemente almacenando la carga útil JSON como un archivo plano. También puede tener ya establecido un proceso ETL downstream que sea capaz de consumir y cargar datos en formato JSON. En ambos casos, puede utilizar el archivo plano creado por nuestra lambda de procesamiento que creamos anteriormente tal cual.
Alternativamente, puede necesitar transformar los datos, como convertirlos de un formato JSON a un formato CSV, o cargar los datos directamente en una base de datos. En este ejemplo, crearemos una función lambda simple que convertirá los datos del webhook del formato JSON original a un archivo CSV que podría cargarse en una base de datos.
Dependiendo del propósito previsto para almacenar los datos del evento Bird, es posible que sus requisitos se satisfagan simplemente almacenando la carga útil JSON como un archivo plano. También puede tener ya establecido un proceso ETL downstream que sea capaz de consumir y cargar datos en formato JSON. En ambos casos, puede utilizar el archivo plano creado por nuestra lambda de procesamiento que creamos anteriormente tal cual.
Alternativamente, puede necesitar transformar los datos, como convertirlos de un formato JSON a un formato CSV, o cargar los datos directamente en una base de datos. En este ejemplo, crearemos una función lambda simple que convertirá los datos del webhook del formato JSON original a un archivo CSV que podría cargarse en una base de datos.
Crear un Lambda para Procesar los Datos
Al igual que con la función lambda para consumir los datos del webhook, necesitamos crear una nueva función lambda navegando al servicio Lambda dentro de AWS y presionando "Create Function." Esta nueva función lambda se activará cuando se cree un nuevo archivo en nuestro bucket S3 – leerá los datos y los convertirá en un nuevo archivo csv.
La función lambda acepta la información del archivo como un evento. En la función lambda de ejemplo, verá que primero tenemos una serie de comprobaciones de validación para asegurar que los datos estén completos y formateados como se espera. A continuación, convertimos la carga JSON en un archivo CSV utilizando la biblioteca "csv" y escribiéndolo en un archivo temporal. Las funciones Lambda solo pueden escribir archivos locales en el directorio "/tmp", por lo que creamos un archivo csv temporal y lo nombramos con la convención <batch_id>.csv. La razón por la que usamos el batch_id aquí es simplemente para asegurar que cualquier proceso paralelo que se ejecute como resultado de recibir múltiples cargas de webhook no interfiera entre sí, ya que cada lote de webhook tendrá un batch_id único.
Una vez que los datos se han convertido completamente a CSV, leemos los datos CSV como un flujo de bytes, eliminamos el archivo temporal y guardamos los datos CSV como un nuevo archivo en S3. Es importante señalar que se necesita un bucket S3 diferente para la salida, de lo contrario, corremos el riesgo de crear un bucle recursivo que puede resultar en un aumento del uso de lambda y costos incrementados. Necesitaremos identificar en qué bucket S3 y ubicación queremos que se almacene nuestro archivo CSV dentro de nuestra función lambda. Siga el mismo procedimiento mencionado anteriormente para crear un nuevo bucket S3 para almacenar nuestro archivo CSV.
Tenga en cuenta que el directorio tmp está limitado a 512 MB de espacio, por lo que es importante que el archivo temporal se elimine posteriormente para asegurar espacio suficiente para futuras ejecuciones. La razón por la que usamos un archivo temporal, en lugar de escribir directamente en S3, es simplificar la conexión con S3 al tener una única solicitud.
Al igual que con la función lambda de consumo, puede que necesite actualizar los permisos para su función lambda de proceso. Esta función lambda requiere que el rol de ejecución tenga permisos GetObject para el bucket S3 de entrada, y tanto PutObject como GetObject para el bucket S3 de salida.
Una muestra de nuestra función lambda de procesamiento se puede encontrar aquí.
Al igual que con la función lambda para consumir los datos del webhook, necesitamos crear una nueva función lambda navegando al servicio Lambda dentro de AWS y presionando "Create Function." Esta nueva función lambda se activará cuando se cree un nuevo archivo en nuestro bucket S3 – leerá los datos y los convertirá en un nuevo archivo csv.
La función lambda acepta la información del archivo como un evento. En la función lambda de ejemplo, verá que primero tenemos una serie de comprobaciones de validación para asegurar que los datos estén completos y formateados como se espera. A continuación, convertimos la carga JSON en un archivo CSV utilizando la biblioteca "csv" y escribiéndolo en un archivo temporal. Las funciones Lambda solo pueden escribir archivos locales en el directorio "/tmp", por lo que creamos un archivo csv temporal y lo nombramos con la convención <batch_id>.csv. La razón por la que usamos el batch_id aquí es simplemente para asegurar que cualquier proceso paralelo que se ejecute como resultado de recibir múltiples cargas de webhook no interfiera entre sí, ya que cada lote de webhook tendrá un batch_id único.
Una vez que los datos se han convertido completamente a CSV, leemos los datos CSV como un flujo de bytes, eliminamos el archivo temporal y guardamos los datos CSV como un nuevo archivo en S3. Es importante señalar que se necesita un bucket S3 diferente para la salida, de lo contrario, corremos el riesgo de crear un bucle recursivo que puede resultar en un aumento del uso de lambda y costos incrementados. Necesitaremos identificar en qué bucket S3 y ubicación queremos que se almacene nuestro archivo CSV dentro de nuestra función lambda. Siga el mismo procedimiento mencionado anteriormente para crear un nuevo bucket S3 para almacenar nuestro archivo CSV.
Tenga en cuenta que el directorio tmp está limitado a 512 MB de espacio, por lo que es importante que el archivo temporal se elimine posteriormente para asegurar espacio suficiente para futuras ejecuciones. La razón por la que usamos un archivo temporal, en lugar de escribir directamente en S3, es simplificar la conexión con S3 al tener una única solicitud.
Al igual que con la función lambda de consumo, puede que necesite actualizar los permisos para su función lambda de proceso. Esta función lambda requiere que el rol de ejecución tenga permisos GetObject para el bucket S3 de entrada, y tanto PutObject como GetObject para el bucket S3 de salida.
Una muestra de nuestra función lambda de procesamiento se puede encontrar aquí.
Al igual que con la función lambda para consumir los datos del webhook, necesitamos crear una nueva función lambda navegando al servicio Lambda dentro de AWS y presionando "Create Function." Esta nueva función lambda se activará cuando se cree un nuevo archivo en nuestro bucket S3 – leerá los datos y los convertirá en un nuevo archivo csv.
La función lambda acepta la información del archivo como un evento. En la función lambda de ejemplo, verá que primero tenemos una serie de comprobaciones de validación para asegurar que los datos estén completos y formateados como se espera. A continuación, convertimos la carga JSON en un archivo CSV utilizando la biblioteca "csv" y escribiéndolo en un archivo temporal. Las funciones Lambda solo pueden escribir archivos locales en el directorio "/tmp", por lo que creamos un archivo csv temporal y lo nombramos con la convención <batch_id>.csv. La razón por la que usamos el batch_id aquí es simplemente para asegurar que cualquier proceso paralelo que se ejecute como resultado de recibir múltiples cargas de webhook no interfiera entre sí, ya que cada lote de webhook tendrá un batch_id único.
Una vez que los datos se han convertido completamente a CSV, leemos los datos CSV como un flujo de bytes, eliminamos el archivo temporal y guardamos los datos CSV como un nuevo archivo en S3. Es importante señalar que se necesita un bucket S3 diferente para la salida, de lo contrario, corremos el riesgo de crear un bucle recursivo que puede resultar en un aumento del uso de lambda y costos incrementados. Necesitaremos identificar en qué bucket S3 y ubicación queremos que se almacene nuestro archivo CSV dentro de nuestra función lambda. Siga el mismo procedimiento mencionado anteriormente para crear un nuevo bucket S3 para almacenar nuestro archivo CSV.
Tenga en cuenta que el directorio tmp está limitado a 512 MB de espacio, por lo que es importante que el archivo temporal se elimine posteriormente para asegurar espacio suficiente para futuras ejecuciones. La razón por la que usamos un archivo temporal, en lugar de escribir directamente en S3, es simplificar la conexión con S3 al tener una única solicitud.
Al igual que con la función lambda de consumo, puede que necesite actualizar los permisos para su función lambda de proceso. Esta función lambda requiere que el rol de ejecución tenga permisos GetObject para el bucket S3 de entrada, y tanto PutObject como GetObject para el bucket S3 de salida.
Una muestra de nuestra función lambda de procesamiento se puede encontrar aquí.
Configurar una Lambda para Ejecutar Cuando se Almacenen Nuevos Datos en S3
Ahora que nuestra función lambda para convertir el archivo de JSON a formato CSV ha sido creada, necesitamos configurarla para que se active cuando se crea un nuevo archivo en nuestro bucket S3. Para hacer esto, necesitamos agregar un activador a nuestra función lambda abriendo nuestra función lambda y haciendo clic en “Add Trigger” en la parte superior de la página. Seleccione “S3” y proporcione el nombre del bucket S3 donde se almacenan los payloads brutos de webhook. También tiene la opción de especificar prefijo y/o sufijo de archivo para filtrar. Una vez que se han configurado los ajustes, puede agregar el activador haciendo clic en “Add” en la parte inferior de la página. Ahora su función lambda de procesamiento se ejecutará cada vez que se añada un nuevo archivo a su bucket S3.
Ahora que nuestra función lambda para convertir el archivo de JSON a formato CSV ha sido creada, necesitamos configurarla para que se active cuando se crea un nuevo archivo en nuestro bucket S3. Para hacer esto, necesitamos agregar un activador a nuestra función lambda abriendo nuestra función lambda y haciendo clic en “Add Trigger” en la parte superior de la página. Seleccione “S3” y proporcione el nombre del bucket S3 donde se almacenan los payloads brutos de webhook. También tiene la opción de especificar prefijo y/o sufijo de archivo para filtrar. Una vez que se han configurado los ajustes, puede agregar el activador haciendo clic en “Add” en la parte inferior de la página. Ahora su función lambda de procesamiento se ejecutará cada vez que se añada un nuevo archivo a su bucket S3.
Ahora que nuestra función lambda para convertir el archivo de JSON a formato CSV ha sido creada, necesitamos configurarla para que se active cuando se crea un nuevo archivo en nuestro bucket S3. Para hacer esto, necesitamos agregar un activador a nuestra función lambda abriendo nuestra función lambda y haciendo clic en “Add Trigger” en la parte superior de la página. Seleccione “S3” y proporcione el nombre del bucket S3 donde se almacenan los payloads brutos de webhook. También tiene la opción de especificar prefijo y/o sufijo de archivo para filtrar. Una vez que se han configurado los ajustes, puede agregar el activador haciendo clic en “Add” en la parte inferior de la página. Ahora su función lambda de procesamiento se ejecutará cada vez que se añada un nuevo archivo a su bucket S3.
Cargando los datos en una base de datos
En este ejemplo, no cubriré en detalle la carga de datos en una base de datos, pero si has estado siguiendo este ejemplo, tienes un par de opciones:
Cargar los datos directamente en tu base de datos dentro de tu función lambda de procesamiento
Consumir tu archivo CSV utilizando un proceso ETL establecido
Ya sea que estés utilizando un servicio de base de datos de AWS, como RDS o DynamoDB, o tengas tu propia base de datos PostgreSQL (o similar), puedes conectar tu servicio de base de datos directamente desde tu función lambda de proceso. Por ejemplo, de la misma manera que llamamos al servicio S3 usando "boto3” en nuestra función lambda, también podrías usar "boto3” para llamar a RDS o DynamoDB. El servicio de AWS Athena también podría utilizarse para leer los archivos de datos directamente desde los archivos planos y acceder a los datos usando un lenguaje de consulta similar al SQL. Recomiendo referirse a la documentación respectiva del servicio que estás utilizando para obtener más información sobre cómo lograr esto de la mejor manera en tu entorno.
De manera similar, hay muchos servicios disponibles que pueden ayudar a consumir archivos CSV y cargar los datos en una base de datos. Es posible que ya tengas un proceso ETL establecido que puedas aprovechar.
Esperamos que encuentres esta guía útil, ¡feliz envío!
En este ejemplo, no cubriré en detalle la carga de datos en una base de datos, pero si has estado siguiendo este ejemplo, tienes un par de opciones:
Cargar los datos directamente en tu base de datos dentro de tu función lambda de procesamiento
Consumir tu archivo CSV utilizando un proceso ETL establecido
Ya sea que estés utilizando un servicio de base de datos de AWS, como RDS o DynamoDB, o tengas tu propia base de datos PostgreSQL (o similar), puedes conectar tu servicio de base de datos directamente desde tu función lambda de proceso. Por ejemplo, de la misma manera que llamamos al servicio S3 usando "boto3” en nuestra función lambda, también podrías usar "boto3” para llamar a RDS o DynamoDB. El servicio de AWS Athena también podría utilizarse para leer los archivos de datos directamente desde los archivos planos y acceder a los datos usando un lenguaje de consulta similar al SQL. Recomiendo referirse a la documentación respectiva del servicio que estás utilizando para obtener más información sobre cómo lograr esto de la mejor manera en tu entorno.
De manera similar, hay muchos servicios disponibles que pueden ayudar a consumir archivos CSV y cargar los datos en una base de datos. Es posible que ya tengas un proceso ETL establecido que puedas aprovechar.
Esperamos que encuentres esta guía útil, ¡feliz envío!
En este ejemplo, no cubriré en detalle la carga de datos en una base de datos, pero si has estado siguiendo este ejemplo, tienes un par de opciones:
Cargar los datos directamente en tu base de datos dentro de tu función lambda de procesamiento
Consumir tu archivo CSV utilizando un proceso ETL establecido
Ya sea que estés utilizando un servicio de base de datos de AWS, como RDS o DynamoDB, o tengas tu propia base de datos PostgreSQL (o similar), puedes conectar tu servicio de base de datos directamente desde tu función lambda de proceso. Por ejemplo, de la misma manera que llamamos al servicio S3 usando "boto3” en nuestra función lambda, también podrías usar "boto3” para llamar a RDS o DynamoDB. El servicio de AWS Athena también podría utilizarse para leer los archivos de datos directamente desde los archivos planos y acceder a los datos usando un lenguaje de consulta similar al SQL. Recomiendo referirse a la documentación respectiva del servicio que estás utilizando para obtener más información sobre cómo lograr esto de la mejor manera en tu entorno.
De manera similar, hay muchos servicios disponibles que pueden ayudar a consumir archivos CSV y cargar los datos en una base de datos. Es posible que ya tengas un proceso ETL establecido que puedas aprovechar.
Esperamos que encuentres esta guía útil, ¡feliz envío!
