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à.

Test di macchine a stati con TestState API

Panoramica di

Puoi testare uno stato supportato utilizzando la TestState funzionalità nella Step Functions console o nell'AWSCommand Line Interface (AWS CLI)SDK.

L'TestStateAPI accetta la definizione di uno stato e la esegue. Consente di testare uno stato senza creare una macchina a stati o aggiornare una macchina a stati esistente. È possibile fornire:

L'TestStateAPI assume un IAM ruolo che deve contenere le IAM autorizzazioni necessarie per le risorse a cui accede lo stato. Quando si specifica un mock, la specificazione del ruolo diventa facoltativa e consente di testare la logica della macchina a stati senza configurare le autorizzazioni. IAM Per informazioni sulle autorizzazioni di cui uno stato potrebbe aver bisogno, consulta. IAMautorizzazioni per l'utilizzo dell'API TestState

Argomenti

Utilizzo dei livelli di ispezione nell'API TestState

Quando testate uno stato utilizzando l'TestStateAPI, potete specificare la quantità di dettagli che desiderate visualizzare nei risultati del test. Ad esempio, se hai utilizzato filtri di elaborazione dei dati di input e output come InputPatho ResultPath, puoi visualizzare i risultati intermedi e finali dell'elaborazione dei dati. Step Functionsfornisce i seguenti livelli di ispezione:

Tutti questi livelli restituiscono anche nextState i campi status and. statusindica lo stato dell'esecuzione dello stato. Ad esempio, SUCCEEDEDFAILED,RETRIABLE, eCAUGHT_ERROR. nextStateindica il nome dello stato successivo verso cui passare. Se non hai definito uno stato successivo nella definizione, questo campo restituisce un valore vuoto.

Per informazioni sul test di uno stato utilizzando questi livelli di ispezione nella Step Functions console eAWS CLI, consulta Test di uno stato utilizzando la console AWS Step Functions eTestare uno stato utilizzando AWS CLI.

INFO Inspection Level

Se il test ha esito positivo, questo livello mostra l'output dello stato. Se il test fallisce, questo livello mostra l'output dell'errore. Per impostazione predefinita, Step Functions imposta il livello di ispezione su INFO se non si specifica un livello.

Livello di ispezione DEBUG

Se il test ha esito positivo, questo livello mostra lo stato di output e il risultato dell'elaborazione dei dati di input e output.

Se il test fallisce, questo livello mostra l'output dell'errore. Questo livello mostra i risultati intermedi dell'elaborazione dei dati fino al punto di errore. Ad esempio, supponiamo di aver testato uno stato Task che richiama una funzione. Lambda Immagina di aver applicato i Filtraggio dell'output dello stato utilizzando OutputPath filtriInputPath, ParametersSpecificazione dello stato dell'output utilizzando ResultPath in Step Functions, e allo stato Task. Supponiamo che l'invocazione sia fallita. In questo caso, il DEBUG livello mostra i risultati dell'elaborazione dei dati in base all'applicazione dei filtri nell'ordine seguente:

Le informazioni diagnostiche disponibili in questo livello possono aiutarti a risolvere i problemi relativi all'integrazione di un servizio o al flusso di elaborazione dei dati di input e output che potresti aver definito.

Livello di ispezione TRACE

Step Functionsfornisce il livello TRACE per testare un task HTTP. Questo livello restituisce informazioni sulla richiesta HTTP che Step Functions effettua e sulla risposta restituita da un'API HTTPS. La risposta potrebbe contenere informazioni, come le intestazioni e il corpo della richiesta. Inoltre, è possibile visualizzare l'output dello stato e il risultato dell'elaborazione dei dati di input e output in questo livello.

Se il test fallisce, questo livello mostra l'output dell'errore.

Questo livello è applicabile solo per HTTP Task. Step Functionsgenera un errore se si utilizza questo livello per altri tipi di stato.

