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 d'état avec une TestState API

Présentation de

Vous pouvez tester un état pris en charge à l'aide de la TestState fonctionnalité de la Step Functions console ou du SDK. AWSCommand Line Interface (AWS CLI)

L'TestStateAPI accepte la définition d'un état et l'exécute. Il vous permet de tester un état sans créer de machine à états ni mettre à jour une machine à états existante. Vous pouvez fournir :

L'TestStateAPI assume un IAM rôle qui doit contenir les IAM autorisations requises pour les ressources auxquelles votre État accède. Lorsque vous spécifiez une maquette, la spécification du rôle devient facultative, ce qui vous permet de tester la logique de la machine d'état sans configurer IAM les autorisations. Pour plus d'informations sur les autorisations dont un État peut avoir besoin, consultezIAMautorisations d'utilisation de l' TestState API.

Rubriques

Utilisation des niveaux d'inspection dans TestState l'API

Lorsque vous testez un état à l'aide de l'TestStateAPI, vous pouvez spécifier le niveau de détail que vous souhaitez afficher dans les résultats du test. Par exemple, si vous avez utilisé des filtres de traitement des données d'entrée et de sortie tels que InputPathou ResultPath, vous pouvez afficher les résultats intermédiaires et finaux du traitement des données. Step Functionsfournit les niveaux d'inspection suivants :

Tous ces niveaux renvoient également les nextState champs status et. statusindique le statut de l'exécution de l'état. Par exemple, SUCCEEDEDFAILED,RETRIABLE, etCAUGHT_ERROR. nextStateindique le nom du prochain état vers lequel effectuer la transition. Si vous n'avez pas défini d'état suivant dans votre définition, ce champ renvoie une valeur vide.

Pour plus d'informations sur le test d'un état à l'aide de ces niveaux d'inspection dans la Step Functions consoleAWS CLI, voir Tester un état à l'aide de la console AWS Step Functions etTester un état en utilisant AWS CLI.

Niveau d'inspection INFO

Si le test réussit, ce niveau indique l'état de sortie. Si le test échoue, ce niveau indique le résultat de l'erreur. Par défaut, Step Functions définit le niveau d'inspection sur INFO si vous ne spécifiez aucun niveau.

Niveau d'inspection DEBUG

Si le test réussit, ce niveau indique l'état de sortie et le résultat du traitement des données d'entrée et de sortie.

Si le test échoue, ce niveau indique le résultat de l'erreur. Ce niveau indique les résultats intermédiaires du traitement des données jusqu'au point de défaillance. Supposons, par exemple, que vous ayez testé un état de tâche qui invoque une Lambda fonction. Imaginez que vous ayez appliqué les Filtrer la sortie d'état à l'aide OutputPath filtres InputPathParameters,Spécification de la sortie d'état à l'aide ResultPath de in Step Functions, et à l'état de la tâche. Supposons que l'invocation ait échoué. Dans ce cas, le DEBUG niveau affiche les résultats du traitement des données en fonction de l'application des filtres dans l'ordre suivant :

Les informations de diagnostic disponibles à ce niveau peuvent vous aider à résoudre les problèmes liés à une intégration de services ou à un flux de traitement des données d'entrée et de sortie que vous avez peut-être défini.

Niveau d'inspection TRACE

Step Functionsfournit le niveau TRACE pour tester une tâche HTTP. Ce niveau renvoie des informations sur la requête HTTP émise Step Functions et la réponse renvoyée par une API HTTPS. La réponse peut contenir des informations, telles que les en-têtes et le corps de la demande. De plus, vous pouvez visualiser l'état de sortie et le résultat du traitement des données d'entrée et de sortie à ce niveau.

Si le test échoue, ce niveau indique le résultat de l'erreur.

Ce niveau ne s'applique qu'à la tâche HTTP. Step Functionsgénère une erreur si vous utilisez ce niveau pour d'autres types d'états.

