ICYMI: five updates you’ve missed about Serverless Step Functions
Tags: aws, lambda, stepfunctions, serverless
Published: 2019-05-22 20:59:10

---
title: ICYMI: five updates you’ve missed about Serverless Step Functions
published: true
tags: AWS,Lambda,Step Functions,Serverless
canonical_url: https://theburningmonk.com/2019/05/icmi-five-updates-youve-missed-about-serverless-step-functions/
---

Over the last 6 months, we have made the [Serverless Step Functions](https://github.com/horike37/serverless-step-functions) plugin better and more useful. Here are the most impactful changes, in case you missed it!

### Support for intrinsic function

One of the main pain points of using the plugin has long been that you needed to use fully-formed ARNs. As of [v1.18.0](https://github.com/horike37/serverless-step-functions/releases/tag/v1.18.0) you can use CloudFormation intrinsic functions `Fn:GetAtt` and `Ref` for `Task` states.

This works for both `Task` states with Lambda functions as well as non-Lambda services such as SNS, SQS, DynamoDB, ECS and Batch.

```
stepFunctions:
  stateMachines:
    hellostepfunc1:      
      name: myStateMachine
      definition:
        StartAt: HelloWorld1
        States:
          HelloWorld1:
            Type: Task
            Resource:
              Fn::GetAtt: [HelloLambdaFunction, Arn]
            End: true
```

### Integration with non-Lambda services

Speaking of non-Lambda services. Step Functions announced [support for eight more services](https://aws.amazon.com/about-aws/whats-new/2018/11/aws-step-functions-adds-eight-more-service-integrations/) (besides Lambda) at re:invent 2018. This has been supported in the `serverless-step-functions` plugin as of [v1.10.0](https://github.com/horike37/serverless-step-functions/releases/tag/1.10.0).

SNS and SQS examples are available in this example [repo](https://github.com/theburningmonk/complete-guide-to-step-functions-examples). They are also covered in my video course [**Complete guide to AWS Step Functions**](https://theburningmonk.thinkific.com/courses/complete-guide-to-aws-step-functions).

To publish a message to SNS, you need something like the following:

```
stepFunctions:
  stateMachines:
    hellostepfunc1:      
      name: myStateMachine
      definition:
        StartAt: Publish SNS message
        States:
          Publish SNS message:
            Type: Task
            Resource: arn:aws:states:::sns:publish
            Parameters:
              Message: "{ \"answer\": 42 }"
              TopicArn:
                Ref: AlarmTopic
            End: true
```

When you integrate with these non-Lambda services, the plugin would auto-generate the corresponding IAM permissions for the execution role.

At the moment, SNS, SQS, DynamoDB, ECS and Batch are supported.

### CloudWatch Alarms

It’s common practice to want to monitor the health of your workflows and be alerted when something goes wrong. You can now use the built-in `alarms` configuration to generate a set of default alarms for each state machine.

```
stepFunctions:
  stateMachines:
    myStateMachine:
      alarms:
        topics:
          ok: arn:aws:sns:...
          alarm: arn:aws:sns:...
          insufficientData: arn:aws:sns:...
        metrics:
          - executionsTimeOut
          - executionsFailed
          - executionsAborted
          - executionThrottled
        treatMissingData: missing
```

The generated CloudWatch alarms would have the following configurations:

```
namespace: 'AWS/States'
metric: <ExecutionsTimeOut | ExecutionsFailed | ExecutionsAborted | ExecutionThrottled>
threshold: 1
period: 60
evaluationPeriods: 1
ComparisonOperator: GreaterThanOrEqualToThreshold
Statistic: Sum
treatMissingData: <missing (default) | ignore | breaching | notBreaching>
Dimensions:
  - Name: StateMachineArn
    Value: <ArnOfTheStateMachine>
```

### Workflow execution events

Step Functions recently announced [support for Workflow execution events](https://aws.amazon.com/about-aws/whats-new/2019/05/aws-step-functions-adds-support-for-workflow-execution-events/). With this new feature, you can set up automated notifications when the status of a workflow starts/completes/errors through CloudWatch Events. Events can be delivered to AWS Lambda, SNS, SQS, Kinesis, or AWS Step Functions for automated response to the event.

With the `serverless-step-functions` plugin, you can set up notifications when a workflow’s status changes to `ABORTED`, `FAILED`, `RUNNING`, `SUCCEEDED` or `TIMED_OUT`. Here’s how you can configuration `notifications`:

```
stepFunctions:
  stateMachines:
    hellostepfunc1:
      name: test
      definition:
        ...
      notifications:
        ABORTED:
          - sns: SNS_TOPIC_ARN
          - sqs: SQS_TOPIC_ARN
          - sqs: # for FIFO queues, which requires you to configure the message group ID
              arn: SQS_TOPIC_ARN
              messageGroupId: 12345
          - lambda: LAMBDA_FUNCTION_ARN
          - kinesis: KINESIS_STREAM_ARN
          - kinesis:
               arn: KINESIS_STREAM_ARN
               partitionKeyPath: $.id # used to choose the parition key from payload
          - firehose: FIREHOSE_STREAM_ARN
          - stepFunctions: STATE_MACHINE_ARN
        FAILED:
          ... # same as above
        ... # other status
```

You can also use CloudFormation intrinsic functions `Fn::GetAtt` and `Ref` to reference additional resources in the `serverless.yml`.

### LAMBDA\_PROXY request template

When you use the HTTP event trigger, the default API Gateway request template only forwards the request body as input.

This means you lose out a lot of the context around the HTTP request such as HTTP headers as well as path and query string parameters. To access this information you’d have to create a custom request template.

Also, it presents a stark difference to the event payload we have come to expect when building APIs with API Gateway and Lambda.

So we updated the HTTP event trigger and gave you the option to choose the LAMBDA\_PROXY request template instead.

```
stepFunctions:
  stateMachines:
    hello:
      events:
        - http:
            path: posts/create
            method: POST
            request:
              template: lambda_proxy
```

This gives you a **close approximation** to the event payload you can expect from API Gateway when you use LAMBDA\_PROXY integration method. However, multi-value query string parameters do not work at the moment. This owes to the fact that API Gateway does not pass them through to the integration request. Once that is addressed we will add support for it.

### Other changes

So those are the five most noteworthy changes in the last 6 months. To wrap things up, here are a couple of smaller changes that you might also be interested in:

- [Support global tags](https://github.com/horike37/serverless-step-functions/issues/182)
- [Custom IAM role for scheduled events](https://github.com/horike37/serverless-step-functions/commit/f5362f4)
- [Support DependsOn](https://github.com/horike37/serverless-step-functions/issues/158)

If you’re interested in learning more about Step Functions and where it fits into your wider solution. Please check out my course – [Complete guide to AWS Step Functions](https://theburningmonk.thinkific.com/courses/complete-guide-to-aws-step-functions).

The post [ICMI: five updates you’ve missed about Serverless Step Functions](https://theburningmonk.com/2019/05/icmi-five-updates-youve-missed-about-serverless-step-functions/) appeared first on [theburningmonk.com](https://theburningmonk.com).

 ![](http://feeds.feedburner.com/~r/theburningmonk/~4/Edcz8ICPhyU)