Quando si imposta il livello di ispezione su TRACE, è possibile visualizzare anche i segreti inclusi nella EventBridge connessione. A tale scopo, è necessario impostare il revealSecrets parametro su true nell'TestStateAPI. Inoltre, devi assicurarti che l'IAMutente che chiama l' TestState API disponga dell'autorizzazione per l'states:RevealSecretsazione. Per un esempio di IAM politica che imposta l'states:RevealSecretsautorizzazione, vediIAMautorizzazioni per l'utilizzo dell'API TestState . Senza questa autorizzazione, Step Functions genera un errore di accesso negato.

Se si imposta il revealSecrets parametro sufalse, Step Functions omette tutti i segreti nei dati di richiesta e risposta HTTP. Tieni presente che non puoi utilizzarlo revealSecrets quando il mocking è abilitato. Se si specificano entrambi revealSecrets e un mock nella richiesta TestState API, Step Functions restituisce un'eccezione di convalida.

IAMautorizzazioni per l'utilizzo dell'API TestState

L'IAMutente che chiama l'TestStateAPI deve avere l'autorizzazione per eseguire l'states:TestStateazione. Quando non si utilizza il mocking, l'IAMutente deve inoltre disporre dell'autorizzazione a eseguire l'iam:PassRoleazione a cui passare il ruolo di esecuzione. Step Functions Inoltre, se si imposta il revealSecrets parametro sutrue, l'IAMutente deve disporre dell'autorizzazione per eseguire l'states:RevealSecretsazione. Senza questa autorizzazione, Step Functions genera un errore di accesso negato.

Tieni presente che quando specifichi un mock nella richiesta TestState API, puoi testare la logica della tua macchina a stati senza fornire un ruolo di esecuzione (vedi maggiori dettagli in Integrazioni del servizio di simulazione). Quando non si utilizzano mock, è necessario fornire un ruolo di esecuzione che contenga le autorizzazioni necessarie per le risorse a cui accede il proprio stato. Per informazioni sulle autorizzazioni che potrebbero essere necessarie al tuo stato, vedi Gestione dei ruoli di esecuzione.

Test di uno stato utilizzando la console AWS Step Functions

È possibile testare uno stato nella console e controllare lo stato di output o il flusso di elaborazione dei dati di input e output. Per un task HTTP, puoi testare la richiesta e la risposta HTTP non elaborate.

Testare uno stato utilizzando AWS CLI

È possibile testare uno stato utilizzando l'TestStateAPI inAWS CLI. Questa API accetta la definizione di uno stato e la esegue.

Per ogni stato, puoi specificare la quantità di dettagli che desideri visualizzare nei risultati del test. Questi dettagli forniscono informazioni aggiuntive sull'esecuzione dello stato, inclusi i risultati dell'elaborazione dei dati di input e output e le informazioni su richieste e risposte HTTP. Gli esempi seguenti mostrano i diversi livelli di ispezione che è possibile specificare per l' TestState API.

Questa sezione contiene i seguenti esempi che descrivono come utilizzare i diversi livelli di ispezione disponibili in: Step Functions AWS CLI

Esempio 1: utilizzo di INFO InspectionLevel per testare uno stato Choice

Per testare uno stato utilizzando INFO InspectionLevel inAWS CLI, esegui il test-state comando come mostrato nell'esempio seguente.

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}'

Questo esempio utilizza uno stato Choice per determinare il percorso di esecuzione dello stato in base all'input numerico fornito. Per impostazione predefinita, Step Functions imposta inspectionLevel su INFO se non si imposta un livello.

Step Functionsrestituisce il seguente risultato.

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

Esempio 2: utilizzo di DEBUG inspectionLevel per eseguire il debug dell'elaborazione dei dati di input e output in uno stato Pass

Per testare uno stato utilizzando DEBUG InspectionLevel inAWS CLI, esegui il comando come mostrato nell'esempio seguentetest-state.

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

