refactor(aws-stepfunctions-tasks): implement service integration patterns for tasks #3114
Comments
…erns for tasks Step Functions allows users to call different integrated services in different ways. They are also called service integration patterns, including Request Response, Run a Job and Wait for Callback. Users must choose exactly one of them and specify it in the "Resource" field. This commit introduces a new member variable, serviceIntegrationPattern, in the interface of properties within each existing integrated service. This helps to avoid using multiple boolean variables in the service such as ECS, which supports different service integration patterns. It is also beneficial for code maintenances: if Step Functions adds new integrated services or updates the existing integration patterns in the future, keeping pace with these changes will be simply updating this variable of enum type. BREAKING CHANGE: To define a callback task, users should specify "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.WAIT_FOR_CALLBACK" instead of "waitForTaskToken: true". For a sync task, users should use "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.RUN_A_JOB" in the place of "synchronous: true". In addition, this commit enables users to define callback task with ECS. **@aws-cdk/aws-stepfunctions-tasks** Closes aws#3114
…erns for tasks Step Functions allows users to call different integrated services in different ways. They are also called service integration patterns, including Request Response, Run a Job and Wait for Callback. Users must choose exactly one of them and specify it in the "Resource" field. This commit introduces a new member variable, serviceIntegrationPattern, in the interface of properties within each existing integrated service. This helps to avoid using multiple boolean variables in the service such as ECS, which supports different service integration patterns. It is also beneficial for code maintenances: if Step Functions adds new integrated services or updates the existing integration patterns in the future, keeping pace with these changes will be simply updating this variable of enum type. BREAKING CHANGE: To define a callback task, users should specify "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.WAIT_FOR_CALLBACK" instead of "waitForTaskToken: true". For a sync task, users should use "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.RUN_A_JOB" in the place of "synchronous: true". In addition, this commit enables users to define callback task with ECS. **@aws-cdk/aws-stepfunctions-tasks** Closes aws#3114
…erns for tasks Step Functions allows users to call different integrated services in different ways. They are also called service integration patterns, including Request Response, Run a Job and Wait for Callback. Users must choose exactly one of them and specify it in the "Resource" field. This commit introduces a new member variable, serviceIntegrationPattern, in the interface of properties within each existing integrated service. This helps to avoid using multiple boolean variables in the service such as ECS, which supports different service integration patterns. It is also beneficial for code maintenances: if Step Functions adds new integrated services or updates the existing integration patterns in the future, keeping pace with these changes will be simply updating this variable of enum type. BREAKING CHANGE: To define a callback task, users should specify "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.WAIT_FOR_CALLBACK" instead of "waitForTaskToken: true". For a sync task, users should use "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.RUN_A_JOB" in the place of "synchronous: true". In addition, this commit enables users to define callback task with ECS. **@aws-cdk/aws-stepfunctions-tasks** Closes aws#3114
NGL321
added
gap
@aws-cdk/aws-stepfunctions
|
Hi @wqzoww! Thank you for addressing this, and putting in a PR! We are working hard to stabilize the CDK APIs and tuning them to meet our consistency guidelines. While we work on getting the APIs aligned with our guidelines, we are pausing work on most community PRs. Please continue to report issues and submit feature requests, of course. We expect to get back to work on community PRs within a few weeks. We will absolutely take a took at your PR as soon as we are able. |
|
Ran into a use case today that requires using Task Tokens, judging by this issue and my inability to find any docs or sourcecode based on the keyword "waitForTaskToken", is it safe to assume this functionality doesn't exist yet in the CDK? |
|
Hi @MichaelHindley, Which integrated service do you use in your case ? Today, CDK supports "waitForTaskToken" for Lambda, SNS and SQS with an additional boolean property "waitForTaskToken". The following link shows how to define a callback task (waitForTaskToken) for Lambda: Hope my answer helps. |
|
@wqzoww I'm using lambda through This search Just for my own sanity, there is no DynamoDB support for stepfunction tasks yet, right? |
I updated the README.md file and provided use cases to cover both classes in the corresponding PR of this issue. Hope my PR will be reviewed and accepted soon.
To confirm, DDB is not supported in stepfunctions-task today. |
|
Hope it will be merged soon as my StepFunctions make big use of |
Yep same here, we're currently using a generic lambda that accepts an DDB operation as it's input as a workaround, which gets the job done but I wouldn't want to maintain this in LTS. |
…erns for tasks Step Functions allows users to call different integrated services in different ways. They are also called service integration patterns, including Request Response, Run a Job and Wait for Callback. Users must choose exactly one of them and specify it in the "Resource" field. This commit introduces a new member variable, serviceIntegrationPattern, in the interface of properties within each existing integrated service. This helps to avoid using multiple boolean variables in the service such as ECS, which supports different service integration patterns. It is also beneficial for code maintenances: if Step Functions adds new integrated services or updates the existing integration patterns in the future, keeping pace with these changes will be simply updating this variable of enum type. BREAKING CHANGE: To define a callback task, users should specify "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.WAIT_FOR_TASK_TOKEN" instead of "waitForTaskToken: true". For a sync task, users should use "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.SYNC" in the place of "synchronous: true". In addition, this commit enables users to define callback task with ECS. **@aws-cdk/aws-stepfunctions-tasks** Closes aws#3114
…erns for tasks Step Functions allows users to call different integrated services in different ways. They are also called service integration patterns, including Request Response, Run a Job and Wait for Callback. Users must choose exactly one of them and specify it in the "Resource" field. This commit introduces a new member variable, serviceIntegrationPattern, in the interface of properties within each existing integrated service. This helps to avoid using multiple boolean variables in the service such as ECS, which supports different service integration patterns. It is also beneficial for code maintenances: if Step Functions adds new integrated services or updates the existing integration patterns in the future, keeping pace with these changes will be simply updating this variable of enum type. BREAKING CHANGE: To define a callback task, users should specify "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.WAIT_FOR_TASK_TOKEN" instead of "waitForTaskToken: true". For a sync task, users should use "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.SYNC" in the place of "synchronous: true". In addition, this commit enables users to define callback task with ECS. **@aws-cdk/aws-stepfunctions-tasks** Closes aws#3114
* refactor(aws-stepfunctions-tasks): implement service integration patterns for tasks Step Functions allows users to call different integrated services in different ways. They are also called service integration patterns, including Request Response, Run a Job and Wait for Callback. Users must choose exactly one of them and specify it in the "Resource" field. This commit introduces a new member variable, serviceIntegrationPattern, in the interface of properties within each existing integrated service. This helps to avoid using multiple boolean variables in the service such as ECS, which supports different service integration patterns. It is also beneficial for code maintenances: if Step Functions adds new integrated services or updates the existing integration patterns in the future, keeping pace with these changes will be simply updating this variable of enum type. BREAKING CHANGE: To define a callback task, users should specify "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.WAIT_FOR_TASK_TOKEN" instead of "waitForTaskToken: true". For a sync task, users should use "serviceIntegrationPattern: sfn.ServiceIntegrationPattern.SYNC" in the place of "synchronous: true". In addition, this commit enables users to define callback task with ECS. **@aws-cdk/aws-stepfunctions-tasks** Closes #3114 * serviceIntegrationPattern -> integrationPattern
Note: for support questions, please first reference our documentation, then use Stackoverflow. This repository's issues are intended for feature requests and bug reports.
I'm submitting a ...
What is the current behavior?
Today, to define a task state with another aws services, users should specify their service integration pattern with booleans, such as "waitForTaskToken" and "synchronous".
What is the expected behavior (or behavior of feature suggested)?
As users are supposed to choose exactly one pattern among all the existing ones, I would like to introduce a single enum variable to indicate service integration pattern.
What is the motivation / use case for changing the behavior or adding this feature?
Please tell us about your environment:
Other information
https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html
The text was updated successfully, but these errors were encountered: