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 Bei der Ankunft der Datei ruft ein Transfer Family-Server eine Lambda-Funktion auf, die eine 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 SendWorkflowStepState API-Vorgang aufruft. SendWorkflowStepStatebenachrichtigt die Workflow-Ausführung darüber, dass der Schritt entweder mit dem Status „Erfolg“ oder „Fehler“ abgeschlossen wurde. Der Status des SendWorkflowStepState API-Vorgangs 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 fehlschlägt oder eine Zeitüberschreitung eintritt, schlägt der Schritt fehl, was StepErrored in Ihren Protokollen angezeigt wird. CloudWatch Wenn die Lambda-Funktion Teil des nominalen Schritts ist und die Funktion SendWorkflowStepState mit einem Timeout Status="FAILURE" oder einem Timeout darauf reagiert, wird der Ablauf mit den Schritten zur Ausnahmebehandlung fortgesetzt. In diesem Fall führt der Workflow die verbleibenden (falls vorhanden) nominalen Schritte nicht weiter aus. 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 finden Sie in den folgenden Abschnitten). 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 des AWS SDK verwenden, die nach der Einführung verwalteter Workflows veröffentlicht wurde.

Verwenden Sie mehrere Lambda-Funktionen nacheinander

Wenn Sie mehrere benutzerdefinierte Schritte nacheinander verwenden, funktioniert die Option Dateispeicherort anders als wenn Sie nur einen einzelnen benutzerdefinierten Schritt verwenden. Transfer Family unterstützt nicht das Zurückgeben der Lambda-processed Datei zur Verwendung als Eingabe für den nächsten Schritt. Wenn du also mehrere benutzerdefinierte Schritte konfiguriert hast, die alle für die Verwendung der 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, Ihr Arbeitsablauf umfasst die folgenden drei Schritte.

Wenn Sie das sourceFileLocation für Schritt 3 so konfigurieren${original.file}, verwendet Schritt 3 den ursprünglichen Dateispeicherort, an dem der Server die Datei in Schritt 1 in den Speicher hochgeladen hat. Wenn Sie es ${previous.file} für Schritt 3 verwenden, verwendet Schritt 3 den Dateispeicherort, 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 im benutzerdefinierten Schritt das Entitäts-Tag (ETag) example-file.txt so geändert wird, dass es nicht mit der Originaldatei übereinstimmt.

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

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-Server verwendet, auf dem die Domain mit Amazon S3 konfiguriert ist. Das andere Beispiel verwendet einen Transfer Family-Server, auf dem die Domain Amazon EFS verwendet.

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": "amzn-s3-demo-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 SendWorkflowStepState API-Vorgang auf, um den Status für den Schritt SUCCESS an den Workflow zurückzugeben — entweder oder. FAILURE Bevor Ihre Funktion den SendWorkflowStepState API-Vorgang aufruft, können Sie Lambda so konfigurieren, dass es eine Aktion ausführt, die auf Ihrer Workflow-Logik basiert.

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

IAM-Berechtigungen für einen benutzerdefinierten Schritt

Damit ein Schritt, der ein Lambda aufruft, erfolgreich ist, 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"
    ]
}