Calling Flow

Overview

When sending requests asynchronously between Lambda functions we can use Calling Flow to inform which service sent the request, this can be used in 3 main ways:

Returning cached results

When sending a request to Lambda functions that begin a Stored Cache flow, the calling workflow will be waiting for a 'complete' message to continue it's work but there might be any number of flows that subscribe to the 'complete' topic, in the event that the Stored Cache has cached results we can immediately send a 'complete' message but there is no benefit in triggering every flow that is subscribed, only the calling flow needs to receive this message, if other flows want the same results they will send their own request.

To achieve this we add callingFlow param to the request, if cache exists a 'complete' message is sent with the callingFlow param added to the message attributes, the SQS Lambda trigger for all subscribed flows has a filter that only triggers when callingFlow message attribute does not exist or is set to the current flow.

Example: FindData, ProcessLogical

independent work flow

When a task needs to pass multiple work flows and parent flows for a specific invocation needs to continue for that invocation only, we can use callingFlow to ensure only the parent flow is triggered after the child flow completes.

callingFlowProperties can be used at any stage passing between flows to add properties that each stage requires when passing back up the flow chain, sometimes these values can be pulled from other return values, but if not callingFlowProperties is used.

callingFlow properties are used when going down child workflow, at the time that we reverse and start to go back up the flow hierarchy we use passBackProperties param name.

Example: ImportData's CreateObject flow which needs to receive pendingObjectId sent in callingFlowProperties to match the newly created object to the existing pending object.

Send a complete message if Calling Flow set

Some actions can be invoked completely async/independent of the calling workflow, for example graph operations that the flow has no logic that needs to wait for the result before continuing.

In this case if no callingFlow is added to the param then no message is sent.

On other occasions the same function might need to do additional logic after the called Lambda is complete, eg after a graph query has completed, to facilitate this we can add callingFlow to the params and a message will only be sent when it exists, in addition the callingFlow is added to the message attributes so only the calling work flow receives the message using same technique as Stored Cache processing.

In addition to the Calling Flow, additional callingFlowProperties can be added and will passed down the workflow stack or be returned back to the calling function in passBackProperties, using shared callingFlow lib.

Example: most graph functions.