Usando integrações de serviços simulados - AWS Step Functions

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Usando integrações de serviços simulados

No Step Functions Local, você pode testar os caminhos de execução de suas máquinas de estado sem realmente chamar serviços integrados usando integrações de serviços simuladas. Para configurar suas máquinas de estado para usar integrações de serviços simuladas, crie um arquivo de configuração simulado. Nesse arquivo, você define a saída desejada de suas integrações de serviços como respostas simuladas e as execuções que usam essas respostas para simular um caminho de execução como casos de teste.

Ao fornecer o arquivo de configuração simulado ao Step Functions Local, você pode testar as chamadas de integração de serviços executando máquinas de estado que usam as respostas simuladas especificadas nos casos de teste em vez de fazer chamadas reais de integração de serviços.

nota

Se você não especificar respostas de integração de serviços simulados no arquivo de configuração simulado, o Step Functions Local invocará a integração de AWS serviços usando o endpoint que você configurou ao configurar o Step Functions Local. Para obter informações sobre como configurar endpoints para Step Functions Local, consulte Definindo opções de configuração para Step Functions Local.

Principais conceitos neste tópico

Este tópico usa vários conceitos definidos na lista a seguir:

  • Integrações de serviços simulados: refere-se aos estados de tarefas configurados para usar respostas simuladas em vez de realizar chamadas de serviço reais.

  • Respostas simuladas: refere-se aos dados simulados que os estados da tarefa podem ser configurados para usar.

  • Casos de teste: refere-se às execuções de máquinas de estado configuradas para usar integrações de serviços simuladas.

  • Arquivo de configuração simulado: refere-se ao arquivo de configuração simulado que contém JSON, que define integrações de serviços simulados, respostas simuladas e casos de teste.

Etapa 1: especificar integrações de serviços simulados em um arquivo de configuração simulado

Você pode testar o AWS SDK do Step Functions e as integrações de serviços otimizadas usando o Step Functions Local. A imagem a seguir mostra a máquina de estado definida na guia Definição de máquina de estado:

Exemplo de integração de serviços simulada.

