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.

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. SendWorkflowStepStatenotifica 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.

Custom step that uses an Amazon S3 domain

{
    "token": "MzI0Nzc4ZDktMGRmMi00MjFhLTgxMjUtYWZmZmRmODNkYjc0",
    "serviceMetadata": {
        "executionDetails": {
            "workflowId": "w-1234567890example",
            "executionId": "abcd1234-aa11-bb22-cc33-abcdef123456"
        },
        "transferDetails": {
            "sessionId": "36688ff5d2deda8c",
            "userName": "myuser",
            "serverId": "s-example1234567890"
        }
    },
    "fileLocation": {
        "domain": "S3",
        "bucket": "DOC-EXAMPLE-BUCKET",
        "key": "path/to/mykey",
        "eTag": "d8e8fca2dc0f896fd7cb4cb0031ba249",
        "versionId": null
    }
}

Custom step that uses an Amazon EFS domain

{
    "token": "MTg0N2Y3N2UtNWI5Ny00ZmZlLTk5YTgtZTU3YzViYjllNmZm",
    "serviceMetadata": {
        "executionDetails": {
            "workflowId": "w-1234567890example",
            "executionId": "abcd1234-aa11-bb22-cc33-abcdef123456"
        },
        "transferDetails": {
            "sessionId": "36688ff5d2deda8c",
            "userName": "myuser",
            "serverId": "s-example1234567890"
        }
    },
    "fileLocation": {
        "domain": "EFS",
        "fileSystemId": "fs-1234567",
        "path": "/path/to/myfile"
    }
}

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"
            ]
        }