Questo esempio utilizza uno Passare lo stato del workflow stato per mostrare come Step Functions filtra e manipola i dati JSON di input utilizzando i filtri di elaborazione dei dati di input e output. Questo esempio utilizza i seguenti filtri:InputPath,, eParameters. Specificazione dello stato dell'output utilizzando ResultPath in Step Functions Filtraggio dell'output dello stato utilizzando OutputPath

Step Functionsrestituisce il seguente risultato.

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

Esempio 3: utilizzo di TRACE InspectionLevel e RevealSecrets per ispezionare la richiesta HTTP inviata a un'API HTTPS

Per testare un task HTTP utilizzando TRACE InspectionLevel insieme al parametro RevealSecrets in, esegui il comando come illustrato nell'AWS CLIesempio seguente. test-state

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

Questo esempio verifica se il task HTTP chiama l'API HTTPS specificata,. https://httpbin.org/ Mostra anche i dati di richiesta e risposta HTTP per la chiamata API.

Step Functionsrestituisce un output simile all'esempio originale nella documentazione corrente.

Esempio 4: utilizzo dell'utilità jq per filtrare e stampare la risposta restituita dall' TestState API

L' TestState API restituisce i dati JSON come stringhe di escape nella sua risposta. L'AWS CLIesempio seguente estende l'esempio 3 e utilizza l'jqutilità per filtrare e stampare la risposta HTTP restituita dall' TestState API in un formato leggibile dall'uomo. Per informazioni jq e istruzioni di installazione, consulta 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'esempio seguente mostra l'output restituito in un formato leggibile dall'uomo.

