カスタムのファイル処理ステップを使用してください。 - AWS Transfer Family
複数の Lambda 関数を続けて使用するカスタム処理後のファイルへのアクセスファイルのアップロード AWS Lambda 時に に送信されるイベントの例カスタムワークフローステップの Lambda 関数の例IAM カスタムステップのアクセス許可

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

カスタムのファイル処理ステップを使用してください。

カスタムファイル処理ステップを使用することで、 AWS Lambdaを使用して独自のファイル処理ロジックを実現できます。ファイルが到着すると、Transfer Family サーバーは、ファイルの暗号化、マルウェアのスキャン、不正なファイルタイプのチェックなど、カスタムファイル処理ロジックを含む Lambda 関数を呼び出します。次の例では、ターゲット AWS Lambda 関数が前のステップの出力ファイルを処理するのに使われています。

注記

サンプルの Lambda 関数については、「カスタムワークフローステップの Lambda 関数の例」を参照してください。イベント (Lambda に渡されるファイルの場所を含む) の例については、ファイルのアップロード AWS Lambda 時に に送信されるイベントの例を参照してください。

カスタムワークフローステップでは、SendWorkflowStepStateAPIオペレーションを呼び出すように Lambda 関数を設定する必要があります。 は、ステップが完了したことをワークフロー実行に成功ステータスまたは失敗ステータスでSendWorkflowStepState通知します。SendWorkflowStepState API オペレーションのステータスは、Lambda 関数の結果に基づいて、例外ハンドラーステップまたは線形シーケンスの公称ステップを呼び出します。

Lambda 関数が失敗またはタイムアウトすると、ステップは失敗し、 CloudWatch ログStepErroredに表示されます。Lambda 関数がノミナルステップの一部であり、その関数がSendWorkflowStepStateにStatus="FAILURE"で応答するかタイムアウトした場合、フローは例外ハンドラステップに進みます。この場合、ワークフローは残りの (もしあれば) 名目上のステップを実行し続けません。詳細については、「ワークフローの例外処理」を参照してください。

SendWorkflowStepState API オペレーションを呼び出すときは、次のパラメータを送信する必要があります。

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

Lambda 関数実行時に渡される入力イベントから、ExecutionId、Token、WorkflowId を抽出することができます（以下のセクションに例を示す）。Status 値は SUCCESS または FAILURE のいずれかです。

Lambda 関数から SendWorkflowStepState API オペレーションを呼び出すには、Managed Workflows が導入された後に発行された のバージョン 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"
    },

このエラーは、カスタムステップが のエンティティタグ (ETag) を変更example-file.txtして、元のファイルと一致しないために発生します。

注記

Amazon はエンティティタグを使用してファイルを識別しないEFSため、Amazon を使用している場合EFS、この動作は発生しません。

ファイルのアップロード AWS Lambda 時に に送信されるイベントの例

次の例は、ファイルのアップロードが完了した AWS Lambda ときに に送信されるイベントを示しています。ある例では、ドメインが Amazon S3 で構成されている Transfer Family サーバーを使用しています。もう 1 つの例では、ドメインが Amazon を使用する Transfer Family サーバーを使用しています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"
    }
}

カスタムワークフローステップの Lambda 関数の例

次の Lambda 関数は、実行ステータスに関する情報を抽出し、 SendWorkflowStepStateAPIオペレーションを呼び出して、 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"
            ]
        }