Reach

Grow

Manage

Automate

Reach

Grow

Manage

Automate

Creando y Consumando Webhooks de Aves

Correo electrónico

1 min read

Creando y Consumando Webhooks de Aves

Correo electrónico

1 min read

Creando y Consumando Webhooks de Aves

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 de AWS.

Los webhooks de eventos en tiempo real de Bird son una herramienta increíblemente valiosa para que los remitentes tengan los datos enviados automáticamente a sus sistemas. Esto puede impulsar la automatización posterior, como actualizar listas de correo, activar recorridos de correo electrónico automatizados o completar tableros internos. Aunque los mismos datos de eventos pueden ser accedidos a través de la interfaz de Bird usando Event Search, o programáticamente aprovechando la Events API de Bird, las limitaciones impuestas en la cantidad de registros devueltos en una sola solicitud o las restricciones de velocidad impuestas en el endpoint 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 endpoint al que Bird transmite los datos, y los datos pueden ser consumidos sin tener que programar trabajos cron que extraigan los datos. También existen compensaciones logísticas al extraer los datos en lugar de recibirlos, como tener que identificar qué período de tiempo y parámetros utilizar para cada solicitud de API. Si los períodos de tiempo no están perfectamente alineados, se corre el riesgo de perder datos, y si los períodos de tiempo se superponen, entonces hay que manejar los registros de datos duplicados. Con los webhooks en tiempo real, los datos de eventos simplemente se envían a tu endpoint a medida que se vuelven disponibles dentro de Bird.




Si bien los beneficios de recibir datos de eventos en tiempo real para impulsar procesos de automatización pueden ser comprendidos de inmediato por muchos remitentes, el proceso real de implementación y consumo de webhooks puede resultar intimidante. Esto puede ser especialmente cierto si no estás familiarizado con los componentes técnicos de la creación de un endpoint y el manejo de datos programáticamente. Hay servicios disponibles que consumirán los datos del webhook de Bird y realizarán ETL en tu base de datos automáticamente; un ejemplo sería StitchData, sobre el cual hemos escrito en el blog en el pasado.  Sin embargo, si deseas tener más control sobre el proceso, puedes construir fácilmente los componentes tú mismo. Lo siguiente es una guía simple para ayudar a los remitentes a sentirse cómodos al crear un webhook de eventos de Bird y consumir los datos usando la infraestructura dentro de AWS.

Configuración del Endpoint de Webhook objetivo

Cuando se crea un evento de Bird, queremos que los datos de ese evento se transmitan en tiempo real a un endpoint en AWS para que podamos consumir y usar esos datos de manera programática. Los datos se enviarán desde Bird a un endpoint de destino, que reenviará el payload a una función lambda que procesará y almacenará los datos en un bucket de S3. Un diagrama de alto nivel del flujo de datos descrito se puede ver a continuación:










Para implementar este flujo de trabajo, vamos a construirlo en orden inverso comenzando con la creación de un bucket de S3 donde almacenaremos nuestros datos de eventos y luego trabajaremos hacia atrás, agregando cada componente que alimenta lo que hemos construido.




Crear un Bucket de 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 bucket de S3 donde se almacenarán los datos. Para hacer esto, navegue al servicio S3 dentro de AWS y presione “Crear Bucket.” Se le solicitará asignar un nombre a su bucket y establecer la región; asegúrese de usar la misma región que su ALB y función lambda. Cuando se crea su bucket de S3, 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 bucket de S3 “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 real de los datos será realizado por una función lambda que es invocada por nuestro balanceador de carga de aplicaciones (ALB).




El primer paso es crear su función lambda navegando al servicio Lambda dentro de AWS y haciendo clic en “Crear Función.” Se le pedirá que asigne un nombre a su función lambda y seleccione en qué lenguaje de programación escribir su función. Para este ejemplo, usamos Python como lenguaje de ejecución.




Ahora necesitamos desarrollar nuestra función lambda. Por un momento, supongamos que nuestro balanceador de carga de aplicaciones ha sido configurado y está reenviando el payload del webhook a nuestra función lambda; la lambda recibirá un payload que incluye los encabezados completos y el cuerpo. El payload se pasa a nuestra función lambda usando el objeto “event” como un diccionario. Puede referenciar los encabezados y el cuerpo del payload de manera independiente accediendo a los objetos “headers” y “body” dentro del payload. En este ejemplo, simplemente vamos a leer el encabezado “x-messagesystems-batch-id”, donde el ID de lote es un valor único creado por Bird para el lote del webhook, y usarlo como el nombre del archivo al almacenar el cuerpo como un archivo plano en S3; sin embargo, puede que desee agregar funcionalidades adicionales como verificaciones de autenticación o manejo de errores, según sea necesario.




