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

File di configurazione per integrazioni di servizi simulate in Step Functions

Per utilizzare integrazioni di servizi simulate, devi prima creare un file di configurazione fittizio denominato contenente le tue configurazioni fittizie. MockConfigFile.json Quindi fornisci a Step Functions Local il file di configurazione fittizio. Questo file di configurazione definisce i casi di test, che contengono stati fittizi che utilizzano risposte simulate di integrazione dei servizi. La sezione seguente contiene informazioni sulla struttura della configurazione fittizia che include gli stati fittizi e le risposte simulate:

Struttura fittizia del file di configurazione

Una configurazione fittizia è un JSON oggetto contenente i seguenti campi di primo livello:

Di seguito è riportato un esempio di un file di configurazione fittizio che include una StateMachine definizione e. MockedResponse

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

Riferimento al campo di configurazione fittizio

Le sezioni seguenti spiegano i campi oggetto di primo livello che è necessario definire nella configurazione fittizia.

StateMachines

L'StateMachinesoggetto definisce quali macchine a stati utilizzeranno integrazioni di servizi simulate. La configurazione per ogni macchina a stati è rappresentata come un campo di primo livello di. StateMachines Il nome del campo è il nome della macchina a stati e il valore è un oggetto contenente un singolo campo denominatoTestCases, i cui campi rappresentano i casi di test di quella macchina a stati.

La sintassi seguente mostra una macchina a stati con due casi di test:

"MyStateMachine": {
  "TestCases": {
    "HappyPath": {
      ...
    },
    "SadPath": {
      ...
    }
  }

TestCases

I campi TestCases rappresentano singoli casi di test per la macchina a stati. Il nome di ogni test case deve essere univoco per macchina a stati e il valore di ogni test case è un oggetto che specifica una risposta simulata da utilizzare per gli stati Task nella macchina a stati.

L'esempio seguente TestCase collega due Task stati a due: MockedResponses

"HappyPath": {
  "SomeTaskState": "SomeMockedResponse",
  "AnotherTaskState": "AnotherMockedResponse"
}

MockedResponses

MockedResponsesè un oggetto contenente più oggetti di risposta simulati con nomi di campo univoci. Un oggetto di risposta simulato definisce il risultato positivo o l'output di errore per ogni invocazione di uno stato Task simulato. È possibile specificare il numero di invocazione utilizzando singole stringhe di numeri interi, come «0", «1", «2" e «3" o un intervallo inclusivo di numeri interi, come «0-1», «2-3».

Quando si simula un Task, è necessario specificare una risposta simulata per ogni invocazione. Una risposta deve contenere un singolo campo denominato Return o il Throw cui valore è l'output del risultato o dell'errore per la chiamata simulata del Task. Se non si specifica una risposta simulata, l'esecuzione della macchina a stati avrà esito negativo.

Di seguito è riportato un esempio di MockedResponse con Throw e Return oggetti. In questo esempio, le prime tre volte che viene eseguita la macchina a stati, "0-2" viene restituita la risposta specificata in e la quarta volta che viene eseguita la macchina a stati, "3" viene restituita la risposta specificata in.

"SomeMockedResponse": {
  "0-2": {
    "Throw": {
      ...
    }
  },
  "3": {
    "Return": {
      ...
    }
  }
}

Return

Returnè rappresentato come un campo degli oggetti. MockedResponse Specifica il risultato positivo di uno stato Task simulato.

Di seguito è riportato un esempio di Return oggetto che contiene una risposta simulata per la chiamata Invokea una funzione Lambda:

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

Lancia

Throwè rappresentato come un campo degli MockedResponse oggetti. Specifica l'output di errore di un'operazione non riuscita. Il valore di Throw deve essere un oggetto contenente un Error e Cause campi con valori di stringa. Inoltre, il valore di stringa specificato nel Error campo in MockConfigFile.json deve corrispondere agli errori gestiti nelle Catch sezioni Retry e della macchina a stati.

Di seguito è riportato un esempio di Throw oggetto che contiene una risposta simulata per la chiamata Invokea una funzione Lambda:

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