First write!
"); responseStream.write("${loremIpsum1}
`); await new Promise(r => setTimeout(r, 1000)); responseStream.write("DONE!
"); responseStream.write(""); responseStream.end(); } ); ``` A continuación, se presenta un ejemplo del archivo `template.yaml`. La transmisión de respuestas para nuestra función de Lambda se configura mediante la propiedad `FunctionUrlConfig`. ``` AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Description: > Sample SAM Template for lambda-streaming-nodejs-app Resources: StreamingFunction: Type: AWS::Serverless::Function Properties: CodeUri: src/ Handler: index.handler Runtime: nodejs18.x Architectures: - x86_64 Timeout: 10 FunctionUrlConfig: AuthType: AWS_IAM InvokeMode: RESPONSE_STREAM Outputs: StreamingFunction: Description: "Streaming Lambda Function ARN" Value: !GetAtt StreamingFunction.Arn StreamingFunctionURL: Description: "Streaming Lambda Function URL" Value: !GetAtt StreamingFunctionUrl.FunctionUrl ``` Por lo general, puede usar `sam build` y `sam deploy --guided` para crear e implementar una aplicación de producción. En este ejemplo, accederemos a un entorno de desarrollo y utilizaremos el comando `sam sync` para crear e implementar nuestra aplicación. **nota** Se recomienda usar el comando `sam sync` para entornos de desarrollo. Para obtener más información, consulta [Introducción al uso sam sync de la sincronización con Nube de AWS](using-sam-cli-sync.md). Antes de ejecutar `sam sync`, debe verificar que el proyecto esté configurado correctamente en el archivo `samconfig.toml`. Asimismo, recuerde verificar los valores de `stack_name` y `watch`. Con estos valores especificados en el archivo de configuración, no es necesario proporcionarlos en la línea de comandos. ``` version = 0.1 [default] [default.global.parameters] stack_name = "lambda-streaming-nodejs-app" [default.build.parameters] cached = true parallel = true [default.validate.parameters] lint = true [default.deploy.parameters] capabilities = "CAPABILITY_IAM" confirm_changeset = true resolve_s3 = true s3_prefix = "lambda-streaming-nodejs-app" region = "us-west-2" image_repositories = [] [default.package.parameters] resolve_s3 = true [default.sync.parameters] watch = true [default.local_start_api.parameters] warm_containers = "EAGER" [default.local_start_lambda.parameters] warm_containers = "EAGER" ``` A continuación, ejecuta `sam sync` para crear e implementar nuestra aplicación. Como la opción `--watch` está configurada en nuestro archivo de configuración, la CLI de AWS SAM compilará la aplicación, la implementará y estará pendiente de los cambios. ``` $ sam sync The SAM CLI will use the AWS Lambda, Amazon API Gateway, and AWS StepFunctions APIs to upload your code without performing a CloudFormation deployment. This will cause drift in your CloudFormation stack. **The sync command should only be used against a development stack**. Queued infra sync. Waiting for in progress code syncs to complete... Starting infra sync. Building codeuri: /Users/.../lambda-streaming-nodejs-app/src runtime: nodejs18.x metadata: {} architecture: x86_64 functions: StreamingFunction package.json file not found. Continuing the build without dependencies. Running NodejsNpmBuilder:CopySource Build Succeeded Successfully packaged artifacts and wrote output template to file /var/folders/45/5ct135bx3fn2551_ptl5g6_80000gr/T/tmpavrzdhgp. Execute the following command to deploy the packaged template sam deploy --template-file /var/folders/45/5ct135bx3fn2551_ptl5g6_80000gr/T/tmpavrzdhgp --stack-nameFirst write!
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque vitae mi tincidunt tellus ultricies dignissim id et diam. Morbi pharetra eu nisi et finibus. Vivamus diam nulla, vulputate et nisl cursus, pellentesque vehicula libero. Cras imperdiet lorem ante, non posuere dolor sollicitudin a. Vestibulum ipsum lacus, blandit nec augue id, lobortis dictum urna. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia curae; Morbi auctor orci eget tellus aliquam, non maximus massa porta. In diam ante, pulvinar aliquam nisl non, elementum hendrerit sapien. Vestibulum massa nunc, mattis non congue vitae, placerat in quam. Nam vulputate lectus metus, et dignissim erat varius a.
DONE!
START RequestId: 1e4cdf04-60de-4769-b3a2-c1481982deb4 Version: $LATEST END RequestId: 1e4cdf04-60de-4769-b3a2-c1481982deb4 REPORT RequestId: 1e4cdf04-60de-4769-b3a2-c1481982deb4 Duration: 4088.66 ms Billed Duration: 4089 ms Memory Size: 128 MB Max Memory Used: 68 MB Init Duration: 168.45 ms ``` Cuando modificamos el código de la función, la CLI de AWS SAM detecta los cambios realizados al instante y los implementa de inmediato. Este es un ejemplo del resultado de la CLI de AWS SAM después de realizar cambios en el código de nuestra función: ``` Syncing Lambda Function StreamingFunction... Building codeuri: /Users/.../lambda-streaming-nodejs-app/src runtime: nodejs18.x metadata: {} architecture: x86_64 functions: StreamingFunction package.json file not found. Continuing the build without dependencies. Running NodejsNpmBuilder:CopySource Finished syncing Lambda Function StreamingFunction. Syncing Layer StreamingFunctione9cfe924DepLayer... SyncFlow [Layer StreamingFunctione9cfe924DepLayer]: Skipping resource update as the content didn't change Finished syncing Layer StreamingFunctione9cfe924DepLayer. ``` Ahora puede volver a utilizar `sam remote invoke` para interactuar con la función en la nube y probar los cambios. ### Ejemplos de SQS #### Ejemplos básicos **Invocar una cola de Amazon SQS al proporcionar el ARN como ID de recurso:** ``` $ sam remote invoke arn:aws:sqs:us-west-2:01234567890:sqs-example-4DonhBsjsW1b --event '{"hello": "world"}' --output json Sending message to SQS queue MySqsQueue { "MD5OfMessageBody": "49dfdd54b01cbcd2d2ab5e9e5ee6b9b9", "MessageId": "4f464cdd-15ef-4b57-bd72-3ad225d80adc", "ResponseMetadata": { "RequestId": "95d39377-8323-5ef0-9223-ceb198bd09bd", "HTTPStatusCode": 200, "HTTPHeaders": { "x-amzn-requestid": "95d39377-8323-5ef0-9223-ceb198bd09bd", "date": "Wed, 08 Nov 2023 23:27:26 GMT", "content-type": "application/x-amz-json-1.0", "content-length": "106", "connection": "keep-alive" }, "RetryAttempts": 0 } }% ``` ### Ejemplos de Step Functions #### Ejemplos básicos **Para invocar una máquina de estados, proporciona su ID físico como ID de recurso:** En primer lugar, usa `sam list resources` para obtener el ID físico: ``` $ sam list resources --stack-name state-machine-example --output json [ { "LogicalResourceId": "HelloWorldStateMachine", "PhysicalResourceId": "arn:aws:states:us-west-2:513423067560:stateMachine:HelloWorldStateMachine-z69tFEUx0F66" }, { "LogicalResourceId": "HelloWorldStateMachineRole", "PhysicalResourceId": "simple-state-machine-HelloWorldStateMachineRole-PduA0BDGuFXw" } ] ``` A continuación, invoca la máquina de estados mediante el ID físico como ID de recurso. Transmita un evento en la línea de comandos con la opción `--event`: ``` $ sam remote invoke arn:aws:states:us-west-2:01234567890:stateMachine:HelloWorldStateMachine-z69tFEUx0F66 --event '{"is_developer": true}' Invoking Step Function arn:aws:states:us-west-2:01234567890:stateMachine:HelloWorldStateMachine-z69tFEUx0F66 "Hello Developer World"% ``` **Invoque una máquina de estados pasando un evento vacío:** ``` $ sam remote invoke HelloWorldStateMachine --stack-name state-machine-example Invoking Step Function HelloWorldStateMachine "Hello World"% ``` ## Vínculos relacionados Para obtener documentación relacionada `sam remote invoke` con el uso del AWS SAMCLI, consulte lo siguiente: + [sam remote invoke](sam-cli-command-reference-remote-invoke.md) + [Solución de problemas para AWS SAM CLI](sam-cli-troubleshooting.md) # Automatice las pruebas de integración local con AWS SAM Si bien puede usarlo [Introducción a las pruebas con sam local invoke](using-sam-cli-local-invoke.md) para probar el código manualmente, AWS SAM también le permite probar su código mediante pruebas de integración automatizadas. Las pruebas de integración le ayudan a detectar problemas en las primeras etapas del ciclo de desarrollo, a mejorar la calidad del código, a ahorrar tiempo y, al mismo tiempo, a reducir los costos. Para crear pruebas de integración automatizadas AWS SAM, primero debe ejecutar pruebas con funciones Lambda locales antes de implementarlas en la AWS nube. El comando [Introducción a las pruebas con sam local start-lambda](using-sam-cli-local-start-lambda.md) inicia un punto de conexión local que emula el punto de conexión de invocación de Lambda. Puedes invocarlo desde sus pruebas automatizadas. Debido a que este punto de conexión emula el punto de conexión de invocación de Lambda, puede escribir pruebas una vez y ejecutarlas (sin ninguna modificación) en la función de Lambda local o en una función de Lambda implementada. También puede ejecutar las mismas pruebas en una AWS SAM pila implementada en su CI/CD proceso. Así es como funciona el proceso: 1. Inicie el punto de conexión Lambda local. Inicie el punto final Lambda local ejecutando el siguiente comando en el directorio que contiene la plantilla AWS SAM : ``` sam local start-lambda ``` Este comando inicia un punto de conexión local en `http://127.0.0.1:3001` que emula AWS Lambda. Puede ejecutar las pruebas automatizadas en este punto de conexión Lambda local. Al invocar este punto final mediante el SDK AWS CLI o el SDK, ejecuta localmente la función Lambda que se especifica en la solicitud y devuelve una respuesta. 1. Ejecute una prueba de integración en el punto de conexión Lambda local. En la prueba de integración, puede usar el AWS SDK para invocar la función Lambda con los datos de la prueba, esperar la respuesta y comprobar que la respuesta es la esperada. Para ejecutar la prueba de integración localmente, debe configurar el SDK de AWS para que envía la llamada a la API invocación de Lambda al punto de conexión local de Lambda iniciado en el paso anterior. El siguiente es un ejemplo de Python ( AWS SDKs los otros lenguajes tienen configuraciones similares): ``` import boto3 import botocore # Set "running_locally" flag if you are running the integration test locally running_locally = True if running_locally: # Create Lambda SDK client to connect to appropriate Lambda endpoint lambda_client = boto3.client('lambda', region_name="us-west-2", endpoint_url="http://127.0.0.1:3001", use_ssl=False, verify=False, config=botocore.client.Config( signature_version=botocore.UNSIGNED, read_timeout=15, retries={'max_attempts': 0}, ) ) else: lambda_client = boto3.client('lambda') # Invoke your Lambda function as you normally usually do. The function will run # locally if it is configured to do so response = lambda_client.invoke(FunctionName="HelloWorldFunction") # Verify the response assert response == "Hello World" ``` Puede usar este código para probar las funciones de Lambda implementadas configurando `running_locally` en `False`. Esto configura el AWS SDK al que se debe conectar AWS Lambda en la AWS nube. # Genere cargas útiles de eventos de muestra con AWS SAM Para probar las funciones de Lambda, puede generar y personalizar ejemplos de cargas útiles de eventos que imiten los datos que recibirán las funciones de Lambda cuando sean activadas por otros servicios. AWS Esto incluye servicios de como API Gateway, CloudFormation o Amazon S3, entre otros. La generación de cargas útiles de eventos de muestra le ayuda a probar el comportamiento de la función de Lambda con una variedad de entradas diferentes sin necesidad de trabajar en un entorno en vivo. Este enfoque también ahorra tiempo en comparación con la creación manual de muestras de eventos de AWS servicio para probar las funciones. Para ver la lista completa de servicios para los que puede generar cargas útiles de eventos de muestra, utiliza este comando: ``` sam local generate-event --help ``` Para ver la lista de opciones que puede usar para un servicio concreto, utiliza este comando: ``` sam local generate-event [SERVICE] --help ``` Ejemplos: ``` #Generates the event from S3 when a new object is created sam local generate-event s3 put # Generates the event from S3 when an object is deleted sam local generate-event s3 delete ``` # Prueba y depuración de funciones duraderas Probar y depurar funciones duraderas a nivel local funciona de forma similar a las funciones Lambda normales, con soporte automático para puntos de control y reproducción. Esta guía cubre los escenarios de prueba y las técnicas de solución de problemas más comunes. ## Flujo de trabajo de pruebas locales Cuando se prueban funciones duraderas a nivel local, el flujo de trabajo es diferente al de las funciones Lambda normales: **Flujo de trabajo de pruebas de funciones duradero** 1. Cree su aplicación: ``` $ sam build ``` 1. Invoque su función duradera: ``` $ sam local invoke MyDurableFunction --durable-execution-name test ``` 1. Compruebe el historial de ejecución si es necesario: ``` $ sam local execution history execution-id ``` ## Escenarios de prueba comunes ### Probar el comportamiento de los puntos de control Para comprobar que su funcionamiento es correcto, los puntos de control indican: ``` # Example Python durable function def handler(event, context): # This will create a checkpoint context.wait(10) # Wait 10 seconds # Function resumes here after wait return {"message": "Function resumed after wait"} ``` Al invocar esta función de forma local, el período de espera se gestiona automáticamente. ### Probando escenarios de devolución de llamadas Para las funciones que esperan llamadas externas: 1. Inicie su función duradera que espera una devolución de llamada 1. En otro terminal, resuelve la devolución de llamada: ``` $ sam local callback succeed callback-id ``` 1. Observe cómo se reanuda la ejecución de la función ## Resolución de problemas ### La función duradera no se ejecuta correctamente **Problema:** la función no se comporta como una función duradera. **Soluciones:** + Comprueba que `DurableConfig` esté configurado en tu plantilla SAM + Asegúrese de que el código de su función utilice métodos de SDK de funciones duraderas (por ejemplo,`context.wait()`) + Comprueba que estás utilizando un entorno de ejecución compatible (TypeScript, JavaScript, Python) ### No se puede recuperar el historial de ejecución **Problema:** el `local execution history` comando no devuelve ningún resultado. **Soluciones:** + Compruebe que el identificador de ejecución es correcto + Compruebe que la función se haya invocado al menos una vez ### Los comandos callback no funcionan **Problema:** los comandos de devolución de llamada no resuelven las operaciones pendientes. **Soluciones:** + Compruebe que el identificador de devolución de llamada sea correcto + Asegúrese de que la función esté realmente esperando una devolución de llamada + Compruebe que está utilizando la sintaxis correcta del comando de devolución de llamada ## Consejos de depuración + **Utilice el historial de ejecución**: revise el historial de ejecución para comprender el flujo de su función duradera + **Realice pruebas incrementales**: comience con operaciones de espera sencillas antes de añadir una lógica compleja + **Utilice el registro detallado: habilite el registro** detallado para rastrear el flujo de ejecución ## Más información Para obtener más información sobre las pruebas y la depuración, consulte: + [Introducción a las pruebas con sam local invoke](using-sam-cli-local-invoke.md)- Documentación de invocación local + [sam local execution history](sam-cli-command-reference-sam-local-execution-history.md)- Historial de ejecuciones