Utilizzo di integrazioni di servizi simulati - AWS Step Functions
Concetti chiave in questo argomentoPassaggio 1: specificare le integrazioni di servizi simulati in un file di configurazione fittizioPassaggio 2: fornire il file di configurazione fittizio a Step Functions LocalFase 3: Eseguire i test di integrazione dei servizi simulati

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo di integrazioni di servizi simulati

In Step Functions Local, puoi testare i percorsi di esecuzione delle tue macchine a stati senza chiamare effettivamente servizi integrati utilizzando integrazioni di servizi simulate. Per configurare le macchine a stati per utilizzare integrazioni di servizi simulate, create un file di configurazione fittizio. In questo file, definisci l'output desiderato delle integrazioni di servizio come risposte simulate e le esecuzioni che utilizzano le risposte simulate per simulare un percorso di esecuzione come casi di test.

Fornendo il file di configurazione fittizio a Step Functions Local, è possibile testare le chiamate di integrazione dei servizi eseguendo macchine a stati che utilizzano le risposte simulate specificate nei casi di test invece di effettuare chiamate di integrazione del servizio effettive.

Nota

Se non specifichi risposte simulate di integrazione del servizio nel file di configurazione fittizio, Step Functions Local invocherà l'integrazione del AWS servizio utilizzando l'endpoint configurato durante la configurazione di Step Functions Local. Per informazioni sulla configurazione degli endpoint per Step Functions Local, vedere. Impostazione delle opzioni di configurazione per Step Functions Local

Argomenti

Concetti chiave in questo argomento

In questo argomento vengono utilizzati diversi concetti definiti nell'elenco seguente:

  • Integrazioni di servizi simulati: si riferisce agli stati delle attività configurati per utilizzare risposte simulate anziché eseguire chiamate di servizio effettive.

  • Risposte simulate: si riferisce a dati fittizi per i quali gli stati di Task possono essere configurati per l'utilizzo.

  • Casi di test: si riferisce alle esecuzioni di macchine a stati configurate per utilizzare integrazioni di servizi simulate.

  • File di configurazione fittizio: si riferisce al file di configurazione fittizio che contiene JSON, che definisce integrazioni di servizi simulate, risposte simulate e casi di test.

Passaggio 1: specificare le integrazioni di servizi simulati in un file di configurazione fittizio

Puoi testare Step Functions AWS SDK e integrazioni di servizi ottimizzate utilizzando Step Functions Local. L'immagine seguente mostra la macchina a stati definita nella scheda Definizione della macchina a stati:

Esempio di integrazione di servizi simulati.

