feat(stepfunctions-tasks): start a nested state machine execution as a construct #8178
Conversation
This class is the replacement for the previous `StartExecution` class. There are a few differences: 1. the `stateMachine` parameter has been moved into props. Rationale: alignment with constructs. 2. the resource ARN that's generated in the Amazon States language uses `sync:2`. This returns an output of JSON instead of a string. Rationale: alignment with Step Functions documentation. 3. The `input` parameter has been changed to be of type `sfn.TaskInput` Rationale: previous type precluded the ability to assign state input to this parameter.
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
packages/@aws-cdk/aws-stepfunctions-tasks/lib/stepfunctions/start-execution.ts
Outdated
Show resolved
Hide resolved
packages/@aws-cdk/aws-stepfunctions-tasks/lib/stepfunctions/start-execution.ts
Outdated
Show resolved
Hide resolved
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
| @@ -39,6 +41,8 @@ export interface StartExecutionProps { | |||
| * A Step Functions Task to call StartExecution on another state machine. | |||
| * | |||
| * It supports three service integration patterns: FIRE_AND_FORGET, SYNC and WAIT_FOR_TASK_TOKEN. | |||
| * | |||
| * @deprecated - use 'StepFunctionsStartExecution' | |||
There was a problem hiding this comment.
Same comment as with batch.
Can we call new StepFunctionsStartExecution() in the constructor here and delete most of the code in this file?
There was a problem hiding this comment.
I think that's pretty natural and organic if we were replacing one API with another to create an adapter and call into the replacement. I don't think this is a scenario where we can just proxy into the replacement as the replacement contains and configures properties (i.e. inputPath, outputPath, ...) that the older
In this case, we are replacing a class that implemented a bind method to contribute a portion of the properties to represent a Task with a class that's a construct and configures all of the properties for a Task state.
The user experience with the current format will be to embed the call to start execution into the invocation of a new Task. I don't think proxying to invoke a new StepFunctionStartExeuction yields the right replacement.
new Task(this, 'my-task', {
task: new tasks.ExecuteStateMachine(child, {...}),
...
}Some of the other ones to come like DynamoDB and ECS, I've tried to reuse the shared types. I could perhaps move more into a central location here and DRY it up a bit.
Did you have something else in mind? If so, are you opposed to me making a subsequent PR to do some refactoring?
packages/@aws-cdk/aws-stepfunctions-tasks/lib/stepfunctions/start-execution.ts
Outdated
Show resolved
Hide resolved
|
@nija-at would love if you could take another look when you get a chance! |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
shivlaks
changed the title
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from master and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
This class is the replacement for the previous
StartExecutionclass.There are a few differences:
the
stateMachineparameter has been moved into props.Rationale: alignment with constructs.
the resource ARN that's generated in the Amazon States
language uses
sync:2. This returns an output of JSON insteadof a string.
Rationale: alignment with Step Functions team recommendation.
The
inputparameter has been changed to be of typesfn.TaskInputRationale: previous type precluded the ability to assign state input to
this parameter.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license