I have some exciting news to share with you about the Serverless Step Functions plugin.
One of the main pain points of using the plugin was that you needed to use fully-formed ARNs. We addressed this in v1.18.0 by supporting CloudFormation intrinsic functions
Ref. This makes it possible for you to reference a local function instead.
functions: hello-world: handler: hello-world.handler stepFunctions: stateMachines: myStateMachine: definition: StartAt: HelloWorld States: HelloWorld: Type: Task Resource: Fn::GetAtt: [HelloDashworldLambdaFunction, Arn] End: true
But this is still a leaky abstraction – you have to know how the Serverless framework converts local function names into CloudFormation logical IDs.
Newcomers would often get confused here.
“How did you get the logical ID
I can hardly blame them for not knowing. This is an implementation detail in the Serverless framework, one that you shouldn’t have to care about!
Which is why I’m really happy to tell you that, as of v2.2.0 you can reference local functions using their local names in the state machine definition.
functions: hello-world: handler: hello-world.handler stepFunctions: stateMachines: myStateMachine: definition: StartAt: firstTask States: firstTask: Type: Task Resource: Fn::GetAtt: [hello-world, Arn] Next: secondTask secondTask: Type: Task Resource: arn:aws:states:::lambda:invoke Parameters: FunctionName: # you can use Ref to get the function name Ref: hello-world Payload: answer: 42 Next: thirdTask thirdTask: Type: Task Resource: arn:aws:states:::lambda:invoke.waitForTaskToken Parameters: FunctionName: # you can also use Fn::GetAtt to get the ARN Fn::GetAtt: [hello-world, Arn] Payload: token.$: $$.Task.Token End: true
In the above example, when we reference the local function
hello-world we no longer need to use its CloudFormation logical ID
As you can see from the example, it applies when you use either
Fn::GetAtt functions in a
Task state. And it applies to all 3 ways of invoking a Lambda function from a