A tale scopo, è necessario creare un file di configurazione fittizio contenente le sezioni definite in. Introduzione alla struttura della configurazione fittizia

  1. Crea un file denominato MockConfigFile.json per configurare i test con integrazioni di servizi simulate.

    L'esempio seguente mostra un file di configurazione fittizio che fa riferimento a una macchina a stati con due stati definiti denominati and. LambdaState SQSState

    Mock configuration file example

    Di seguito è riportato un esempio di file di configurazione fittizio che dimostra come simulare le risposte richiamando una funzione Lambda e inviando un messaggio ad Amazon SQS. In questo esempio, la macchina a LambdaSQSIntegrationstati contiene tre casi di test denominatiHappyPath,RetryPath, e HybridPath che simulano gli stati denominati and. Task LambdaState SQSState Questi stati utilizzano le risposte di MockedLambdaSuccess servizio MockedSQSSuccess simulate e MockedLambdaRetry simulate. Queste risposte di servizio simulate sono definite nella MockedResponses sezione del file.

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

    Di seguito è riportato un esempio di definizione di macchina a stati denominataLambdaSQSIntegration, che definisce due stati delle attività di integrazione dei servizi denominati LambdaState and. SQSState LambdaStatecontiene una politica di ripetizione dei tentativi basata su. 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
    }
  }
}

    È possibile eseguire la definizione della macchina a LambdaSQSIntegration stati a cui si fa riferimento nel file di configurazione fittizio utilizzando uno dei seguenti casi di test:

    • HappyPath- Questo test simula rispettivamente l'output e l'SQSStateutilizzo MockedLambdaSuccess di LambdaState e. MockedSQSSuccess

      • LambdaStateRestituirà il seguente valore:

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

      • SQSStateRestituirà il seguente valore:

        "0":{
  "Return":{
    "MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51",
    "MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51"
  }
}

    • RetryPath- Questo test simula MockedSQSSuccess rispettivamente l'output LambdaState e SQSState l'utilizzo di MockedLambdaRetry e. Inoltre, LambdaState è configurato per eseguire quattro tentativi di nuovo tentativo. Le risposte simulate per questi tentativi sono definite e indicizzate nello stato. MockedLambdaRetry

      • Il tentativo iniziale termina con un'operazione non riuscita contenente un messaggio di causa e di errore, come illustrato nell'esempio seguente:

        "0":{
  "Throw": {
    "Error": "Lambda.ResourceNotReadyException",
    "Cause": "Lambda resource is not ready."
  }
}

      • Il primo e il secondo tentativo terminano con un errore dell'operazione contenente un messaggio di causa e di errore, come illustrato nell'esempio seguente:

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

      • Il terzo tentativo termina con un'operazione riuscita contenente il risultato dello stato della sezione Payload nella risposta Lambda simulata.

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

        • Per gli stati con una politica di nuovi tentativi, Step Functions Local esaurirà i tentativi di riprova impostati nella politica fino a quando non riceverà una risposta positiva. Ciò significa che, per i tentativi ripetuti, è necessario indicare un numero di tentativi consecutivi e includere tutti i tentativi ripetuti prima di restituire una risposta riuscita.

        • Se non si specifica una risposta simulata per un tentativo specifico, ad esempio, riprova «3", l'esecuzione della macchina a stati avrà esito negativo.

    • HybridPath- Questo test simula l'output di. LambdaState Dopo aver LambdaState eseguito correttamente e ricevuto dati simulati come risposta, SQSState esegue una chiamata di servizio effettiva alla risorsa specificata in produzione.

    Per informazioni su come avviare esecuzioni di test con integrazioni di servizi simulate, consulta. Fase 3: Eseguire i test di integrazione dei servizi simulati

  2. Assicurati che la struttura delle risposte simulate sia conforme alla struttura delle risposte di servizio effettive che ricevi quando effettui chiamate di servizio integrate. Per informazioni sui requisiti strutturali per le risposte simulate, vedere. Configurazione di integrazioni di servizi fittizie

    Nell'esempio precedente, il file di configurazione fittizio, le risposte simulate sono definite MockedLambdaSuccess e sono MockedLambdaRetry conformi alla struttura delle risposte effettive restituite dalla chiamata. HelloFromLambda

    Importante

    AWS le risposte al servizio possono variare nella struttura tra i diversi servizi. Step Functions Local non verifica se le strutture di risposta simulate sono conformi alle strutture di risposta del servizio effettive. È necessario assicurarsi che le risposte simulate siano conformi alle risposte effettive prima del test. Per esaminare la struttura delle risposte di servizio, è possibile eseguire le chiamate di servizio effettive utilizzando Step Functions o visualizzare la documentazione relativa a tali servizi.

Passaggio 2: fornire il file di configurazione fittizio a Step Functions Local

È possibile fornire il file di configurazione fittizio a Step Functions Local in uno dei seguenti modi:

Docker
Nota

Se utilizzi la versione Docker di Step Functions Local, puoi fornire il file di configurazione fittizio utilizzando solo una variabile di ambiente. Inoltre, è necessario montare il file di configurazione fittizio nel contenitore Step Functions Local all'avvio iniziale del server.

Monta il file di configurazione fittizio su qualsiasi directory all'interno del contenitore Step Functions Local. Quindi, imposta una variabile di ambiente denominata SFN_MOCK_CONFIG che contiene il percorso del file di configurazione fittizio nel contenitore. Questo metodo consente di assegnare qualsiasi nome al file di configurazione fittizio purché la variabile di ambiente contenga il percorso e il nome del file.

Il comando seguente mostra il formato per avviare l'immagine 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'esempio seguente utilizza il comando per avviare l'immagine 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

