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

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 des scénarios 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, y compris les états fictifs et les réponses simulées :

Présentation de la structure de la configuration fictive

Une configuration fictive est un objet JSON 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 décrivent les champs d'objet de niveau supérieur que vous devez définir dans votre configuration fictive.

StateMachines

L'StateMachinesobjet définit les machines d'État qui utiliseront des intégrations de services simulées. La configuration de chaque machine d'état est représentée sous la forme d'un champ de niveau supérieur deStateMachines. Le nom du champ est le nom de la machine d'état et la valeur est un objet contenant un seul champ nomméTestCases, dont les champs représentent des cas de test de cette machine d'état.

La syntaxe suivante montre une machine d'état 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 d'État. Le nom de chaque scénario de test doit être unique par machine d'état et la valeur de chaque scénario de test est un objet spécifiant une réponse simulée à utiliser pour les états des tâches 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 complète 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 pour l'appel de tâche simulé. Si vous ne spécifiez pas de réponse simulée, l'exécution de la machine d'état échouera.

Voici un exemple d'un MockedResponse avec 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 qui contient une réponse simulée pour appeler 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 la sortie 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 traitées dans les Catch sections Retry et de votre machine d'état.

Voici un exemple d'Throwobjet qui contient une réponse simulée pour appeler une Invokefonction Lambda :

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

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 ne fait pas en sorte que les simulacres soient les mêmes que les vraies API. 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.