Lorsque vous définissez le niveau d'inspection sur TRACE, vous pouvez également consulter les secrets inclus dans la EventBridge connexion. Pour ce faire, vous devez définir le revealSecrets paramètre sur true dans l'TestStateAPI. En outre, vous devez vous assurer que l'IAMutilisateur qui appelle l' TestState API est autorisé à effectuer cette states:RevealSecrets action. Pour un exemple de IAM politique définissant l'states:RevealSecretsautorisation, voirIAMautorisations d'utilisation de l' TestState API. Sans cette autorisation, Step Functions renvoie une erreur de refus d'accès.

Si vous définissez le revealSecrets paramètre surfalse, Step Functions omet tous les secrets dans les données de requête et de réponse HTTP. Notez que vous ne pouvez pas l'utiliser revealSecrets lorsque le moquage est activé. Si vous spécifiez les deux revealSecrets et une maquette dans la demande d' TestState API, Step Functions renvoie une exception de validation.

IAMautorisations d'utilisation de l' TestState API

L'IAMutilisateur qui appelle l'TestStateAPI doit être autorisé à effectuer l'states:TestStateaction. Lorsque vous n'utilisez pas le simulacre, l'IAMutilisateur doit également être autorisé à effectuer l'iam:PassRoleaction à laquelle le rôle d'exécution doit être Step Functions transféré. En outre, si vous définissez le revealSecrets paramètre surtrue, l'IAMutilisateur doit être autorisé à effectuer l'states:RevealSecretsaction. Sans cette autorisation, Step Functions renvoie une erreur de refus d'accès.

Notez que lorsque vous spécifiez une maquette dans la demande d' TestState API, vous pouvez tester la logique de votre machine à états sans fournir de rôle d'exécution (voir plus de détails sous Intégrations de services de simulation). Lorsque vous n'utilisez pas de simulacres, vous devez fournir un rôle d'exécution contenant les autorisations requises pour les ressources auxquelles votre État accède. Pour plus d'informations sur les autorisations dont votre État peut avoir besoin, consultez la section Gestion des rôles d'exécution.

Tester un état à l'aide de la console AWS Step Functions

Vous pouvez tester un état dans la console et vérifier l'état de sortie ou le flux de traitement des données d'entrée et de sortie. Pour une tâche HTTP, vous pouvez tester la requête et la réponse HTTP brutes.

Tester un état en utilisant AWS CLI

Vous pouvez tester un état à l'aide de TestStatel'API duAWS CLI. Cette API accepte la définition d'un état et l'exécute.

Pour chaque État, vous pouvez spécifier la quantité de détails que vous souhaitez afficher dans les résultats des tests. Ces informations fournissent des informations supplémentaires sur l'exécution de l'État, notamment le résultat du traitement des données d'entrée et de sortie et les informations de requête et de réponse HTTP. Les exemples suivants présentent les différents niveaux d'inspection que vous pouvez spécifier pour l' TestState API.

Cette section contient les exemples suivants qui décrivent comment vous pouvez utiliser les différents niveaux d'inspection Step Functions fournis dans AWS CLI :

Exemple 1 : utilisation d'INFO InspectionLevel pour tester un état Choice

Pour tester un état à l'aide du INFO paramètre InspectionLevel dans leAWS CLI, exécutez la test-state commande comme indiqué dans l'exemple suivant.

aws stepfunctions test-state \
    --definition '{"Type": "Choice", "Choices": [{"Variable": "$.number", "NumericEquals": 1, "Next": "Equals 1"}, {"Variable": "$.number", "NumericEquals": 2, "Next": "Equals 2"}], "Default": "No Match"}' \
    --role-arn arn:aws:iam::account-id:role/myRole \
    --input '{"number": 2}'

Cet exemple utilise un état Choice pour déterminer le chemin d'exécution de cet état en fonction de l'entrée numérique que vous fournissez. Par défaut, Step Functions définit la valeur inspectionLevel à INFO si vous ne définissez aucun niveau.

Step Functionsrenvoie le résultat suivant.

{
    "output": "{\"number\": 2}",
    "nextState": "Equals 2",
    "status": "SUCCEEDED"
}

Exemple 2 : utilisation de DEBUG InspectionLevel pour déboguer le traitement des données d'entrée et de sortie dans un état Passage