Al almacenar el payload en un archivo plano en S3, necesitaremos definir el nombre del bucket de S3, ubicación, y el nombre del archivo donde se almacenarán los datos del payload. En nuestra muestra de función lambda, 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 asegurar que los datos se recopilen y almacenen antes de que la conexión HTTP entre Bird y su endpoint se agote. Aunque podría ajustar la configuración de tiempo de espera de la conexión en su balanceador de carga, no hay garantías 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 su función lambda termine de ejecutarse. Es una práctica recomendada mantener su función consumidora lo más eficiente posible y reservar las actividades de procesamiento de datos para procesos posteriores donde sea posible, como convertir el payload batido en formato JSON en un archivo CSV, o cargar los datos del evento en una base de datos.




Es importante señalar que puede ser necesario actualizar los permisos para su función lambda. Su rol de ejecución necesitará permisos PutObject y GetObject para S3. Es una práctica recomendada aplicar el principio de menor privilegio, por lo que recomiendo establecer estos permisos solo para el bucket de S3 donde se almacenarán los payloads del webhook.




Una muestra de nuestra función lambda consumidora se puede encontrar aquí.




Como una nota rápida sobre el ID de lote: Bird combinará eventos en un único payload, donde cada lote puede contener de 1 a 350 o más registros de eventos. Al lote se le asignará un ID de lote único, que se puede usar para ver el estado del lote aprovechando la API de Event Webhooks o dentro de su cuenta de Bird haciendo clic en una transmisión de webhook y seleccionando “Estado del Lote.” En el caso de que un payload de webhook no pudiera ser entregado, como durante una conexión agotada, Bird automáticamente reintentará el lote usando el mismo ID de lote. Esto puede suceder cuando su función lambda está funcionando 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 forma asíncrona a la transmisión de los datos, y no hay riesgo de perder datos debido a una conexión terminada. Discuto la función lambda de procesamiento en una sección posterior.




Crear un Balanceador de Carga de Aplicaciones




Para recibir un payload de webhook, necesitamos proporcionar un endpoint para enviar los payloads. Hacemos esto creando un balanceador de carga de aplicaciones dentro de AWS navegando a EC2 > Load Balancers y haciendo clic en “Crear Balanceador de Carga.” Se le pedirá que elija qué tipo de balanceador de carga desea crear; para esto, queremos crear un balanceador de carga de aplicaciones. Necesitamos usar un balanceador de carga de aplicaciones (ALB) para construir nuestro consumidor porque los webhooks de eventos se enviarán como una solicitud HTTP, y los ALBs se utilizan para enrutar solicitudes HTTP dentro de AWS. Podríamos implementar un Gateway HTTP como alternativa; sin embargo, usamos un ALB para este proyecto porque es más ligero y rentable que el Gateway HTTP. Es importante señalar que si opta por utilizar un Gateway HTTP, el formato de los eventos puede ser diferente que con un ALB, y por lo tanto, su función lambda necesitará manejar el objeto de solicitud en consecuencia.




Una vez que su ALB ha sido creado, se le solicitará asignar un nombre a su ALB y configurar el esquema y los ajustes de acceso/seguridad; como planeamos recibir datos de eventos de una fuente externa (Bird), queremos que nuestro ALB sea accesible desde internet. Bajo “Listeners and routing,” el ALB debe escuchar 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 consumidora que creamos arriba. También necesita asegurarse de que el grupo de seguridad tenga permiso para aceptar tráfico a través del puerto 443.




Crear un Registro DNS para el Balanceador de Carga




Para facilitarnos el uso de nuestro ALB como un endpoint, crearemos un registro A en DNS que apunte a nuestro ALB. Para esto, podemos usar 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 (e.g. spevents.<your_domain>). El registro A debe configurarse para apuntar al ALB que creamos. Si está utilizando Route 53 para gestionar los registros de DNS, puede referenciar directamente la instancia del ALB habilitando “Alias” y seleccionando el ALB; de lo contrario, si está usando un proveedor de DNS externo, debe apuntar el registro A a la dirección IP pública de la instancia ALB.




Recomiendo usar una herramienta como Postman para probar que todo se ha configurado correctamente antes de habilitar su webhook de Bird. Puede hacer una solicitud POST a su endpoint y confirmar que se recibe una respuesta. Si su solicitud POST no devuelve una respuesta, puede necesitar verificar dos veces que su ALB esté escuchando el puerto correcto.




Crear un Webhook de Bird