{
  "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 e debug del flusso di dati di input e output

L'TestStateAPI è utile per testare ed eseguire il debug dei dati che fluiscono attraverso il flusso di lavoro. Questa sezione fornisce alcuni concetti chiave e spiega come utilizzarli TestState per questo scopo.

Concetti chiave

NelStep Functions, il processo di filtraggio e manipolazione dei dati JSON mentre attraversano gli stati della macchina a stati viene chiamato elaborazione di input e output. Per ulteriori informazioni sul funzionamento, consulta Elaborazione di input e output in Step Functions.

Tutti i tipi di stato presenti in Lingua degli Stati di Amazon (ASL) (Task, Parallel, Map, Pass, Wait, Choice, Succeed e Fail) condividono una serie di campi comuni per filtrare e manipolare i dati JSON che li attraversano. Questi campi sono:InputPath,, eParameters. ResultSelector Specificazione dello stato dell'output utilizzando ResultPath in Step Functions Filtraggio dell'output dello stato utilizzando OutputPath Il supporto per ogni campo varia a seconda degli stati. In fase di esecuzione, Step Functions applica ogni campo in un ordine specifico. Il diagramma seguente mostra l'ordine in cui questi campi vengono applicati ai dati all'interno di uno stato del task:

L'elenco seguente descrive l'ordine di applicazione dei campi di elaborazione di input e output mostrati nel diagramma.

Questi campi di elaborazione di input e output sono opzionali. Se non si utilizza nessuno di questi campi nella definizione dello stato, l'attività utilizzerà lo stato non elaborato e restituirà il risultato dell'attività come output dello stato.

Utilizzo TestState per ispezionare l'elaborazione di input e output

Quando si chiama l'TestStateAPI e si imposta il inspectionLevel parametro suDEBUG, la risposta dell'API include un oggetto chiamatoinspectionData. Questo oggetto contiene campi che consentono di verificare in che modo i dati sono stati filtrati o manipolati all'interno dello stato in cui sono stati eseguiti. L'esempio seguente mostra l'inspectionDataoggetto per uno stato Task.

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

In questo esempio, ogni campo che contiene il after prefisso mostra i dati dopo l'applicazione di un determinato campo. Ad esempio, afterInputPath mostra l'effetto dell'applicazione del InputPath campo per filtrare l'input allo stato grezzo. Il diagramma seguente mappa ogni campo di definizione ASL al campo corrispondente nell'inspectionDataoggetto:

Per esempi di utilizzo dell' TestState API per il debug dell'elaborazione di input e output, consulta quanto segue:

In particolare per lo stato della mappa, quando inspectionLevel è impostato suDEBUG, l'inspectionDataoggetto include campi aggiuntivi che consentono di controllare come lo stato della mappa estrae e trasforma gli elementi. Puoi saperne di più su questi campi nella sezione Comprendere i dati di ispezione dello stato della mappa.

Comprensione dei dati delle ispezioni statali sulla mappa

Quando testate uno stato della mappa con inspectionLevel set toDEBUG, la risposta dell' TestState API include campi aggiuntivi nell'inspectionDataoggetto che mostrano come lo stato della mappa elabora i dati:

Questi campi consentono di verificare che le trasformazioni dei dati e le configurazioni di tolleranza agli errori dello stato della mappa funzionino correttamente prima della distribuzione.

Cosa puoi testare e affermare con l'API TestState

L' TestState API consente di scrivere test unitari completi per le macchine a stati. Potete affermarvi su diversi aspetti della logica della vostra macchina a stati, tra cui:

Gestione degli errori: a quale metodo Catch o Retry si applica

Quando simuli un errore, puoi utilizzare l' TestState API per vedere quale gestore di errori si attiva.

Per i blocchi Catch, puoi affermare:

Per i blocchi Retry, puoi affermare:

Trasformazioni dei dati: elaborazione di input e output

Utilizzando l' TestState API, è possibile convalidare il modo in cui i dati di stato vengono trasformati in ogni fase dell'elaborazione.

Puoi affermare su:

Trasformazioni dello stato della mappa: ItemSelector,, ItemsPath, ItemBatcher ItemsPointer

Per gli stati della mappa, puoi utilizzare l' TestState API per vedere come gli elementi vengono estratti e trasformati.

Puoi affermare su:

Soglie di errore dello stato della mappa: Stati di test. ExceedToleratedFailureThreshold

Verifica se un numero specifico di iterazioni fallite attiva la soglia di errore tollerata.

Puoi affermare su:

Propagazione degli errori negli stati Map e Parallel

Quando si testano gli stati all'interno degli stati Map o Parallel, gli errori si propagano ai gestori degli errori dello stato principale proprio come farebbero in un'esecuzione reale.

Specificare l'origine dell'errore con State errorCausedBy

Quando si simulano gli errori per gli stati Map o Parallel, è necessario specificare quale sottostato ha causato l'errore utilizzando il parametro. stateConfiguration.errorCausedByState Ciò è particolarmente importante quando si testano errori con caratteri jolly come. States.TaskFailed States.TaskFailedè un errore con caratteri jolly che si applica a qualsiasi errore relativo allo stato del task. Per verificare in che modo lo stato Map o Parallel gestisce questo errore, devi identificare lo stato secondario specifico che lo ha generato. Vedi l'esempio seguente:

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

In questo esempio, errorCausedByState indica TestState che lo stato "ProcessItem" all'interno del Map/Parallel flusso di lavoro ha generato l'errore. I gestori Catch o Retry Map/Parallel dello stato principale elaboreranno l'errore come farebbero durante l'esecuzione effettiva. Il nextState campo nella risposta mostra quale gestore degli errori ha rilevato l'errore. Puoi affermare su:

Integrazioni di servizi di simulazione

L' TestState API supporta la simulazione dei risultati delle integrazioni di servizi, consentendoti di testare la logica della tua macchina a stati senza richiamare servizi effettivi. AWS

Quando usare il mocking

La presa in giro è utile per:

Quando si specifica un mock, il roleArn parametro diventa facoltativo e consente di concentrarsi sul test della definizione della macchina a stati senza affrontare problemi relativi alle autorizzazioni.

Sintassi di simulazione di base

Per simulare il risultato di un'integrazione di servizi:

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\"}}"}'

Per simulare un errore:

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"}}'

