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.

Fichier de configuration pour les intégrations de services simulées dans Step Functions

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 JSON objet contenant les champs de niveau supérieur suivants :

Voici un exemple de fichier de configuration fictif qui inclut une StateMachine définition etMockedResponse.

{
  "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

L'StateMachinesobjet 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 deStateMachines. 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

MockedResponsesest 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'Returnobjets. 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": {
      ...
    }
  }
}

Return

Returnest représenté sous la forme d'un champ d'MockedResponseobjets. Il indique le résultat positif d'un état de tâche simulé.

Voici un exemple d'Returnobjet contenant une réponse simulée pour l'appel d'une Invokefonction Lambda :

"Return": {
  "StatusCode": 200,
  "Payload": {
    "StatusCode": 200,
    "body": "Hello from Lambda!"
  }
}

Jeter

Throwest représenté sous la forme d'un champ d'MockedResponseobjets. Il indique le résultat d'erreur 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'Throwobjet contenant une réponse simulée pour l'appel d'une Invokefonction Lambda :

"Throw": {
  "Error": "Lambda.TimeoutException",
  "Cause": "Lambda timed out."
}