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 State-Maschinen testen, ohne integrierte Dienste aufzurufen, indem Sie nachgebildete Dienstintegrationen verwenden. Um Ihre State Machines für die Verwendung von simulierten Dienstintegrationen zu konfigurieren, erstellen Sie eine Scheinkonfigurationsdatei. In dieser Datei definieren Sie die gewünschte Ausgabe Ihrer Service-Integrationen als abgebildete Antworten und die Ausführungen, die Ihre simulierten Antworten verwenden, um einen Ausführungspfad zu simulieren, als Testfälle.

Indem Sie Step Functions Local die Mock-Konfigurationsdatei zur Verfügung stellen, können Sie Service-Integrationsaufrufe testen, indem Sie State-Maschinen ausführen, die die in den Testfällen angegebenen simulierten Antworten verwenden, anstatt tatsächliche Dienstintegrationsaufrufe zu tätigen.

Anmerkung

Wenn Sie in der Mock-Konfigurationsdatei keine simulierten Service-Integrationsantworten angeben, ruft Step Functions Local die AWS Dienstintegration mit dem Endpunkt auf, den Sie bei der Einrichtung von Step Functions Local konfiguriert haben. Hinweise zur Konfiguration von Endpunkten für Step Functions Local finden Sie unterKonfigurationsoptionen für Step Functions lokal einrichten.

Die wichtigsten Konzepte zu diesem Thema

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

  • Gefälschte Dienstintegrationen — Bezieht sich auf Aufgabenstatus, die so konfiguriert sind, dass simulierte Antworten verwendet werden, anstatt tatsächliche Serviceaufrufe auszuführen.

  • Gefälschte Antworten — Bezieht sich auf Scheindaten, für deren Verwendung Taskstatus konfiguriert werden kann.

  • Testfälle — Bezieht sich auf State-Machine-Ausführungen, die so konfiguriert sind, dass sie simulierte Dienstintegrationen verwenden.

  • Scheinkonfigurationsdatei — Bezieht sich auf eine Scheinkonfigurationsdatei, die JSON enthält und simulierte Serviceintegrationen, simulierte Antworten und Testfälle definiert.

Schritt 1: Geben Sie Mocked Service-Integrationen in einer Scheinkonfigurationsdatei an