Pour tester un état à l'aide du DEBUG paramètre InspectionLevel dans leAWS CLI, exécutez la test-state commande comme indiqué dans l'exemple suivant.

aws stepfunctions test-state \
    --definition '{"Type": "Pass", "InputPath": "$.payload", "Parameters": {"data": 1}, "ResultPath": "$.result", "OutputPath": "$.result.data", "Next": "Another State"}' \
    --role-arn arn:aws:iam::account-id:role/myRole \
    --input '{"payload": {"foo": "bar"}}' \
    --inspection-level DEBUG

Cet exemple utilise un Passer l'état du flux de travail état pour montrer comment filtrer et manipuler les données JSON d'entrée à l'aide des Step Functions filtres de traitement des données d'entrée et de sortie. Cet exemple utilise les filtres suivants : InputPathParameters,Spécification de la sortie d'état à l'aide ResultPath de in Step Functions, etFiltrer la sortie d'état à l'aide OutputPath.

Step Functionsrenvoie le résultat suivant.

{
    "output": "1",
    "inspectionData": {
        "input": "{\"payload\": {\"foo\": \"bar\"}}",
        "afterInputPath": "{\"foo\":\"bar\"}",
        "afterParameters": "{\"data\":1}",
        "afterResultSelector": "{\"data\":1}",
        "afterResultPath": "{\"payload\":{\"foo\":\"bar\"},\"result\":{\"data\":1}}"
    },
    "nextState": "Another State",
    "status": "SUCCEEDED"
}

Exemple 3 : utilisation de TRACE InspectionLevel et RevealSecrets pour inspecter la requête HTTP envoyée à une API HTTPS

Pour tester une tâche HTTP à l'aide du paramètre TRACE InspectionLevel et du paramètre RevealSecrets dans leAWS CLI, exécutez la test-state commande comme indiqué dans l'exemple suivant.

aws stepfunctions test-state \
    --definition '{"Type": "Task", "Resource": "arn:aws:states:::http:invoke", "Parameters": {"Method": "GET", "Authentication": {"ConnectionArn": "arn:aws:events:region:account-id:connection/MyConnection/0000000-0000-0000-0000-000000000000"}, "ApiEndpoint": "https://httpbin.org/get", "Headers": {"definitionHeader": "h1"}, "RequestBody": {"message": "Hello from Step Functions!"}, "QueryParameters": {"queryParam": "q1"}}, "End": true}' \
    --role-arn arn:aws:iam::account-id:role/myRole \
    --inspection-level TRACE \
    --reveal-secrets

Cet exemple teste si la tâche HTTP appelle l'API HTTPS spécifiée,https://httpbin.org/. Il affiche également les données de requête et de réponse HTTP pour l'appel d'API.

Step Functionsrenvoie une sortie similaire à l'exemple original dans la documentation actuelle.

Exemple 4 : Utilisation de l'utilitaire jq pour filtrer et imprimer la réponse renvoyée par l' TestState API

L' TestState API renvoie les données JSON sous forme de chaînes échappées dans sa réponse. L'AWS CLIexemple suivant étend l'exemple 3 et utilise l'jqutilitaire pour filtrer et imprimer la réponse HTTP renvoyée par l' TestState API dans un format lisible par l'homme. Pour plus d'informations jq et ses instructions d'installation, consultez jq on GitHub.

aws stepfunctions test-state \
    --definition '{"Type": "Task", "Resource": "arn:aws:states:::http:invoke", "Parameters": {"Method": "GET", "Authentication": {"ConnectionArn": "arn:aws:events:region:account-id:connection/MyConnection/0000000-0000-0000-0000-000000000000"}, "ApiEndpoint": "https://httpbin.org/get", "Headers": {"definitionHeader": "h1"}, "RequestBody": {"message": "Hello from Step Functions!"}, "QueryParameters": {"queryParam": "q1"}}, "End": true}' \
    --role-arn arn:aws:iam::account-id:role/myRole \
    --inspection-level TRACE \
    --reveal-secrets \
    | jq '.inspectionData.response.body | fromjson'

L'exemple suivant montre le résultat renvoyé dans un format lisible par l'homme.

