Definición
La $externalFunction La etapa activa procesos en un recurso específico de AWS Lambda. Su solicitud al proceso de AWS Lambda puede ser síncrona o asíncrona.
Crea una función AWS Lambda y autentícate con Unified AWS Access
Para llamar a un recurso de AWS Lambda desde dentro de tu pipeline de Atlas Stream Processing, tu AWS Lambda debe estar implementado en la misma región de AWS en la que tu Atlas Stream Processing esté implementado. Para obtener más información sobre cómo implementar un recurso de AWS Lambda, consulta la documentación de AWS.
Cree una función AWS Lambda.
Con la CLI de AWS o a través de la Interfaz de Usuario de AWS, crea una función lambda.
Configurar el acceso unificado a AWS.
Nota
El procedimiento descrito aquí solo cubre el flujo de configuración básica en la Interfaz de Usuario de Atlas. Para obtener más información, consulte el/la Configurar la documentación de Unified AWS Access.
Acceso requerido
Para configurar unificado Acceso a AWS, debe Organization Owner tener acceso o Project Owner al proyecto.
Requisitos previos
Nota
Su política de AWS IAM debe incluir la acción
lambda:InvokeFunction.Debe reemplazar los valores de los marcadores de posición
ExternalIdyResourcepor los suyos propios, disponibles mediante el proceso de configuración de Unified AWS Access. Tenga en cuenta que elExternalIdde este ejemplo incluye un comodín que coincide con cualquier función Lambda cuyo nombre comience porfunction-.
Añade relaciones de confianza a un rol existente en la interfaz de usuario de Atlas
A continuación, debes habilitar tu rol autogestionado de AWS IAM para ejecutar el recurso AWS Lambda.
permission-policy.json
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": "arn:aws:lambda:us-east-1:257394458927:function:<function-name>" } ] }
Navega a la página de integración de AWS IAM en tu proyecto de Atlas y haz clic en el Authorize an AWS IAM role botón.
Crea un nuevo rol (o modifica uno existente) con el
role-trust-policy.jsonque se muestra en el modal.Una vez que el rol se cree (o el rol existente se actualice con la nueva política de confianza), pega el ARN del rol en la ventana emergente.
En la consola de AWS, ve a IAM > Roles y selecciona tu rol.
En la pestaña permissions, agregue un nuevo "permiso en línea" para permitir que este rol invoque sus lambdas. El ejemplo
permission-policy.jsonanterior agrega el permiso para ejecutar cualquier lambda con el nombre<function-name>.Por último, navegue a su espacio de trabajo de procesamiento de secuencias Atlas, agregue un nuevo AWS Lambda connection y elija el AWS IAM Role ARN que configuró en el paso anterior.
Conecta tu espacio de trabajo de Atlas Stream Processing a tu función AWS Lambda
Para enviar una solicitud a tu recurso de AWS Lambda desde tu pipeline de Atlas Stream Processing, primero debes agregar tu recurso de AWS Lambda como una conexión en tu recurso de Atlas Stream Processing.
Puede agregar su recurso de AWS Lambda como una conexión a través de la interfaz de usuario de Atlas, la CLI de Atlas o la API de Atlas, como se muestra en el siguiente ejemplo. Puede actualizar el roleArn marcador de posición en el ejemplo con el arn de su configuración de AWS IAM.
Nota
Este curl comando utiliza un token de acceso a la cuenta de servicio(OAuth) 2.0 para autenticarse en lugar de claves de API. Para obtener más información, consulte la guía de inicio rápido de la API de administración de Atlas.
curl --header "Authorization: Bearer {ACCESS-TOKEN}" \ --header "Content-Type: application/json" \ --header "Accept: application/vnd.atlas.2023-02-01+json" \ --include \ --data '{"name": "TestAWSLambdaConnection","type": "AWSLambda","aws": {"roleArn": "arn:aws:iam::<aws_account>:role/<role_name>"}}' \ --request POST "https://cloud.mongodb.com/api/atlas/v2/groups/<group_id>/streams/<tenant_name>/connections"
Sintaxis
Solicitud mínima
El siguiente ejemplo muestra los campos obligatorios para una solicitud mínima.
{ $externalFunction: { connectionName: "myLambdaConnection", functionName: "arn:aws:lambda:region:account-id:function:function-name", as: "response", }}
Solicitud personalizada
El siguiente ejemplo personalizado especifica el manejo de errores, la ejecución sincrónica y un documento de procesamiento de flujo Atlas preprocesado como carga útil, además de los campos obligatorios ilustrados anteriormente.
{ $externalFunction: { connectionName: "myLambdaConnection", functionName: "arn:aws:lambda:region:account-id:function:function-name", execution: "sync" as: "response", onError: "fail", payload: [{$replaceRoot: { newRoot: "$fullDocument.payloadToSend" } }, { $addFields: { sum: { $sum: "$randomArray" }}}, { $project: { success: 1, sum: 1 }}], }}
Nota
El campo onError define el comportamiento para errores a nivel de API tanto para solicitudes síncronas como asíncronas a su recurso AWS Lambda, así como errores de la función AWS Lambda para solicitudes síncronas.
La etapa $externalFunction procesa un documento con los siguientes campos:
Campo | Tipo | Necesidad | Descripción |
|---|---|---|---|
| string | Requerido | Etiqueta que identifica la conexión en el Registro de Conexiones, a la que se envía la solicitud. |
| string | Requerido | El ARN completo de AWS o el nombre de la función AWS Lambda que se va a activar. |
| enum | Opcional | Parámetro que especifica si la función de AWS Lambda debe llamarse de forma síncrona o asíncrona. Los valores aceptados son:
Por defecto a |
| string | Opcional | Nombre del campo para la respuesta de la API REST. Si el endpoint devuelve 0 bytes, el operador no configura el campo |
| string | Opcional | Comportamiento cuando el operador encuentra un
Se establece por defecto en |
| arreglo | Opcional | Pipeline interno personalizado que permite personalizar el cuerpo de la solicitud enviado al endpoint de la API.
|
Comportamiento
La etapa envía una solicitud al recurso de AWS Lambda especificado. Si la solicitud es síncrona, la respuesta se devuelve en el campo especificado y la canalización continúa el procesamiento. Si la solicitud es asíncrona, la canalización continúa el procesamiento sin esperar la $externalFunction respuesta.
Si una solicitud síncrona falla, el comportamiento de manejo de errores del pipeline está determinado por el campo onError. Si la solicitud es asíncrona, el campo onError se aplica solo a errores de la API de AWS, en lugar de errores de función de AWS Lambda. Si el campo onError no se especifica, el comportamiento por defecto es enviar el documento afectado a la fila de letra muerta.
onError Valor | Comportamiento |
|---|---|
| El documento afectado se envía a la fila de letra muerta. |
| El documento afectado se ignora. |
| El procesador de flujo se termina en caso de error. |
Si la canalización no puede convertir el documento a un JSON correcto o la canalización configurada no crea un objeto BSON válido como producto de la etapa final, el documento se envía a la fila de letra muerta independientemente del ajuste onError.
Los errores que surgen de una configuración incorrecta del operador $externalFunction en sí, como expresiones no válidas, no desencadenan el comportamiento onError. En cambio, el procesador de flujo falla con un mensaje de error. La pipeline de Atlas Stream Processing reintenta las solicitudes fallidas que pueden ser resultado de errores transitorios.