Verwenden von Mocked-Service-Integrationen - AWS Step Functions

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 von Mocked-Service-Integrationen

In Step Functions Local können Sie die Ausführungspfade Ihrer Zustandsautomaten testen, ohne tatsächlich integrierte Services aufzurufen, indem Sie simulierte Serviceintegrationen verwenden. Um Ihre Zustandsautomaten für die Verwendung von simulierten Serviceintegrationen zu konfigurieren, erstellen Sie eine Pseudokonfigurationsdatei. In dieser Datei definieren Sie die gewünschte Ausgabe Ihrer Serviceintegrationen als simulierte Antworten und die Ausführungen, die Ihre simulierten Antworten verwenden, um einen Ausführungspfad als Testfälle zu simulieren.

Durch die Bereitstellung der Mock-Konfigurationsdatei für Step Functions Local können Sie Serviceintegrationsaufrufe testen, indem Sie Zustandsmaschinen ausführen, die die in den Testfällen angegebenen Mocked-Antworten verwenden, anstatt tatsächliche Serviceintegrationsaufrufe zu tätigen.

Anmerkung

Wenn Sie keine simulierten Serviceintegrationsantworten in der Mock-Konfigurationsdatei angeben, ruft Step Functions Local die AWS Serviceintegration mit dem Endpunkt auf, den Sie bei der Einrichtung von Step Functions Local konfiguriert haben. Informationen zum Konfigurieren von Endpunkten für Step Functions Local finden Sie unter Konfigurationsoptionen für Step Functions lokal einrichten.

Wichtige Konzepte in diesem Thema

In diesem Thema werden mehrere Konzepte verwendet, die in der folgenden Liste definiert sind:

  • Mocked Service Integrations – Bezieht sich auf Aufgabenstatus, die so konfiguriert sind, dass sie simulierte Antworten verwenden, anstatt tatsächliche Serviceaufrufe durchzuführen.

  • Pseudoantworten – Bezieht sich auf Pseudodaten, für deren Verwendung Aufgabenstatus konfiguriert werden können.

  • Testfälle – Bezieht sich auf Zustandsautomatenausführungen, die für die Verwendung von simulierten Serviceintegrationen konfiguriert sind.

  • Mock-Konfigurationsdatei – Bezieht sich auf die Mock-Konfigurationsdatei, die JSON enthält, das simulierte Serviceintegrationen, simulierte Antworten und Testfälle definiert.

Schritt 1: Angeben von Mocked-Service-Integrationen in einer Mock-Konfigurationsdatei

Sie können Step Functions AWS SDK und optimierte Serviceintegrationen mit Step Functions Local testen. Die folgende Abbildung zeigt den Zustandsautomaten, der auf der Registerkarte Definition des Zustandsautomaten definiert ist:

Beispiel für eine simulierte Serviceintegration.

