Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Prueba de máquinas de estado con Step Functions Local (no compatible)
**Step Functions Local no es compatible**
Step Functions Local **no** proporciona paridad de características y **no es compatible**.
Podría considerar soluciones de terceros que emulen Step Functions con fines de prueba.
Como alternativa a Step Functions Local, puedes usar la TestState API para realizar pruebas unitarias de la lógica de tu máquina de estados antes de implementarla en tu AWS cuenta. Para obtener más información, consulta [Probar máquinas de estado con la TestState API](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html).
Con AWS Step Functions Local, una versión descargable de Step Functions, puede probar aplicaciones con Step Functions ejecutándose en su propio entorno de desarrollo.
Cuando ejecuta Step Functions Local, puede utilizar una de las siguientes formas de invocar las integraciones de servicios:
+ Configuración de puntos finales locales para AWS Lambda y otros servicios.
+ Realizar llamadas directamente a un AWS servicio desde Step Functions Local.
+ Simular la respuesta de integraciones de servicios.
AWS Step Functions Local está disponible como un paquete JAR o una imagen de Docker independiente que se ejecuta en Microsoft Windows, Linux, macOS y otras plataformas compatibles con Java o Docker.
**aviso**
Solo debe usar Step Functions Local para realizar pruebas y nunca para procesar información confidencial.
**Topics**
+ [Configuración de Step Functions Local y Docker](#sfn-local-docker)
+ [Configuración de Step Functions Local - Versión Java](#sfn-local-jar)
+ [Configuración de opciones de Step Functions Local](#sfn-local-config-options)
+ [Ejecución de Step Functions Local](#sfn-local-computer)
+ [Tutorial: Pruebas con Step Functions y AWS SAM CLI Local](sfn-local-lambda.md)
+ [Pruebas con integraciones de servicios simuladas](sfn-local-test-sm-exec.md)
## Configuración de Step Functions Local (versión descargable) en Docker
La imagen de Docker de Step Functions Local permite empezar a trabajar rápidamente con Step Functions Local mediante una imagen de Docker con todas las dependencias necesarias. La imagen de Docker permite incluir Step Functions Local en las versiones contenedorizadas y como parte de las pruebas continuas de integración.
Para obtener la imagen de Docker para Step Functions Local, consulta [https://hub.docker.com/r/amazon/ aws-stepfunctions-local](https://hub.docker.com/r/amazon/aws-stepfunctions-local) o introduce el siguiente comando de `pull` Docker.
```
docker pull amazon/aws-stepfunctions-local
```
Para iniciar la versión descargable de Step Functions en Docker, ejecute el siguiente comando `run` de Docker.
```
docker run -p 8083:8083 amazon/aws-stepfunctions-local
```
Para interactuar con AWS Lambda u otros servicios compatibles, primero debe configurar sus credenciales y otras opciones de configuración. Para obtener más información, consulte los temas siguientes:
+ [Configurar opciones de configuración para Step Functions Local](#sfn-local-config-options)
+ [Credenciales y configuración de Docker](#docker-credentials)
## Configurar Step Functions Local (versión descargable) - Versión Java
La versión descargable de AWS Step Functions se proporciona como un archivo JAR ejecutable y como una imagen de Docker. La aplicación Java se ejecuta en Windows, Linux, macOS y otras plataformas compatibles con Java. Además de Java, debe instalar el AWS Command Line Interface (AWS CLI). Para obtener información sobre la instalación y configuración de AWS CLI, consulte la [Guía del AWS Command Line Interface usuario](https://docs.aws.amazon.com/cli/latest/userguide/).
**Para configurar y ejecutar Step Functions en su equipo**
1. Descargue Step Functions utilizando los siguientes enlaces.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/step-functions/latest/dg/sfn-local.html)
1. Extraiga el archivo `.zip`.
1. Pruebe la descarga y consulte la información de la versión.
```
$ java -jar StepFunctionsLocal.jar -v
Step Function Local
Version: 2.0.0
Build: 2024-05-18
```
1. (Opcional) Vea una lista de los comandos disponibles.
```
$ java -jar StepFunctionsLocal.jar -h
```
1. Para iniciar Step Functions en el equipo, abra un símbolo del sistema, vaya al directorio donde ha extraído `StepFunctionsLocal.jar` y escriba el comando siguiente.
```
java -jar StepFunctionsLocal.jar
```
1. Para obtener acceso a Step Functions en ejecución local, utilice el parámetro `--endpoint-url`. Por ejemplo, mediante el AWS CLI, especificaría los comandos de Step Functions de la siguiente manera:
```
aws stepfunctions --endpoint-url http://localhost:8083 command
```
**nota**
De forma predeterminada, Step Functions Local utiliza una cuenta de prueba y credenciales locales, y la región de AWS se establece en Este de EE. UU. (Norte de Virginia). Para usar Step Functions Local con AWS Lambda u otros servicios compatibles, debe configurar sus credenciales y su región.
Si utiliza flujos de trabajo rápidos con Step Functions Local, el historial de ejecución se almacenará en un archivo de registro. No está registrado en CloudWatch Logs. La ruta del archivo de registro se basará en el ARN del grupo de CloudWatch registros de registros que se proporcionó al crear la máquina de estado local. El archivo de registro se almacenará en `/aws/states/log-group-name/${execution_arn}.log` respecto a la ubicación en la que se ejecuta Step Functions Local. Por ejemplo, si el ARN de ejecución es:
```
arn:aws:states:region:account-id:express:test:example-ExpressLogGroup-wJalrXUtnFEMI
```
el archivo de registro será:
```
aws/states/log-group-name/arn:aws:states:region:account-id:express:test:example-ExpressLogGroup-wJalrXUtnFEMI.log
```
## Configurar opciones de configuración para Step Functions Local
Al iniciar AWS Step Functions Local mediante el archivo JAR, puede establecer las opciones de configuración mediante AWS Command Line Interface (AWS CLI) o incluirlas en el entorno del sistema. Para Docker, debe especificar estas opciones en un archivo al que haga referencia cuando inicie Step Functions Local.
### Opciones de configuración
Cuando configura el contenedor de Step Functions Local para usar un punto de conexión de anulación, como Punto de conexión de Lambda y Punto de conexión de lote, y realiza llamadas a ese punto de conexión, Step Functions Local no utiliza las [credenciales](#docker-credentials) que especifique. La configuración de estas anulaciones de punto de conexión es opcional.
| Opción | Línea de comandos | Entorno |
| --- | --- | --- |
| Cuenta | -account, --aws-account | AWS\$1ACCOUNT\$1ID |
| Region | -region, --aws-region | AWS\$1DEFAULT\$1REGIÓN |
| Escala de tiempo de espera | -waitTimeScale, --wait-time-scale | WAIT\$1TIME\$1SCALE |
| Punto de enlace de Lambda | -lambdaEndpoint, --lambda-endpoint | LAMBDA\$1ENDPOINT |
| Punto de enlace de Batch | -batchEndpoint, --batch-endpoint | BATCH\$1ENDPOINT |
| Punto de enlace de DynamoDB | -dínamo, --dynamodb-endpoint DBEndpoint | DYNAMODB\$1ENDPOINT |
| Punto de enlace de ECS | -ecsEndpoint, --ecs-endpoint | ECS\$1ENDPOINT |
| Punto de enlace de Glue | -glueEndpoint, --glue-endpoint | GLUE\$1ENDPOINT |
| SageMaker Punto final | -sageMakerEndpoint, --sagemaker-endpoint | SAGE\$1MAKER\$1ENDPOINT |
| Punto de enlace de SQS | -sqsEndpoint, --sqs-endpoint | SQS\$1ENDPOINT |
| Punto de enlace de SNS | -snsEndpoint, --sns-endpoint | SNS\$1ENDPOINT |
| Punto de conexión de Step Functions | -stepFunctionsEndpoint, --step-functions-endpoint | STEP\$1FUNCTIONS\$1ENDPOINT |
### Credenciales y configuración de Docker
Para configurar Step Functions Local para Docker, cree el archivo siguiente: `aws-stepfunctions-local-credentials.txt`.
Este archivo contiene sus credenciales y otras opciones de configuración. Se puede utilizar lo siguiente como plantilla al crear el archivo `aws-stepfunctions-local-credentials.txt`.
```
AWS_DEFAULT_REGION=AWS_REGION_OF_YOUR_AWS_RESOURCES
AWS_ACCESS_KEY_ID=YOUR_AWS_ACCESS_KEY
AWS_SECRET_ACCESS_KEY=YOUR_AWS_SECRET_KEY
WAIT_TIME_SCALE=VALUE
LAMBDA_ENDPOINT=VALUE
BATCH_ENDPOINT=VALUE
DYNAMODB_ENDPOINT=VALUE
ECS_ENDPOINT=VALUE
GLUE_ENDPOINT=VALUE
SAGE_MAKER_ENDPOINT=VALUE
SQS_ENDPOINT=VALUE
SNS_ENDPOINT=VALUE
STEP_FUNCTIONS_ENDPOINT=VALUE
```
Una vez que haya configurado sus credenciales y las opciones de configuración en `aws-stepfunctions-local-credentials.txt`, inicie Step Functions con el siguiente comando.
```
docker run -p 8083:8083 --env-file aws-stepfunctions-local-credentials.txt amazon/aws-stepfunctions-local
```
**nota**
Se recomienda utilizar el nombre de DNS especial `host.docker.internal`, que se resuelve en la dirección IP interna que utiliza el host, por ejemplo `http://host.docker.internal:8000`. Para obtener más información, consulte la documentación de Docker para Mac y Windows en [Networking features in Docker Desktop for Mac](https://docs.docker.com/desktop/mac/networking/#use-cases-and-workaround) y [Networking features in Docker Desktop for Windows](https://docs.docker.com/desktop/windows/networking/), respectivamente.
## Ejecute Step Functions Local en su ordenador
Utilice la versión local de Step Functions para configurar, desarrollar y probar máquinas de estado en su ordenador.
### Ejecute una máquina de estados localmente HelloWorld
Tras ejecutar Step Functions localmente con AWS Command Line Interface (AWS CLI), puede iniciar la ejecución de una máquina de estados.
1. Cree una máquina de estados a partir AWS CLI de la definición de la máquina de estados.
```
aws stepfunctions --endpoint-url http://localhost:8083 create-state-machine --definition "{\
\"Comment\": \"A Hello World example of the Amazon States Language using a Pass state\",\
\"StartAt\": \"HelloWorld\",\
\"States\": {\
\"HelloWorld\": {\
\"Type\": \"Pass\",\
\"End\": true\
}\
}}" --name "HelloWorld" --role-arn "arn:aws:iam::012345678901:role/DummyRole"
```
**nota**
El `role-arn` no se utiliza para Step Functions Local, pero debe incluirlo con la sintaxis adecuada. Puede utilizar el nombre de recurso de Amazon (ARN) del ejemplo anterior.
Si ha creado correctamente la máquina de estado, Step Functions responderá con la fecha de creación y el ARN de la máquina de estado.
```
{
"creationDate": 1548454198.202,
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld"
}
```
1. Inicie una ejecución utilizando el ARN de la máquina de estado que ha creado.
```
aws stepfunctions --endpoint-url http://localhost:8083 start-execution --state-machine-arn arn:aws:states:region:account-id:stateMachine:HelloWorld
```
### Step Functions Local con AWS SAM CLI Local
Puede utilizar la versión local de Step Functions junto con una versión local de AWS Lambda. Para configurar esto, debe instalar y configurar AWS SAM.
Para obtener información sobre la configuración y la ejecución AWS SAM, consulte lo siguiente:
+ [Configurar AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html)
+ [Iniciar AWS SAM CLI local](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-cli-command-reference-sam-local-start-lambda.html)
Una vez que Lambda se esté ejecutando en el sistema local, puede iniciar Step Functions Local. Desde el directorio en el que extrajo los archivos JAR de Step Functions Local, inicie Step Functions Local y utilice el parámetro `--lambda-endpoint` para configurar el punto de conexión de Lambda local.
```
java -jar StepFunctionsLocal.jar --lambda-endpoint http://127.0.0.1:3001 command
```
Para obtener más información sobre cómo ejecutar Step Functions Local con AWS Lambda, consulte[Tutorial: Probar flujos de trabajo con Step Functions y AWS SAM CLI Local](sfn-local-lambda.md).
# Tutorial: Probar flujos de trabajo con Step Functions y AWS SAM CLI Local
**Step Functions Local no es compatible**
Step Functions Local **no** proporciona paridad de características y **no es compatible**.
Podría considerar soluciones de terceros que emulen Step Functions con fines de prueba.
Como alternativa a Step Functions Local, puedes usar la TestState API para realizar pruebas unitarias de la lógica de tu máquina de estados antes de implementarla en tu AWS cuenta. Para obtener más información, consulta [Probar máquinas de estado con la TestState API](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html).
Con ambas funciones AWS Step Functions y AWS Lambda ejecutándose en su máquina local, puede probar la máquina de estado y las funciones de Lambda sin tener que implementar el código en ellas. AWS
Para obtener más información, consulte los temas siguientes:
+ [Prueba de máquinas de estado con Step Functions Local (no compatible)](sfn-local.md)
+ [Configurar AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html)
## Paso 1: Configurar AWS SAM
AWS Serverless Application Model (AWS SAM) CLI Local requiere la instalación de AWS Command Line Interface AWS SAM, y Docker.
1. [Instale la AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html).
**nota**
Antes de instalar la AWS SAM CLI, debe instalar AWS CLI y Docker. Consulte los [requisitos previos](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-sam-cli-install.html) para instalar la AWS SAM CLI.
1. Lea la documentación de [Inicio rápido de AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html). Asegúrese de seguir los pasos para hacer lo siguiente:
1. [Inicializar la aplicación](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html#gs-ex1-setup-local-app)
1. [Probar la aplicación localmente](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/serverless-quick-start.html#gs-ex1-test-locally)
Esto crea un directorio `sam-app` y crea un entorno que incluye una función de Lambda Hello World basada en Python.
## Paso 2: Probar AWS SAM CLI local
Ahora que ha instalado AWS SAM y creado la función Lambda de Hello World, puede probarla. En el directorio `sam-app`, introduzca el siguiente comando:
```
sam local start-api
```
Se lanzará una instancia local de su función de Lambda. Debería ver una salida similar a esta:
```
2019-01-31 16:40:27 Found credentials in shared credentials file: ~/.aws/credentials
2019-01-31 16:40:27 Mounting HelloWorldFunction at http://127.0.0.1:3000/hello [GET]
2019-01-31 16:40:27 You can now browse to the above endpoints to invoke your functions. You do not need to restart/reload SAM CLI while working on your functions changes will be reflected instantly/automatically. You only need to restart SAM CLI if you update your AWS SAM template
2019-01-31 16:40:27 * Running on http://127.0.0.1:3000/ (Press CTRL+C to quit)
```
Abra un navegador y escriba lo siguiente.
```
http://127.0.0.1:3000/hello
```
La salida será una respuesta similar a la siguiente:
```
{"message": "hello world", "location": "72.21.198.66"}
```
Pulse **CTRL\$1C** para finalizar la API de Lambda.
## Paso 3: iniciar AWS SAM CLI local
Ahora que ha comprobado que la función funciona, inicie AWS SAM CLI Local. En el directorio `sam-app`, introduzca el siguiente comando:
```
sam local start-lambda
```
Esto inicia AWS SAM CLI Local y proporciona el punto final que se debe utilizar, similar al siguiente resultado:
```
2019-01-29 15:33:32 Found credentials in shared credentials file: ~/.aws/credentials
2019-01-29 15:33:32 Starting the Local Lambda Service. You can now invoke your Lambda Functions defined in your template through the endpoint.
2019-01-29 15:33:32 * Running on http://127.0.0.1:3001/ (Press CTRL+C to quit)
```
## Paso 4: Iniciar Step Functions Local
### Archivo JAR
Si utiliza la versión del archivo `.jar` de Step Functions Local, inicie Step Functions y especifique el punto de conexión de Lambda. En el directorio donde extrajo los archivos `.jar`, escriba el siguiente comando:
```
java -jar StepFunctionsLocal.jar --lambda-endpoint http://localhost:3001
```
Cuando Step Functions Local se inicie, comprueba el entorno y después las credenciales configuradas en su archivo `~/.aws/credentials`. De forma predeterminada, comienza a usar un ID de usuario ficticio y aparece como `region us-east-1`.
```
2019-01-29 15:38:06.324: Failed to load credentials from environment because Unable to load AWS credentials from environment variables (AWS_ACCESS_KEY_ID (or AWS_ACCESS_KEY) and AWS_SECRET_KEY (or AWS_SECRET_ACCESS_KEY))
2019-01-29 15:38:06.326: Loaded credentials from profile: default
2019-01-29 15:38:06.326: Starting server on port 8083 with account account-id, region us-east-1
```
### Docker
En caso de que se utilice la versión de Docker de Step Functions Local, lance Step Functions con el siguiente comando:
```
docker run -p 8083:8083 amazon/aws-stepfunctions-local
```
Para obtener información sobre cómo instalar la versión de Docker de Step Functions, consulte [Configuración de Step Functions Local (versión descargable) en Docker](sfn-local.md#sfn-local-docker).
**nota**
Puede especificar el punto de conexión con la línea de comandos o configurando variables de entorno si lanza Step Functions desde el archivo `.jar`. Para la versión de Docker, debe especificar los puntos de enlace y las credenciales en un archivo de texto. Consulte [Configurar opciones de configuración para Step Functions Local](sfn-local.md#sfn-local-config-options).
## Paso 5: Cree una máquina de estados que haga referencia a su función local de AWS SAM CLI
Una vez que Step Functions Local se esté ejecutando, cree una máquina de estado que haga referencia a la `HelloWorldFunction` que inicializó en [Paso 1: Configurar AWS SAM](#install-sam).
```
aws stepfunctions --endpoint http://localhost:8083 create-state-machine --definition "{\
\"Comment\": \"A Hello World example of the Amazon States Language using an AWS Lambda Local function\",\
\"StartAt\": \"HelloWorld\",\
\"States\": {\
\"HelloWorld\": {\
\"Type\": \"Task\",\
\"Resource\": \"arn:aws:lambda:region:account-id:function:HelloWorldFunction\",\
\"End\": true\
}\
}\
}\" --name "HelloWorld" --role-arn "arn:aws:iam::012345678901:role/DummyRole"
```
De esta manera, se creará una máquina de estado y se proporcionará un nombre de recurso de Amazon (ARN), que puede utilizar para iniciar una ejecución:
```
{
"creationDate": 1548805711.403,
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld"
}
```
## Paso 6: Iniciar una ejecución de su máquina de estado local
Una vez que haya creado una máquina de estado, inicie una ejecución. Deberá hacer referencia al punto de conexión y al ARN de la máquina de estado cuando utilice el siguiente comando **aws stepfunctions**:
```
aws stepfunctions --endpoint http://localhost:8083 start-execution --state-machine arn:aws:states:region:account-id:stateMachine:HelloWorld --name test
```
Esto inicia una ejecución denominada `test` de su máquina de estado `HelloWorld`.
```
{
"startDate": 1548810641.52,
"executionArn": "arn:aws:states:region:account-id:execution:HelloWorld:test"
}
```
Ahora que Step Functions se ejecuta localmente, puede interactuar con él mediante AWS CLI. Por ejemplo, para obtener información sobre esta ejecución, utilice el siguiente comando:
```
aws stepfunctions --endpoint http://localhost:8083 describe-execution --execution-arn arn:aws:states:region:account-id:execution:HelloWorld:test
```
La llamada a `describe-execution` para una ejecución proporciona detalles más completos, como se indica en la siguiente salida:
```
{
"status": "SUCCEEDED",
"startDate": 1549056334.073,
"name": "test",
"executionArn": "arn:aws:states:region:account-id:execution:HelloWorld:test",
"stateMachineArn": "arn:aws:states:region:account-id:stateMachine:HelloWorld",
"stopDate": 1549056351.276,
"output": "{\"statusCode\": 200, \"body\": \"{\\\"message\\\": \\\"hello world\\\", \\\"location\\\": \\\"72.21.198.64\\\"}\"}",
"input": "{}"
}
```
# Uso de integraciones de servicios simuladas para realizar pruebas en Step Functions Local
**Step Functions Local no es compatible**
Step Functions Local **no** proporciona paridad de características y **no es compatible**.
Podría considerar soluciones de terceros que emulen Step Functions con fines de prueba.
En Step Functions Local, puede probar las rutas de ejecución de sus máquinas de estado sin llamar realmente a los servicios integrados mediante integraciones de servicios simuladas. Para configurar sus máquinas de estado para que utilicen integraciones de servicios simuladas, cree un archivo de configuración simulado. En este archivo, defina la salida deseada de sus integraciones de servicios como respuestas simuladas y las ejecuciones que utilizan sus respuestas simuladas para simular una ruta de ejecución como casos de prueba.
Al proporcionar el archivo de configuración simulado a Step Functions Local, puede probar las llamadas de integración de servicios ejecutando máquinas de estado que utilizan las respuestas simuladas especificadas en los casos de prueba en lugar de realizar llamadas de integración de servicios reales.
**nota**
Si no especificas respuestas de integración de servicios simuladas en el archivo de configuración simulado, Step Functions Local invocará la integración de AWS servicios mediante el punto final que configuraste al configurar Step Functions Local. Para obtener información sobre la configuración de puntos de conexión para Step Functions Local, consulte [Configurar opciones de configuración para Step Functions Local](sfn-local.md#sfn-local-config-options).
En este tema se utilizan varios conceptos que se definen en la siguiente lista:
+ Integraciones de servicios simuladas: se refiere a los estados Task configurados para utilizar respuestas simuladas en lugar de realizar llamadas de servicio reales.
+ Respuestas simuladas: se refiere a datos simulados que los estados Task pueden configurar para usar.
+ Casos de prueba: se refieren a las ejecuciones de máquinas de estado configuradas para utilizar integraciones de servicios simuladas.
+ Archivo de configuración simulado: se refiere al archivo de configuración simulado que contiene JSON, que define las integraciones de servicios simuladas, las respuestas simuladas y los casos de prueba.
## Configuración de integraciones de servicios simuladas
Puede simular cualquier integración de servicios mediante Step Functions Local. Sin embargo, Step Functions Local no exige que los simulacros sean iguales a los reales APIs. Una tarea simulada nunca llamará al punto de conexión del servicio. Si no especifica una respuesta simulada, una tarea intentará llamar a los puntos de conexión del servicio. Además, Step Functions Local generará automáticamente un token de tarea cuando simule una tarea con `.waitForTaskToken`.
## Paso 1: Especificar las integraciones de servicios simuladas en un archivo de configuración simulado
Puede probar el AWS SDK de Step Functions y las integraciones de servicios optimizadas mediante Step Functions Local. En la siguiente imagen se muestra la máquina de estado definida en la pestaña Definición de máquina de estado:
![\[Ejemplo de integración de servicios simulada.\]](http://docs.aws.amazon.com/es_es/step-functions/latest/dg/images/msi-graph.png)
Para ello, debe crear un archivo de configuración simulado que contenga las secciones definidas en [Estructura del archivo de configuración del archivo](#mock-cfg-struct).
1. Cree un archivo con el nombre `MockConfigFile.json` para configurar las pruebas con integraciones de servicios simuladas.
En el siguiente ejemplo se muestra un archivo de configuración simulado que hace referencia a una máquina de estado con dos estados definidos denominados `LambdaState` y `SQSState`
------
#### [ Mock configuration file example ]
A continuación se muestra un ejemplo de un archivo de configuración simulado que muestra cómo simular respuestas al [invocar una función de Lambda](connect-lambda.md) y [enviar un mensaje a Amazon SQS](connect-sqs.md). En este ejemplo, la máquina de estado [`LambdaSQSIntegration`](#mock-cfg-sm-sect) contiene tres casos de prueba denominados `HappyPath`, `RetryPath` y `HybridPath` que simulan los estados `Task` denominados `LambdaState` y `SQSState`. Estos estados utilizan las respuestas de servicio simuladas `MockedLambdaSuccess`, `MockedSQSSuccess` y `MockedLambdaRetry`. Estas respuestas de servicio simuladas se definen en la sección `MockedResponses` del archivo.
```
{
"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 ]
A continuación se muestra un ejemplo de una definición de máquina de estado denominada `LambdaSQSIntegration`, que define dos estados de tareas de integración de servicios denominados `LambdaState` y `SQSState`. `LambdaState` contiene una política de reintentos basada en `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/account-id/myQueue",
"MessageBody.$":"$"
},
"End": true
}
}
}
```
------
Puede ejecutar la definición de la máquina de estado `LambdaSQSIntegration` a la que se hace referencia en el archivo de configuración simulado mediante uno de los siguientes casos de prueba:
+ `HappyPath`: esta prueba simula la salida de `LambdaState` y `SQSState` mediante `MockedLambdaSuccess` y `MockedSQSSuccess`, respectivamente.
+ El `LambdaState` devolverá los siguientes valores:
```
"0":{
"Return":{
"StatusCode":200,
"Payload":{
"StatusCode":200,
"body":"Hello from Lambda!"
}
}
}
```
+ El `SQSState` devolverá los siguientes valores:
```
"0":{
"Return":{
"MD5OfMessageBody":"3bcb6e8e-7h85-4375-b0bc-1a59812c6e51",
"MessageId":"3bcb6e8e-8b51-4375-b0bc-1a59812c6e51"
}
}
```
+ `RetryPath`: esta prueba simula la salida de `LambdaState` y `SQSState` mediante `MockedLambdaRetry` y `MockedSQSSuccess`, respectivamente. Además, `LambdaState` está configurada para realizar cuatro reintentos. Las respuestas simuladas para estos intentos se definen e indexan en el estado `MockedLambdaRetry`.
+ El intento inicial finaliza con un error en la tarea que contiene un mensaje de causa y error, como se muestra en el siguiente ejemplo:
```
"0":{
"Throw": {
"Error": "Lambda.ResourceNotReadyException",
"Cause": "Lambda resource is not ready."
}
}
```
+ El primer y el segundo intento finalizan con un error en la tarea que contiene un mensaje de causa y error, como se muestra en el siguiente ejemplo:
```
"1-2":{
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
}
```
+ El tercer intento finaliza con una tarea exitosa que contiene el resultado de estado de la sección Carga en la respuesta de Lambda simulada.
```
"3":{
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
}
```
**nota**
En el caso de los estados con una política de reintentos, Step Functions Local agotará los reintentos establecidos en la política hasta que reciba una respuesta correcta. Esto significa que debe denotar simulaciones para los reintentos con números de intentos consecutivos y debe cubrir todos los reintentos antes de obtener una respuesta correcta.
Si no especifica una respuesta simulada para un reintento específico (por ejemplo, si reintenta «3»), la ejecución de la máquina de estado generará un error.
+ `HybridPath`: esta prueba simula la salida de `LambdaState`. Después de que `LambdaState` se ejecute correctamente y reciba datos simulados como respuesta, `SQSState` realiza una llamada de servicio real al recurso especificado en producción.
Para obtener información sobre cómo iniciar las ejecuciones de pruebas con integraciones de servicios simuladas, consulte [Paso 3: Ejecutar pruebas de integración de servicios simuladas](#run-mocked-serv-integ-tests).
1. Asegúrese de que la estructura de las respuestas simuladas se ajuste a la estructura de las respuestas de servicio reales que recibe cuando realiza llamadas de servicio integradas. Para obtener información sobre los requisitos estructurales de las respuestas simuladas, consulte [Configuración de integraciones de servicios simuladas](#mock-resp-struct-req).
En el archivo de configuración simulada del ejemplo anterior, las respuestas simuladas definidas en `MockedLambdaSuccess` y `MockedLambdaRetry` se ajustan a la estructura de las respuestas reales que se devuelven al llamar a `HelloFromLambda`.
**importante**
Las respuestas del servicio de AWS pueden variar entre los distintos servicios. Step Functions Local no valida si las estructuras de respuesta simuladas se ajustan a las estructuras de respuesta del servicio reales. Debe asegurarse de que sus respuestas simuladas se ajusten a las respuestas reales antes de realizar la prueba. Para revisar la estructura de las respuestas de servicios, puede realizar las llamadas de servicio reales mediante Step Functions o consultar la documentación de dichos servicios.
## Paso 2: Proporcionar el archivo de configuración simulado a Step Functions Local
Puede proporcionar el archivo de configuración simulado a Step Functions Local de una de las siguientes maneras:
------
#### [ Docker ]
**nota**
Si utiliza la versión Docker de Step Functions Local, puede proporcionar el archivo de configuración simulado utilizando únicamente una variable de entorno. Además, debe montar el archivo de configuración simulado en el contenedor de Step Functions Local en el arranque inicial del servidor.
Monte el archivo de configuración simulado en cualquier directorio del contenedor de Step Functions Local. A continuación, defina una variable de entorno denominada `SFN_MOCK_CONFIG` que contenga la ruta al archivo de configuración simulado del contenedor. Este método permite que el archivo de configuración simulado reciba cualquier nombre siempre que la variable de entorno contenga la ruta y el nombre del archivo.
El siguiente comando muestra el formato para iniciar la imagen de 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
```
En el siguiente ejemplo se utiliza el comando para iniciar la imagen de 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 una de las siguientes formas para proporcionar el archivo de configuración simulado a Step Functions Local:
+ Coloque el archivo de configuración simulado en el mismo directorio que `Step FunctionsLocal.jar`. Al usar este método, debe asignar un nombre al archivo de configuración simulado `MockConfigFile.json`.
+ En la sesión en la que se ejecuta Step Functions Local, defina una variable de entorno denominada `SFN_MOCK_CONFIG`, con la ruta completa del archivo de configuración simulado. Este método permite que el archivo de configuración simulado reciba cualquier nombre siempre que la variable de entorno contenga la ruta y el nombre del archivo. En el siguiente ejemplo, la variable `SFN_MOCK_CONFIG` se establece para que apunte a un archivo de configuración simulado denominado `EnvSpecifiedMockConfig.json`, ubicado en el directorio `/home/workspace`.
```
export SFN_MOCK_CONFIG="/home/workspace/EnvSpecifiedMockConfig.json"
```
**nota**
Si no se proporciona la variable de entorno `SFN_MOCK_CONFIG` a Step Functions Local, de forma predeterminada, intentará leer un archivo de configuración simulado denominado `MockConfigFile.json` en el directorio desde el que se inició Step Functions Local.
Si coloca el archivo de configuración simulado en el mismo directorio que `Step FunctionsLocal.jar` y establece la variable de entorno `SFN_MOCK_CONFIG`, Step Functions Local leerá el archivo especificado por la variable de entorno.
------
## Paso 3: Ejecutar pruebas de integración de servicios simuladas
Después de crear y proporcionar un archivo de configuración simulado a Step Functions Local, ejecute la máquina de estado configurada en el archivo de configuración simulado mediante integraciones de servicios simuladas. A continuación, compruebe los resultados de la ejecución mediante una acción de API.
1. Cree una máquina de estado basada en la definición mencionada anteriormente en el [archivo de configuración simulado](#create-mock-config-file).
```
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:region:account-id: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/account-id/myQueue\",\"MessageBody.$\":\"$\"},\"End\":true}}}" \
--name "LambdaSQSIntegration" --role-arn "arn:aws:iam::account-id:role/service-role/LambdaSQSIntegration"
```
1. Ejecute la máquina de estado mediante integraciones de servicios simuladas.
Para usar el archivo de configuración simulado, realice una llamada a la API `[StartExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_StartExecution.html)` en una máquina de estado configurada en el archivo de configuración simulado. Para ello, añada el sufijo ,`#test_name`, al ARN de la máquina de estado utilizado por `StartExecution`. `test_name` es un caso de prueba, que se configura para la máquina de estado en el mismo archivo de configuración simulado.
El siguiente comando es un ejemplo que utiliza la máquina de estado `LambdaSQSIntegration` y la configuración simulada. En este ejemplo, la máquina de estado `LambdaSQSIntegration` se ejecuta mediante la prueba `HappyPath` definida en [Paso 1: Especificar las integraciones de servicios simuladas en un archivo de configuración simulado](#create-mock-config-file). La prueba `HappyPath` contiene la configuración de la ejecución para gestionar las llamadas de integración de servicios simuladas que los estados `LambdaState` y `SQSState` realizan mediante las respuestas de servicio simuladas `MockedLambdaSuccess` y `MockedSQSSuccess`.
```
aws stepfunctions start-execution \
--endpoint http://localhost:8083 \
--name executionWithHappyPathMockedServices \
--state-machine arn:aws:states:region:account-id:stateMachine:LambdaSQSIntegration#HappyPath
```
1. Vea el estado de la respuesta de ejecución de la máquina.
La respuesta a una llamada a `StartExecution` mediante una prueba de integración de servicios simulada es la misma que la respuesta a una llamada a `StartExecution` normal, que devuelve el ARN de ejecución y la fecha de inicio.
A continuación se muestra un ejemplo de respuesta a una llamada `StartExecution` mediante la prueba de integración de servicios simulada:
```
{
"startDate":"2022-01-28T15:03:16.981000-05:00",
"executionArn":"arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices"
}
```
1. Compruebe los resultados de la ejecución realizando una llamada a la API `[ListExecutions](https://docs.aws.amazon.com/step-functions/latest/apireference/API_ListExecutions.html)`, `[DescribeExecution](https://docs.aws.amazon.com/step-functions/latest/apireference/API_DescribeExecution.html)` o `[GetExecutionHistory](https://docs.aws.amazon.com/step-functions/latest/apireference/API_GetExecutionHistory.html)`
```
aws stepfunctions get-execution-history \
--endpoint http://localhost:8083 \
--execution-arn arn:aws:states:region:account-id:execution:LambdaSQSIntegration:executionWithHappyPathMockedServices
```
En el siguiente ejemplo se muestran partes de una respuesta a una llamada a `GetExecutionHistory` mediante el ARN de ejecución de la respuesta de ejemplo que se muestra en el paso 2. En este ejemplo, la salida de `LambdaState` y `SQSState` son los datos simulados definidos en `MockedLambdaSuccess` y `MockedSQSSuccess` en el [archivo de configuración simulado](#create-mock-config-file). Además, los datos simulados se utilizan de la misma manera que los datos devueltos al realizar llamadas de integración de servicios reales. Además, en este ejemplo, la salida de `LambdaState` se transfiere 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
}
}
},
...
]
}
```
## Archivo de configuración para integraciones de servicios simulados en Step Functions
**Step Functions Local no es compatible**
Step Functions Local **no** proporciona paridad de características y **no es compatible**.
Podría considerar soluciones de terceros que emulen Step Functions con fines de prueba.
Como alternativa a Step Functions Local, puedes usar la TestState API para realizar pruebas unitarias de la lógica de tu máquina de estados antes de implementarla en tu AWS cuenta. Para obtener más información, consulta [Probar máquinas de estado con la TestState API](https://docs.aws.amazon.com/step-functions/latest/dg/test-state-isolation.html).
Para usar integraciones de servicios simuladas, primero debe crear un archivo de configuración simulado denominado `MockConfigFile.json` que contenga las configuraciones simuladas. A continuación, proporcione a Step Functions Local el archivo de configuración simulado. Este archivo de configuración define los casos de prueba, que contienen estados simulados que utilizan respuestas de integración de servicios simuladas. La siguiente sección contiene información sobre la estructura de la configuración simulada, que incluye los estados simulados y las respuestas simuladas:
### Estructura del archivo de configuración del archivo
Una configuración simulada es un objeto JSON que contiene los siguientes campos de nivel superior:
+ `StateMachines`: los campos de este objeto representan máquinas de estado configuradas para utilizar integraciones de servicios simuladas.
+ `MockedResponse`: los campos de este objeto representan respuestas simuladas para las llamadas de integración de servicios.
A continuación se muestra un ejemplo de un archivo de configuración simulado que incluye una definición `StateMachine` y `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!"
}
}
}
}
}
}
```
#### Referencia de campo de configuración simulada
En las siguientes secciones se explican los campos de objetos de nivel superior que debe definir en la configuración simulada.
+ [StateMachines](#mock-cfg-sm-sect)
+ [MockedResponses](#mock-cfg-mckd-resp-sect)
##### StateMachines
El objeto `StateMachines` define qué máquinas de estado utilizarán integraciones de servicios simuladas. La configuración de cada máquina de estado se representa como un campo de nivel superior de `StateMachines`. El nombre del campo es el nombre de la máquina de estado y el valor es un objeto que contiene un único campo denominado `TestCases`, cuyos campos representan casos de prueba de esa máquina de estado.
La siguiente sintaxis muestra una máquina de estado con dos casos de prueba:
```
"MyStateMachine": {
"TestCases": {
"HappyPath": {
...
},
"SadPath": {
...
}
}
```
##### TestCases
Los campos de `TestCases` representan casos de prueba individuales para la máquina de estado. El nombre de cada caso de prueba debe ser único para cada máquina de estado y el valor de cada caso de prueba es un objeto que especifica una respuesta simulada para utilizarla en los estados Task de la máquina de estado.
El siguiente ejemplo de `TestCase` vincula dos estados `Task` a dos `MockedResponses`:
```
"HappyPath": {
"SomeTaskState": "SomeMockedResponse",
"AnotherTaskState": "AnotherMockedResponse"
}
```
##### MockedResponses
`MockedResponses` es un objeto que contiene varios objetos de respuesta simulados con nombres de campo únicos. Un objeto de respuesta simulado define el resultado correcto o la salida con error de cada invocación de un estado Task simulado. El número de invocación se especifica mediante cadenas de números enteros individuales, como «0», «1», «2» y «3», o un rango inclusivo de números enteros, como «0-1», «2-3».
Cuando se simula una tarea, se debe especificar una respuesta simulada para cada invocación. La respuesta debe contener un único campo denominado `Return` o `Throw` cuyo valor sea el resultado o error de la invocación de la tarea simulada. Si no especifica una respuesta simulada, la ejecución de la máquina de estado generará un error.
A continuación se muestra un ejemplo de una `MockedResponse` con `Throw` y `Return` objetos. En este ejemplo, las tres primeras veces que se ejecuta la máquina de estado, se devuelve la respuesta especificada en `"0-2"`, y la cuarta vez que se ejecuta la máquina de estado, se devuelve la respuesta especificada en `"3"`.
```
"SomeMockedResponse": {
"0-2": {
"Throw": {
...
}
},
"3": {
"Return": {
...
}
}
}
```
**nota**
Si utiliza un estado `Map` y quiere garantizar respuestas predecibles para el estado `Map`, defina el valor de `maxConcurrency` en 1. Si establece un valor superior a 1, Step Functions Local ejecutará varias iteraciones simultáneamente, lo que provocará que el orden general de ejecución de los estados de las iteraciones sea impredecible. Además, esto puede provocar que Step Functions Local utilice diferentes respuestas simuladas para los estados de iteración de una ejecución a la siguiente.
##### Return
`Return` se representa como un campo de los objetos `MockedResponse`. Especifica el resultado correcto de un estado Task simulado.
A continuación se muestra un ejemplo de un objeto `Return` que contiene una respuesta simulada para llamar a [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) en una función de Lambda:
```
"Return": {
"StatusCode": 200,
"Payload": {
"StatusCode": 200,
"body": "Hello from Lambda!"
}
}
```
##### Throw
`Throw` se representa como un campo de los objetos `MockedResponse`. Especifica la [salida de error](concepts-error-handling.md) de una tarea fallida. El valor de `Throw` debe ser un objeto que contenga campos `Error` y `Cause` con valores de cadena. Además, el valor de cadena que especifique en el campo `Error` en `MockConfigFile.json` debe coincidir con los errores gestionados en las secciones `Retry` y `Catch` de su máquina de estado.
A continuación se muestra un ejemplo de un objeto `Throw` que contiene una respuesta simulada para llamar a [https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html](https://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html) en una función de Lambda:
```
"Throw": {
"Error": "Lambda.TimeoutException",
"Cause": "Lambda timed out."
}
```