This is a Hello World function that shows Amazon WorkMail integration with AWS Lambda. When you deploy it to your account, the system creates a Lambda function with all the necessary resources and permissions to access and modify incoming events from WorkMail.
Add your own business logic to the Lambda function based on your use-case. For more information see AWS WorkMail Lambda documentation
- Deploy this application via AWS Serverless Application Repository
- Open the WorkMail Console and create a RunLambda Email Flow Rule that uses this Lambda function.
You now have a working Lambda function that will be triggered by WorkMail based on the rule you created. To add business logic to your Lambda function, open the AWS Lambda Console to edit and test your Lambda function with the built-in code editor.
For more advanced use cases, such as changing your CloudFormation template to create additional AWS resources that will support this application, follow the instructions below.
By default, this serverless application and the resources that it creates can integrate with any WorkMail Organization in your account, but the application and organization must be in the same region. To restrict that behavior you can either update the SourceArn attribute in template.yaml and then deploy the application by following the steps below or update the SourceArn attribute directly in the resource policy of each resource via their AWS Console after the deploying this application, see example.
For more information about the SourceArn attribute, see this documentation.
Clone this repository from GitHub.
We recommend creating and activating a virtual environment, for more information see Creation of virtual environments.
If you are not familiar with CloudFormation templates, see Learn Template Basics.
- Create additional resources for your application by changing template.yaml. See this documentation for more details.
- Modify your Lambda function by changing app.py.
- Test your Lambda function locally:
-
Configure environment variables at
tst/env_vars.json
. -
Configure test event at
tst/event.json
. -
Invoke your Lambda function locally using:
sam local invoke WorkMailHelloWorldFunction -e tst/event.json --env-vars tst/env_vars.json
This application uses a messageId
passed to the Lambda function to retrieve the message content from WorkMail. When testing, the tst/event.json
file uses a mock messageId which does not exist. If you want to test with a real messageId, you can configure a WorkMail Email Flow Rule with the Lambda action that uses the Lambda function created in Setup, and send some emails that will trigger the email flow rule. The Lambda function will emit the messageId it receives from WorkMail in the CloudWatch logs, which you can
then use in your test event data. For more information see Accessing Amazon CloudWatch logs for AWS Lambda. Note that you can access messages in transit for a maximum of one day.
Once you have validated that your Lambda function behaves as expected, you are ready to deploy this Lambda function.
If you develop using the AWS Lambda Console, then this section can be skipped.
Please create an S3 bucket if you do not have one yet, see How do I create an S3 Bucket?.
and check how to create a Bucket Policy.
We refer to this bucket as <Bucket-Name-For-Deployment>
.
This step bundles all your code and configuration to the given S3 bucket.
sam package \
--template-file template.yaml \
--output-template-file packaged.yaml \
--s3-bucket <Bucket-Name-For-Deployment>
This step updates your Cloud Formation stack to reflect the changes you made, which will in turn update changes made in the Lambda function.
sam deploy \
--template-file packaged.yaml \
--stack-name workmail-hello-world \
--capabilities CAPABILITY_IAM
Your Lambda function is now deployed. You can now configure WorkMail to trigger this function.