Para fazer isso, você deve criar um arquivo de configuração simulado contendo seções conforme definido em Apresentando a estrutura da configuração simulada.

  1. Crie um arquivo chamado MockConfigFile.json para configurar testes com integrações de serviços simuladas.

    O exemplo a seguir mostra um arquivo de configuração simulado referenciando uma máquina de estados com dois estados definidos chamados LambdaState e SQSState.

    Mock configuration file example

    Veja a seguir um exemplo de um arquivo de configuração simulado que demonstra como simular respostas da invocação de uma função do Lambda e do envio de uma mensagem para o Amazon SQS. Neste exemplo, a máquina de estado LambdaSQSIntegration contém três casos de teste chamados HappyPath, RetryPath e HybridPath que simulam os estados Task chamados LambdaState e SQSState. Esses estados usam as respostas de serviço simuladas MockedLambdaSuccess, MockedSQSSuccess e MockedLambdaRetry. Essas respostas de serviço simuladas são definidas na seção MockedResponses do arquivo.

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

    Veja a seguir um exemplo de uma definição de máquina de estado chamada LambdaSQSIntegration, que define dois estados de tarefas de integração de serviços chamados LambdaState e SQSState. LambdaState contém uma política de repetição baseada em 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/123456789012/myQueue", "MessageBody.$":"$" }, "End": true } } }

    Você pode executar a definição da máquina de estado LambdaSQSIntegration referenciada no arquivo de configuração simulado usando um dos seguintes casos de teste:

    • HappyPath - Este teste simula a saída de LambdaState e SQSState usando MockedLambdaSuccess e MockedSQSSuccess respectivamente.

      • O LambdaState retorna o seguinte valor:

        "0":{ "Return":{ "StatusCode":200, "Payload":{ "StatusCode":200, "body":"Hello from Lambda!" } } }
      • O SQSState retorna o seguinte valor:

        "0":{ "Return":{ "MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51", "MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51" } }
    • RetryPath - Este teste simula a saída de LambdaState e SQSState usando MockedLambdaRetry e MockedSQSSuccess respectivamente. Além disso, o LambdaState está configurado para realizar quatro tentativas de repetição. As respostas simuladas para essas tentativas são definidas e indexadas no estado MockedLambdaRetry.

      • A tentativa inicial termina com uma falha de tarefa contendo uma causa e uma mensagem de erro, conforme mostrado no exemplo a seguir:

        "0":{ "Throw": { "Error": "Lambda.ResourceNotReadyException", "Cause": "Lambda resource is not ready." } }
      • A primeira e a segunda tentativas terminam com uma falha de tarefa contendo uma causa e uma mensagem de erro, conforme mostrado no exemplo a seguir:

        "1-2":{ "Throw": { "Error": "Lambda.TimeoutException", "Cause": "Lambda timed out." } }
      • A terceira tentativa termina com uma tarefa bem-sucedida contendo o resultado do estado da seção Payload na resposta simulada do Lambda.

        "3":{ "Return": { "StatusCode": 200, "Payload": { "StatusCode": 200, "body": "Hello from Lambda!" } } }
        nota
        • Para estados com uma política de repetição, o Step Functions Local esgotará as tentativas de repetição definidas na política até receber uma resposta bem-sucedida. Isso significa que você deve indicar simulações para novas tentativas com números de tentativas consecutivos e deve abranger todas as tentativas antes de retornar uma resposta bem-sucedida.

        • Se você não especificar uma resposta simulada para uma tentativa de repetição específica, por exemplo, tentar novamente “3”, a execução da máquina de estado falhará.

    • HybridPath - Este teste simula a saída de LambdaState. Depois de LambdaState ser executado com sucesso e receber dados simulados como resposta, SQSState executa uma chamada de serviço real para o recurso especificado na produção.

    Para obter informações sobre como iniciar execuções de teste com integrações de serviços simuladas, consulte Etapa 3: executar testes de integração de serviços simulados.

  2. Certifique-se de que a estrutura das respostas simuladas esteja em conformidade com a estrutura das respostas de serviço reais que você recebe ao fazer chamadas de serviço integradas. Para obter informações sobre os requisitos estruturais para respostas simuladas, consulte Configurando integrações de serviços simuladas.

    No exemplo anterior do arquivo de configuração simulado, as respostas simuladas são definidas em MockedLambdaSuccess e MockedLambdaRetry está em conformidade com a estrutura das respostas reais que são retornadas da chamada HelloFromLambda.

    Importante

    As respostas do serviço AWS podem variar em estrutura entre os diferentes serviços. O Step Functions Local não valida se as estruturas de resposta simuladas estão em conformidade com as estruturas reais de resposta do serviço. Você deve garantir que suas respostas simuladas estejam em conformidade com as respostas reais antes do teste. Para revisar a estrutura das respostas de serviço, você pode realizar as chamadas de serviço reais usando Step Functions ou visualizar a documentação desses serviços.

Etapa 2: forneça ao Step Functions Local o arquivo de configuração simulado

É possível fornecer o arquivo de configuração simulado ao Step Functions Local de uma das seguintes maneiras:

Docker
nota

Se você estiver usando a versão Docker do Step Functions Local, poderá fornecer o arquivo de configuração simulado usando somente uma variável de ambiente. Além disso, você deve montar o arquivo de configuração simulado no contêiner do Step Functions Local na inicialização do servidor.

Monte o arquivo de configuração simulado em qualquer diretório dentro do contêiner do Step Functions Local. Em seguida, defina uma variável de ambiente chamada SFN_MOCK_CONFIG que contenha o caminho para o arquivo de configuração simulado no contêiner. Esse método permite que o arquivo de configuração simulado tenha qualquer nome, desde que a variável de ambiente contenha o caminho e o nome do arquivo.

O comando a seguir mostra o formato para iniciar a imagem do 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

O comando a seguir mostra o comando para iniciar a imagem do 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