Dazu müssen Sie eine Mock-Konfigurationsdatei erstellen, die Abschnitte enthält, wie in definiertEinführung in die Struktur der Mock-Konfiguration.

  1. Erstellen Sie eine Datei mit dem Namen MockConfigFile.json, um Tests mit simulierten Serviceintegrationen zu konfigurieren.

    Das folgende Beispiel zeigt eine Mock-Konfigurationsdatei, die auf einen Zustandsautomaten mit zwei definierten Zuständen namens LambdaState und verweistSQSState.

    Mock configuration file example

    Im Folgenden finden Sie ein Beispiel für eine Mock-Konfigurationsdatei, die zeigt, wie Antworten aus dem Aufrufen einer Lambda-Funktion und dem Senden einer Nachricht an Amazon SQS nachgeahmt werden. In diesem Beispiel enthält der LambdaSQSIntegration Zustandsautomat drei Testfälle mit dem Namen HappyPath, und RetryPath, HybridPath die die Task Zustände mit dem Namen LambdaState und nachahmenSQSState. Diese Zustände verwenden die MockedLambdaSuccess, MockedSQSSuccessund MockedLambdaRetry simulierten Service-Antworten. Diese simulierten Service-Antworten sind im -MockedResponsesAbschnitt der -Datei definiert.

    { "StateMachines":{ "LambdaSQSIntegration":{ "TestCases":{ "HappyPath":{ "LambdaState":"MockedLambdaSuccess", "SQSState":"MockedSQSSuccess" }, "RetryPath":{ "LambdaState":"MockedLambdaRetry", "SQSState":"MockedSQSSuccess" }, "HybridPath":{ "LambdaState":"MockedLambdaSuccess" } } } }, "MockedResponses":{ "MockedLambdaSuccess":{ "0":{ "Return":{ "StatusCode":200, "Payload":{ "StatusCode":200, "body":"Hello from Lambda!" } } } }, "LambdaMockedResourceNotReady":{ "0":{ "Throw":{ "Error":"Lambda.ResourceNotReadyException", "Cause":"Lambda resource is not ready." } } }, "MockedSQSSuccess":{ "0":{ "Return":{ "MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51", "MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51" } } }, "MockedLambdaRetry":{ "0":{ "Throw":{ "Error":"Lambda.ResourceNotReadyException", "Cause":"Lambda resource is not ready." } }, "1-2":{ "Throw":{ "Error":"Lambda.TimeoutException", "Cause":"Lambda timed out." } }, "3":{ "Return":{ "StatusCode":200, "Payload":{ "StatusCode":200, "body":"Hello from Lambda!" } } } } } }
    State machine definition

    Im Folgenden finden Sie ein Beispiel für eine Zustandsautomatendefinition namens LambdaSQSIntegration, die zwei Status von Serviceintegrationsaufgaben mit dem Namen LambdaState und definiertSQSState. LambdaState enthält eine Wiederholungsrichtlinie, die auf basiertStates.ALL.

    { "Comment":"This state machine is called: LambdaSQSIntegration", "StartAt":"LambdaState", "States":{ "LambdaState":{ "Type":"Task", "Resource":"arn:aws:states:::lambda:invoke", "Parameters":{ "Payload.$":"$", "FunctionName":"HelloWorldFunction" }, "Retry":[ { "ErrorEquals":[ "States.ALL" ], "IntervalSeconds":2, "MaxAttempts":3, "BackoffRate":2 } ], "Next":"SQSState" }, "SQSState":{ "Type":"Task", "Resource":"arn:aws:states:::sqs:sendMessage", "Parameters":{ "QueueUrl":"https://sqs.us-east-1.amazonaws.com/123456789012/myQueue", "MessageBody.$":"$" }, "End": true } } }

    Sie können die Definition des LambdaSQSIntegration Zustandsautomaten, auf die in der Mock-Konfigurationsdatei verwiesen wird, mit einem der folgenden Testfälle ausführen:

    • HappyPath – Dieser Test ahmt die Ausgabe von LambdaState und SQSState mit MockedLambdaSuccess MockedSQSSuccess bzw. nach.

      • Der LambdaState gibt den folgenden Wert zurück:

        "0":{ "Return":{ "StatusCode":200, "Payload":{ "StatusCode":200, "body":"Hello from Lambda!" } } }
      • Der SQSState gibt den folgenden Wert zurück:

        "0":{ "Return":{ "MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51", "MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51" } }
    • RetryPath – Dieser Test ahmt die Ausgabe von LambdaState und SQSState mit MockedLambdaRetry MockedSQSSuccess bzw. nach. Darüber hinaus LambdaState ist so konfiguriert, dass vier Wiederholungsversuche durchgeführt werden. Die simulierten Antworten für diese Versuche werden im MockedLambdaRetry Status definiert und indiziert.

      • Der erste Versuch endet mit einem Aufgabenfehler, der eine Ursache und eine Fehlermeldung enthält, wie im folgenden Beispiel gezeigt:

        "0":{ "Throw": { "Error": "Lambda.ResourceNotReadyException", "Cause": "Lambda resource is not ready." } }
      • Die ersten und zweiten Wiederholungsversuche enden mit einem Aufgabenfehler, der eine Ursache und eine Fehlermeldung enthält, wie im folgenden Beispiel gezeigt:

        "1-2":{ "Throw": { "Error": "Lambda.TimeoutException", "Cause": "Lambda timed out." } }
      • Der dritte Wiederholungsversuch endet mit einem Aufgabenerfolg, der den Abschnitt Statusergebnis aus Nutzlast in der simulierten Lambda-Antwort enthält.

        "3":{ "Return": { "StatusCode": 200, "Payload": { "StatusCode": 200, "body": "Hello from Lambda!" } } }
        Anmerkung
        • Bei Zuständen mit einer Wiederholungsrichtlinie erschöpft Step Functions Local die in der Richtlinie festgelegten Wiederholungsversuche, bis es eine Erfolgsantwort erhält. Das bedeutet, dass Sie Mocks für Wiederholungsversuche mit aufeinanderfolgenden Versuchszahlen kennzeichnen müssen und alle Wiederholungsversuche abdecken sollten, bevor Sie eine Erfolgsantwort zurückgeben.

        • Wenn Sie keine simulierte Antwort für einen bestimmten Wiederholungsversuch angeben, z. B. „3“ wiederholen, schlägt die Ausführung des Zustandsautomaten fehl.

    • HybridPath – Dieser Test ahmt die Ausgabe von nachLambdaState. Nachdem erfolgreich LambdaState ausgeführt wurde und simulierte Daten als Antwort empfängt, SQSState führt einen tatsächlichen Serviceaufruf der in der Produktion angegebenen Ressource durch.

    Informationen zum Starten von Testausführungen mit simulierten Serviceintegrationen finden Sie unter Schritt 3: Ausführen von Mocked-Service-Integrationstests.

  2. Stellen Sie sicher, dass die Struktur der simulierten Antworten der Struktur der tatsächlichen Serviceantworten entspricht, die Sie erhalten, wenn Sie integrierte Serviceaufrufe tätigen. Informationen zu den Strukturanforderungen für simulierte Antworten finden Sie unter Konfiguration von simulierten Serviceintegrationen.

    In der vorherigen Beispiel-Mock-Konfigurationsdatei MockedLambdaRetry entsprechen die in definierten MockedLambdaSuccess und simulierten Antworten der Struktur der tatsächlichen Antworten, die vom Aufruf von zurückgegeben werdenHelloFromLambda.

    Wichtig

    AWS -Serviceantworten können in der Struktur zwischen verschiedenen Services variieren. Step Functions Local überprüft nicht, ob simulierte Antwortstrukturen den tatsächlichen Service-Antwortstrukturen entsprechen. Sie müssen sicherstellen, dass Ihre simulierten Antworten den tatsächlichen Antworten entsprechen, bevor Sie sie testen. Um die Struktur der Service-Antworten zu überprüfen, können Sie entweder die tatsächlichen Service-Aufrufe mit Step Functions durchführen oder die Dokumentation für diese Services anzeigen.