{
  "args": {
    "QueryParam1": "QueryParamValue1",
    "queryParam": "q1"
  },
  "headers": {
    "Authorization": "Basic XXXXXXXX",
    "Content-Type": "application/json; charset=UTF-8",
    "Customheader1": "CustomHeaderValue1",
    "Definitionheader": "h1",
    "Host": "httpbin.org",
    "Range": "bytes=0-262144",
    "Transfer-Encoding": "chunked",
    "User-Agent": "Amazon|StepFunctions|HttpInvoke|region",
    "X-Amzn-Trace-Id": "Root=1-0000000-0000-0000-0000-000000000000"
  },
  "origin": "12.34.567.891",
  "url": "https://httpbin.org/get?queryParam=q1&QueryParam1=QueryParamValue1"
}

Test et débogage du flux de données d'entrée et de sortie

L'TestStateAPI est utile pour tester et déboguer les données qui circulent dans votre flux de travail. Cette section fournit quelques concepts clés et explique comment les utiliser TestState à cette fin.

Concepts clés

DansStep Functions, le processus de filtrage et de manipulation des données JSON lorsqu'elles passent par les états de votre machine à états est appelé traitement des entrées et des sorties. Pour plus d'informations sur la façon dont cela fonctionne, consultez Traitement des entrées et des sorties dans Step Functions.

Tous les types d'états du Amazon States Language (ASL) (Task, Parallel, Map, Pass, Wait, Choice, Succeed et Fail) partagent un ensemble de champs communs permettant de filtrer et de manipuler les données JSON qui les traversent. Ces champs sont les suivants : InputPathParameters,ResultSelector,Spécification de la sortie d'état à l'aide ResultPath de in Step Functions, etFiltrer la sortie d'état à l'aide OutputPath. Support pour chaque domaine varie d'un État à l'autre. Au moment de l'exécution, Step Functions applique chaque champ dans un ordre spécifique. Le schéma suivant montre l'ordre dans lequel ces champs sont appliqués aux données dans un état de tâche :

La liste suivante décrit l'ordre d'application des champs de traitement d'entrée et de sortie présentés dans le diagramme.

Ces champs de traitement d'entrée et de sortie sont facultatifs. Si vous n'utilisez aucun de ces champs dans votre définition d'état, la tâche consommera l'entrée d'état brute et renverra le résultat de la tâche en tant que sortie d'état.

Utilisation TestState pour inspecter le traitement des entrées et des sorties

Lorsque vous appelez l'TestStateAPI et que vous définissez le inspectionLevel paramètre surDEBUG, la réponse de l'API inclut un objet appeléinspectionData. Cet objet contient des champs qui vous aident à inspecter la manière dont les données ont été filtrées ou manipulées dans l'état dans lequel elles ont été exécutées. L'exemple suivant montre l'inspectionDataobjet correspondant à un état de tâche.

"inspectionData":   {
  "input": string, 
  "afterInputPath": string, 
  "afterParameters": string, 
  "result": string, 
  "afterResultSelector": string, 
  "afterResultPath": string,
  "output": string 
}

Dans cet exemple, chaque champ contenant le after préfixe affiche les données après l'application d'un champ particulier. Par exemple, afterInputPath montre l'effet de l'application du InputPath champ pour filtrer l'entrée d'état brute. Le schéma suivant met en correspondance chaque champ de définition ASL avec le champ correspondant dans l'inspectionDataobjet :

Pour des exemples d'utilisation de l' TestState API pour déboguer le traitement des entrées et des sorties, consultez les pages suivantes :

Pour l'état de la carte en particulier, lorsque inspectionLevel ce paramètre est défini surDEBUG, l'inspectionDataobjet inclut des champs supplémentaires qui vous aident à inspecter la manière dont l'état de la carte extrait et transforme les éléments. Vous pouvez en savoir plus sur ces champs dans la section Comprendre les données d'inspection de l'état de la carte.

Comprendre les données d'inspection de l'état de la carte

Lorsque vous testez un état de carte inspectionLevel défini surDEBUG, la réponse de l' TestState API inclut des champs supplémentaires dans l'inspectionDataobjet qui indiquent comment l'état de votre carte traite les données :