Sie können das Step Functions AWS SDK und optimierte Serviceintegrationen mit Step Functions Local testen. Die folgende Abbildung zeigt die State-Maschine, die auf der Registerkarte State Machine Definition definiert ist:


        Beispiel für eine verspottete Serviceintegration.

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

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

    Das folgende Beispiel zeigt eine Scheinkonfigurationsdatei, die auf eine State-Maschine mit zwei definierten Zuständen namens LambdaState und SQSState verweist.

    Mock configuration file example

    Im Folgenden finden Sie ein Beispiel für eine Mock-Konfigurationsdatei, die zeigt, wie Sie Antworten simulieren können, die beim Aufrufen einer Lambda-Funktion und dem Senden einer Nachricht an Amazon SQS entstehen. In diesem Beispiel enthält die LambdaSQSIntegrationState-Maschine drei Testfälle mit dem Namen HappyPathRetryPath, und HybridPath die die Task Zustände mit dem Namen LambdaState und simulierenSQSState. Diese Staaten verwenden dieMockedLambdaSuccess,MockedSQSSuccess, und MockedLambdaRetry verspotteten Service-Antworten. Diese simulierten Service-Antworten sind im MockedResponses Abschnitt 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 State-Machine-Definition namensLambdaSQSIntegration, die zwei Status der Dienstintegrationsaufgabe mit dem Namen LambdaState und definiertSQSState. LambdaStateenthält eine Wiederholungsrichtlinie, die auf basiert. States.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 LambdaSQSIntegration State-Machine-Definition, auf die in der Mock-Konfigurationsdatei verwiesen wird, mithilfe eines der folgenden Testfälle ausführen:

    • HappyPath- Dieser Test verspottet die Ausgabe von LambdaState MockedLambdaSuccess MockedSQSSuccess bzw. die SQSState Verwendung von.

      • Das LambdaState gibt den folgenden Wert zurück:

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

        "0":{ "Return":{ "MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51", "MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51" } }
    • RetryPath- Dieser Test verspottet die Ausgabe von LambdaState MockedLambdaRetry MockedSQSSuccess bzw. die SQSState Verwendung von. Darüber hinaus LambdaState ist es so konfiguriert, dass es vier Wiederholungsversuche durchführt. Die verspotteten Antworten auf diese Versuche werden im Bundesstaat definiert und indexiert. MockedLambdaRetry

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

        "0":{ "Throw": { "Error": "Lambda.ResourceNotReadyException", "Cause": "Lambda resource is not ready." } }
      • Der erste und der zweite Wiederholungsversuch enden mit einem Taskfehler, der eine Ursache und eine Fehlermeldung enthält, wie im folgenden Beispiel dargestellt:

        "1-2":{ "Throw": { "Error": "Lambda.TimeoutException", "Cause": "Lambda timed out." } }
      • Der dritte Wiederholungsversuch endet mit einer erfolgreichen Aufgabe, die das Statusergebnis aus dem Payload-Abschnitt in der simulierten Lambda-Antwort enthält.

        "3":{ "Return": { "StatusCode": 200, "Payload": { "StatusCode": 200, "body": "Hello from Lambda!" } } }
        Anmerkung
        • Bei Staaten mit einer Wiederholungsrichtlinie erschöpft Step Functions Local die in der Richtlinie festgelegten Wiederholungsversuche, bis eine erfolgreiche Antwort eingeht. Das bedeutet, dass Sie Mocks für Wiederholungsversuche mit aufeinanderfolgenden Versuchsnummern kennzeichnen müssen und alle Wiederholungsversuche abdecken sollten, bevor eine erfolgreiche Antwort zurückgegeben wird.

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

    • HybridPath- Dieser Test verspottet die Ausgabe von. LambdaState LambdaStateFührt nach erfolgreicher Ausführung und Empfang von simulierten Daten als Antwort einen tatsächlichen Serviceaufruf an die in der Produktion angegebene Ressource SQSState durch.

    Hinweise zum Starten von Testausführungen mit simulierten Serviceintegrationen finden Sie unter. Schritt 3: Führen Sie Mocked Service Integration Tests durch

  2. Stellen Sie sicher, dass die Struktur der simulierten Antworten mit der Struktur der tatsächlichen Service-Antworten übereinstimmt, die Sie erhalten, wenn Sie integrierte Serviceanrufe tätigen. Informationen zu den strukturellen Anforderungen für simulierte Antworten finden Sie unterKonfiguration von simulierten Serviceintegrationen.

    In der vorherigen Beispiel-Mock-Konfigurationsdatei sind die simulierten Antworten in der Struktur der tatsächlichen Antworten definiert, die beim Aufruf zurückgegeben werden, MockedLambdaSuccess und MockedLambdaRetry entsprechen dieser Struktur. HelloFromLambda

    Wichtig

    AWSDie Antworten auf Dienste können in ihrer Struktur zwischen den verschiedenen Diensten variieren. Step Functions Local überprüft nicht, ob die simulierten Antwortstrukturen den tatsächlichen Service-Antwortstrukturen entsprechen. Sie müssen vor dem Testen sicherstellen, dass Ihre verspotteten Antworten den tatsächlichen Antworten entsprechen. Um die Struktur der Service-Antworten zu überprüfen, können Sie entweder die eigentlichen Serviceaufrufe mithilfe von Step Functions ausführen oder die Dokumentation für diese Dienste einsehen.

Schritt 2: Stellen Sie die Mock-Konfigurationsdatei für Step Functions Local bereit

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 mithilfe einer Umgebungsvariablen bereitstellen. Darüber hinaus müssen Sie die Mock-Konfigurationsdatei beim ersten Serverstart in den Step Functions Local-Container mounten.

Hängen Sie die Mock-Konfigurationsdatei in ein beliebiges Verzeichnis innerhalb des Step Functions Local-Containers ein. Legen Sie dann eine Umgebungsvariable mit dem Namen SFN_MOCK_CONFIG fest, die den Pfad zur Mock-Konfigurationsdatei im Container enthält. Mit dieser Methode kann die Mock-Konfigurationsdatei beliebig benannt werden, solange die Umgebungsvariable den Dateipfad und -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 Methoden, um die Mock-Konfigurationsdatei für Step Functions Local bereitzustellen:

  • Platzieren Sie die Mock-Konfigurationsdatei in dasselbe Verzeichnis wieStep FunctionsLocal.jar. Wenn Sie diese Methode verwenden, müssen Sie der Mock-Konfigurationsdatei einen Namen gebenMockConfigFile.json.

  • Stellen Sie in der Sitzung, in der Step Functions Local ausgeführt wirdSFN_MOCK_CONFIG, eine Umgebungsvariable mit dem Namen auf den vollständigen Pfad der Mock-Konfigurationsdatei ein. Mit dieser Methode kann die Mock-Konfigurationsdatei beliebig benannt werden, solange die Umgebungsvariable ihren Dateipfad und Namen enthält. Im folgenden Beispiel ist die SFN_MOCK_CONFIG Variable so gesetzt, dass sie auf eine Scheinkonfigurationsdatei mit dem Namen zeigtEnvSpecifiedMockConfig.json, die sich im /home/workspace Verzeichnis befindet.

    export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