Schritt 2: Bereitstellen der Mock-Konfigurationsdatei für Step Functions Local

Sie können die Mock-Konfigurationsdatei auf eine der folgenden Arten für Step Functions Local bereitstellen:

Docker
Anmerkung

Wenn Sie die Docker-Version von Step Functions Local verwenden, können Sie die Mock-Konfigurationsdatei nur mit einer Umgebungsvariablen bereitstellen. Darüber hinaus müssen Sie die Mock-Konfigurationsdatei beim ersten Serverstart auf dem lokalen Container von Step Functions mounten.

Mounten Sie die Mock-Konfigurationsdatei in einem beliebigen Verzeichnis im lokalen Container von Step Functions. Legen Sie dann eine Umgebungsvariable mit dem Namen festSFN_MOCK_CONFIG, die den Pfad zur Mock-Konfigurationsdatei im Container enthält. Mit dieser Methode kann die Mock-Konfigurationsdatei benannt werden, solange die Umgebungsvariable den Dateipfad und den Namen enthält.

Der folgende Befehl zeigt das Format zum Starten des Docker-Images.

docker run -p 8083:8083 --mount type=bind,readonly,source={absolute path to mock config file},destination=/home/StepFunctionsLocal/MockConfigFile.json -e SFN_MOCK_CONFIG="/home/StepFunctionsLocal/MockConfigFile.json" amazon/aws-stepfunctions-local

Im folgenden Beispiel wird der Befehl verwendet, um das Docker-Image zu starten.

