翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# カスタムのファイル処理ステップを使用してください。
カスタムファイル処理ステップを使用することで、 AWS Lambdaを使用して独自のファイル処理ロジックを実現できます。ファイルが到着すると、Transfer Family サーバーは、ファイルの暗号化、マルウェアのスキャン、不正なファイルタイプのチェックなど、カスタムファイル処理ロジックを含む Lambda 関数を呼び出します。次の例では、ターゲット AWS Lambda 関数が前のステップの出力ファイルを処理するのに使われています。
**注記**
サンプルの Lambda 関数については、「[カスタムワークフローステップの Lambda 関数の例](#example-workflow-lambda)」を参照してください。イベント (Lambda に渡されるファイルの場所を含む) の例については、[ファイルのアップロード AWS Lambda 時に に送信されるイベントの例](#example-workflow-lambdas)を参照してください。
カスタムワークフローステップでは、「[SendWorkflowStepState](https://docs.aws.amazon.com/transfer/latest/APIReference/API_SendWorkflowStepState.html)」API オペレーションを呼び出すように Lambda 関数を構成する必要があります。`SendWorkflowStepState` は、ステップの完了を成功か失敗のどちらかのステータスでワークフロー実行に通知します。`SendWorkflowStepState`API オペレーションのステータスにより、Lambda 関数の結果に基づいて、例外ハンドラーステップまたは線形シーケンスのノミナルステップが呼び出されます。
Lambda 関数が失敗するかタイムアウトになると、ステップが失敗し、CloudWatch Logs `StepErrored` が表示されます。Lambda 関数がノミナルステップの一部であり、その関数が`SendWorkflowStepState`に`Status="FAILURE"`で応答するかタイムアウトした場合、フローは例外ハンドラステップに進みます。この場合、ワークフローは残りの (もしあれば) 名目上のステップを実行し続けません。詳細については、[ワークフローの例外処理](transfer-workflows.md#exception-workflow)を参照してください。
`SendWorkflowStepState` API オペレーションを呼び出す際には、以下のパラメーターを送信する必要があります。
```
{
"ExecutionId": "string",
"Status": "string",
"Token": "string",
"WorkflowId": "string"
}
```
Lambda 関数実行時に渡される入力イベントから、`ExecutionId`、`Token`、`WorkflowId` を抽出することができます（以下のセクションに例を示す）。`Status` 値は `SUCCESS` または `FAILURE` のいずれかです。
Lambda 関数から `SendWorkflowStepState` API オペレーションを呼び出すには、[マネージドワークフローの導入](doc-history.md#workflows-introduced)後に発行された AWS SDK のバージョンを使用する必要があります。
## 複数の Lambda 関数を続けて使用する
複数のカスタムステップを次々に使用する場合、**[ファイルロケーション]** オプションは 1 つのカスタムステップのみを使用する場合とは動作が異なります。Transfer Family は、Lambda で処理されたファイルを戻して次のステップの入力として使用することをサポートしていません。そのため、`previous.file`オプションを使用するように構成された複数のカスタム・ステップがある場合、それらはすべて同じファイルの場所（最初のカスタム・ステップの入力ファイルの場所）を使用します。
**注記**
カスタムステップの後に定義済みのステップ (タグ付け、コピー、復号化、または削除) がある場合も、`previous.file`設定の動作は異なります。定義済みステップが`previous.file`設定を使用するように構成されている場合、定義済みステップはカスタム・ステップで使用されるのと同じ入力ファイルを使用します。カスタムステップで処理されたファイルは、定義済みのステップには渡されません。
## カスタム処理後のファイルへのアクセス
Amazon S3 をストレージとして使用していて、ワークフローに最初にアップロードされたファイルに対してアクションを実行するカスタムステップが含まれている場合、以降のステップでは処理されたファイルにアクセスできません。つまり、カスタムステップの後のどのステップも、カスタムステップの出力から更新されたファイルを参照することはできません。
例えば、ワークフローに次の 3 つがあるとします。
+ **ステップ 1** — `example-file.txt` という名前のファイルをアップロードします。
+ **ステップ 2** — `example-file.txt`を何らかの方法で変更する Lambda 関数を呼び出します。
+ **ステップ 3** — 更新されたバージョンの`example-file.txt`に対して、さらなる処理を試みます。
ステップ 3 の`sourceFileLocation`を`${original.file}`として設定した場合、ステップ 3 では、でサーバがステップ 1 ファイルをストレージにアップロードしたときの元のファイルロケーションが使用されます。ステップ 3 で`${previous.file}`を使用している場合、ステップ 3 はステップ 2 が入力として使用したファイルの場所を再利用します。
そのため、ステップ 3 ではエラーが発生します。例えば、ステップ 3 で更新された`example-file.txt`をコピーしようとすると、以下のエラーが発生します。
```
{
"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"
},
```
このエラーは、カスタム・ステップで`example-file.txt`用のエンティティ・タグ （ETag） が変更され、元のファイルと一致しなくなるために発生します。
**注記**
Amazon EFS ではファイルの識別にエンティティタグを使用しないため、Amazon EFS を使用している場合はこの動作は発生しません。
## ファイルのアップロード AWS Lambda 時に に送信されるイベントの例
次の例は、ファイルのアップロードが完了した AWS Lambda ときに に送信されるイベントを示しています。ある例では、ドメインが Amazon S3 で構成されている Transfer Family サーバーを使用しています。もう 1 つは Transfer Family サーバーでドメインで 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": "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"
}
}
```
------
## カスタムワークフローステップの Lambda 関数の例
以下の Lambda 関数は、実行ステータスに関する情報を抽出し、「[SendWorkflowStepState](https://docs.aws.amazon.com/transfer/latest/APIReference/API_SendWorkflowStepState.html)」API オペレーションを呼び出して、ステップ（`SUCCESS` または `FAILURE`）のステータスをワークフローに返します。関数が`SendWorkflowStepState` API オペレーションを呼び出す前に、ワークフローロジックに基づいたアクションを取るように Lambda を設定できます。
```
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 権限
Lambda を呼び出すステップを成功させるには、ワークフローの実行ロールに次の権限が含まれていることを確認してください。
```
{
"Sid": "Custom",
"Effect": "Allow",
"Action": [
"lambda:InvokeFunction"
],
"Resource": [
"arn:aws:lambda:{{region}}:{{account-id}}:function:{{function-name}}"
]
}
```