Ahora estamos listos para crear el webhook en Bird y usar el nombre de host definido por el registro A arriba como nuestro endpoint de destino. Para crear el webhook, navegue a la sección de Webhooks dentro de su cuenta de Bird y haga clic en “Crear Webhook.” Se le pedirá que asigne un nombre a su webhook y proporcione una URL de destino; el destino debe ser el nombre de host del registro A que creó anteriormente. Tenga en cuenta que la URL de destino puede requerir que se incluya “HTTPS://” en la URL.




Una vez completado, verifique que la subcuenta correcta y los eventos estén seleccionados y presione “Crear Webhook” para guardar su configuración. Los datos del evento para todos los tipos de eventos seleccionados ahora se transmitirán a nuestra URL de destino y serán consumidos por nuestro ALB para su procesamiento posterior.

Procesamiento de Webhook Event Data

Dependiendo del propósito previsto para almacenar los datos de eventos de Bird, sus requisitos pueden satisfacerse simplemente almacenando la carga útil JSON como un archivo plano. También puede tener un proceso ETL downstream ya establecido que sea capaz de consumir y cargar datos en formato JSON. En ambos casos, puede utilizar el archivo plano creado por nuestro procesamiento lambda que creamos anteriormente tal cual.




Alternativamente, puede que necesite transformar los datos, por ejemplo, para convertir 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 en 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 crea 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. Luego, 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 los procesos en paralelo que se ejecutan como resultado de recibir múltiples cargas del webhook no interfieran entre sí, ya que cada batch 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 destacar que se necesita un bucket S3 diferente para el resultado; de lo contrario, corremos el riesgo de crear un bucle recursivo que puede resultar en un aumento del uso de lambda y mayores costos. Necesitaremos identificar en qué bucket y ubicación de S3 queremos que nuestro archivo CSV sea almacenado dentro de nuestra función lambda.  Siga el mismo procedimiento práctico anterior 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 después de asegurar suficiente espacio para futuras ejecuciones. La razón por la cual usamos un archivo temporal, en lugar de escribir directamente en S3, es para simplificar la conexión a S3 mediante una sola solicitud.




Al igual que con la función lambda de consumo, puede que necesite actualizar los permisos para su función lambda de procesamiento. Esta función lambda requiere que el rol de ejecución tenga permisos GetObject para el bucket de entrada de S3, y tanto PutObject como GetObject para el bucket de salida de S3.




Una muestra de nuestra función lambda de procesamiento se puede encontrar aquí.




Configurar un Lambda para Ejecutar Cuando Nuevos Datos se Almacenen en S3




Ahora que nuestra función lambda para convertir el archivo de formato JSON a CSV ha sido creada, necesitamos configurarla para que se active cuando se cree un nuevo archivo en nuestro bucket S3. Para hacer esto, necesitamos agregar un disparador 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 las cargas del webhook en bruto. También tiene la opción de especificar el prefijo y/o sufijo del archivo para filtrar. Una vez que los ajustes se hayan configurado, puede agregar el disparador 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 agregue un nuevo archivo a su bucket S3.




Cargar los Datos en una Base de Datos




En este ejemplo, no cubriré en detalle la carga de los datos en una base de datos, pero si ha seguido a lo largo de este ejemplo, tiene un par de opciones:




  1. Cargar los datos directamente en su base de datos dentro de su función lambda de procesamiento

  2. Consumir su archivo CSV utilizando un proceso ETL establecido




Ya sea que esté usando un servicio de base de datos de AWS, como RDS o DynamoDB, o tenga su propia base de datos PostgreSQL (o similar), puede conectar su servicio de base de datos directamente desde su función lambda de proceso. Por ejemplo, de la misma manera que llamamos al servicio S3 utilizando “boto3” en nuestra función lambda, también podría usar “boto3” para llamar a RDS o DynamoDB. El servicio de AWS Athena también podría usarse para leer los archivos de datos directamente desde los archivos planos, y acceder a los datos usando un lenguaje de consulta similar a SQL. Recomiendo consultar la documentación respectiva para el servicio que está utilizando para obtener más información sobre cómo lograr esto de la mejor manera dentro de su entorno.




De manera similar, hay muchos servicios disponibles que pueden ayudar a consumir archivos CSV y cargar los datos en una base de datos. Puede que ya tenga un proceso ETL establecido que pueda aprovechar.




Esperamos que haya encontrado esta guía útil: ¡feliz envío!

Dependiendo del propósito previsto para almacenar los datos de eventos de Bird, sus requisitos pueden satisfacerse simplemente almacenando la carga útil JSON como un archivo plano. También puede tener un proceso ETL downstream ya establecido que sea capaz de consumir y cargar datos en formato JSON. En ambos casos, puede utilizar el archivo plano creado por nuestro procesamiento lambda que creamos anteriormente tal cual.