docker run -p 8083:8083 --mount type=bind,readonly,source=/Users/admin/Desktop/workplace/MockConfigFile.json,destination=/home/StepFunctionsLocal/MockConfigFile.json -e SFN_MOCK_CONFIG="/home/StepFunctionsLocal/MockConfigFile.json" amazon/aws-stepfunctions-local
JAR File

Verwenden Sie eine der folgenden Möglichkeiten, die Mock-Konfigurationsdatei für Step Functions Local bereitzustellen:

  • Platzieren Sie die Mock-Konfigurationsdatei im selben Verzeichnis wie Step FunctionsLocal.jar. Wenn Sie diese Methode verwenden, müssen Sie die Mock-Konfigurationsdatei benennenMockConfigFile.json.

  • Legen Sie in der Sitzung mit Step Functions Local eine Umgebungsvariable mit dem Namen SFN_MOCK_CONFIGauf den vollständigen Pfad der Mock-Konfigurationsdatei fest. Mit dieser Methode kann die Mock-Konfigurationsdatei benannt werden, solange die Umgebungsvariable ihren Dateipfad und Namen enthält. Im folgenden Beispiel ist die SFN_MOCK_CONFIG Variable so eingestellt, dass sie auf eine Mock-Konfigurationsdatei namens verweistEnvSpecifiedMockConfig.json, die sich im /home/workspace Verzeichnis befindet.

    export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
Anmerkung
  • Wenn Sie die Umgebungsvariable nicht SFN_MOCK_CONFIG für Step Functions Local bereitstellen, versucht sie standardmäßig, eine Mock-Konfigurationsdatei mit dem Namen MockConfigFile.json in dem Verzeichnis zu lesen, aus dem Sie Step Functions Local gestartet haben.

  • Wenn Sie die Mock-Konfigurationsdatei im selben Verzeichnis wie platzieren Step FunctionsLocal.jar und die Umgebungsvariable festlegenSFN_MOCK_CONFIG, liest Step Functions Local die durch die Umgebungsvariable angegebene Datei.

Schritt 3: Ausführen von Mocked-Service-Integrationstests

