Description

Fixes#125

Why is the change necessary?

This adds support for AWS Step Functions service integration.
AddedStartExecution step that allows to start an execution of another state machine

Solution

Provide support for 3 integration patterns by usingIntegrationPattern enum in the step constructor to determine how to call the integrated service. TheIntegrationPattern is used to build aResource arn:

SeeService Integration Patterns for more details

Omitting support for "arn:aws:states:::states:startExecution.sync" resource that allows to get a string format response.
CDK does not expose a property to configure the response format and there was no demand for one. If there is an ask to get a response in string format, we can easily add the possibility to do so in the future.

RenamingIntegrationPattern.RequestResponse toIntegrationPattern.CallAndContinue

Note

Changing the existingIntegrationPattern is technically backwards incompatible, but this is acceptable due to the following:

1. IntegrationPattern was not documented or exposed to any "public" interface
2. We received feedback from our customers thatRequestResponse was a confusing term as it sounded synchronous and they were not sure what it meant. After lengthy discussion with the team, we settled onCallAndContinue which indicates clearly that we are not waiting for the state execution to end before continuing to the next state.

After the next release,IntegrationPattern will be something we need to protect from backwards incompatible changes since it is part of the step constructor args.

Trade-offs

• Using an enum to select the Service Integration Pattern diverges from the implementation we have for previous service integrations that use flags (ex: wait_for_completion and wait_for_callback). The implementation will not be consistent across all service integrations and the customer experience when using the service integrations will not be consistent.

Future considerations

To provide customers with an intuitive and consistent experience when using service integrations, I am proposing that we follow this pattern for all future integrations. This includes the services integrations that have not been released yet (EKS and Glue Databrew).

What about existing services?

Once we are ready for a major update, let's change existing service integrations to use the enum pattern to provide a consistent customer experience throughout.

Testing

• Added unit tests for all resources
• No integ tests added as external resources were required for testing (Lambda function)
• Manual test done for all resources

Test1: WaitForCompletion

Validated that the state machine succeeded after the nested state machine execution succeeded (after 60 s wait time)

# Created state machine with a Wait step wait_workflow = Workflow(    name="WaitWF",    definition=Wait("Wait State", seconds=60),    role=workflow_execution_role)wait_workflow_arn = wait_workflow.create()# Created state machine with nested state machine using default and WaitForCompletion integration patternstart_execution_step_default = "StartExecutionDefault", StepFunctionsStartExecutionStep(    "SFN Start Execution", parameters={        "StateMachineArn": wait_workflow_arn,        "Name": unique_name_from_base("StartExecution1")    })start_execution_step_sync = "StartExecutionSync", StepFunctionsStartExecutionStep(    "SFN Start Execution - Sync", integration_pattern=IntegrationPattern.WaitForCompletion,    parameters={        "StateMachineArn": wait_workflow_arn,        "Name": unique_name_from_base("StartExecutionSync")    })

Test2: CallAndContinue

Validated that the state machine succeeded without waiting for the nested step machine execution to complete

# Using same wait_workflow defined in Test1# Created state machine with nested state machine using CallAndContinue integration patternstart_execution_step_call_and_continue = "StartExecutionCallAndContinue", StepFunctionsStartExecutionStep(    "SFN Start Execution", integration_pattern=IntegrationPattern.CallAndContinue, parameters={        "StateMachineArn": wait_workflow_arn,        "Name": unique_name_from_base("StartExecutionCallAnContinue")    })

Test3 : WaitForTaskToken

Validated that the state machine succeeded after the token was returned

# Created state machine with a LambdaStep that invokes `SendTaskSuccessFunction` and takes the token in input:# Note: `SendTaskSuccessFunction` lambda function calls SendTaskSuccess with the token provided as inputlambda_params = {    "FunctionName": "SendTaskSuccessFunction",      "Payload.$": "$"}send_success_workflow = Workflow(    name="SendTaskSuccessWF",    definition=LambdaStep("Lambda Step", parameters=lambda_params),    role=workflow_execution_role)send_success_workflow_arn = send_success_workflow.create()# Created state machine with nested state machine usinf WaitForTaskToken integration patternstart_execution_step_wait_for_task_token = "StartExecutionWaitForTaskToken", StepFunctionsStartExecutionStep(    "SFN Start Execution - Wait for Callback", integration_pattern=IntegrationPattern.WaitForTaskToken, parameters={        "Input": {            "token.$": "$$.Task.Token"        },        "StateMachineArn": send_success_workflow_arn,        "Name": unique_name_from_base("StartExecutionCallback")    })

Pull Request Checklist

Please check all boxes (including N/A items)

Testing

• Unit tests added
• integration test added -N/A: Manual tests done since these required external resources, such as Lambda function

Documentation

• docs: All relevantdocs updated
• docstrings: All public APIs documented

Title and description

• Change type: Title is prefixed with change type: and followsconventional commits
• References: Indicate issues fixed via:Fixes #xxx

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.