Ces champs vous permettent de vérifier que les transformations de données et les configurations de tolérance aux défaillances de l'état de votre carte fonctionnent correctement avant le déploiement.

Ce que vous pouvez tester et affirmer avec l' TestState API

L' TestState API vous permet d'écrire des tests unitaires complets pour vos machines d'état. Vous pouvez faire des assertions sur plusieurs aspects de la logique de votre machine à états, notamment les suivants :

Gestion des erreurs : quel Catch ou Retry s'applique

Lorsque vous simulez une erreur, vous pouvez utiliser l' TestState API pour voir quel gestionnaire d'erreurs est activé.

Pour les blocs Catch, vous pouvez affirmer :

Pour les blocs Retry, vous pouvez affirmer :

Transformations de données : traitement des entrées et des sorties

À l'aide de l' TestState API, vous pouvez valider la manière dont vos données d'état sont transformées à chaque étape du traitement.

Vous pouvez affirmer sur :

Transformations de l'état de la carte : ItemSelector ItemsPath,, ItemBatcher, ItemsPointer

Pour les états de carte, vous pouvez utiliser TestState l'API pour voir comment les éléments sont extraits et transformés.

Vous pouvez affirmer sur :

Cartographier les seuils de défaillance des états : états de test. ExceedToleratedFailureThreshold

Testez si un nombre spécifique d'itérations échouées déclenche le seuil d'échec toléré.

Vous pouvez affirmer sur :

Propagation des erreurs dans les états cartographique et parallèle

Lorsque vous testez des états dans des états Map ou Parallel, les erreurs se propagent aux gestionnaires d'erreurs de l'état parent comme elles le feraient lors d'une exécution réelle.

Spécification de la source d'erreur avec errorCausedBy l'état

Lorsque vous simulez des erreurs pour des états cartographiques ou parallèles, vous devez spécifier le sous-état à l'origine de l'erreur à l'aide du stateConfiguration.errorCausedByState paramètre. Ceci est particulièrement important lorsque vous testez des erreurs génériques telles queStates.TaskFailed. States.TaskFailedest une erreur générique qui s'applique à toute défaillance de l'état d'une tâche. Pour tester la façon dont votre état Map ou Parallel gère cette erreur, vous devez identifier le sous-état spécifique à l'origine de cette erreur. Voir l'exemple ci-dessous :

aws stepfunctions test-state \
  --definition '{...Map or Parallel state definition...}' \
  --input '[...]' \
  --state-configuration '{"errorCausedByState": "ProcessItem"}' \
  --mock '{"errorOutput": {"error": "States.TaskFailed", "cause": "Task execution failed"}}'

Dans cet exemple, errorCausedByState indique TestState que l'état « ProcessItem » du Map/Parallel flux de travail a généré l'erreur. Les gestionnaires Catch ou Retry de Map/Parallel l'état parent traiteront l'erreur comme ils le feraient lors de l'exécution réelle. Le nextState champ de la réponse indique quel gestionnaire d'erreurs a détecté l'erreur. Vous pouvez affirmer sur :

Intégrations de services de simulation

L' TestState API permet de simuler les résultats des intégrations de services, ce qui vous permet de tester la logique de votre machine à états sans invoquer de services réels. AWS

Quand utiliser le moquage

La moquerie est utile pour :

Lorsque vous spécifiez une maquette, le roleArn paramètre devient facultatif, ce qui vous permet de vous concentrer sur le test de la définition de votre machine à états sans vous soucier des problèmes liés aux autorisations.

Syntaxe de simulation de base

Pour simuler le résultat d'une intégration de services :

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Arguments": {
      "FunctionName": "MyFunction",
      "Payload.$": "$"
    },
    "End": true
  }' \
  --input '{"key": "value"}' \
  --mock '{"result": "{\"Payload\": {\"statusCode\": 200, \"body\": \"Success\"}}"}'

Pour simuler une erreur :

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Arguments": {...},
    "End": true
  }' \
  --input '{"key": "value"}' \
  --mock '{"errorOutput": {"error": "Lambda.ServiceException", "cause": "Service unavailable"}}'

