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-Serviceintegrationen zum Testen in Step Functions Local
**Step Functions Local wird nicht unterstützt**
Step Functions Local bietet **keine** Funktionsparität und wird **nicht** unterstützt.
Sie könnten Lösungen von Drittanbietern in Betracht ziehen, die Step Functions zu Testzwecken emulieren.
In Step Functions Local können Sie die Ausführungspfade Ihrer Zustandsmaschinen testen, ohne tatsächlich integrierte Dienste aufzurufen, indem Sie simulierte Dienstintegrationen verwenden. Um Ihre Zustandsmaschinen so zu konfigurieren, dass sie simulierte Dienstintegrationen verwenden, erstellen Sie eine simulierte Konfigurationsdatei. In dieser Datei definieren Sie die gewünschte Ausgabe Ihrer Service-Integrationen als simulierte Antworten und die Ausführungen, die Ihre simulierten Antworten verwenden, um einen Ausführungspfad zu simulieren, als Testfälle.
Indem Sie die Scheinkonfigurationsdatei für Step Functions Local bereitstellen, können Sie Serviceintegrationsrufe testen, indem Sie Zustandsmaschinen ausführen, die die in den Testfällen angegebenen simulierten Antworten verwenden, anstatt tatsächliche Serviceintegrationsaufrufe zu tätigen.
**Anmerkung**
Wenn Sie in der Mock-Konfigurationsdatei keine simulierten Serviceintegrationsantworten angeben, ruft Step Functions Local die AWS Serviceintegration mit dem Endpunkt auf, den Sie bei der Einrichtung von Step Functions Local konfiguriert haben. Informationen zur Konfiguration von Endpunkten für Step Functions Local finden Sie unter[Konfigurationsoptionen für Step Functions lokal einrichten](sfn-local.md#sfn-local-config-options).
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 Serviceanfragen auszuführen.
+ Mocked Responses — Bezieht sich auf Scheindaten, für deren Verwendung Task-Status konfiguriert werden können.
+ Testfälle — Bezieht sich auf State-Machine-Ausführungen, die so konfiguriert sind, dass sie simulierte Service-Integrationen verwenden.
+ Vorgetäuschte Konfigurationsdatei — Bezieht sich auf eine Scheinkonfigurationsdatei, die JSON enthält. Darin werden simulierte Dienstintegrationen, simulierte Antworten und Testfälle definiert.
## Konfiguration von Mocked-Serviceintegrationen
Mit Step Functions Local können Sie jede Serviceintegration simulieren. Step Functions Local erzwingt jedoch nicht, dass die Mocks mit den echten APIs identisch sind. Ein simulierter Task ruft niemals den Service-Endpunkt auf. Wenn Sie keine simulierte Antwort angeben, versucht eine Task, die Dienstendpunkte aufzurufen. Darüber hinaus generiert Step Functions Local automatisch ein Task-Token, wenn Sie eine Aufgabe mit dem simulieren`.waitForTaskToken`.
## Schritt 1: Geben Sie Mocked Service-Integrationen in einer simulierten Konfigurationsdatei an
Sie können das Step Functions AWS SDK und optimierte Serviceintegrationen mit Step Functions Local testen. Die folgende Abbildung zeigt den Zustandsmaschine, der auf der Registerkarte State-Machine-Definition definiert ist:
![\[Beispiel für die Integration eines verspotteten Dienstes.\]](http://docs.aws.amazon.com/de_de/step-functions/latest/dg/images/msi-graph.png)
Dazu müssen Sie eine simulierte Konfigurationsdatei erstellen, die Abschnitte enthält, wie unter definiert. [Struktur der Scheinkonfigurationsdatei](#mock-cfg-struct)
1. Erstellen Sie eine Datei mit dem Namen`MockConfigFile.json`, um Tests mit simulierten Dienstintegrationen zu konfigurieren.
Das folgende Beispiel zeigt eine simulierte Konfigurationsdatei, die auf eine Zustandsmaschine mit zwei definierten Zuständen namens und verweist. `LambdaState` `SQSState`
------
#### [ Mock configuration file example ]
Im Folgenden finden Sie ein Beispiel für eine simulierte Konfigurationsdatei, die zeigt, wie Antworten beim [Aufrufen einer Lambda-Funktion und beim Senden einer](connect-lambda.md) [Nachricht an Amazon](connect-sqs.md) SQS simuliert werden. In diesem Beispiel enthält die [`LambdaSQSIntegration`](#mock-cfg-sm-sect)Zustandsmaschine drei Testfälle mit dem Namen`HappyPath`,, und`RetryPath`, die sich über die `Task` Zustände mit `HybridPath` dem Namen und lustig machen. `LambdaState` `SQSState` In diesen Staaten werden die Service-Antworten `MockedLambdaSuccess``MockedSQSSuccess`, und `MockedLambdaRetry` Mocked Service Responses verwendet. Diese gefälschten Serviceantworten 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 Zustandsmaschinen-Definition mit dem Namen und`LambdaSQSIntegration`, die zwei Status von Serviceintegrationsaufgaben mit dem Namen `LambdaState` und `SQSState` definiert. `LambdaState`enthält eine Wiederholungsrichtlinie auf `States.ALL` der Grundlage von.
```
{
"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/account-id/myQueue",
"MessageBody.$":"$"
},
"End": true
}
}
}
```
------
Sie können die `LambdaSQSIntegration` State-Machine-Definition, auf die in der Scheinkonfigurationsdatei verwiesen wird, mithilfe eines der folgenden Testfälle ausführen:
+ `HappyPath`- Dieser Test simuliert die Ausgabe von `LambdaState` `MockedSQSSuccess` bzw. `SQSState` unter Verwendung von `MockedLambdaSuccess` und.
+ Der gibt `LambdaState` den folgenden Wert zurück:
```
"0":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
```
+ Das gibt `SQSState` den folgenden Wert zurück:
```
"0":{
"Return":{
"MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51",
"MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51"
}
}
```
+ `RetryPath`- Dieser Test simuliert die Ausgabe von `LambdaState` `MockedLambdaRetry` `MockedSQSSuccess` bzw. `SQSState` unter Verwendung von. Darüber hinaus `LambdaState` ist er so konfiguriert, dass er vier Wiederholungsversuche durchführt. Die simulierten Antworten für diese Versuche sind im Status definiert und indexiert. `MockedLambdaRetry`
+ Der erste Versuch endet mit einem fehlgeschlagenen Task, 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 Fehler bei der Aufgabe, 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 erfolgreichen Task, der das Zustandsergebnis aus dem Payload-Abschnitt in der simulierten Lambda-Antwort enthält.
```
"3":{
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
}
```
**Anmerkung**
Für Staaten mit einer Wiederholungsrichtlinie erschöpft Step Functions Local die in der Richtlinie festgelegten Wiederholungsversuche, bis eine erfolgreiche Antwort eingeht. Das bedeutet, dass Sie Wiederholungsversuche mit aufeinanderfolgenden Versuchsnummern kennzeichnen müssen und dass Sie alle Wiederholungsversuche abdecken müssen, bevor Sie eine erfolgreiche Antwort zurückgeben.
Wenn Sie für einen bestimmten Wiederholungsversuch keine simulierte Antwort angeben, z. B. „3" wiederholen, schlägt die Ausführung der Zustandsmaschine fehl.
+ `HybridPath`- Dieser Test simuliert die Ausgabe von. `LambdaState` After `LambdaState` wird erfolgreich ausgeführt und empfängt als Antwort simulierte Daten. `SQSState` Führt einen tatsächlichen Serviceaufruf an die in der Produktion angegebene Ressource durch.
Hinweise zum Starten von Testausführungen mit simulierten Dienstintegrationen finden Sie unter. [Schritt 3: Führen Sie die Mocked Service-Integrationstests durch](#run-mocked-serv-integ-tests)
1. Stellen Sie sicher, dass die Struktur der simulierten Antworten der Struktur der tatsächlichen Serviceantworten entspricht, die Sie erhalten, wenn Sie integrierte Serviceanfragen tätigen. Informationen zu den strukturellen Anforderungen für gefälschte Antworten finden Sie unter. [Konfiguration von Mocked-Serviceintegrationen](#mock-resp-struct-req)
In der vorherigen Beispielkonfigurationsdatei sind die simulierten Antworten in der Struktur der tatsächlichen Antworten definiert, die beim Aufrufen zurückgegeben werden, `MockedLambdaSuccess` und `MockedLambdaRetry` entsprechen dieser Struktur. `HelloFromLambda`
**Wichtig**
AWS Serviceantworten können in ihrer Struktur zwischen verschiedenen Diensten variieren. Step Functions Local überprüft nicht, ob simulierte Antwortstrukturen den tatsächlichen Service-Response-Strukturen entsprechen. Vor dem Testen müssen Sie sicherstellen, dass Ihre gefälschten Antworten den tatsächlichen Antworten entsprechen. Um die Struktur der Serviceantworten zu überprüfen, können Sie entweder die eigentlichen Serviceabrufe 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 Scheinkonfigurationsdatei 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 Scheinkonfigurationsdatei nur mit einer Umgebungsvariablen bereitstellen. Darüber hinaus müssen Sie die Scheinkonfigurationsdatei beim ersten Serverstart in den Step Functions Local Container mounten.
Hängen Sie die Scheinkonfigurationsdatei 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 Scheinkonfigurationsdatei im Container enthält. Mit dieser Methode kann die Scheinkonfigurationsdatei beliebig 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, um die Scheinkonfigurationsdatei für Step Functions Local bereitzustellen:
+ Platzieren Sie die Scheinkonfigurationsdatei im selben Verzeichnis wie`Step FunctionsLocal.jar`. Wenn Sie diese Methode verwenden, müssen Sie der Scheinkonfigurationsdatei einen Namen geben`MockConfigFile.json`.
+ Setzen Sie in der Sitzung, in der Step Functions Local ausgeführt wird`SFN_MOCK_CONFIG`, eine Umgebungsvariable mit dem Namen, auf den vollständigen Pfad der Scheinkonfigurationsdatei. Diese Methode ermöglicht es, der Scheinkonfigurationsdatei einen beliebigen Namen zu geben, solange die Umgebungsvariable ihren Dateipfad und Namen enthält. Im folgenden Beispiel ist die `SFN_MOCK_CONFIG` Variable so eingestellt, dass sie auf eine simulierte Konfigurationsdatei mit dem Namen verweist`EnvSpecifiedMockConfig.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, wird standardmäßig versucht, eine Scheinkonfigurationsdatei zu lesen, die `MockConfigFile.json` in dem Verzeichnis benannt ist, aus dem Sie Step Functions Local gestartet haben.
Wenn Sie die Scheinkonfigurationsdatei im selben Verzeichnis platzieren wie `Step FunctionsLocal.jar` und die Umgebungsvariable setzen`SFN_MOCK_CONFIG`, liest Step Functions Local die durch die Umgebungsvariable angegebene Datei.
------
## Schritt 3: Führen Sie die Mocked Service-Integrationstests durch
Nachdem Sie eine Scheinkonfigurationsdatei erstellt und für Step Functions Local bereitgestellt haben, führen Sie den in der Scheinkonfigurationsdatei konfigurierten Zustandsmaschine mithilfe von simulierten Dienstintegrationen aus. Überprüfen Sie anschließend die Ausführungsergebnisse mithilfe einer API-Aktion.
1. Erstellen Sie eine Zustandsmaschine auf der Grundlage der zuvor genannten Definition in der [Scheinkonfigurationsdatei](#create-mock-config-file).
```
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:region:account-id: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/account-id/myQueue\",\"MessageBody.$\":\"$\"},\"End\":true}}}" \
--name "LambdaSQSIntegration" --role-arn "arn:aws:iam::account-id:role/service-role/LambdaSQSIntegration"
```
1. Führen Sie die Zustandsmaschine mithilfe von simulierten Dienstintegrationen aus.
Um die Scheinkonfigurationsdatei zu verwenden, führen Sie einen `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` API-Aufruf auf einer Zustandsmaschine durch, die in der Scheinkonfigurationsdatei konfiguriert ist. Hängen Sie dazu das Suffix,, an den ARN der Zustandsmaschine an`#test_name`, der von verwendet wird. `StartExecution` `test_name`ist ein Testfall, der für die Zustandsmaschine in derselben Scheinkonfigurationsdatei konfiguriert ist.
Der folgende Befehl ist ein Beispiel, das die `LambdaSQSIntegration` Zustandsmaschine und die Scheinkonfiguration verwendet. In diesem Beispiel wird die `LambdaSQSIntegration` Zustandsmaschine mit dem in definierten `HappyPath` Test ausgeführt[Schritt 1: Geben Sie Mocked Service-Integrationen in einer simulierten Konfigurationsdatei an](#create-mock-config-file). Der `HappyPath` Test enthält die Konfiguration für die Ausführung zur Verarbeitung von simulierten Dienstintegrationsaufrufen `LambdaState` und `SQSState` Zuständen, die anhand der Dienstantworten `MockedLambdaSuccess` und `MockedSQSSuccess` simulierten Dienstantworten erfolgen.
```
aws stepfunctions start-execution \
--endpoint http://localhost:8083 \
--name executionWithHappyPathMockedServices \
--state-machine arn:aws:states:region:account-id:stateMachine:LambdaSQSIntegration#HappyPath
```
1. Die Antwort der State-Machine-Ausführung anzeigen.
Die Antwort auf einen Aufruf `StartExecution` mithilfe eines simulierten Serviceintegrationstests entspricht der Antwort auf einen `StartExecution` normalen Aufruf, bei dem der Ausführungs-ARN und das Startdatum zurückgegeben werden.
Im Folgenden finden Sie ein Beispiel für eine Antwort auf einen Aufruf `StartExecution` mit dem Mocked Service Integration Test:
```
{
"startDate":"2022-01-28T15:03:16.981000-05:00",
"executionArn":"arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices"
}
```
1. Überprüfen Sie die Ergebnisse der Ausführung, indem Sie einen `[ListExecutions](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListExecutions.html)``[DescribeExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeExecution.html)`, oder `[GetExecutionHistory](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetExecutionHistory.html)` API-Aufruf ausführen.
```
aws stepfunctions get-execution-history \
--endpoint http://localhost:8083 \
--execution-arn arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices
```
Das folgende Beispiel zeigt Teile einer Antwort auf einen Aufruf `GetExecutionHistory` unter Verwendung des 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 Scheindaten, die in `MockedLambdaSuccess` und `MockedSQSSuccess` in der [Scheinkonfigurationsdatei](#create-mock-config-file) definiert sind. Darüber hinaus werden die simulierten Daten auf die gleiche Weise verwendet, wie Daten verwendet würden, die bei der Ausführung von tatsächlichen Serviceintegrationsaufrufen zurückgegeben werden. Außerdem wird in diesem Beispiel die Ausgabe von `LambdaState` `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
}
}
},
...
]
}
```
## Konfigurationsdatei für simulierte Serviceintegrationen in Step Functions
**Step Functions Local wird nicht unterstützt**
Step Functions Local bietet **keine** Funktionsparität und wird **nicht** unterstützt.
Sie könnten Lösungen von Drittanbietern in Betracht ziehen, die Step Functions zu Testzwecken emulieren.
Als Alternative zu Step Functions Local können Sie die TestState API verwenden, um Ihre State-Machine-Logik vor der Bereitstellung in Ihrem AWS Konto auf Unit-Tests zu testen. Weitere Informationen finden Sie unter [Testen von Zustandsmaschinen mit TestState API](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html).
Um simulierte Dienstintegrationen zu verwenden, müssen Sie zunächst eine simulierte Konfigurationsdatei `MockConfigFile.json` mit dem Namen erstellen, die Ihre Scheinkonfigurationen enthält. Stellen Sie dann Step Functions Local die Scheinkonfigurationsdatei zur Verfügung. Diese Konfigurationsdatei definiert Testfälle, die Scheinzustände enthalten, die simulierte Antworten zur Serviceintegration verwenden. Der folgende Abschnitt enthält Informationen zur Struktur der Scheinkonfiguration, die die Scheinstatus und die simulierten Antworten umfasst:
### Struktur der Scheinkonfigurationsdatei
Eine Scheinkonfiguration ist ein JSON-Objekt, das die folgenden Felder der obersten Ebene enthält:
+ `StateMachines`- Die Felder dieses Objekts stellen Zustandsmaschinen dar, die so konfiguriert sind, dass sie simulierte Dienstintegrationen verwenden.
+ `MockedResponse`- Die Felder dieses Objekts stellen simulierte Antworten auf Aufrufe zur Serviceintegration dar.
Das Folgende ist ein Beispiel für eine simulierte Konfigurationsdatei, die eine `StateMachine` Definition und `MockedResponse` enthält.
```
{
"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](#mock-cfg-sm-sect)
+ [MockedResponses](#mock-cfg-mckd-resp-sect)
##### StateMachines
Das `StateMachines` Objekt definiert, welche Zustandsmaschinen simulierte Dienstintegrationen verwenden. Die Konfiguration für jede Zustandsmaschine wird als Feld der obersten Ebene von dargestellt. `StateMachines` Der Feldname ist der Name der Zustandsmaschine und der Wert ist ein Objekt, das ein einzelnes Feld mit dem Namen enthält`TestCases`, dessen Felder Testfälle dieses Zustandsmaschinen darstellen.
Die folgende Syntax zeigt eine Zustandsmaschine mit zwei Testfällen:
```
"MyStateMachine": {
"TestCases": {
"HappyPath": {
...
},
"SadPath": {
...
}
}
```
##### TestCases
Die Felder von `TestCases` stehen für einzelne Testfälle für die Zustandsmaschine. 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 Task-Status in der Zustandsmaschine verwendet werden soll.
Das folgende Beispiel für a `TestCase` verknüpft zwei `Task` Zustände mit zwei`MockedResponses`:
```
"HappyPath": {
"SomeTaskState": "SomeMockedResponse",
"AnotherTaskState": "AnotherMockedResponse"
}
```
##### MockedResponses
`MockedResponses`ist ein Objekt, das mehrere simulierte Antwortobjekte mit eindeutigen Feldnamen enthält. Ein simuliertes Antwortobjekt definiert das erfolgreiche Ergebnis oder die Fehlerausgabe für jeden Aufruf eines simulierten Task-Status. Sie geben die Aufrufnummer mithilfe einzelner Ganzzahlzeichenfolgen wie „0“, „1“, „2“ und „3“ oder mithilfe eines inklusiven Bereichs von ganzen Zahlen 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 mit dem Namen `Return` oder `Throw` dessen Wert das Ergebnis oder die Fehlerausgabe für den simulierten Task-Aufruf enthalten. Wenn Sie keine simulierte Antwort angeben, schlägt die Ausführung der Zustandsmaschine fehl.
Im Folgenden finden Sie ein Beispiel für `Return` Objekte `MockedResponse` mit `Throw` und. In diesem Beispiel wird die in angegebene Antwort zurückgegeben, wenn die Zustandsmaschine zum ersten Mal ausgeführt `"0-2"` wird, und beim vierten Mal, wenn die Zustandsmaschine ausgeführt wird, `"3"` wird die in angegebene Antwort zurückgegeben.
```
"SomeMockedResponse": {
"0-2": {
"Throw": {
...
}
},
"3": {
"Return": {
...
}
}
}
```
**Anmerkung**
Wenn Sie einen `Map` Status verwenden und vorhersehbare Reaktionen für diesen `Map` Zustand sicherstellen möchten, setzen Sie den Wert `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 über Iterationen hinweg nicht vorhersehbar ist. Dies kann außerdem dazu führen, dass Step Functions Local unterschiedliche simulierte Antworten für Iterationszustände von einer Ausführung zur nächsten verwendet.
##### Ergebnis
`Return`wird als ein Feld der Objekte dargestellt. `MockedResponse` Es gibt das erfolgreiche Ergebnis eines simulierten Aufgabenstatus an.
Das Folgende ist ein Beispiel für ein `Return` Objekt, das eine simulierte Antwort [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)auf den Aufruf einer Lambda-Funktion enthält:
```
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
```
##### Wirf
`Throw`wird als ein Feld der `MockedResponse` Objekte dargestellt. Es gibt die [Fehlerausgabe](concepts-error-handling.md) einer fehlgeschlagenen Aufgabe an. Der Wert von `Throw` muss ein Objekt sein, das `Cause` Felder `Error` und mit Zeichenfolgenwerten enthält. Darüber hinaus `MockConfigFile.json` muss der Zeichenkettenwert, den Sie in dem `Error` Feld angeben, den Fehlern entsprechen, die in den `Catch` Abschnitten `Retry` und Ihrer Zustandsmaschine behandelt wurden.
Das Folgende ist ein Beispiel für ein `Throw` Objekt, das eine simulierte Antwort [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)auf den Aufruf einer Lambda-Funktion enthält:
```
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
```