Alternativamente, puede que necesite transformar los datos, por ejemplo, para convertir 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 en 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 crea 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. Luego, 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 los procesos en paralelo que se ejecutan como resultado de recibir múltiples cargas del webhook no interfieran entre sí, ya que cada batch 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 destacar que se necesita un bucket S3 diferente para el resultado; de lo contrario, corremos el riesgo de crear un bucle recursivo que puede resultar en un aumento del uso de lambda y mayores costos. Necesitaremos identificar en qué bucket y ubicación de S3 queremos que nuestro archivo CSV sea almacenado dentro de nuestra función lambda.  Siga el mismo procedimiento práctico anterior 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 después de asegurar suficiente espacio para futuras ejecuciones. La razón por la cual usamos un archivo temporal, en lugar de escribir directamente en S3, es para simplificar la conexión a S3 mediante una sola solicitud.




Al igual que con la función lambda de consumo, puede que necesite actualizar los permisos para su función lambda de procesamiento. Esta función lambda requiere que el rol de ejecución tenga permisos GetObject para el bucket de entrada de S3, y tanto PutObject como GetObject para el bucket de salida de S3.




Una muestra de nuestra función lambda de procesamiento se puede encontrar aquí.




Configurar un Lambda para Ejecutar Cuando Nuevos Datos se Almacenen en S3




Ahora que nuestra función lambda para convertir el archivo de formato JSON a CSV ha sido creada, necesitamos configurarla para que se active cuando se cree un nuevo archivo en nuestro bucket S3. Para hacer esto, necesitamos agregar un disparador 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 las cargas del webhook en bruto. También tiene la opción de especificar el prefijo y/o sufijo del archivo para filtrar. Una vez que los ajustes se hayan configurado, puede agregar el disparador 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 agregue un nuevo archivo a su bucket S3.




Cargar los Datos en una Base de Datos




En este ejemplo, no cubriré en detalle la carga de los datos en una base de datos, pero si ha seguido a lo largo de este ejemplo, tiene un par de opciones:




  1. Cargar los datos directamente en su base de datos dentro de su función lambda de procesamiento

  2. Consumir su archivo CSV utilizando un proceso ETL establecido




Ya sea que esté usando un servicio de base de datos de AWS, como RDS o DynamoDB, o tenga su propia base de datos PostgreSQL (o similar), puede conectar su servicio de base de datos directamente desde su función lambda de proceso. Por ejemplo, de la misma manera que llamamos al servicio S3 utilizando “boto3” en nuestra función lambda, también podría usar “boto3” para llamar a RDS o DynamoDB. El servicio de AWS Athena también podría usarse para leer los archivos de datos directamente desde los archivos planos, y acceder a los datos usando un lenguaje de consulta similar a SQL. Recomiendo consultar la documentación respectiva para el servicio que está utilizando para obtener más información sobre cómo lograr esto de la mejor manera dentro de su entorno.




De manera similar, hay muchos servicios disponibles que pueden ayudar a consumir archivos CSV y cargar los datos en una base de datos. Puede que ya tenga un proceso ETL establecido que pueda aprovechar.




Esperamos que haya encontrado esta guía útil: ¡feliz envío!

Dependiendo del propósito previsto para almacenar los datos de eventos de Bird, sus requisitos pueden satisfacerse simplemente almacenando la carga útil JSON como un archivo plano. También puede tener un proceso ETL downstream ya establecido que sea capaz de consumir y cargar datos en formato JSON. En ambos casos, puede utilizar el archivo plano creado por nuestro procesamiento lambda que creamos anteriormente tal cual.




Alternativamente, puede que necesite transformar los datos, por ejemplo, para convertir 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 en 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 crea 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. Luego, 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 los procesos en paralelo que se ejecutan como resultado de recibir múltiples cargas del webhook no interfieran entre sí, ya que cada batch 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 destacar que se necesita un bucket S3 diferente para el resultado; de lo contrario, corremos el riesgo de crear un bucle recursivo que puede resultar en un aumento del uso de lambda y mayores costos. Necesitaremos identificar en qué bucket y ubicación de S3 queremos que nuestro archivo CSV sea almacenado dentro de nuestra función lambda.  Siga el mismo procedimiento práctico anterior 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 después de asegurar suficiente espacio para futuras ejecuciones. La razón por la cual usamos un archivo temporal, en lugar de escribir directamente en S3, es para simplificar la conexión a S3 mediante una sola solicitud.