Modes de validation fictifs

L' TestState API valide les réponses simulées par rapport aux modèles d'API AWS de service pour garantir leur exactitude. Vous pouvez contrôler le comportement de validation à l'aide du fieldValidationMode paramètre :

Exemple avec mode de validation :

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::dynamodb:putItem",
    "Parameters": {...},
    "End": true
  }' \
  --input '{"key": "value"}' \
  --mock '{"fieldValidationMode": "STRICT", "result": "{\"Attributes\": {...}}"}'

Carte de test et états parallèles

L' TestState API permet de tester les états Map et Parallel lorsqu'une maquette est spécifiée. Cela vous permet de tester le traitement d'entrée et de sortie de ces états de flux.

Comprendre les tests d'état des cartes

Lorsque vous testez un état de carte avec l' TestState API, vous testez le traitement d'entrée et de sortie de l'état de la carte sans exécuter les itérations internes. Cette approche permet de tester :

Vous ne testez pas ce qui se passe à l'intérieur du ItemProcessor (les états qui traitent chaque élément).

Tester l'état d'une carte

Lorsque vous testez l'état d'une carte, le résultat simulé doit représenter la sortie de l'état complet de la carte. Le résultat fictif doit être un tableau JSON ou un objet JSON valide en fonction de la configuration de l'état de votre carte. Voir l'exemple ci-dessous :

aws stepfunctions test-state \
  --definition '{
    "Type": "Map",
    "ItemsPath": "$.items",
    "ItemSelector": {
      "value.$": "$$.Map.Item.Value",
      "index.$": "$$.Map.Item.Index"
    },
    "ItemProcessor": {
      "ProcessorConfig": {"Mode": "INLINE"},
      "StartAt": "ProcessItem",
      "States": {
        "ProcessItem": {
          "Type": "Task",
          "Resource": "arn:aws:states:::lambda:invoke",
          "End": true
        }
      }
    },
    "End": true
  }' \
  --input '{"items": [1, 2, 3, 4, 5]}' \
  --mock '{"result": "[10, 20, 30, 40, 50]"}' \
  --inspection-level DEBUG

Tester les états des cartes distribuées

Les états cartographiques distribués sont testés de la même manière que les états cartographiques intégrés. Lorsque votre carte utilise un ItemReader pour lire depuis S3, fournissez les données directement dans l'entrée (comme si elles avaient déjà été lues depuis S3). Par exemple :

aws stepfunctions test-state \
  --definition '{
    "Type": "Map",
    "ItemReader": {
      "Resource": "arn:aws:states:::s3:getObject",
      "Parameters": {
        "Bucket": "my-bucket",
        "Key": "orders.json"
      }
    },
    "ItemsPath": "$.orders",
    "ItemProcessor": {
      "ProcessorConfig": {"Mode": "DISTRIBUTED"},
      ...
    },
    "ToleratedFailureCount": 5,
    "End": true
  }' \
  --input '{
    "orders": [
      {"orderId": "123"},
      {"orderId": "456"},
      {"orderId": "789"}
    ]
  }' \
  --mock '{"result": "..."}'

Population contextuelle automatique

