Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Tester des machines à états avec Step Functions Local (non pris en charge)
**Step Functions Local n'est pas pris en charge**
Step Functions Local n'**assure pas** la parité des fonctionnalités et n'est **pas pris en charge**.
Vous pouvez envisager des solutions tierces qui émulent Step Functions à des fins de test.
Comme alternative à Step Functions Local, vous pouvez utiliser l' TestState API pour tester la logique de votre machine à états avant de la déployer sur votre AWS compte. Pour plus d'informations, consultez la section [Tester les machines à états avec TestState l'API](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html).
Avec AWS Step Functions Local, une version téléchargeable de Step Functions, vous pouvez tester des applications avec Step Functions exécutées dans votre propre environnement de développement.
Lorsque vous exécutez Step Functions Local, vous pouvez utiliser l'une des méthodes suivantes pour invoquer des intégrations de services :
+ Configuration de points de terminaison locaux pour AWS Lambda et d'autres services.
+ Téléphoner directement à un AWS service depuis Step Functions Local.
+ Se moquer de la réponse des intégrations de services.
AWS Step Functions Local est disponible sous forme de package JAR ou d'image Docker autonome qui s'exécute sur Microsoft Windows, Linux, macOS et d'autres plateformes compatibles avec Java ou Docker.
**Avertissement**
Vous ne devez utiliser Step Functions Local qu'à des fins de test et ne jamais traiter d'informations sensibles.
**Topics**
+ [Configuration de Step Functions Local et Docker](#sfn-local-docker)
+ [Configuration de Step Functions en local - Version Java](#sfn-local-jar)
+ [Configuration des options locales de Step Functions](#sfn-local-config-options)
+ [Exécution de Step Functions en local](#sfn-local-computer)
+ [Tutoriel : Test à l'aide de Step Functions et de AWS SAM CLI Local](sfn-local-lambda.md)
+ [Tests avec des intégrations de services simulées](sfn-local-test-sm-exec.md)
## Configuration de Step Functions en local (version téléchargeable) dans Docker
L'image Docker Step Functions Local vous permet de démarrer rapidement avec Step Functions Local en utilisant une image Docker avec toutes les dépendances nécessaires. L'image Docker vous permet d'inclure Step Functions Local dans vos versions conteneurisées et dans le cadre de vos tests d'intégration continus.
Pour obtenir l'image Docker de Step Functions Local, consultez [https://hub.docker.com/r/amazon/ aws-stepfunctions-local](https://hub.docker.com/r/amazon/aws-stepfunctions-local) ou entrez la commande `pull` Docker suivante.
```
docker pull amazon/aws-stepfunctions-local
```
Pour démarrer la version téléchargeable de Step Functions sur Docker, exécutez la commande `run` Docker suivante
```
docker run -p 8083:8083 amazon/aws-stepfunctions-local
```
Pour interagir avec les services pris en charge AWS Lambda ou avec d'autres services pris en charge, vous devez d'abord configurer vos informations d'identification et les autres options de configuration. Pour plus d’informations, consultez les rubriques suivantes :
+ [Configuration des options de configuration pour Step Functions Local](#sfn-local-config-options)
+ [Informations d'identification et configuration pour Docker](#docker-credentials)
## Configuration de Step Functions en local (version téléchargeable) - Version Java
La version téléchargeable de AWS Step Functions est fournie sous forme de fichier JAR exécutable et d'image Docker. L'application Java s'exécute sur Windows, Linux, macOS X et autres plateformes qui prennent en charge Java. En plus de Java, vous devez installer le AWS Command Line Interface (AWS CLI). Pour plus d'informations sur l'installation et la configuration du AWS CLI, consultez le [guide de AWS Command Line Interface l'utilisateur](https://docs.aws.amazon.com/cli/latest/userguide/).
**Pour configurer et exécuter Step Functions sur votre ordinateur**
1. Téléchargez Step Functions à l'aide des liens suivants.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/step-functions/latest/dg/sfn-local.html)
1. Extrayez le fichier `.zip`.
1. Testez le téléchargement et affichez les informations de version.
```
$ java -jar StepFunctionsLocal.jar -v
Step Function Local
Version: 2.0.0
Build: 2024-05-18
```
1. (Facultatif) Affichez la liste des commandes disponibles.
```
$ java -jar StepFunctionsLocal.jar -h
```
1. Pour démarrer Step Functions sur votre ordinateur, ouvrez une invite de commande, accédez au répertoire dans lequel vous avez effectué l'extraction `StepFunctionsLocal.jar` et entrez la commande suivante.
```
java -jar StepFunctionsLocal.jar
```
1. Pour accéder à Step Functions s'exécutant localement, utilisez le `--endpoint-url` paramètre. Par exemple, en utilisant le AWS CLI, vous devez spécifier les commandes Step Functions comme suit :
```
aws stepfunctions --endpoint-url http://localhost:8083 command
```
**Note**
Par défaut, Step Functions Local utilise un compte de test local et des informations d'identification, et la AWS région est définie sur USA Est (Virginie du Nord). Pour utiliser Step Functions Local avec AWS Lambda ou d'autres services pris en charge, vous devez configurer vos informations d'identification et votre région.
Si vous utilisez des flux de travail Express avec Step Functions Local, l'historique d'exécution sera enregistré dans un fichier journal. Il n'est pas enregistré dans CloudWatch Logs. Le chemin du fichier journal sera basé sur l'ARN du groupe de CloudWatch journaux des journaux fourni lors de la création de la machine d'état locale. Le fichier journal sera stocké `/aws/states/log-group-name/${execution_arn}.log` par rapport à l'emplacement où vous exécutez Step Functions Local. Par exemple, si l'ARN d'exécution est :
```
arn:aws:states:region:account-id:express:test:example-ExpressLogGroup-wJalrXUtnFEMI
```
le fichier journal sera :
```
aws/states/log-group-name/arn:aws:states:region:account-id:express:test:example-ExpressLogGroup-wJalrXUtnFEMI.log
```
## Configuration des options de configuration pour Step Functions Local
Lorsque vous démarrez AWS Step Functions Local à l'aide du fichier JAR, vous pouvez définir les options de configuration en utilisant le AWS Command Line Interface (AWS CLI) ou en les incluant dans l'environnement système. Pour Docker, vous devez spécifier ces options dans un fichier auquel vous faites référence lors du démarrage de Step Functions Local.
### Options de configuration
Lorsque vous configurez le conteneur Step Functions Local pour utiliser un point de terminaison de remplacement tel que Lambda Endpoint et Batch Endpoint, et que vous appelez ce point de terminaison, Step Functions Local n'utilise pas [les](#docker-credentials) informations d'identification que vous spécifiez. La définition de ces remplacements de point de terminaison est facultative.
| Option | Ligne de commande | Environnement |
| --- | --- | --- |
| Compte | -compte, --aws-account | AWS\$1ACCOUNT\$1ID |
| Région | -région, --aws-region | AWS\$1DEFAULT\$1RÉGION |
| Échelle de délai d'attente | -waitTimeScale, --wait-time-scale | WAIT\$1TIME\$1SCALE |
| Point de terminaison Lambda | -Point de terminaison Lambda, --lambda-point de terminaison | LAMBDA\$1ENDPOINT |
| Point de terminaison par lot | -BatchEndpoint, --batch-endpoint | BATCH\$1ENDPOINT |
| Point de terminaison DynamoDB | -dynamo, --dynamodb-endpoint DBEndpoint | DYNAMODB\$1ENDPOINT |
| Point de terminaison ECS | -ECSendpoint, --ecs-endpoint | ECS\$1ENDPOINT |
| Point de terminaison Glue | -glueEndpoint, --glue-endpoint | GLUE\$1ENDPOINT |
| SageMaker Point final | -sageMakerEndpoint, --sagemaker-endpoint | SAGE\$1MAKER\$1ENDPOINT |
| Point de terminaison SQS | -SQSendpoint, --sqs-endpoint | SQS\$1ENDPOINT |
| Point de terminaison SNS | -SNSendpoint, --sns-endpoint | SNS\$1ENDPOINT |
| Point de terminaison Step Functions | -stepFunctionsEndpoint, --step-functions-endpoint | STEP\$1FUNCTIONS\$1ENDPOINT |
### Informations d'identification et configuration pour Docker
Pour configurer Step Functions Local pour Docker, créez le fichier suivant : `aws-stepfunctions-local-credentials.txt`
Ce fichier contient vos informations d'identification et d'autres options de configuration. Ce qui suit peut être utilisé comme modèle lors de la création du `aws-stepfunctions-local-credentials.txt` fichier.
```
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
```
Une fois que vous avez configuré vos informations d'identification et vos options de configuration dans`aws-stepfunctions-local-credentials.txt`, lancez Step Functions avec la commande suivante.
```
docker run -p 8083:8083 --env-file aws-stepfunctions-local-credentials.txt amazon/aws-stepfunctions-local
```
**Note**
Il est recommandé d'utiliser le nom DNS spécial`host.docker.internal`, qui correspond à l'adresse IP interne utilisée par l'hôte, par exemple`http://host.docker.internal:8000`. Pour plus d'informations, consultez la documentation Docker pour Mac et Windows sous [Fonctionnalités réseau dans Docker Desktop pour Mac](https://docs.docker.com/desktop/mac/networking/#use-cases-and-workaround) et [Fonctionnalités réseau dans Docker Desktop pour](https://docs.docker.com/desktop/windows/networking/) Windows respectivement.
## Exécution de Step Functions Local sur votre ordinateur
Utilisez la version locale de Step Functions pour configurer, développer et tester des machines d'état sur votre ordinateur.
### Exécuter une machine HelloWorld d'état localement
Après avoir exécuté Step Functions localement avec le AWS Command Line Interface (AWS CLI), vous pouvez démarrer une exécution State Machine.
1. Créez une machine à états à partir du AWS CLI en échappant à la définition de la machine à états.
```
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"
```
**Note**
Le n'`role-arn`est pas utilisé pour Step Functions Local, mais vous devez l'inclure avec la syntaxe appropriée. Vous pouvez utiliser l'ARN (Amazon Resource Name) de l'exemple précédent.
Si vous créez correctement la machine à états, Step Functions répond en indiquant la date de création et l'ARN de la machine à états.
```
{
"creationDate": 1548454198.202,
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld"
}
```
1. Démarrez une exécution à l'aide de l'ARN de la machine d'état que vous avez créée.
```
aws stepfunctions --endpoint-url http://localhost:8083 start-execution --state-machine-arn arn:aws:states:region:account-id:stateMachine:HelloWorld
```
### Step Functions Local avec AWS SAM CLI Local
Vous pouvez utiliser la version locale de Step Functions avec une version locale de AWS Lambda. Pour configurer cela, vous devez installer et configurer AWS SAM.
Pour plus d'informations sur la configuration et l'exécution AWS SAM, consultez les rubriques suivantes :
+ [Configuration AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html)
+ [Démarrer la AWS SAM CLI locale](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-local-start-lambda.html)
Lorsque Lambda est exécuté sur votre système local, vous pouvez démarrer Step Functions Local. Dans le répertoire où vous avez extrait vos fichiers JAR locaux de Step Functions, lancez Step Functions Local et utilisez le `--lambda-endpoint` paramètre pour configurer le point de terminaison Lambda local.
```
java -jar StepFunctionsLocal.jar --lambda-endpoint http://127.0.0.1:3001 command
```
Pour plus d'informations sur l'exécution de Step Functions Local avec AWS Lambda, consultez[Tutoriel : Test des flux de travail à l'aide de Step Functions et de AWS SAM CLI Local](sfn-local-lambda.md).
# Tutoriel : Test des flux de travail à l'aide de Step Functions et de AWS SAM CLI Local
**Step Functions Local n'est pas pris en charge**
Step Functions Local n'**assure pas** la parité des fonctionnalités et n'est **pas pris en charge**.
Vous pouvez envisager des solutions tierces qui émulent Step Functions à des fins de test.
Comme alternative à Step Functions Local, vous pouvez utiliser l' TestState API pour tester la logique de votre machine à états avant de la déployer sur votre AWS compte. Pour plus d'informations, consultez la section [Tester les machines à états avec TestState l'API](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html).
Avec les deux AWS Step Functions et AWS Lambda en les exécutant sur votre machine locale, vous pouvez tester votre machine à états et les fonctions Lambda sans y déployer votre code. AWS
Pour plus d’informations, consultez les rubriques suivantes :
+ [Tester des machines à états avec Step Functions Local (non pris en charge)](sfn-local.md)
+ [Configuration AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html)
## Étape 1 : Configuration AWS SAM
AWS Serverless Application Model (AWS SAM) CLI Local nécessite l'installation de AWS Command Line Interface AWS SAM, et de Docker.
1. [Installez la AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html).
**Note**
Avant d'installer la AWS SAM CLI, vous devez installer Docker AWS CLI et. Consultez les [conditions préalables à](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html) l'installation de la AWS SAM CLI.
1. Lisez la documentation [AWS SAM Quick Start](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html). Assurez-vous de suivre les étapes pour effectuer les opérations suivantes :
1. [Initialiser l'application](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html#gs-ex1-setup-local-app)
1. [Tester l'application localement](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html#gs-ex1-test-locally)
Cela crée un `sam-app` répertoire et crée un environnement qui inclut une fonction Lambda Hello World basée sur Python.
## Étape 2 : Tester la AWS SAM CLI locale
Maintenant que vous avez installé AWS SAM et créé la fonction Lambda Hello World, vous pouvez la tester. Dans le répertoire `sam-app`, entrez la commande suivante :
```
sam local start-api
```
Cela lance une instance locale de votre fonction Lambda. Vous devez voir des résultats similaires à ce qui suit :
```
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)
```
Ouvrez un navigateur et entrez les informations suivantes :
```
http://127.0.0.1:3000/hello
```
Cela produira une réponse similaire à la suivante :
```
{"message": "hello world", "location": "72.21.198.66"}
```
Entrez **CTRL\$1C** pour terminer l'API Lambda.
## Étape 3 : démarrer la AWS SAM CLI locale
Maintenant que vous avez testé le fonctionnement de la fonction, lancez AWS SAM CLI Local. Dans le répertoire `sam-app`, entrez la commande suivante :
```
sam local start-lambda
```
Cela démarre AWS SAM CLI Local et fournit le point de terminaison à utiliser, comme dans le résultat suivant :
```
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)
```
## Étape 4 : Démarrez Step Functions Local
### Fichier JAR
Si vous utilisez la version `.jar` fichier de Step Functions Local, lancez Step Functions et spécifiez le point de terminaison Lambda. Dans le répertoire où vous avez extrait les `.jar` fichiers, entrez la commande suivante :
```
java -jar StepFunctionsLocal.jar --lambda-endpoint http://localhost:3001
```
Lorsque Step Functions Local démarre, il vérifie l'environnement, puis les informations d'identification configurées dans votre `~/.aws/credentials` fichier. Par défaut, il commence par utiliser un nom d'utilisateur fictif et est répertorié sous le nom. `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
Si vous utilisez la version Docker de Step Functions Local, lancez Step Functions avec la commande suivante :
```
docker run -p 8083:8083 amazon/aws-stepfunctions-local
```
Pour plus d'informations sur l'installation de la version Docker de Step Functions, consultez[Configuration de Step Functions en local (version téléchargeable) dans Docker](sfn-local.md#sfn-local-docker).
**Note**
Vous pouvez spécifier le point de terminaison via la ligne de commande ou en définissant des variables d'environnement si vous lancez Step Functions depuis le `.jar` fichier. Pour la version Docker, vous devez spécifier les points de terminaison et les informations d'identification dans un fichier texte. Consultez [Configuration des options de configuration pour Step Functions Local](sfn-local.md#sfn-local-config-options).
## Étape 5 : créer une machine à états qui fait référence à votre fonction locale AWS SAM CLI
Une fois que Step Functions Local est en cours d'exécution, créez une machine à états qui fait référence à `HelloWorldFunction` celle dans [Étape 1 : Configuration AWS SAM](#install-sam) laquelle vous l'avez initialisée.
```
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"
```
Cela créera une machine à états et fournira un Amazon Resource Name (ARN) que vous pourrez utiliser pour démarrer une exécution.
```
{
"creationDate": 1548805711.403,
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld"
}
```
## Étape 6 : Démarrer une exécution de votre machine d'état locale
Une fois que vous avez créé une machine à états, lancez une exécution. Vous devez faire référence au point de terminaison et à l'ARN de la machine à états lorsque vous utilisez la **aws stepfunctions** commande suivante :
```
aws stepfunctions --endpoint http://localhost:8083 start-execution --state-machine arn:aws:states:region:account-id:stateMachine:HelloWorld --name test
```
Cela lance une exécution nommée `test` de votre machine `HelloWorld` d'état.
```
{
"startDate": 1548810641.52,
"executionArn": "arn:aws:states:region:account-id:execution:HelloWorld:test"
}
```
Maintenant que Step Functions est exécuté localement, vous pouvez interagir avec celui-ci à l'aide du AWS CLI. Par exemple, pour obtenir des informations sur cette exécution, utilisez la commande suivante :
```
aws stepfunctions --endpoint http://localhost:8083 describe-execution --execution-arn arn:aws:states:region:account-id:execution:HelloWorld:test
```
L'`describe-execution`appel à une exécution fournit des détails plus complets, similaires à la sortie suivante :
```
{
"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": "{}"
}
```
# Utilisation d'intégrations de services simulées pour les tests dans Step Functions Local
**Step Functions Local n'est pas pris en charge**
Step Functions Local n'**assure pas** la parité des fonctionnalités et n'est **pas pris en charge**.
Vous pouvez envisager des solutions tierces qui émulent Step Functions à des fins de test.
Dans Step Functions Local, vous pouvez tester les chemins d'exécution de vos machines d'état sans réellement appeler de services intégrés en utilisant des intégrations de services simulées. Pour configurer vos machines d'état afin d'utiliser des intégrations de services simulées, vous devez créer un fichier de configuration fictif. Dans ce fichier, vous définissez le résultat souhaité de vos intégrations de services sous forme de réponses simulées et les exécutions qui utilisent vos réponses simulées pour simuler un chemin d'exécution sous forme de cas de test.
En fournissant le fichier de configuration fictif à Step Functions Local, vous pouvez tester les appels d'intégration de services en exécutant des machines d'état qui utilisent les réponses simulées spécifiées dans les scénarios de test au lieu de passer de véritables appels d'intégration de services.
**Note**
Si vous ne spécifiez pas de réponses d'intégration de service simulées dans le fichier de configuration fictif, Step Functions Local invoquera l'intégration de AWS services en utilisant le point de terminaison que vous avez configuré lors de la configuration de Step Functions Local. Pour plus d'informations sur la configuration des points de terminaison pour Step Functions Local, consultez[Configuration des options de configuration pour Step Functions Local](sfn-local.md#sfn-local-config-options).
Cette rubrique utilise plusieurs concepts définis dans la liste suivante :
+ Intégrations de services simulées - Fait référence aux états des tâches configurés pour utiliser des réponses simulées au lieu d'effectuer de véritables appels de service.
+ Réponses simulées - Fait référence à des données fictives que les états des tâches peuvent être configurés pour utiliser.
+ Cas de test : fait référence aux exécutions automatiques configurées pour utiliser des intégrations de services simulées.
+ Fichier de configuration fictif - Fait référence au fichier de configuration fictif contenant du JSON, qui définit les intégrations de services simulées, les réponses simulées et les cas de test.
## Configuration d'intégrations de services simulées
Vous pouvez simuler n'importe quelle intégration de service à l'aide de Step Functions Local. Cependant, Step Functions Local n'impose pas que les maquettes soient identiques aux vraies APIs. Une tâche simulée n'appellera jamais le point de terminaison du service. Si vous ne spécifiez pas de réponse simulée, une tâche tentera d'appeler les points de terminaison du service. En outre, Step Functions Local génère automatiquement un jeton de tâche lorsque vous simulez une tâche à l'aide du`.waitForTaskToken`.
## Étape 1 : Spécifier les intégrations de services simulées dans un fichier de configuration fictif
Vous pouvez tester le AWS SDK Step Functions et les intégrations de services optimisées à l'aide de Step Functions Local. L'image suivante montre la machine à états définie dans l'onglet Définition de la machine à états :
![\[Exemple simulé d'intégration de services.\]](http://docs.aws.amazon.com/fr_fr/step-functions/latest/dg/images/msi-graph.png)
Pour ce faire, vous devez créer un fichier de configuration fictif contenant les sections définies dans[Structure de fichier de configuration fictive](#mock-cfg-struct).
1. Créez un fichier nommé `MockConfigFile.json` pour configurer les tests avec des intégrations de services simulées.
L'exemple suivant montre un fichier de configuration fictif faisant référence à une machine à états avec deux états définis nommés `LambdaState` et`SQSState`.
------
#### [ Mock configuration file example ]
Voici un exemple de fichier de configuration fictif qui montre comment simuler des réponses suite à l'[appel d'une fonction Lambda](connect-lambda.md) [et à l'envoi d'un message à Amazon SQS](connect-sqs.md). Dans cet exemple, la machine à [`LambdaSQSIntegration`](#mock-cfg-sm-sect)états contient trois cas de test nommés `HappyPath``RetryPath`, et `HybridPath` qui simulent les `Task` états nommés `LambdaState` et`SQSState`. Ces états utilisent les réponses de `MockedLambdaSuccess` service `MockedSQSSuccess` simulées et les `MockedLambdaRetry` réponses de service simulées. Ces réponses de service simulées sont définies dans la `MockedResponses` section du fichier.
```
{
"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 ]
Voici un exemple de définition de machine à états appelée`LambdaSQSIntegration`, qui définit deux états de tâches d'intégration de services nommés `LambdaState` et`SQSState`. `LambdaState`contient une politique de nouvelle tentative basée sur`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/account-id/myQueue",
"MessageBody.$":"$"
},
"End": true
}
}
}
```
------
Vous pouvez exécuter la définition de machine à `LambdaSQSIntegration` états référencée dans le fichier de configuration fictif en utilisant l'un des cas de test suivants :
+ `HappyPath`- Ce test simule la sortie de `LambdaState` et l'`SQSState`utilisation de `MockedLambdaSuccess` et `MockedSQSSuccess` respectivement.
+ Le `LambdaState` renverra la valeur suivante :
```
"0":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
```
+ Le `SQSState` renverra la valeur suivante :
```
"0":{
"Return":{
"MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51",
"MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51"
}
}
```
+ `RetryPath`- Ce test simule la sortie de `LambdaState` et l'`SQSState`utilisation de `MockedLambdaRetry` et `MockedSQSSuccess` respectivement. En outre, `LambdaState` est configuré pour effectuer quatre tentatives de nouvelle tentative. Les réponses simulées pour ces tentatives sont définies et indexées dans l'`MockedLambdaRetry`état.
+ La tentative initiale se termine par un échec de tâche contenant un message de cause et d'erreur, comme illustré dans l'exemple suivant :
```
"0":{
"Throw": {
"Error": "Lambda.ResourceNotReadyException",
"Cause": "Lambda resource is not ready."
}
}
```
+ La première et la deuxième tentative se terminent par un échec de tâche contenant un message de cause et d'erreur, comme illustré dans l'exemple suivant :
```
"1-2":{
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
}
```
+ La troisième tentative se termine par une tâche réussie contenant le résultat d'état de la section Payload dans la réponse Lambda simulée.
```
"3":{
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
}
```
**Note**
Pour les États dotés d'une politique de nouvelles tentatives, Step Functions Local épuisera le nombre de tentatives définies dans la politique jusqu'à ce qu'il reçoive une réponse positive. Cela signifie que vous devez indiquer les simulations pour les tentatives avec des numéros de tentatives consécutifs et que vous devez couvrir toutes les tentatives avant de renvoyer une réponse positive.
Si vous ne spécifiez pas de réponse simulée pour une nouvelle tentative spécifique, par exemple, réessayez « 3 », l'exécution de la machine à états échouera.
+ `HybridPath`- Ce test simule le résultat de. `LambdaState` Une fois l'`LambdaState`exécution réussie et la réception de données simulées en réponse, `SQSState` effectue un véritable appel de service à la ressource spécifiée en production.
Pour plus d'informations sur la façon de démarrer des exécutions de tests avec des intégrations de services simulées, consultez. [Étape 3 : Exécuter des tests d'intégration de services simulés](#run-mocked-serv-integ-tests)
1. Assurez-vous que la structure des réponses simulées est conforme à la structure des réponses de service réelles que vous recevez lorsque vous passez des appels de service intégrés. Pour plus d'informations sur les exigences structurelles applicables aux réponses simulées, consultez[Configuration d'intégrations de services simulées](#mock-resp-struct-req).
Dans l'exemple de fichier de configuration fictif précédent, les réponses simulées sont définies `MockedLambdaSuccess` et `MockedLambdaRetry` conformes à la structure des réponses réelles renvoyées par un appel`HelloFromLambda`.
**Important**
AWS la structure des réponses aux services peut varier d'un service à l'autre. Step Functions Local ne vérifie pas si les structures de réponse simulées sont conformes aux structures de réponse de service réelles. Vous devez vous assurer que vos réponses simulées sont conformes aux réponses réelles avant le test. Pour examiner la structure des réponses du service, vous pouvez soit effectuer les appels de service proprement dits à l'aide de Step Functions, soit consulter la documentation relative à ces services.
## Étape 2 : Fournir le fichier de configuration fictif à Step Functions Local
Vous pouvez fournir le fichier de configuration fictif à Step Functions Local de l'une des manières suivantes :
------
#### [ Docker ]
**Note**
Si vous utilisez la version Docker de Step Functions Local, vous pouvez fournir le fichier de configuration fictif en utilisant uniquement une variable d'environnement. En outre, vous devez monter le fichier de configuration fictif sur le conteneur Step Functions Local lors du démarrage initial du serveur.
Montez le fichier de configuration fictif dans n'importe quel répertoire du conteneur Step Functions Local. Définissez ensuite une variable d'environnement nommée `SFN_MOCK_CONFIG` qui contient le chemin d'accès au fichier de configuration fictif dans le conteneur. Cette méthode permet au fichier de configuration fictif de porter n'importe quel nom tant que la variable d'environnement contient le chemin et le nom du fichier.
La commande suivante indique le format de démarrage de l'image Docker.
```
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
```
L'exemple suivant utilise la commande pour démarrer l'image Docker.
```
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 ]
Utilisez l'une des méthodes suivantes pour fournir le fichier de configuration fictif à Step Functions Local :
+ Placez le fichier de configuration fictif dans le même répertoire que`Step FunctionsLocal.jar`. Lorsque vous utilisez cette méthode, vous devez nommer le fichier de configuration fictif`MockConfigFile.json`.
+ Dans la session d'exécution de Step Functions Local, définissez une variable d'environnement nommée`SFN_MOCK_CONFIG`, sur le chemin complet du fichier de configuration fictif. Cette méthode permet au fichier de configuration fictif de porter n'importe quel nom tant que la variable d'environnement contient son chemin et son nom de fichier. Dans l'exemple suivant, la `SFN_MOCK_CONFIG` variable est définie pour pointer vers un fichier de configuration fictif nommé`EnvSpecifiedMockConfig.json`, situé dans le `/home/workspace` répertoire.
```
export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
```
**Note**
Si vous ne fournissez pas la variable d'environnement `SFN_MOCK_CONFIG` à Step Functions Local, Step Functions Local essaiera par défaut de lire un fichier de configuration fictif nommé `MockConfigFile.json` dans le répertoire à partir duquel vous avez lancé Step Functions Local.
Si vous placez le fichier de configuration fictif dans le même répertoire que la variable d'environnement `Step FunctionsLocal.jar` et que vous la définissez`SFN_MOCK_CONFIG`, Step Functions Local lira le fichier spécifié par la variable d'environnement.
------
## Étape 3 : Exécuter des tests d'intégration de services simulés
Après avoir créé et fourni un fichier de configuration fictif à Step Functions Local, exécutez la machine d'état configurée dans le fichier de configuration fictif à l'aide d'intégrations de services simulées. Vérifiez ensuite les résultats de l'exécution à l'aide d'une action d'API.
1. Créez une machine à états basée sur la définition mentionnée précédemment dans le [fichier de configuration fictif](#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. Exécutez la machine d'état à l'aide d'intégrations de services simulées.
Pour utiliser le fichier de configuration fictif, effectuez un appel d'`[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)`API sur une machine d'état configurée dans le fichier de configuration fictif. Pour ce faire, ajoutez le suffixe`#test_name`, à l'ARN de la machine à états utilisé par. `StartExecution` `test_name`est un cas de test configuré pour la machine d'état dans le même fichier de configuration fictif.
La commande suivante est un exemple d'utilisation de la machine à `LambdaSQSIntegration` états et de la configuration fictive. Dans cet exemple, la machine à `LambdaSQSIntegration` états est exécutée à l'aide du `HappyPath` test défini dans[Étape 1 : Spécifier les intégrations de services simulées dans un fichier de configuration fictif](#create-mock-config-file). Le `HappyPath` test contient la configuration pour l'exécution afin de gérer les appels d'intégration de services fictifs que `SQSState` les États `LambdaState` et les États effectuent à l'aide `MockedLambdaSuccess` des réponses `MockedSQSSuccess` de service simulées.
```
aws stepfunctions start-execution \
--endpoint http://localhost:8083 \
--name executionWithHappyPathMockedServices \
--state-machine arn:aws:states:region:account-id:stateMachine:LambdaSQSIntegration#HappyPath
```
1. Consultez la réponse d'exécution de la machine à états.
La réponse à un appel `StartExecution` utilisant un test d'intégration de service simulé est identique à la réponse à un appel `StartExecution` normal, qui renvoie l'ARN d'exécution et la date de début.
Voici un exemple de réponse à un appel `StartExecution` utilisant le test d'intégration de services simulé :
```
{
"startDate":"2022-01-28T15:03:16.981000-05:00",
"executionArn":"arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices"
}
```
1. Vérifiez les résultats de l'exécution en effectuant un appel `[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)`, ou `[GetExecutionHistory](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetExecutionHistory.html)` API.
```
aws stepfunctions get-execution-history \
--endpoint http://localhost:8083 \
--execution-arn arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices
```
L'exemple suivant illustre certaines parties d'une réponse à un appel `GetExecutionHistory` utilisant l'ARN d'exécution à partir de l'exemple de réponse présenté à l'étape 2. Dans cet exemple, la sortie de `LambdaState` et `SQSState` correspond aux données fictives définies dans `MockedLambdaSuccess` et `MockedSQSSuccess` dans le [fichier de configuration fictif](#create-mock-config-file). En outre, les données simulées sont utilisées de la même manière que les données renvoyées lors de l'exécution d'appels d'intégration de services réels. De plus, dans cet exemple, la sortie de `LambdaState` est transmise `SQSState` en tant qu'entrée.
```
{
"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
}
}
},
...
]
}
```
## Fichier de configuration pour les intégrations de services simulées dans Step Functions
**Step Functions Local n'est pas pris en charge**
Step Functions Local n'**assure pas** la parité des fonctionnalités et n'est **pas pris en charge**.
Vous pouvez envisager des solutions tierces qui émulent Step Functions à des fins de test.
Comme alternative à Step Functions Local, vous pouvez utiliser l' TestState API pour tester la logique de votre machine à états avant de la déployer sur votre AWS compte. Pour plus d'informations, consultez la section [Tester les machines à états avec TestState l'API](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html).
Pour utiliser des intégrations de services simulées, vous devez d'abord créer un fichier de configuration fictif nommé `MockConfigFile.json` contenant vos configurations fictives. Fournissez ensuite à Step Functions Local le fichier de configuration fictif. Ce fichier de configuration définit les cas de test, qui contiennent des états fictifs utilisant des réponses d'intégration de services simulées. La section suivante contient des informations sur la structure de la configuration fictive qui inclut les états fictifs et les réponses simulées :
### Structure de fichier de configuration fictive
Une configuration fictive est un objet JSON contenant les champs de niveau supérieur suivants :
+ `StateMachines`- Les champs de cet objet représentent des machines à états configurées pour utiliser des intégrations de services simulées.
+ `MockedResponse`- Les champs de cet objet représentent des réponses simulées pour les appels d'intégration de services.
Voici un exemple de fichier de configuration fictif qui inclut une `StateMachine` définition et`MockedResponse`.
```
{
"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!"
}
}
}
}
}
}
```
#### Référence de champ de configuration fictive
Les sections suivantes expliquent les champs d'objet de niveau supérieur que vous devez définir dans votre configuration fictive.
+ [StateMachines](#mock-cfg-sm-sect)
+ [MockedResponses](#mock-cfg-mckd-resp-sect)
##### StateMachines
L'`StateMachines`objet définit les machines à états qui utiliseront des intégrations de services simulées. La configuration de chaque machine à états est représentée par un champ de niveau supérieur de`StateMachines`. Le nom du champ est le nom de la machine à états et la valeur est un objet contenant un seul champ nommé`TestCases`, dont les champs représentent des cas de test de cette machine à états.
La syntaxe suivante montre une machine à états avec deux scénarios de test :
```
"MyStateMachine": {
"TestCases": {
"HappyPath": {
...
},
"SadPath": {
...
}
}
```
##### TestCases
Les champs de `TestCases` représentent des cas de test individuels pour la machine à états. Le nom de chaque cas de test doit être unique par machine d'état et la valeur de chaque cas de test est un objet spécifiant une réponse simulée à utiliser pour les états de tâche dans la machine d'état.
L'exemple de a suivant `TestCase` lie deux `Task` états à deux `MockedResponses` :
```
"HappyPath": {
"SomeTaskState": "SomeMockedResponse",
"AnotherTaskState": "AnotherMockedResponse"
}
```
##### MockedResponses
`MockedResponses`est un objet contenant plusieurs objets de réponse simulés avec des noms de champs uniques. Un objet de réponse simulé définit le résultat réussi ou la sortie d'erreur pour chaque appel d'un état de tâche simulé. Vous spécifiez le numéro d'appel à l'aide de chaînes entières individuelles, telles que « 0 », « 1 », « 2 » et « 3 » ou d'une plage inclusive d'entiers, telle que « 0-1 », « 2-3 ».
Lorsque vous simulez une tâche, vous devez spécifier une réponse simulée pour chaque appel. Une réponse doit contenir un seul champ nommé `Return` ou `Throw` dont la valeur est le résultat ou la sortie d'erreur de l'invocation de tâche simulée. Si vous ne spécifiez pas de réponse simulée, l'exécution de la machine à états échouera.
Voici un exemple de `MockedResponse` with `Throw` et d'`Return`objets. Dans cet exemple, les trois premières fois que la machine d'état est exécutée, la réponse spécifiée dans `"0-2"` est renvoyée, et la quatrième fois que la machine d'état s'exécute, la réponse spécifiée dans `"3"` est renvoyée.
```
"SomeMockedResponse": {
"0-2": {
"Throw": {
...
}
},
"3": {
"Return": {
...
}
}
}
```
**Note**
Si vous utilisez un `Map` état et que vous souhaitez garantir des réponses prévisibles pour `Map` cet état, définissez la valeur `maxConcurrency` de 1. Si vous définissez une valeur supérieure à 1, Step Functions Local exécutera plusieurs itérations simultanément, ce qui rendra imprévisible l'ordre d'exécution global des états entre les itérations. Cela peut également amener Step Functions Local à utiliser différentes réponses simulées pour les états d'itération d'une exécution à l'autre.
##### Return
`Return`est représenté sous la forme d'un champ d'`MockedResponse`objets. Il indique le résultat positif d'un état de tâche simulé.
Voici un exemple d'`Return`objet contenant une réponse simulée pour l'appel d'une [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)fonction Lambda :
```
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
```
##### Jeter
`Throw`est représenté sous la forme d'un champ d'`MockedResponse`objets. Il indique le [résultat d'erreur](concepts-error-handling.md) d'une tâche ayant échoué. La valeur de `Throw` doit être un objet contenant des `Cause` champs `Error` et avec des valeurs de chaîne. En outre, la valeur de chaîne que vous spécifiez dans le `Error` champ `MockConfigFile.json` doit correspondre aux erreurs gérées dans les `Catch` sections `Retry` et de votre machine à états.
Voici un exemple d'`Throw`objet contenant une réponse simulée pour l'appel d'une [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html)fonction Lambda :
```
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
```