Konfigurationsdatei für 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.

Konfigurationsdatei für Mocked Service-Integrationen

Um Mock-Service-Integrationen verwenden zu können, müssen Sie zunächst eine Scheinkonfigurationsdatei MockConfigFile.json mit dem Namen erstellen, die Ihre Scheinkonfigurationen enthält. Stellen Sie dann Step Functions Local die Mock-Konfigurationsdatei zur Verfügung. Diese Konfigurationsdatei definiert Testfälle, die Scheinzustände enthalten, die simulierte Antworten auf die Serviceintegration verwenden. Der folgende Abschnitt enthält Informationen zur Struktur der Scheinkonfiguration, einschließlich der Mock-Status und der simulierten Antworten:

Einführung in die Struktur der Mock-Konfiguration

Eine Scheinkonfiguration ist ein JSON-Objekt, das die folgenden Felder auf oberster Ebene enthält:

  • StateMachines- Die Felder dieses Objekts stellen State-Maschinen dar, die für die Verwendung nachgemachter Dienstintegrationen konfiguriert sind.

  • MockedResponse- Die Felder dieses Objekts stellen vorgetäuschte Antworten auf Service-Integrationsaufrufe dar.

Das Folgende ist ein Beispiel für eine Scheinkonfigurationsdatei, die eine StateMachine Definition und enthältMockedResponse.

{ "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!" } } } } } }

Referenz zum Feld „Scheinkonfiguration“

In den folgenden Abschnitten werden die Objektfelder der obersten Ebene erläutert, die Sie in Ihrer Scheinkonfiguration definieren müssen.

StateMachines

Das StateMachines Objekt definiert, welche State-Maschinen simulierte Serviceintegrationen verwenden werden. Die Konfiguration für jede Zustandsmaschine wird als übergeordnetes Feld von StateMachines dargestellt. Der Feldname ist der Name der Zustandsmaschine und Wert ist ein Objekt, das ein einzelnes Feld mit dem Namen enthältTestCases, dessen Felder Testfälle dieser Zustandsmaschine darstellen.

Die folgende Syntax zeigt eine State Machine mit zwei Testfällen:

"MyStateMachine": { "TestCases": { "HappyPath": { ... }, "SadPath": { ... } }
TestCases

Die Felder von TestCases stellen einzelne Testfälle für die Staatsmaschine dar. Der Name jedes Testfalls muss pro Zustandsmaschine eindeutig sein, und der Wert jedes Testfalls ist ein Objekt, das eine simulierte Antwort angibt, die für Aufgabenzustände in der Zustandsmaschine verwendet werden soll.

Das folgende Beispiel für a TestCase verknüpft zwei Task Staaten mit zweiMockedResponses:

"HappyPath": { "SomeTaskState": "SomeMockedResponse", "AnotherTaskState": "AnotherMockedResponse" }

MockedResponses

MockedResponsesist ein Objekt, das mehrere simulierte Antwortobjekte mit eindeutigen Feldnamen enthält. Ein simuliertes Antwortobjekt definiert die erfolgreiche Ergebnis- oder Fehlerausgabe für jeden Aufruf eines simulierten Task-Status. Sie geben die Aufrufnummer mithilfe einzelner ganzzahliger Zeichenketten wie „0“, „1“, „2“ und „3“ oder eines inklusiven Bereichs von Ganzzahlen wie „0-1“, „2-3“ an.

Wenn Sie eine Aufgabe simulieren, müssen Sie für jeden Aufruf eine simulierte Antwort angeben. Eine Antwort muss ein einzelnes Feld enthalten, das den Namen hat Return oder Throw dessen Wert die Ergebnis- oder Fehlerausgabe des simulierten Task-Aufrufs ist. Wenn Sie keine simulierte Antwort angeben, schlägt die Ausführung der State Machine fehl.

Das Folgende ist ein Beispiel für Return Objekte MockedResponse mit Throw und. In diesem Beispiel wird beim ersten dreimaligen Ausführen der Zustandsmaschine die in angegebene Antwort zurückgegeben, und beim vierten Mal, wenn die Zustandsmaschine ausgeführt "0-2" wird, "3" wird die in angegebene Antwort zurückgegeben.

"SomeMockedResponse": { "0-2": { "Throw": { ... } }, "3": { "Return": { ... } } }
Anmerkung

Wenn Sie einen Map Bundesstaat verwenden und vorhersehbare Reaktionen für diesen Map Bundesstaat sicherstellen möchten, setzen Sie den Wert von maxConcurrency auf 1. Wenn Sie einen Wert größer als 1 festlegen, führt Step Functions Local mehrere Iterationen gleichzeitig aus, wodurch die allgemeine Ausführungsreihenfolge der Zustände zwischen den Iterationen unvorhersehbar ist. Dies kann außerdem dazu führen, dass Step Functions Local von einer Ausführung zur nächsten unterschiedliche simulierte Antworten für Iterationszustände verwendet.

Ergebnis

Returnwird als Feld der MockedResponse Objekte dargestellt. Es gibt das erfolgreiche Ergebnis eines simulierten Task-Status an.

Das Folgende ist ein Beispiel für ein Return Objekt, das eine simulierte Antwort für den Aufruf Invokeeiner Lambda-Funktion enthält:

"Return": { "StatusCode": 200, "Payload": { "StatusCode": 200, "body": "Hello from Lambda!" } }
Wirf

Throwwird als Feld der MockedResponse Objekte dargestellt. Es gibt die Fehlerausgabe einer fehlgeschlagenen Aufgabe an. Der Wert von Throw muss ein Objekt sein, das Cause Felder Error und Felder mit Zeichenfolgenwerten enthält. Darüber hinaus MockConfigFile.json muss der Zeichenfolgenwert, den Sie im Error Feld in der angeben, mit den Fehlern übereinstimmen, die in den Catch Abschnitten Retry und auf Ihrem State-Computer behandelt werden.

Das Folgende ist ein Beispiel für ein Throw Objekt, das eine simulierte Antwort für den Aufruf Invokeeiner Lambda-Funktion enthält:

"Throw": { "Error": "Lambda.TimeoutException", "Cause": "Lambda timed out." }

Konfiguration von simulierten Serviceintegrationen

Mit Step Functions Local können Sie jede Dienstintegration simulieren. Step Functions Local erzwingt jedoch nicht, dass die Mocks mit den echten APIs identisch sind. Eine nachgeahmte Aufgabe ruft niemals den Dienstendpunkt auf. Wenn Sie keine simulierte Antwort angeben, versucht ein Task, die Dienstendpunkte aufzurufen. Darüber hinaus generiert Step Functions Local automatisch ein Task-Token, wenn Sie eine Aufgabe mit dem simulieren.waitForTaskToken.