Discover service integration patterns in Step Functions

AWS Step Functions integrates with services directly in the Amazon States Language. You can control these AWS services using three service integration patterns:

Each of these service integration patterns is controlled by how you create a URI in the "Resource" field of your task definition.

For information about configuring AWS Identity and Access Management (IAM) for integrated services, see How Step Functions generates IAM policies for integrated services.

Integration pattern support

Standard Workflows and Express Workflows support the same integrations but not the same integration patterns.

To help decide between the two types, see Choosing workflow type in Step Functions.

AWS SDK integrations in Step Functions

Optimized integrations in Step Functions

Request Response

When you specify a service in the "Resource" string of your task state, and you only provide the resource, Step Functions will wait for an HTTP response and then progress to the next state. Step Functions will not wait for a job to complete.

The following example shows how you can publish an Amazon SNS topic.

"Send message to SNS":{
            "Type":"Task",
            "Resource":"arn:aws:states:::sns:publish",
            "Parameters":{
            "TopicArn":"arn:aws:sns:us-east-1:123456789012:myTopic",
            "Message":"Hello from Step Functions!"
            },
            "Next":"NEXT_STATE"
            }

This example references the Publish API of Amazon SNS. The workflow progresses to the next state after calling the Publish API.

Run a Job (.sync)

For integrated services such as AWS Batch and Amazon ECS, Step Functions can wait for a request to complete before progressing to the next state. To have Step Functions wait, specify the "Resource" field in your task state definition with the .sync suffix appended after the resource URI.

For example, when submitting an AWS Batch job, use the "Resource" field in the state machine definition as shown in this example.

"Manage Batch task": {
            "Type": "Task",
            "Resource": "arn:aws:states:::batch:submitJob.sync",
            "Parameters": {
            "JobDefinition": "arn:aws:batch:us-east-2:123456789012:job-definition/testJobDefinition",
            "JobName": "testJob",
            "JobQueue": "arn:aws:batch:us-east-2:123456789012:job-queue/testQueue"
            },
            "Next": "NEXT_STATE"
            }

Having the .sync portion appended to the resource Amazon Resource Name (ARN) means that Step Functions waits for the job to complete. After calling AWS Batch submitJob, the workflow pauses. When the job is complete, Step Functions progresses to the next state. For more information, see the AWS Batch sample project: Manage a batch job with AWS Batch and Amazon SNS.

If a task using this (.sync) service integration pattern is aborted, and Step Functions is unable to cancel the task, you might incur additional charges from the integrated service. A task can be aborted if:

Step Functions will make a best-effort attempt to cancel the task. For example, if a Step Functions states:startExecution.sync task is aborted, it will call the Step Functions StopExecution API action. However, it is possible that Step Functions will be unable to cancel the task. Reasons for this include, but are not limited to:

When you use the .sync service integration pattern, Step Functions uses polling that consumes your assigned quota and events to monitor a job's status. For .sync invocations within the same account, Step Functions uses EventBridge events and polls the APIs that you specify in the Task state. For cross-account .sync invocations, Step Functions only uses polling. For example, for states:StartExecution.sync, Step Functions performs polling on the DescribeExecution API and uses your assigned quota.

To see a list of what integrated services support waiting for a job to complete (.sync), see Integrating services with Step Functions.

In some cases, you may want Step Functions to continue your workflow before the job is fully complete. You can achieve this in the same way as when using the Wait for a Callback with Task Token service integration pattern. To do this, pass a task token to your job, then return it using a SendTaskSuccess or SendTaskFailure API call. Step Functions will use the data you provide in that call to complete the task, stop monitoring the job, and continue the workflow.

Wait for a Callback with Task Token

Callback tasks provide a way to pause a workflow until a task token is returned. A task might need to wait for a human approval, integrate with a third party, or call legacy systems. For tasks like these, you can pause Step Functions until the workflow execution reaches the one year service quota (see, Quotas related to state throttling), and wait for an external process or workflow to complete. For these situations Step Functions allows you to pass a task token to the AWS SDK service integrations, and also to some Optimized service integrations. The task will pause until it receives that task token back with a SendTaskSuccess or SendTaskFailure call.

If a Task state using the callback task token times out, a new random token is generated. You can access the task tokens from the Context object.

To use .waitForTaskToken with an AWS SDK integration, the API you use must have a parameter field in which to place the task token.

To see a list of what integrated services support waiting for a task token (.waitForTaskToken), see Integrating services with Step Functions.

Task Token Example