Modalità di convalida fittizie

L' TestState API convalida le risposte simulate rispetto ai modelli di API di AWS servizio per garantire la correttezza. Puoi controllare il comportamento di convalida utilizzando il parametro: fieldValidationMode

Esempio con modalità di convalida:

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

Test degli stati di Map e Parallel

L' TestState API supporta il test degli stati Map e Parallel quando viene specificato un mock. Ciò consente di testare l'elaborazione di input e output di questi stati di flusso.

Comprensione dei test dello stato delle mappe

Quando testate uno stato della mappa con l' TestState API, state testando l'elaborazione di input e output dello stato della mappa senza eseguire le iterazioni interne. Questo approccio consente di testare:

Non stai testando cosa succede all'interno degli ItemProcessor (gli stati che elaborano ogni elemento).

Test dello stato di una mappa

Quando si verifica uno stato della mappa, il risultato simulato deve rappresentare l'output dell'intero stato della mappa. Il risultato fittizio deve essere un array JSON o un oggetto JSON valido a seconda della configurazione dello stato della mappa. Vedi l'esempio seguente:

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

Test degli stati delle mappe distribuite

Gli stati delle mappe distribuite vengono testati in modo simile agli stati delle mappe in linea. Quando la tua mappa utilizza un ItemReader per leggere da S3, fornisci i dati direttamente nell'input (come se fossero già stati letti da S3). Esempio:

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

Popolazione automatica del contesto

Quando si verifica uno stato all'interno di uno stato della mappa (utilizzando il stateName parametro) senza fornire un context parametro, popola TestState automaticamente l'oggetto Context con valori predefiniti. Ciò include campi contestuali specifici della mappa come:

Test degli stati paralleli

Quando si testa uno stato parallelo, il risultato simulato deve essere un array JSON con un elemento per ogni ramo, nello stesso ordine in cui i rami appaiono nella definizione.

Testing Activity, .sync e. waitForTaskStati dei token

L' TestState API supporta il test degli stati di attività, dei modelli di integrazione del servizio.sync e. waitForTaskSchemi di token quando viene specificato un mock. Senza un mock, l'invocazione di questi stati tramite TestState API restituirà un'eccezione di convalida.

Iterazione attraverso le definizioni delle macchine a stati

È possibile fornire una definizione completa della macchina a stati all' TestState API e specificare lo stato da testare utilizzando il stateName parametro. Ciò consente di testare quello stato specifico nel contesto della macchina a stati completa. È inoltre possibile concatenare i test utilizzando l'output e NextState da un test come input al successivo. Ciò consente di testare percorsi di esecuzione parziali o completi all'interno della macchina a stati.

Utilizzo del campo contestuale nell' TestState API

Il context parametro consente di fornire valori per l'oggetto Context che normalmente verrebbero compilati durante l'esecuzione. Questo è utile per testare gli stati che fanno riferimento a valori di contesto come l'ID di esecuzione, il nome dello stato o l'ora inserita. L'esempio seguente mostra come è possibile utilizzare l'oggetto Context nella chiamata TestState 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\"}"}'

Test, ripetizione dei tentativi e della gestione degli errori

L' TestState API consente di simulare scenari di nuovi tentativi e di testare la logica di gestione degli errori specificando tentativi di ripetizione ed errori di simulazione.

Simulazione dei tentativi di nuovo tentativo

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 risposta include i dettagli dell'errore in InspectionData:

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

Questa risposta indica:

Test dei gestori di catch

Quando un errore viene simulato e corrisponde a un gestore Catch, il nextState campo nella risposta dell' TestState API indica quale stato gestirà l'errore. Nell'esempio seguente:

Per la richiesta TestState API indicata di seguito,

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 risposta API prevista dovrebbe essere:

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

Questa risposta indica che:

Puoi anche verificare cosa succede quando tutti i tentativi di riprova sono esauriti aumentando RetryCount i valori nell'oggetto contestuale.