Nachdem Sie eine Mock-Konfigurationsdatei für Step Functions Local erstellt und bereitgestellt haben, führen Sie den in der Mock-Konfigurationsdatei konfigurierten Zustandsautomaten mithilfe von Mocked-Service-Integrationen aus. Überprüfen Sie dann die Ausführungsergebnisse mit einer API-Aktion.

  1. Erstellen Sie einen Zustandsautomaten basierend auf der zuvor erwähnten Definition in der Mock-Konfigurationsdatei .

    aws stepfunctions create-state-machine \ --endpoint http://localhost:8083 \ --definition "{\"Comment\":\"Thisstatemachineiscalled:LambdaSQSIntegration\",\"StartAt\":\"LambdaState\",\"States\":{\"LambdaState\":{\"Type\":\"Task\",\"Resource\":\"arn:aws:states:::lambda:invoke\",\"Parameters\":{\"Payload.$\":\"$\",\"FunctionName\":\"arn:aws:lambda:us-east-1:123456789012:function:HelloWorldFunction\"},\"Retry\":[{\"ErrorEquals\":[\"States.ALL\"],\"IntervalSeconds\":2,\"MaxAttempts\":3,\"BackoffRate\":2}],\"Next\":\"SQSState\"},\"SQSState\":{\"Type\":\"Task\",\"Resource\":\"arn:aws:states:::sqs:sendMessage\",\"Parameters\":{\"QueueUrl\":\"https://sqs.us-east-1.amazonaws.com/123456789012/myQueue\",\"MessageBody.$\":\"$\"},\"End\":true}}}" \ --name "LambdaSQSIntegration" --role-arn "arn:aws:iam::123456789012:role/service-role/LambdaSQSIntegration"
  2. Führen Sie den Zustandsautomaten mit simulierten Serviceintegrationen aus.

    Um die Mock-Konfigurationsdatei zu verwenden, führen Sie einen StartExecution API-Aufruf auf einem Zustandsautomaten durch, der in der Mock-Konfigurationsdatei konfiguriert ist. Hängen Sie dazu das Suffix #test_namean den von verwendeten Zustandsautomaten-ARN anStartExecution. test_name ist ein Testfall, der für den Zustandsautomaten in derselben Mock-Konfigurationsdatei konfiguriert ist.

    Der folgende Befehl ist ein Beispiel, das den LambdaSQSIntegration Zustandsautomaten und die Mock-Konfiguration verwendet. In diesem Beispiel wird der LambdaSQSIntegration Zustandsautomat mit dem in definierten HappyPath Test ausgeführtSchritt 1: Angeben von Mocked-Service-Integrationen in einer Mock-Konfigurationsdatei. Der HappyPath Test enthält die Konfiguration für die Ausführung, um simulierte Serviceintegrationsaufrufe zu verarbeiten, die LambdaState und -SQSStateZustände mit den MockedSQSSuccess simulierten Serviceantworten MockedLambdaSuccess und durchführen.

    aws stepfunctions start-execution \ --endpoint http://localhost:8083 \ --name executionWithHappyPathMockedServices \ --state-machine arn:aws:states:us-east-1:123456789012:stateMachine:LambdaSQSIntegration#HappyPath
  3. Zeigen Sie die Ausführungsantwort des Zustandsautomaten an.

    Die Antwort auf den Aufruf StartExecution mit einem simulierten Serviceintegrationstest entspricht der Antwort auf StartExecution den normalen Aufruf von , der den Ausführungs-ARN und das Startdatum zurückgibt.

    Im Folgenden finden Sie eine Beispielantwort auf den Aufruf StartExecution von mit dem simulierten Serviceintegrationstest:

    { "startDate":"2022-01-28T15:03:16.981000-05:00", "executionArn":"arn:aws:states:us-east-1:123456789012:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices" }
  4. Überprüfen Sie die Ergebnisse der AusführungListExecutions, indem Sie einen DescribeExecution-, - oder GetExecutionHistory-API-Aufruf durchführen.

    aws stepfunctions get-execution-history \ --endpoint http://localhost:8083 \ --execution-arn arn:aws:states:us-east-1:123456789012:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices

    Das folgende Beispiel zeigt Teile einer Antwort auf den Aufruf GetExecutionHistory mit dem Ausführungs-ARN aus der Beispielantwort in Schritt 2. In diesem Beispiel SQSState ist die Ausgabe von LambdaState und die Mock-Daten, die in MockedLambdaSuccess und MockedSQSSuccess in der Mock-Konfigurationsdatei definiert sind. Darüber hinaus werden die simulierten Daten auf die gleiche Weise verwendet, wie Daten verwendet werden, die durch die Durchführung tatsächlicher Serviceintegrationsaufrufe zurückgegeben werden. Außerdem LambdaState wird in diesem Beispiel die Ausgabe von SQSState als Eingabe an übergeben.

    { "events": [ ... { "timestamp": "2021-12-02T19:39:48.988000+00:00", "type": "TaskStateEntered", "id": 2, "previousEventId": 0, "stateEnteredEventDetails": { "name": "LambdaState", "input": "{}", "inputDetails": { "truncated": false } } }, ... { "timestamp": "2021-11-25T23:39:10.587000+00:00", "type": "LambdaFunctionSucceeded", "id": 5, "previousEventId": 4, "lambdaFunctionSucceededEventDetails": { "output": "{\"statusCode\":200,\"body\":\"\\\"Hello from Lambda!\\\"\"}", "outputDetails": { "truncated": false } } }, ... "timestamp": "2021-12-02T19:39:49.464000+00:00", "type": "TaskStateEntered", "id": 7, "previousEventId": 6, "stateEnteredEventDetails": { "name": "SQSState", "input": "{\"statusCode\":200,\"body\":\"\\\"Hello from Lambda!\\\"\"}", "inputDetails": { "truncated": false } } }, ... { "timestamp": "2021-11-25T23:39:10.652000+00:00", "type": "TaskSucceeded", "id": 10, "previousEventId": 9, "taskSucceededEventDetails": { "resourceType": "sqs", "resource": "sendMessage", "output": "{\"MD5OfMessageBody\":\"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51\",\"MessageId\":\"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51\"}", "outputDetails": { "truncated": false } } }, ... ] }