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.
**Anmerkung**
Eine Beispielfunktion für Lambda finden Sie unter [Beispiel für eine Lambda-Funktion für einen benutzerdefinierten Workflow-Schritt](#example-workflow-lambda). Beispiele für Ereignisse (einschließlich des Speicherorts für Dateien, die an das Lambda übergeben werden) finden Sie unter. [Beispiele für Ereignisse, die gesendet wurden an AWS Lambda beim Hochladen einer Datei](#example-workflow-lambdas)
Bei einem benutzerdefinierten Workflow-Schritt müssen Sie die Lambda-Funktion so konfigurieren, dass sie den [ SendWorkflowStepState ](https://docs.aws.amazon.com/transfer/latest/APIReference/API_SendWorkflowStepState.html) API-Vorgang aufruft. `SendWorkflowStepState`benachrichtigt 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](transfer-workflows.md#exception-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 `ExecutionId``Token`, 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 [](doc-history.md#workflows-introduced) 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).
**Anmerkung**
Die `previous.file` Einstellung funktioniert auch anders, wenn Sie nach einem benutzerdefinierten Schritt einen vordefinierten Schritt (Markieren, Kopieren, Entschlüsseln oder Löschen) haben. Wenn der vordefinierte Schritt für die Verwendung der `previous.file` Einstellung konfiguriert ist, verwendet der vordefinierte Schritt dieselbe Eingabedatei, die für den benutzerdefinierten Schritt verwendet wird. Die verarbeitete Datei aus dem benutzerdefinierten Schritt wird nicht an den vordefinierten Schritt übergeben.
## 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.
+ **Schritt 1 ** — Laden Sie eine Datei mit dem Namen hoch`example-file.txt`.
+ **Schritt 2 ** — Rufen Sie eine Lambda-Funktion auf, die sich `example-file.txt` in irgendeiner Weise ändert.
+ **Schritt 3 ** — Versuchen Sie, die aktualisierte Version von weiterzuverarbeiten. `example-file.txt`
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 kopieren`example-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.
**Anmerkung**
Dieses Verhalten tritt nicht auf, wenn Sie Amazon EFS verwenden, da Amazon EFS keine Entitäts-Tags zur Identifizierung von Dateien verwendet.
## 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 ](https://docs.aws.amazon.com/transfer/latest/APIReference/API_SendWorkflowStepState.html) 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}}"
]
}
```