Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwenden Sie benutzerdefinierte Schritte zur Dateiverarbeitung

Mithilfe eines benutzerdefinierten Dateiverarbeitungsschritts können Sie Ihre eigene Dateiverarbeitungslogik verwenden. AWS Lambda Beim Eintreffen einer Datei ruft ein Transfer Family Family-Server eine Lambda-Funktion auf, die benutzerdefinierte Dateiverarbeitungslogik enthält, z. B. das Verschlüsseln von Dateien, das Scannen nach Malware oder das Überprüfen auf falsche Dateitypen. Im folgenden Beispiel wird die AWS Lambda Zielfunktion verwendet, um die Ausgabedatei aus dem vorherigen Schritt zu verarbeiten.

Bei einem benutzerdefinierten Workflow-Schritt müssen Sie die Lambda-Funktion so konfigurieren, dass sie den SendWorkflowStepStateAPIVorgang aufruft. SendWorkflowStepStatebenachrichtigt die Workflow-Ausführung darüber, dass der Schritt entweder mit einem Erfolgs- oder einem Fehlerstatus abgeschlossen wurde. Der Status der SendWorkflowStepState API Operation ruft einen Exception-Handler-Schritt oder einen nominalen Schritt in der linearen Sequenz auf, basierend auf dem Ergebnis der Lambda-Funktion.

Wenn die Lambda-Funktion ausfällt oder das Zeitlimit überschritten wird, schlägt der Schritt fehl, und das sehen Sie StepErrored in Ihren CloudWatch Protokollen. Wenn die Lambda-Funktion Teil des nominalen Schritts ist und die Funktion SendWorkflowStepState mit Status="FAILURE" oder Timeout reagiert, wird der Ablauf mit den Exception-Handler-Schritten fortgesetzt. In diesem Fall setzt der Workflow die Ausführung der verbleibenden (falls vorhanden) nominalen Schritte nicht fort. Weitere Details finden Sie unter Ausnahmebehandlung für einen Workflow.

Wenn Sie den SendWorkflowStepState API Vorgang aufrufen, müssen Sie die folgenden Parameter senden:

{
    "ExecutionId": "string",
    "Status": "string",
    "Token": "string",
    "WorkflowId": "string"
}

Sie können das ExecutionIdToken, und WorkflowId aus dem Eingabeereignis extrahieren, das bei der Ausführung der Lambda-Funktion übergeben wird (Beispiele werden in den folgenden Abschnitten gezeigt). Der Status Wert kann entweder oder SUCCESS sein. FAILURE

Um den SendWorkflowStepState API Vorgang von Ihrer Lambda-Funktion aus aufrufen zu können, müssen Sie eine Version von verwenden, AWS SDK die nach der Einführung von Managed Workflows veröffentlicht wurde.

Mehrere Lambda-Funktionen nacheinander verwenden

Wenn Sie mehrere benutzerdefinierte Schritte nacheinander verwenden, funktioniert die Option Dateispeicherort anders als wenn Sie nur einen einzigen benutzerdefinierten Schritt verwenden. Transfer Family unterstützt nicht die Rückgabe der mit Lambda verarbeiteten Datei, um sie als Eingabe für den nächsten Schritt zu verwenden. Wenn Sie also mehrere benutzerdefinierte Schritte haben, die alle für die Verwendung dieser previous.file Option konfiguriert sind, verwenden sie alle denselben Dateispeicherort (den Speicherort der Eingabedatei für den ersten benutzerdefinierten Schritt).

Zugreifen auf eine Datei nach der benutzerdefinierten Verarbeitung

Wenn Sie Amazon S3 als Speicher verwenden und Ihr Workflow einen benutzerdefinierten Schritt umfasst, der Aktionen an der ursprünglich hochgeladenen Datei ausführt, können nachfolgende Schritte nicht auf diese verarbeitete Datei zugreifen. Das heißt, jeder Schritt nach dem benutzerdefinierten Schritt kann nicht auf die aktualisierte Datei aus der Ausgabe des benutzerdefinierten Schritts verweisen.

Nehmen wir zum Beispiel an, dass Sie die folgenden drei Schritte in Ihrem Workflow haben.

Wenn Sie das sourceFileLocation für Schritt 3 so konfigurieren${original.file}, verwendet Schritt 3 den ursprünglichen Speicherort der Datei aus dem Zeitpunkt, zu dem der Server die Datei in Schritt 1 in den Speicher hochgeladen hat. Wenn Sie ${previous.file} für Schritt 3 verwenden, wird in Schritt 3 der Speicherort wiederverwendet, den Schritt 2 als Eingabe verwendet hat.

Daher verursacht Schritt 3 einen Fehler. Wenn in Schritt 3 beispielsweise versucht wird, das Update zu kopierenexample-file.txt, wird die folgende Fehlermeldung angezeigt:

{
    "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"
    },

Dieser Fehler tritt auf, weil der benutzerdefinierte Schritt das Entitäts-Tag (ETag) für example-file.txt so ändert, dass es nicht mit der Originaldatei übereinstimmt.

Beispiele für Ereignisse, an die AWS Lambda beim Hochladen einer Datei gesendet werden

Die folgenden Beispiele zeigen die Ereignisse, an die gesendet werden, AWS Lambda wenn ein Datei-Upload abgeschlossen ist. In einem Beispiel wird ein Transfer Family Family-Server verwendet, auf dem die Domain mit Amazon S3 konfiguriert ist. Das andere Beispiel verwendet einen Transfer Family Family-Server, auf dem die Domain Amazon verwendetEFS.

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

Beispiel für eine Lambda-Funktion für einen benutzerdefinierten Workflow-Schritt

Die folgende Lambda-Funktion extrahiert die Informationen zum Ausführungsstatus und ruft dann den SendWorkflowStepStateAPIVorgang auf, um den Status für den Schritt an den Workflow zurückzugeben — SUCCESS entweder oder. FAILURE Bevor Ihre Funktion den SendWorkflowStepState API Vorgang aufruft, können Sie Lambda so konfigurieren, dass eine Aktion auf der Grundlage Ihrer Workflow-Logik ausgeführt wird.

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)
    }

IAMBerechtigungen für einen benutzerdefinierten Schritt

Damit ein Schritt, der ein Lambda aufruft, erfolgreich sein kann, stellen Sie sicher, dass die Ausführungsrolle für Ihren Workflow die folgenden Berechtigungen enthält.

{
            "Sid": "Custom",
            "Effect": "Allow",
            "Action": [
                "lambda:InvokeFunction"
            ],
            "Resource": [
                "arn:aws:lambda:region:account-id:function:function-name"
            ]
        }