Use uma das seguintes maneiras para fornecer o arquivo de configuração simulado ao Step Functions Local:

  • Coloque o arquivo de configuração simulado no mesmo diretório que Step FunctionsLocal.jar. Ao usar esse método, você deve nomear o arquivo de configuração simulado MockConfigFile.json.

  • Na sessão que executa o Step Functions Local, defina uma variável de ambiente chamada SFN_MOCK_CONFIG para o caminho completo do arquivo de configuração simulado. Esse método permite que o arquivo de configuração simulado tenha qualquer nome, desde que a variável de ambiente contenha o caminho e o nome do arquivo. No exemplo a seguir, a variável SFN_MOCK_CONFIG é definida para apontar para um arquivo de configuração simulado chamado EnvSpecifiedMockConfig.json, localizado no diretório /home/workspace.

    export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
nota
  • Se você não fornecer a variável de ambiente SFN_MOCK_CONFIG para o Step Functions Local, por padrão, ele tentará ler um arquivo de configuração simulado chamado MockConfigFile.json no diretório a partir do qual você iniciou o Step Functions Local.

  • Se você colocar o arquivo de configuração simulado no mesmo diretório que Step FunctionsLocal.jar e definir a variável de ambiente SFN_MOCK_CONFIG, o Step Functions Local lerá o arquivo especificado pela variável de ambiente.

Etapa 3: executar testes de integração de serviços simulados

Depois de criar e fornecer um arquivo de configuração simulado ao Step Functions Local, execute a máquina de estado configurada no arquivo de configuração simulado usando integrações de serviços simuladas. Em seguida, verifique os resultados da execução usando uma ação de API.

  1. Crie uma máquina de estado com base na definição mencionada anteriormente no arquivo de configuração simulado.

    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"
  2. Execute a máquina de estado usando integrações de serviços simuladas.

    Para usar o arquivo de configuração simulado, faça uma chamada de API StartExecution em uma máquina de estado configurada no arquivo de configuração simulado. Para fazer isso, anexe o sufixo, #test_name, ao ARN da máquina de estado usado por StartExecution. test_name é um caso de teste, configurado para a máquina de estado no mesmo arquivo de configuração simulado.

    O comando a seguir é um exemplo que usa a máquina de estado LambdaSQSIntegration e a configuração simulada. Neste exemplo, a máquina de estado LambdaSQSIntegration é executada usando o teste HappyPath definido em Etapa 1: especificar integrações de serviços simulados em um arquivo de configuração simulado. O teste HappyPath contém a configuração da execução para lidar com chamadas simuladas de integração de serviços que os estados LambdaState e SQSState fazem usando as respostas de serviço simuladas MockedLambdaSuccess e MockedSQSSuccess.

    aws stepfunctions start-execution \ --endpoint http://localhost:8083 \ --name executionWithHappyPathMockedServices \ --state-machine arn:aws:states:us-east-1:123456789012:stateMachine:LambdaSQSIntegration#HappyPath
  3. Veja a resposta de execução da máquina de estado.

    A resposta à chamada StartExecution usando um teste simulado de integração de serviços é a mesma resposta à chamada StartExecution normal, que retorna o ARN da execução e a data de início.

    Veja a seguir um exemplo de resposta à chamada StartExecution usando o teste simulado de integração de serviços:

    { "startDate":"2022-01-28T15:03:16.981000-05:00", "executionArn":"arn:aws:states:us-east-1:123456789012:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices" }
  4. Verifique os resultados da execução fazendo uma chamada de API ListExecutions, DescribeExecution ou GetExecutionHistory.

    aws stepfunctions get-execution-history \ --endpoint http://localhost:8083 \ --execution-arn arn:aws:states:us-east-1:123456789012:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices

    O exemplo a seguir demonstra partes de uma resposta à chamada GetExecutionHistory usando o ARN de execução do exemplo de resposta mostrado na etapa 2. Neste exemplo, a saída de LambdaState e SQSState são os dados simulados definidos no arquivo de configuração simulado MockedLambdaSuccess e MockedSQSSuccess. Além disso, os dados simulados são usados da mesma forma que os dados retornados pela execução de chamadas reais de integração de serviços seriam usados. Além disso, neste exemplo, a saída de LambdaState é passada a SQSState como entrada.

    { "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 } } }, ... ] }