Concepts clés de cette rubrique Étape 1 : Spécifier les intégrations de services simulées dans un fichier de configuration fictif Étape 2 : Fournir le fichier de configuration fictif à Step Functions Local Étape 3 : Exécuter des tests d'intégration de services simulés

Utilisation d'intégrations de services simulées

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, consultezConfiguration des options de configuration pour Step Functions Local.

Rubriques

Concepts clés de cette rubrique
Étape 1 : Spécifier les intégrations de services simulées dans un fichier de configuration fictif
Étape 2 : Fournir le fichier de configuration fictif à Step Functions Local
Étape 3 : Exécuter des tests d'intégration de services simulés
Fichier de configuration pour les intégrations de services simulées

Concepts clés de cette rubrique

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 aux 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.

É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.

Pour ce faire, vous devez créer un fichier de configuration fictif contenant les sections définies dansPrésentation de la structure de la configuration fictive.

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 etSQSState.
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 et à l'envoi d'un message à Amazon SQS. Dans cet exemple, la machine à LambdaSQSIntegrationétats contient trois cas de test nommés HappyPathRetryPath, et HybridPath qui simulent les Task états nommés LambdaState etSQSState. 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éeLambdaSQSIntegration, qui définit deux états de tâches d'intégration de services nommés LambdaState etSQSState. LambdaStatecontient une politique de nouvelle tentative basée surStates.ALL.
```
{
  "Comment":"This state machine is called: LambdaSQSIntegration",
  "StartAt":"LambdaState",
  "States":{
    "LambdaState":{
      "Type":"Task",
      "Resource":"arn:aws:states:::lambda:invoke",
      "Parameters":{
        "Payload.$":"$",
        "FunctionName":"HelloWorldFunction"
      },
      "Retry":[
        {
          "ErrorEquals":[
            "States.ALL"
          ],
          "IntervalSeconds":2,
          "MaxAttempts":3,
          "BackoffRate":2
        }
      ],
      "Next":"SQSState"
    },
    "SQSState":{
      "Type":"Task",
      "Resource":"arn:aws:states:::sqs:sendMessage",
      "Parameters":{
        "QueueUrl":"https://sqs.us-east-1.amazonaws.com/123456789012/myQueue",
        "MessageBody.$":"$"
      },
      "End": true
    }
  }
}
```
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'SQSStateutilisation 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'SQSStateutilisation 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'LambdaStateexé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
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, consultezConfiguration d'intégrations de services simulées.

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 appelHelloFromLambda.

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 queStep FunctionsLocal.jar. Lorsque vous utilisez cette méthode, vous devez nommer le fichier de configuration fictifMockConfigFile.json.
Dans la session d'exécution de Step Functions Local, définissez une variable d'environnement nomméeSFN_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éfinissezSFN_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.

Créez une machine à états basée sur la définition mentionnée précédemment dans le fichier de configuration fictif.


aws stepfunctions create-state-machine \
    --endpoint http://localhost:8083 \
    --definition "{\"Comment\":\"Thisstatemachineiscalled:LambdaSQSIntegration\",\"StartAt\":\"LambdaState\",\"States\":{\"LambdaState\":{\"Type\":\"Task\",\"Resource\":\"arn:aws:states:::lambda:invoke\",\"Parameters\":{\"Payload.$\":\"$\",\"FunctionName\":\"arn:aws:lambda:us-east-1:123456789012:function:HelloWorldFunction\"},\"Retry\":[{\"ErrorEquals\":[\"States.ALL\"],\"IntervalSeconds\":2,\"MaxAttempts\":3,\"BackoffRate\":2}],\"Next\":\"SQSState\"},\"SQSState\":{\"Type\":\"Task\",\"Resource\":\"arn:aws:states:::sqs:sendMessage\",\"Parameters\":{\"QueueUrl\":\"https://sqs.us-east-1.amazonaws.com/123456789012/myQueue\",\"MessageBody.$\":\"$\"},\"End\":true}}}" \
    --name "LambdaSQSIntegration" --role-arn "arn:aws:iam::123456789012:role/service-role/LambdaSQSIntegration"

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'StartExecutionAPI 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_nameest 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. 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:us-east-1:123456789012:stateMachine:LambdaSQSIntegration#HappyPath
```
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:us-east-1:123456789012:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices"
}
```

Vérifiez les résultats de l'exécution en effectuant un appel ListExecutionsDescribeExecution, ou GetExecutionHistory API.


aws stepfunctions get-execution-history \
    --endpoint http://localhost:8083 \
    --execution-arn arn:aws:states:us-east-1:123456789012: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. 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 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
                }
            }
        },
        ...
    ]
}

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Tester les fonctions de l'étape et l'AWS SAMinterface de ligne de commande locale

Fichier de configuration pour les intégrations de services simulées

Utilisation d'intégrations de services simulées

Note

Rubriques

Concepts clés de cette rubrique

Étape 1 : Spécifier les intégrations de services simulées dans un fichier de configuration fictif

Note

Important

Étape 2 : Fournir le fichier de configuration fictif à Step Functions Local

Note

Note

Étape 3 : Exécuter des tests d'intégration de services simulés