Al igual que con la función lambda de consumo, puede que necesite actualizar los permisos para su función lambda de procesamiento. Esta función lambda requiere que el rol de ejecución tenga permisos GetObject para el bucket de entrada de S3, y tanto PutObject como GetObject para el bucket de salida de S3.




Una muestra de nuestra función lambda de procesamiento se puede encontrar aquí.




Configurar un Lambda para Ejecutar Cuando Nuevos Datos se Almacenen en S3




Ahora que nuestra función lambda para convertir el archivo de formato JSON a CSV ha sido creada, necesitamos configurarla para que se active cuando se cree un nuevo archivo en nuestro bucket S3. Para hacer esto, necesitamos agregar un disparador 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 las cargas del webhook en bruto. También tiene la opción de especificar el prefijo y/o sufijo del archivo para filtrar. Una vez que los ajustes se hayan configurado, puede agregar el disparador 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 agregue un nuevo archivo a su bucket S3.




Cargar los Datos en una Base de Datos




En este ejemplo, no cubriré en detalle la carga de los datos en una base de datos, pero si ha seguido a lo largo de este ejemplo, tiene un par de opciones:




  1. Cargar los datos directamente en su base de datos dentro de su función lambda de procesamiento

  2. Consumir su archivo CSV utilizando un proceso ETL establecido




Ya sea que esté usando un servicio de base de datos de AWS, como RDS o DynamoDB, o tenga su propia base de datos PostgreSQL (o similar), puede conectar su servicio de base de datos directamente desde su función lambda de proceso. Por ejemplo, de la misma manera que llamamos al servicio S3 utilizando “boto3” en nuestra función lambda, también podría usar “boto3” para llamar a RDS o DynamoDB. El servicio de AWS Athena también podría usarse para leer los archivos de datos directamente desde los archivos planos, y acceder a los datos usando un lenguaje de consulta similar a SQL. Recomiendo consultar la documentación respectiva para el servicio que está utilizando para obtener más información sobre cómo lograr esto de la mejor manera dentro de su entorno.




De manera similar, hay muchos servicios disponibles que pueden ayudar a consumir archivos CSV y cargar los datos en una base de datos. Puede que ya tenga un proceso ETL establecido que pueda aprovechar.




Esperamos que haya encontrado esta guía útil: ¡feliz envío!

Únete a nuestro Newsletter.

Mantente al día con Bird a través de actualizaciones semanales en tu buzón.

Al enviar, aceptas que Bird pueda contactarte sobre nuestros productos y servicios.

Puedes darte de baja en cualquier momento. Consulta el Aviso de Privacidad de Bird para obtener detalles sobre el procesamiento de datos.

Únete a nuestro Newsletter.

Mantente al día con Bird a través de actualizaciones semanales en tu buzón.

Al enviar, aceptas que Bird pueda contactarte sobre nuestros productos y servicios.

Puedes darte de baja en cualquier momento. Consulta el Aviso de Privacidad de Bird para obtener detalles sobre el procesamiento de datos.

Únete a nuestro Newsletter.

Mantente al día con Bird a través de actualizaciones semanales en tu buzón.

Al enviar, aceptas que Bird pueda contactarte sobre nuestros productos y servicios.

Puedes darte de baja en cualquier momento. Consulta el Aviso de Privacidad de Bird para obtener detalles sobre el procesamiento de datos.

Pinterest logo
Uber logo
Square logo
Logo de Adobe
Meta logo
PayPal logo

Company

Configuración de privacidad

Newsletter

Mantente al día con Bird a través de actualizaciones semanales en tu buzón.

Al enviar, aceptas que Bird pueda contactarte sobre nuestros productos y servicios.

Puedes darte de baja en cualquier momento. Consulta el Aviso de Privacidad de Bird para obtener detalles sobre el procesamiento de datos.

Uber logo
Square logo
Logo de Adobe
Meta logo

Company

Configuración de privacidad

Newsletter

Mantente al día con Bird a través de actualizaciones semanales en tu buzón.

Al enviar, aceptas que Bird pueda contactarte sobre nuestros productos y servicios.

Puedes darte de baja en cualquier momento. Consulta el Aviso de Privacidad de Bird para obtener detalles sobre el procesamiento de datos.

Uber logo
Logo de Adobe
Meta logo

Company

Configuración de privacidad

Newsletter

Mantente al día con Bird a través de actualizaciones semanales en tu buzón.

Al enviar, aceptas que Bird pueda contactarte sobre nuestros productos y servicios.

Puedes darte de baja en cualquier momento. Consulta el Aviso de Privacidad de Bird para obtener detalles sobre el procesamiento de datos.