Lorsque vous testez un état dans un état de carte (à l'aide du stateName paramètre) sans fournir de context paramètre, l'objet Context est TestState automatiquement renseigné avec les valeurs par défaut. Cela inclut les champs de contexte spécifiques à la carte tels que :

Tester les états parallèles

Lorsque vous testez un état parallèle, le résultat simulé doit être un tableau JSON avec un élément pour chaque branche, dans le même ordre que celui dans lequel les branches apparaissent dans la définition.

Activité de test, .sync et. waitForTaskÉtats du jeton

L' TestState API permet de tester les états d'activité, les modèles d'intégration du service .sync et. waitForTaskModèles de jetons lorsqu'une maquette est spécifiée. Sans simulation, l'invocation de ces états via TestState l'API renverra une exception de validation.

Itérer à travers les définitions des machines à états

Vous pouvez fournir une définition complète de la machine à états à TestState l'API et spécifier l'état à tester à l'aide du stateName paramètre. Cela vous permet de tester cet état spécifique dans le contexte de votre machine à états complète. Vous pouvez également enchaîner les tests en utilisant la sortie et NextState d'un test comme entrée au suivant. Cela vous permet de tester des chemins d'exécution partiels ou complets au sein de votre machine d'état.

Utilisation du champ de contexte dans l' TestState API

Le context paramètre vous permet de fournir des valeurs pour l'objet Context qui devraient normalement être renseignées lors de l'exécution. Cela est utile pour tester les états qui font référence à des valeurs contextuelles telles que l'ID d'exécution, le nom de l'état ou l'heure saisie. L'exemple ci-dessous montre comment vous pouvez utiliser l'objet Context dans votre appel TestState d'API :

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Arguments": {
      "FunctionName": "MyFunction",
      "Payload": {
        "executionId.$": "$$.Execution.Id",
        "stateName.$": "$$.State.Name",
        "enteredTime.$": "$$.State.EnteredTime"
      }
    },
    "End": true
  }' \
  --input '{"data": "value"}' \
  --context '{
    "Execution": {
      "Id": "arn:aws:states:us-east-1:123456789012:execution:MyStateMachine:test-exec-123",
      "Name": "test-exec-123",
      "StartTime": "2024-01-01T10:00:00.000Z"
    },
    "State": {
      "Name": "ProcessData",
      "EnteredTime": "2024-01-01T10:00:05.000Z"
    }
  }' \
  --mock '{"result": "{\"status\": \"success\"}"}'

Tests, nouvelles tentatives et gestion des erreurs

L' TestState API vous permet de simuler des scénarios de nouvelle tentative et de tester la logique de gestion des erreurs en spécifiant les tentatives de nouvelle tentative et en simulant les erreurs.

Simulation de nouvelles tentatives

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Arguments": {...},
    "Retry": [{
      "ErrorEquals": ["Lambda.ServiceException"],
      "IntervalSeconds": 2,
      "MaxAttempts": 3,
      "BackoffRate": 2.0
    }],
    "End": true
  }' \
  --input '{"data": "value"}' \
  --state-configuration '{"retrierRetryCount": 1}' \
  --mock '{"errorOutput": {"error": "Lambda.ServiceException", "cause": "Service error"}}' \
  --inspection-level DEBUG

La réponse inclut les détails de l'erreur dans les données d'inspection :

{
  "status": "RETRIABLE",
  "inspectionData": {
    "errorDetails": {
      "retryBackoffIntervalSeconds": 4,
      "retryIndex": 0
    }
  }
}

Cette réponse indique :

Tester les outils de gestion des catch

Lorsqu'une erreur est simulée et correspond à un gestionnaire Catch, le nextState champ de la réponse de l' TestState API indique l'état qui gérera l'erreur. Dans l'exemple ci-dessous :

Pour la demande TestState d'API donnée ci-dessous,

aws stepfunctions test-state \
  --definition '{
    "Type": "Task",
    "Resource": "arn:aws:states:::lambda:invoke",
    "Arguments": {...},
    "Catch": [{
      "ErrorEquals": ["Lambda.TooManyRequestsException"],
      "ResultPath": "$.error",
      "Next": "HandleThrottling"
    }],
    "Next": "Success"
  }' \
  --input '{"data": "value"}' \
  --mock '{"errorOutput": {"error": "Lambda.TooManyRequestsException", "cause": "Rate exceeded"}}' \
  --inspection-level DEBUG

La réponse attendue de l'API doit être :

{
  "status": "CAUGHT_ERROR",
  "nextState": "HandleThrottling",
  "error": "Lambda.TooManyRequestsException",
  "cause": "Rate exceeded",
  "output": "{\"data\": \"value\", \"error\": {\"Error\": \"Lambda.TooManyRequestsException\", \"Cause\": \"Rate exceeded\"}}",
  "inspectionData": {
    "errorDetails": {
      "catchIndex": 0
    }
  }
}

Cette réponse indique que :

Vous pouvez également tester ce qui se passe lorsque toutes les tentatives sont épuisées en augmentant RetryCount les valeurs de votre objet de contexte.