Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Uso de pasos de procesamiento de archivos personalizados
Al utilizar un paso de procesamiento de archivos personalizado, puede utilizar su propia lógica de procesamiento de archivos con AWS Lambda. Al recibir los archivos, un servidor de Transfer Family invoca una función de Lambda que contiene una lógica de procesamiento de archivos personalizada, como el cifrado de archivos, la detección de malware o la comprobación de tipos de archivos incorrectos. En el siguiente ejemplo, el rol de AWS Lambda de destino se utiliza para procesar el archivo de salida del paso anterior.
![La pantalla de pasos personalizados, con el botón de opción Aplicar procesamiento personalizado al archivo creado a partir del paso anterior seleccionado y una función Lambda que aparece en el campo Objetivo.](images/workflows-step-custom.png)
nota
Para ver una función de Lambda de ejemplo, consulte Ejemplo de función de Lambda para un paso de flujo de trabajo personalizado. Para ver eventos de ejemplo (incluida la ubicación de los archivos que se pasan a Lambda), consulte Ejemplos de eventos enviados AWS Lambda al cargar un archivo.
Con un paso de flujo de trabajo personalizado, debe configurar la función Lambda para llamar a la operación de la SendWorkflowStepStateAPI. SendWorkflowStepState
notifica a la ejecución del flujo de trabajo que el paso se ha completado correctamente o con un estado de error. El estado de la operación de la API SendWorkflowStepState
invoca un paso del controlador de excepciones o un paso nominal en la secuencia lineal en función del resultado de la función de Lambda.
Si se produce un error en la función Lambda o se agota el tiempo de espera, se produce un error en el paso y se muestra StepErrored
en los registros. CloudWatch Si la función de Lambda forma parte del paso nominal y la función responde a SendWorkflowStepState
con Status="FAILURE"
o se agota el tiempo de espera, el flujo continúa con los pasos del controlador de excepciones. En este caso, el flujo de trabajo no continúa ejecutando los pasos nominales restantes (si los hay). Para obtener más información, consulte Gestión de excepciones para un flujo de trabajo.
Al llamar a la operación de la API SendWorkflowStepState
, debe enviar los siguientes parámetros:
{ "ExecutionId": "string", "Status": "string", "Token": "string", "WorkflowId": "string" }
Puede extraer ExecutionId
, Token
y WorkflowId
del evento de entrada que se pasa cuando se ejecuta la función de Lambda (en las siguientes secciones se muestran ejemplos). El valor Status
puede ser SUCCESS
o FAILURE
.
Para poder llamar a la operación de SendWorkflowStepState
API desde su función Lambda, debe usar una versión del AWS SDK que se publicó después de la introducción de Managed Workflows.
Uso de varias funciones de Lambda de forma consecutiva
Cuando se utilizan varios pasos personalizados uno tras otro, la opción de ubicación del archivo funciona de forma diferente que si se utiliza un solo paso personalizado. Transfer Family no permite volver a pasar el archivo procesado por Lambda para usarlo como entrada del siguiente paso. Por lo tanto, si tiene varios pasos personalizados configurados para usar la opción previous.file
, todos usarán la misma ubicación de archivo (la ubicación del archivo de entrada para el primer paso personalizado).
nota
La configuración previous.file
también funciona de forma diferente si tiene un paso predefinido (etiquetado, copiado, descifrado o eliminación) después de un paso personalizado. Si el paso predefinido está configurado para usar la configuración previous.file
, el paso predefinido usará el mismo archivo de entrada que el paso personalizado. El archivo procesado del paso personalizado no se pasa al paso predefinido.
Acceso a un archivo después de un procesamiento personalizado
Si utiliza Amazon S3 como almacenamiento y su flujo de trabajo incluye un paso personalizado que realiza acciones en el archivo cargado originalmente, los pasos siguientes no podrán acceder al archivo procesado. Es decir, ningún paso posterior al paso personalizado puede hacer referencia al archivo actualizado desde la salida del paso personalizado.
Suponga, por ejemplo, que tiene los tres pasos siguientes en su flujo de trabajo.
-
Paso 1: cargue un archivo con el nombre
example-file.txt
. -
Paso 2: invoque una función de Lambda que cambie
example-file.txt
de alguna manera. -
Paso 3: intente realizar un procesamiento adicional en la versión actualizada de
example-file.txt
.
Si configura el sourceFileLocation
para que el paso 3 sea ${original.file}
, el paso 3 utilizará la ubicación original del archivo desde el momento en que el servidor cargó el archivo para almacenarlo en el paso 1. Si utiliza ${previous.file}
para el paso 3, el paso 3 reutilizará la ubicación del archivo que el paso 2 utilizó como entrada.
Por lo tanto, el paso 3 produce un error. Por ejemplo, si el paso 3 intenta copiar el example-file.txt
actualizado, obtendrá el siguiente error:
{ "type": "StepErrored", "details": { "errorType": "NOT_FOUND", "errorMessage": "ETag constraint not met (Service: null; Status Code: 412; Error Code: null; Request ID: null; S3 Extended Request ID: null; Proxy: null)", "stepType": "COPY", "stepName": "CopyFile" },
Este error se produce porque el paso personalizado modifica toda la etiqueta de entidad (ETag) para example-file.txt
de forma que no coincide con el archivo original.
nota
Este comportamiento no se produce si utiliza Amazon EFS porque Amazon EFS no utiliza etiquetas de entidad para identificar los archivos.
Ejemplos de eventos enviados AWS Lambda al cargar un archivo
Los siguientes ejemplos muestran los eventos que se envían AWS Lambda cuando se completa la carga de un archivo. Un ejemplo utiliza un servidor de Transfer Family en el que el dominio está configurado con Amazon S3. El otro ejemplo utiliza un servidor de Transfer Family donde el dominio usa Amazon EFS.
Ejemplo de función de Lambda para un paso de flujo de trabajo personalizado
La siguiente función Lambda extrae la información relativa al estado de la ejecución y, a continuación, llama a la operación de la SendWorkflowStepStateAPI para devolver el estado al flujo de trabajo del pasoSUCCESS
, ya sea una o varias. FAILURE
Antes de que su función llame a la operación de la API SendWorkflowStepState
, puede configurar Lambda para que realice una acción en función de la lógica del flujo de trabajo.
import json import boto3 transfer = boto3.client('transfer') def lambda_handler(event, context): print(json.dumps(event)) # call the SendWorkflowStepState API to notify the workflow about the step's SUCCESS or FAILURE status response = transfer.send_workflow_step_state( WorkflowId=event['serviceMetadata']['executionDetails']['workflowId'], ExecutionId=event['serviceMetadata']['executionDetails']['executionId'], Token=event['token'], Status='SUCCESS|FAILURE' ) print(json.dumps(response)) return { 'statusCode': 200, 'body': json.dumps(response) }
Permisos de IAM para un paso personalizado
Para permitir que un paso que llame a una Lambda se realice correctamente, asegúrese de que el rol de ejecución de su flujo de trabajo contenga los siguientes permisos.
{ "Sid": "Custom", "Effect": "Allow", "Action": [ "lambda:InvokeFunction" ], "Resource": [ "arn:aws:lambda:
region
:account-id
:function:function-name
" ] }