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.
# Testen von Zustandsmaschinen mit Step Functions Local (nicht unterstützt)
**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 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).
Mit AWS Step Functions Local, einer herunterladbaren Version von Step Functions, können Sie Anwendungen mit Step Functions testen, die in Ihrer eigenen Entwicklungsumgebung ausgeführt werden.
Wenn Sie Step Functions Local ausführen, können Sie Serviceintegrationen auf eine der folgenden Arten aufrufen:
+ Konfiguration lokaler Endpunkte für AWS Lambda und andere Dienste.
+ Direktes Aufrufen eines AWS Dienstes von Step Functions Local aus.
+ Die Antwort von Serviceintegrationen verspotten.
AWS Step Functions Local ist als JAR-Paket oder als eigenständiges Docker-Image verfügbar, das unter Microsoft Windows, Linux, macOS und anderen Plattformen läuft, die Java oder Docker unterstützen.
**Warnung**
Sie sollten Step Functions Local nur zum Testen verwenden und niemals vertrauliche Informationen verarbeiten.
**Topics**
+ [Step Functions Local und Docker einrichten](#sfn-local-docker)
+ [Step Functions lokal einrichten — Java-Version](#sfn-local-jar)
+ [Konfiguration der lokalen Optionen von Step Functions](#sfn-local-config-options)
+ [Step Functions lokal ausführen](#sfn-local-computer)
+ [Tutorial: Testen mit Step Functions und AWS SAM CLI Local](sfn-local-lambda.md)
+ [Testen mit Mocked-Serviceintegrationen](sfn-local-test-sm-exec.md)
## Step Functions lokal einrichten (herunterladbare Version) in Docker
Mit dem Docker-Image Step Functions Local können Sie schnell mit Step Functions Local beginnen, indem Sie ein Docker-Image mit allen erforderlichen Abhängigkeiten verwenden. Das Docker-Image ermöglicht es Ihnen, Step Functions Local in Ihre containerisierten Builds und als Teil Ihrer kontinuierlichen Integrationstests aufzunehmen.
Das Docker-Image für Step Functions Local finden Sie unter [https://hub.docker.com/r/amazon/ aws-stepfunctions-local](https://hub.docker.com/r/amazon/aws-stepfunctions-local), oder geben Sie den folgenden `pull` Docker-Befehl ein.
```
docker pull amazon/aws-stepfunctions-local
```
Führen Sie den folgenden Docker-Befehl aus, um die herunterladbare Version von Step Functions auf `run` Docker zu starten
```
docker run -p 8083:8083 amazon/aws-stepfunctions-local
```
Um mit AWS Lambda oder anderen unterstützten Diensten zu interagieren, müssen Sie zuerst Ihre Anmeldeinformationen und andere Konfigurationsoptionen konfigurieren. Weitere Informationen finden Sie unter den folgenden Themen:
+ [Konfigurationsoptionen für Step Functions lokal einrichten](#sfn-local-config-options)
+ [Anmeldeinformationen und Konfiguration für Docker](#docker-credentials)
## Step Functions lokal einrichten (herunterladbare Version) — Java-Version
Die herunterladbare Version von AWS Step Functions wird als ausführbare JAR-Datei und als Docker-Image bereitgestellt. Die Java-Anwendung kann auf Windows-, Linux-, macOS- und anderen Plattformen, die Java unterstützen, ausgeführt werden. Zusätzlich zu Java müssen Sie das AWS Command Line Interface (AWS CLI) installieren. Informationen zur Installation und Konfiguration von finden Sie im [AWS Command Line Interface Benutzerhandbuch](https://docs.aws.amazon.com/cli/latest/userguide/). AWS CLI
**So richten Sie Step Functions auf Ihrem Computer ein und führen sie aus**
1. Laden Sie Step Functions über die folgenden Links herunter.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/step-functions/latest/dg/sfn-local.html)
1. Extrahieren Sie die `.zip`-Datei.
1. Testen Sie den Download und lesen Sie die Versionsinformationen.
```
$ java -jar StepFunctionsLocal.jar -v
Step Function Local
Version: 2.0.0
Build: 2024-05-18
```
1. (Optional) Zeigen Sie eine Liste der verfügbaren Befehle an.
```
$ java -jar StepFunctionsLocal.jar -h
```
1. Um Step Functions auf Ihrem Computer zu starten, öffnen Sie eine Befehlszeile, navigieren Sie zu dem Verzeichnis, in das Sie extrahiert haben`StepFunctionsLocal.jar`, und geben Sie den folgenden Befehl ein.
```
java -jar StepFunctionsLocal.jar
```
1. Verwenden Sie den `--endpoint-url` Parameter, um auf lokal ausgeführte Step-Funktionen zuzugreifen. Mit den würden Sie AWS CLI beispielsweise die Befehle Step Functions wie folgt angeben:
```
aws stepfunctions --endpoint-url http://localhost:8083 command
```
**Anmerkung**
Standardmäßig verwendet Step Functions Local ein lokales Testkonto und Anmeldeinformationen, und die AWS Region ist auf USA Ost (Nord-Virginia) eingestellt. Um Step Functions Local mit AWS Lambda oder anderen unterstützten Diensten verwenden zu können, müssen Sie Ihre Anmeldeinformationen und Region konfigurieren.
Wenn Sie Express-Workflows mit Step Functions Local verwenden, wird der Ausführungsverlauf in einer Protokolldatei gespeichert. Es wird nicht in CloudWatch Logs protokolliert. Der Protokolldateipfad basiert auf dem ARN der CloudWatch Logs-Protokollgruppe, der beim Erstellen des lokalen Zustandsmaschinen bereitgestellt wurde. Die Protokolldatei wird `/aws/states/log-group-name/${execution_arn}.log` relativ zu dem Speicherort gespeichert, an dem Sie Step Functions Local ausführen. Wenn der Ausführungs-ARN beispielsweise folgenden Namen hat:
```
arn:aws:states:region:account-id:express:test:example-ExpressLogGroup-wJalrXUtnFEMI
```
hat die Protokolldatei den Namen:
```
aws/states/log-group-name/arn:aws:states:region:account-id:express:test:example-ExpressLogGroup-wJalrXUtnFEMI.log
```
## Konfigurationsoptionen für Step Functions lokal einrichten
Wenn Sie AWS Step Functions Local mithilfe der JAR-Datei starten, können Sie die Konfigurationsoptionen mithilfe von AWS Command Line Interface (AWS CLI) festlegen oder indem Sie sie in die Systemumgebung aufnehmen. Für Docker müssen Sie diese Optionen in einer Datei angeben, auf die Sie beim Start von Step Functions Local verweisen.
### Konfigurationsoptionen
Wenn Sie den Step Functions Local-Container so konfigurieren, dass er einen Override-Endpunkt wie Lambda-Endpunkt und Batch-Endpunkt verwendet, und diesen Endpunkt aufrufen, verwendet Step Functions Local die von Ihnen angegebenen [Anmeldeinformationen](#docker-credentials) nicht. Das Festlegen dieser Endpunkt-Overrides ist optional.
| Option | Befehlszeile | Umgebung |
| --- | --- | --- |
| Account | -account, --aws-account | AWS\$1ACCOUNT\$1ID |
| Region | -region, --aws-region | AWS\$1DEFAULT\$1REGION |
| Wartezeit-Skalierung | -waitTimeScale, --wait-time-scale | WAIT\$1TIME\$1SCALE |
| Lambda-Endpunkt | -LambdaEndpunkt, --lambda-Endpunkt | LAMBDA\$1ENDPOINT |
| Stapelendpunkt | -Batch-Endpunkt, --batch-Endpunkt | BATCH\$1ENDPOINT |
| DynamoDB-Endpunkt | -dynamoDBEndpoint, --dynamodb-endpunkt | DYNAMODB\$1ENDPOINT |
| ECS-Endpunkt | -ecsEndpoint, --ecs-endpoint | ECS\$1ENDPOINT |
| Glue-Endpunkt | -glue-Endpunkt, --glue-endpoint | GLUE\$1ENDPOINT |
| SageMaker Endpunkt | -sageMakerEndpoint, --sagemaker-endpoint | SAGE\$1MAKER\$1ENDPOINT |
| SQS-Endpunkt | -sqSendpoint, --sqs-endpoint | SQS\$1ENDPOINT |
| SNS-Endpunkt | -snSendPoint, --sns-endpoint | SNS\$1ENDPOINT |
| Step Functions Endpunkt | -stepFunctionsEndpoint, --step-functions-endpoint | STEP\$1FUNCTIONS\$1ENDPOINT |
### Anmeldeinformationen und Konfiguration für Docker
Um Step Functions Local für Docker zu konfigurieren, erstellen Sie die folgende Datei:`aws-stepfunctions-local-credentials.txt`.
Diese Datei enthält Ihre Anmeldeinformationen und andere Konfigurationsoptionen. Folgendes kann beim Erstellen der `aws-stepfunctions-local-credentials.txt` Datei als Vorlage verwendet werden.
```
AWS_DEFAULT_REGION=AWS_REGION_OF_YOUR_AWS_RESOURCES
AWS_ACCESS_KEY_ID=YOUR_AWS_ACCESS_KEY
AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_KEY
WAIT_TIME_SCALE=VALUE
LAMBDA_ENDPOINT=VALUE
BATCH_ENDPOINT=VALUE
DYNAMODB_ENDPOINT=VALUE
ECS_ENDPOINT=VALUE
GLUE_ENDPOINT=VALUE
SAGE_MAKER_ENDPOINT=VALUE
SQS_ENDPOINT=VALUE
SNS_ENDPOINT=VALUE
STEP_FUNCTIONS_ENDPOINT=VALUE
```
Nachdem Sie Ihre Anmeldeinformationen und Konfigurationsoptionen unter konfiguriert haben`aws-stepfunctions-local-credentials.txt`, starten Sie Step Functions mit dem folgenden Befehl.
```
docker run -p 8083:8083 --env-file aws-stepfunctions-local-credentials.txt amazon/aws-stepfunctions-local
```
**Anmerkung**
Es wird empfohlen, den speziellen DNS-Namen zu verwenden`host.docker.internal`, der in die interne IP-Adresse aufgelöst wird, die der Host verwendet, z. B. `http://host.docker.internal:8000` Weitere Informationen finden Sie in der Docker-Dokumentation für Mac und Windows unter [Netzwerkfunktionen in Docker Desktop für Mac bzw.](https://docs.docker.com/desktop/mac/networking/#use-cases-and-workaround) [Netzwerkfunktionen in Docker Desktop](https://docs.docker.com/desktop/windows/networking/) für Windows.
## Step Functions lokal auf Ihrem Computer ausführen
Verwenden Sie die lokale Version von Step Functions, um Zustandsmaschinen auf Ihrem Computer zu konfigurieren, zu entwickeln und zu testen.
### Führen Sie eine HelloWorld Zustandsmaschine lokal aus
Nachdem Sie Step Functions lokal mit AWS Command Line Interface (AWS CLI) ausgeführt haben, können Sie eine State-Machine-Ausführung starten.
1. Erstellen Sie einen Zustandsmaschine aus dem, AWS CLI indem Sie die Zustandsmaschinen-Definition umgehen.
```
aws stepfunctions --endpoint-url http://localhost:8083 create-state-machine --definition "{\
\"Comment\": \"A Hello World example of the Amazon States Language using a Pass state\",\
\"StartAt\": \"HelloWorld\",\
\"States\": {\
\"HelloWorld\": {\
\"Type\": \"Pass\",\
\"End\": true\
}\
}}" --name "HelloWorld" --role-arn "arn:aws:iam::012345678901:role/DummyRole"
```
**Anmerkung**
Das `role-arn` wird nicht für Step Functions Local verwendet, aber Sie müssen es mit der richtigen Syntax einbinden. Sie können den Amazon-Ressourcennamen (ARN) aus dem vorherigen Beispiel verwenden.
Wenn Sie die Zustandsmaschine erfolgreich erstellt haben, antwortet Step Functions mit dem Erstellungsdatum und dem State-Machine-ARN.
```
{
"creationDate": 1548454198.202,
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld"
}
```
1. Starten Sie eine Ausführung mithilfe des ARN des Zustandsautomaten, den Sie erstellt haben.
```
aws stepfunctions --endpoint-url http://localhost:8083 start-execution --state-machine-arn arn:aws:states:region:account-id:stateMachine:HelloWorld
```
### Step Functions Lokal mit AWS SAM CLI Local
Sie können die lokale Version von Step Functions mit einer lokalen Version von verwenden AWS Lambda. Zur Konfiguration müssen Sie AWS SAM installieren und konfigurieren.
Informationen zur Konfiguration und Ausführung AWS SAM finden Sie im Folgenden:
+ [Einrichten AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html)
+ [AWS SAM CLI Local starten](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-local-start-lambda.html)
Wenn Lambda auf Ihrem lokalen System läuft, können Sie Step Functions Local starten. Starten Sie Step Functions Local aus dem Verzeichnis, in das Sie Ihre lokalen Step Functions Functions-JAR-Dateien extrahiert haben, und verwenden Sie den `--lambda-endpoint` Parameter, um den lokalen Lambda-Endpunkt zu konfigurieren.
```
java -jar StepFunctionsLocal.jar --lambda-endpoint http://127.0.0.1:3001 command
```
Weitere Hinweise zum Ausführen von Step Functions Local mit AWS Lambda finden Sie unter[Tutorial: Workflows mit Step Functions und AWS SAM CLI Local testen](sfn-local-lambda.md).
# Tutorial: Workflows mit Step Functions und AWS SAM CLI Local testen
**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).
Wenn Sie beide AWS Step Functions Optionen AWS Lambda verwenden und auf Ihrem lokalen Computer ausgeführt werden, können Sie Ihre State Machine- und Lambda-Funktionen testen, ohne Ihren Code darauf bereitstellen zu müssen AWS.
Weitere Informationen finden Sie unter den folgenden Themen:
+ [Testen von Zustandsmaschinen mit Step Functions Local (nicht unterstützt)](sfn-local.md)
+ [Richten Sie ein AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html)
## Schritt 1: Einrichten AWS SAM
AWS Serverless Application Model (AWS SAM) CLI Local erfordert AWS Command Line Interface, dass Docker AWS SAM, und Docker installiert sind.
1. [Installieren Sie die AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html).
**Anmerkung**
Bevor Sie die AWS SAM CLI installieren, müssen Sie den AWS CLI und Docker installieren. Weitere Informationen finden Sie unter [Voraussetzungen](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html) für die Installation der AWS SAM CLI.
1. Gehen Sie die [AWS SAM Schnellstart](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html)-Dokumentation durch. Beachten Sie die Schritte zum Ausführen folgender Aufgaben:
1. [Initialisieren der Anwendung](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html#gs-ex1-setup-local-app)
1. [Lokales Testen der Anwendung](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html#gs-ex1-test-locally)
Dadurch wird ein `sam-app` Verzeichnis erstellt und eine Umgebung erstellt, die eine Python-basierte Hello World Lambda-Funktion enthält.
## Schritt 2: AWS SAM CLI Local testen
Nachdem Sie die Hello World Lambda-Funktion installiert AWS SAM und erstellt haben, können Sie die Funktion testen. Geben Sie den folgenden Befehl im Verzeichnis `sam-app` ein:
```
sam local start-api
```
Dadurch wird eine lokale Instanz Ihrer Lambda-Funktion gestartet. Die Ausgabe sollte folgendermaßen oder ähnlich aussehen:
```
2019-01-31 16:40:27 Found credentials in shared credentials file: ~/.aws/credentials
2019-01-31 16:40:27 Mounting HelloWorldFunction at http://127.0.0.1:3000/hello [GET]
2019-01-31 16:40:27 You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template
2019-01-31 16:40:27 * Running on http://127.0.0.1:3000/ (Press CTRL+C to quit)
```
Öffnen Sie einen Browser und geben Sie Folgendes ein:
```
http://127.0.0.1:3000/hello
```
Dadurch wird eine Antwort ähnlich der folgenden ausgegeben:
```
{"message": "hello world", "location": "72.21.198.66"}
```
Geben Sie **STRG\$1C** ein, um die Lambda-API zu beenden.
## Schritt 3: AWS SAM CLI Local starten
Nachdem Sie getestet haben, ob die Funktion funktioniert, starten Sie AWS SAM CLI Local. Geben Sie den folgenden Befehl im Verzeichnis `sam-app` ein:
```
sam local start-lambda
```
Dadurch wird AWS SAM CLI Local gestartet und der zu verwendende Endpunkt bereitgestellt, ähnlich der folgenden Ausgabe:
```
2019-01-29 15:33:32 Found credentials in shared credentials file: ~/.aws/credentials
2019-01-29 15:33:32 Starting the Local Lambda Service. You can now invoke your Lambda Functions defined in your template through the endpoint.
2019-01-29 15:33:32 * Running on http://127.0.0.1:3001/ (Press CTRL+C to quit)
```
## Schritt 4: Step Functions Local starten
### JAR-Datei
Wenn Sie die `.jar` Dateiversion von Step Functions Local verwenden, starten Sie Step Functions und geben Sie den Lambda-Endpunkt an. Geben Sie in dem Verzeichnis, in das Sie die `.jar` Dateien extrahiert haben, den folgenden Befehl ein:
```
java -jar StepFunctionsLocal.jar --lambda-endpoint http://localhost:3001
```
Wenn Step Functions Local gestartet wird, überprüft es die Umgebung und dann die in Ihrer `~/.aws/credentials` Datei konfigurierten Anmeldeinformationen. Standardmäßig verwendet es zunächst eine fiktive Benutzer-ID und wird als aufgeführt. `region us-east-1`
```
2019-01-29 15:38:06.324: Failed to load credentials from environment because Unable to load AWS credentials from environment variables (AWS_ACCESS_KEY_ID (or AWS_ACCESS_KEY) and AWS_SECRET_KEY (or AWS_SECRET_ACCESS_KEY))
2019-01-29 15:38:06.326: Loaded credentials from profile: default
2019-01-29 15:38:06.326: Starting server on port 8083 with account account-id, region us-east-1
```
### Docker
Wenn Sie die Docker-Version von Step Functions Local verwenden, starten Sie Step Functions mit dem folgenden Befehl:
```
docker run -p 8083:8083 amazon/aws-stepfunctions-local
```
Informationen zur Installation der Docker-Version von Step Functions finden Sie unter[Step Functions lokal einrichten (herunterladbare Version) in Docker](sfn-local.md#sfn-local-docker).
**Anmerkung**
Sie können den Endpunkt über die Befehlszeile oder durch das Setzen von Umgebungsvariablen angeben, wenn Sie Step Functions von der `.jar` Datei aus starten. Für die Docker-Version müssen Sie die Endpunkte und Anmeldeinformationen in einer Textdatei angeben. Siehe [Konfigurationsoptionen für Step Functions lokal einrichten](sfn-local.md#sfn-local-config-options).
## Schritt 5: Erstellen Sie eine Zustandsmaschine, die auf Ihre lokale AWS SAM CLI-Funktion verweist
Nachdem Step Functions Local ausgeführt wurde, erstellen Sie eine Zustandsmaschine, die auf die verweist`HelloWorldFunction`, in [Schritt 1: Einrichten AWS SAM](#install-sam) der Sie initialisiert haben.
```
aws stepfunctions --endpoint http://localhost:8083 create-state-machine --definition "{\
\"Comment\": \"A Hello World example of the Amazon States Language using an AWS Lambda Local function\",\
\"StartAt\": \"HelloWorld\",\
\"States\": {\
\"HelloWorld\": {\
\"Type\": \"Task\",\
\"Resource\": \"arn:aws:lambda:region:account-id:function:HelloWorldFunction\",\
\"End\": true\
}\
}\
}\" --name "HelloWorld" --role-arn "arn:aws:iam::012345678901:role/DummyRole"
```
Dadurch wird eine Zustandsmaschine erstellt und ein Amazon-Ressourcenname (ARN) bereitgestellt, mit dem Sie eine Ausführung starten können.
```
{
"creationDate": 1548805711.403,
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld"
}
```
## Schritt 6: Die Ausführung des lokalen Zustandsautomaten starten
Sobald Sie eine Zustandsmaschine erstellt haben, starten Sie eine Ausführung. Sie müssen den Endpunkt und den ARN der Zustandsmaschine referenzieren, wenn Sie den folgenden **aws stepfunctions** Befehl verwenden:
```
aws stepfunctions --endpoint http://localhost:8083 start-execution --state-machine arn:aws:states:region:account-id:stateMachine:HelloWorld --name test
```
Dadurch wird eine Ausführung gestartet, die nach Ihrer `test` `HelloWorld` Zustandsmaschine benannt ist.
```
{
"startDate": 1548810641.52,
"executionArn": "arn:aws:states:region:account-id:execution:HelloWorld:test"
}
```
Da Step Functions nun lokal ausgeführt wird, können Sie mit dem Programm interagieren AWS CLI. Um beispielsweise Informationen zu dieser Ausführung zu erhalten, verwenden Sie den folgenden Befehl:
```
aws stepfunctions --endpoint http://localhost:8083 describe-execution --execution-arn arn:aws:states:region:account-id:execution:HelloWorld:test
```
Wenn Sie `describe-execution` eine Ausführung aufrufen, erhalten Sie vollständigere Informationen, die der folgenden Ausgabe ähneln:
```
{
"status": "SUCCEEDED",
"startDate": 1549056334.073,
"name": "test",
"executionArn": "arn:aws:states:region:account-id:execution:HelloWorld:test",
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld",
"stopDate": 1549056351.276,
"output": "{\"statusCode\": 200, \"body\": \"{\\\"message\\\": \\\"hello world\\\", \\\"location\\\": \\\"72.21.198.64\\\"}\"}",
"input": "{}"
}
```
# 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."
}
```