Anmerkung
  • Wenn Sie Step Functions Local die Umgebungsvariable nicht SFN_MOCK_CONFIG zur Verfügung stellen, versucht Step Functions Local standardmäßig, eine Scheinkonfigurationsdatei zu lesen, die MockConfigFile.json in dem Verzeichnis heißt, von dem aus Sie Step Functions Local gestartet haben.

  • Wenn Sie die Mock-Konfigurationsdatei in dasselbe Verzeichnis wie die Umgebungsvariable legen Step FunctionsLocal.jar und festlegenSFN_MOCK_CONFIG, liest Step Functions Local die in der Umgebungsvariablen angegebene Datei.

Schritt 3: Führen Sie Mocked Service Integration Tests durch

Nachdem Sie eine Scheinkonfigurationsdatei erstellt und für Step Functions Local bereitgestellt haben, führen Sie die in der Mock-Konfigurationsdatei konfigurierte State Machine mithilfe von simulierten Dienstintegrationen aus. Überprüfen Sie dann die Ausführungsergebnisse mithilfe einer API-Aktion.

  1. Erstellen Sie eine State Machine, die auf der zuvor erwähnten Definition in der Mock-Konfigurationsdatei basiert.

    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 die State Machine mithilfe von simulierten Serviceintegrationen aus.

    Um die Mock-Konfigurationsdatei zu verwenden, führen Sie einen StartExecution API-Aufruf auf einer State-Maschine durch, die in der Mock-Konfigurationsdatei konfiguriert ist. Fügen Sie dazu das Suffix,#test_name, an den von der Statusmaschine verwendeten ARN an. StartExecution test_nameist ein Testfall, der für die State-Maschine in derselben Mock-Konfigurationsdatei konfiguriert ist.

    Der folgende Befehl ist ein Beispiel, das die LambdaSQSIntegration State Machine- und Mock-Konfiguration verwendet. In diesem Beispiel wird die LambdaSQSIntegration State Machine mit dem in definierten HappyPath Test ausgeführtSchritt 1: Geben Sie Mocked Service-Integrationen in einer Scheinkonfigurationsdatei an. Der HappyPath Test enthält die Konfiguration für die Ausführung, um simulierte Service-Integrationsaufrufe zu verarbeiten, die LambdaState und SQSState Staaten mithilfe der MockedLambdaSuccess MockedSQSSuccess gemockten Service-Antworten tätigen.

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

    Die Antwort auf einen Anruf StartExecution mithilfe eines simulierten Serviceintegrationstests entspricht der Antwort auf einen StartExecution normalen Anruf, bei dem der Ausführungs-ARN und das Startdatum zurückgegeben werden.

    Im Folgenden finden Sie ein Beispiel für eine Antwort auf einen Anruf StartExecution mit dem Mocked Service Integration Test:

    { "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ührung, indem Sie einenListExecutions,DescribeExecution, oder GetExecutionHistory API-Aufruf ausfü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 einen Aufruf GetExecutionHistory mit dem Ausführungs-ARN aus der in Schritt 2 gezeigten Beispielantwort. In diesem Beispiel SQSState handelt es sich bei der Ausgabe von LambdaState und um die in MockedLambdaSuccess und MockedSQSSuccess in der Mock-Konfigurationsdatei definierten Mock-Daten. Darüber hinaus werden die simulierten Daten auf die gleiche Weise verwendet, wie Daten verwendet würden, die bei der Durchführung von tatsächlichen Service-Integrationsaufrufen zurückgegeben wurden. In diesem Beispiel LambdaState wird auch die Ausgabe von SQSState als Eingabe weitergegeben.

    { "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 } } }, ... ] }