First write!
"); responseStream.write("${loremIpsum1}
`); await new Promise(r => setTimeout(r, 1000)); responseStream.write("DONE!
"); responseStream.write(""); responseStream.end(); } ); ``` The following is an example of our `template.yaml` file. Response streaming for our Lambda function is configured using the `FunctionUrlConfig` property. ``` 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 ``` Typically, you can use `sam build` and `sam deploy --guided` to build and deploy a production application. In this example, we’ll assume a development environment and use the `sam sync` command to build and deploy our application. **Note** The `sam sync` command is recommended for development environments. To learn more, see [Introduction to using sam sync to sync to AWS Cloud](using-sam-cli-sync.md). Before running `sam sync`, we verify that our project is configured correctly in our `samconfig.toml` file. Most importantly, we verify the values for `stack_name` and `watch`. With these values specified in our configuration file, we don't have to provide them at the command line. ``` 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" ``` Next, we run `sam sync` to build and deploy our application. Since the `--watch` option is configured in our configuration file, the AWS SAM CLI will build our application, deploy our application, and watch for changes. ``` $ 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 ``` When we modify our function code, the AWS SAM CLI instantly detects and immediately deploys our changes. Here is an example of the AWS SAM CLI output after changes are made to our function code: ``` 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. ``` We can now use `sam remote invoke` again to interact with our function in the cloud and test our changes. ### SQS examples #### Basic examples **Invoke an Amazon SQS queue by providing the ARN as a resource ID:** ``` $ 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 } }% ``` ### Step Functions examples #### Basic examples **Invoke a state machine by providing its physical ID as a resource ID:** First, we use `sam list resources` to obtain our physical ID: ``` $ 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" } ] ``` Next, we invoke our state machine using the physical ID as a resource ID. We pass in an event at the command line with the `--event` option: ``` $ 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"% ``` **Invoke a state machine by passing an empty event:** ``` $ sam remote invoke HelloWorldStateMachine --stack-name state-machine-example Invoking Step Function HelloWorldStateMachine "Hello World"% ``` ## Related links For documentation related to `sam remote invoke` and using the AWS SAM CLI, see the following: + [sam remote invoke](sam-cli-command-reference-remote-invoke.md) + [AWS SAM CLI troubleshooting](sam-cli-troubleshooting.md) # Automate local integration tests with AWS SAM While you can use [Introduction to testing with sam local invoke](using-sam-cli-local-invoke.md) to manually test code, AWS SAM also lets you test your code using automated integration testing. Integration testing helps you detect issues early in the development cycle, improve the quality of your code, and save time while reducing costs. To author automated integration tests in AWS SAM, you first run tests against local Lambda functions before deploying to the AWS Cloud. The [Introduction to testing with sam local start-lambda](using-sam-cli-local-start-lambda.md) command starts a local endpoint that emulates the Lambda invoke endpoint. You can invoke it from your automated tests. Because this endpoint emulates the Lambda invoke endpoint, you can write tests once, and then run them (without any modifications) against the local Lambda function, or against a deployed Lambda function. You can also run the same tests against a deployed AWS SAM stack in your CI/CD pipeline. This is how the process works: 1. Start the local Lambda endpoint. Start the local Lambda endpoint by running the following command in the directory that contains your AWS SAM template: ``` sam local start-lambda ``` This command starts a local endpoint at `http://127.0.0.1:3001` that emulates AWS Lambda. You can run your automated tests against this local Lambda endpoint. When you invoke this endpoint using the AWS CLI or SDK, it locally executes the Lambda function that's specified in the request, and returns a response. 1. Run an integration test against the local Lambda endpoint. In your integration test, you can use the AWS SDK to invoke your Lambda function with test data, wait for response, and verify that the response is what you expect. To run the integration test locally, you should configure the AWS SDK to send a Lambda Invoke API call to invoke the local Lambda endpoint that you started in previous step. The following is a Python example (the AWS SDKs for other languages have similar configurations): ``` 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" ``` You can use this code to test deployed Lambda functions by setting `running_locally` to `False`. This sets up the AWS SDK to connect to AWS Lambda in the AWS Cloud. # Generate sample event payloads with AWS SAM To test your Lambda functions, you can generate and customize sample event payloads that imitate the data your Lambda functions will receive when triggered by other AWS services. This includes services like API Gateway, CloudFormation, Amazon S3, and more. Generating sample event payloads helps you test the behavior of your Lambda function with a variety of different inputs without needing to work in a live environment. This approach also saves time when compared to manually creating AWS service event samples to test functions. For the full list of services that you can generate sample event payloads for, use this command: ``` sam local generate-event --help ``` For the list of options you can use for a particular service, use this command: ``` sam local generate-event [SERVICE] --help ``` Examples: ``` #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 ``` # Testing and debugging durable functions Testing and debugging durable functions locally works similarly to regular Lambda functions, with automatic support for checkpointing and replay. This guide covers common testing scenarios and troubleshooting techniques. ## Local testing workflow When testing durable functions locally, the workflow differs from regular Lambda functions: **Durable function testing workflow** 1. Build your application: ``` $ sam build ``` 1. Invoke your durable function: ``` $ sam local invoke MyDurableFunction --durable-execution-name test ``` 1. Check execution history if needed: ``` $ sam local execution history execution-id ``` ## Common testing scenarios ### Testing checkpointing behavior To test that your function properly checkpoints state: ``` # 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"} ``` When you invoke this function locally, the wait period is handled automatically. ### Testing callback scenarios For functions that wait for external callbacks: 1. Start your durable function that waits for a callback 1. In another terminal, resolve the callback: ``` $ sam local callback succeed callback-id ``` 1. Observe the function resume execution ## Troubleshooting ### Durable function not executing properly **Problem:** The function doesn't behave as a durable function. **Solutions:** + Verify that `DurableConfig` is set in your SAM template + Ensure your function code uses durable function SDK methods (e.g., `context.wait()`) + Check that you're using a supported runtime (TypeScript, JavaScript, Python) ### Cannot retrieve execution history **Problem:** The `local execution history` command returns no results. **Solutions:** + Verify the execution ID is correct + Check that the function has been invoked at least once ### Callback commands not working **Problem:** Callback commands don't resolve pending operations. **Solutions:** + Verify the callback ID is correct + Ensure the function is actually waiting for a callback + Verify you're using the correct callback command syntax ## Debugging tips + **Use execution history** - Review execution history to understand the flow of your durable function + **Test incrementally** - Start with simple wait operations before adding complex logic + **Use verbose logging** - Enable detailed logging to trace execution flow ## Learn more For more information about testing and debugging, see: + [Introduction to testing with sam local invoke](using-sam-cli-local-invoke.md) - Local invoke documentation + [sam local execution history](sam-cli-command-reference-sam-local-execution-history.md) - Execution history