In this example, a Step Functions workflow needs to integrate with an external microservice to perform a credit check as a part of an approval workflow. Step Functions publishes an Amazon SQS message that includes a task token as a part of the message. An external system integrates with Amazon SQS, and pulls the message off the queue. When that's finished, it returns the result and the original task token. Step Functions then continues with its workflow.

The "Resource" field of the task definition that references Amazon SQS includes .waitForTaskToken appended to the end.

"Send message to SQS": {
                "Type": "Task",
                "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
                "Parameters": {
                "QueueUrl": "https://sqs.us-east-2.amazonaws.com/123456789012/myQueue",
                "MessageBody": {
                "Message": "Hello from Step Functions!",
                "TaskToken.$": "$$.Task.Token"
                }
                },
                "Next": "NEXT_STATE"
                }

This tells Step Functions to pause and wait for the task token. When you specify a resource using .waitForTaskToken, the task token can be accessed in the "Parameters" field of your state definition with a special path designation ($$.Task.Token). The initial $$. designates that the path accesses the Context object, and gets the task token for the current task in a running execution.

When it's complete, the external service calls SendTaskSuccess or SendTaskFailure with the taskToken included. Only then does the workflow continue to the next state.

Get a Token from the Context object

The Context object is an internal JSON object that contains information about your execution. Like state input, it can be accessed with a path from the "Parameters" field during an execution. When accessed from within a task definition, it includes information about the specific execution, including the task token.

{
                "Execution": {
                "Id": "arn:aws:states:us-east-1:123456789012:execution:stateMachineName:executionName",
                "Input": {
                "key": "value"
                },
                "Name": "executionName",
                "RoleArn": "arn:aws:iam::123456789012:role...",
                "StartTime": "2019-03-26T20:14:13.192Z"
                },
                "State": {
                "EnteredTime": "2019-03-26T20:14:13.192Z",
                "Name": "Test",
                "RetryCount": 3
                },
                "StateMachine": {
                "Id": "arn:aws:states:us-east-1:123456789012:stateMachine:stateMachineName",
                "Name": "name"
                },
                "Task": {
                "Token": "h7XRiCdLtd/83p1E0dMccoxlzFhglsdkzpK9mBVKZsp7d9yrT1W"
                }
                }

You can access the task token by using a special path from inside the "Parameters" field of your task definition. To access the input or the Context object, you first specify that the parameter will be a path by appending a .$ to the parameter name. The following specifies nodes from both the input and the Context object in a "Parameters" specification.

"Parameters": {
                "Input.$": "$",
                "TaskToken.$": "$$.Task.Token"
                },

In both cases, appending .$ to the parameter name tells Step Functions to expect a path. In the first case, "$" is a path that includes the entire input. In the second case, $$. specifies that the path will access the Context object, and $$.Task.Token sets the parameter to the value of the task token in the Context object of a running execution.

In the Amazon SQS example, .waitForTaskToken in the "Resource" field tells Step Functions to wait for the task token to be returned. The "TaskToken.$": "$$.Task.Token" parameter passes that token as a part of the Amazon SQS message.

"Send message to SQS": {
                "Type": "Task",
                "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
                "Parameters": {
                "QueueUrl": "https://sqs.us-east-2.amazonaws.com/123456789012/myQueue",
                "MessageBody": {
                "Message": "Hello from Step Functions!",
                "TaskToken.$": "$$.Task.Token"
                }
                },
                "Next": "NEXT_STATE"
                }

For more information about the Context object, see Accessing execution data from the Context object in Step Functions in the Processing input and output section in this guide.

Configure a Heartbeat Timeout for a Waiting Task

A task that is waiting for a task token will wait until the execution reaches the one year service quota (see, Quotas related to state throttling). To avoid stuck executions you can configure a heartbeat timeout interval in your state machine definition. Use the HeartbeatSeconds field to specify the timeout interval.

{
                "StartAt": "Push to SQS",
                "States": {
                "Push to SQS": {
                "Type": "Task",
                "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
                "HeartbeatSeconds": 600,
                "Parameters": {
                "MessageBody": { "myTaskToken.$": "$$.Task.Token" },
                "QueueUrl": "https://sqs.us-east-1.amazonaws.com/123456789012/push-based-queue"
                },
                "ResultPath": "$.SQS",
                "End": true
                }
                }
                }

In this state machine definition, a task pushes a message to Amazon SQS and waits for an external process to call back with the provided task token. The "HeartbeatSeconds": 600 field sets the heartbeat timeout interval to 10 minutes. The task will wait for the task token to be returned with one of these API actions:

If the waiting task doesn't receive a valid task token within that 10-minute period, the task fails with a States.Timeout error name.

For more information, see the callback task sample project Create a callback pattern example with Amazon SQS, Amazon SNS, and Lambda.