Utilizzate uno dei seguenti modi per fornire il file di configurazione fittizio a Step Functions Local:

  • Posiziona il file di configurazione fittizio nella stessa directory di. Step FunctionsLocal.jar Quando si utilizza questo metodo, è necessario assegnare un nome al file di configurazione fittizio. MockConfigFile.json

  • Nella sessione che esegue Step Functions Local, imposta una variabile di ambiente denominataSFN_MOCK_CONFIG, sul percorso completo del file di configurazione fittizio. Questo metodo consente di denominare il file di configurazione fittizio con qualsiasi nome purché la variabile di ambiente contenga il percorso e il nome del file. Nell'esempio seguente, la SFN_MOCK_CONFIG variabile è impostata in modo che punti a un file di configurazione fittizio denominatoEnvSpecifiedMockConfig.json, che si trova nella /home/workspace directory. 

    export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
Nota

  • Se non si fornisce la variabile di ambiente SFN_MOCK_CONFIG a Step Functions Local, per impostazione predefinita, tenterà di leggere un file di configurazione fittizio denominato MockConfigFile.json nella directory da cui è stato avviato Step Functions Local.

  • Se si posiziona il file di configurazione fittizio nella stessa directory Step FunctionsLocal.jar e si imposta la variabile di ambienteSFN_MOCK_CONFIG, Step Functions Local leggerà il file specificato dalla variabile di ambiente.

Fase 3: Eseguire i test di integrazione dei servizi simulati

Dopo aver creato e fornito un file di configurazione fittizio a Step Functions Local, esegui la macchina a stati configurata nel file di configurazione fittizio utilizzando integrazioni di servizi fittizi. Quindi controlla i risultati dell'esecuzione utilizzando un'azione API.

  1. Crea una macchina a stati basata sulla definizione menzionata in precedenza nel file di configurazione fittizio.

    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. Esegui la macchina a stati utilizzando integrazioni di servizi simulate.

    Per utilizzare il file di configurazione fittizio, effettua una chiamata StartExecution API su una macchina a stati configurata nel file di configurazione fittizio. A tale scopo, aggiungi il suffisso,#test_name, all'ARN della macchina a stati utilizzata da. StartExecution test_nameè un test case, configurato per la macchina a stati nello stesso file di configurazione fittizio.

    Il comando seguente è un esempio che utilizza la macchina a LambdaSQSIntegration stati e la configurazione fittizia. In questo esempio, la macchina a LambdaSQSIntegration stati viene eseguita utilizzando il HappyPath test definito inPassaggio 1: specificare le integrazioni di servizi simulati in un file di configurazione fittizio. Il HappyPath test contiene la configurazione per l'esecuzione per gestire le chiamate di integrazione di servizi fittizi effettuate LambdaState e SQSState dagli stati utilizzando le risposte del MockedLambdaSuccess servizio MockedSQSSuccess simulate.

    aws stepfunctions start-execution \
    --endpoint http://localhost:8083 \
    --name executionWithHappyPathMockedServices \
    --state-machine arn:aws:states:us-east-1:123456789012:stateMachine:LambdaSQSIntegration#HappyPath

  3. Visualizza la risposta di esecuzione della macchina a stati.

    La risposta alla chiamata StartExecution utilizzando un test di integrazione del servizio simulato è la stessa della risposta alla chiamata StartExecution normale, che restituisce l'ARN di esecuzione e la data di inizio.

    Di seguito è riportato un esempio di risposta alla chiamata StartExecution utilizzando il test di integrazione del servizio simulato:

    {
   "startDate":"2022-01-28T15:03:16.981000-05:00",
   "executionArn":"arn:aws:states:us-east-1:123456789012:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices"
}

  4. Controlla i risultati dell'esecuzione effettuando una chiamata ListExecutionsDescribeExecution, o GetExecutionHistory API.

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

    L'esempio seguente mostra parti di una risposta alla chiamata GetExecutionHistory utilizzando l'ARN di esecuzione dalla risposta di esempio mostrata nel passaggio 2. In questo esempio, l'output di LambdaState e SQSState è costituito dai dati fittizi definiti nel MockedLambdaSuccess e MockedSQSSuccess nel file di configurazione fittizio. Inoltre, i dati simulati vengono utilizzati nello stesso modo in cui verrebbero utilizzati i dati restituiti eseguendo chiamate di integrazione dei servizi effettive. Inoltre, in questo esempio, l'output da LambdaState viene passato SQSState come input.

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