-
Notifications
You must be signed in to change notification settings - Fork 772
Multi App workflow calls. #4847
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: v1.16
Are you sure you want to change the base?
Conversation
Signed-off-by: Cassandra Coyle <cassie@diagrid.io>
Signed-off-by: Albert Callarisa <albert@diagrid.io>
baff25b
to
5988cd5
Compare
Signed-off-by: Albert Callarisa <albert@diagrid.io>
Signed-off-by: Albert Callarisa <albert@diagrid.io>
6dfc23a
to
1429561
Compare
I think we should merge this first, and I will rebase #4855 and incorporate these changes. |
daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md
Outdated
Show resolved
Hide resolved
Signed-off-by: Albert Callarisa <albert@diagrid.io>
Signed-off-by: Albert Callarisa <albert@diagrid.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@@ -16,6 +17,11 @@ Some scenarios where this is useful include: | |||
- Different parts of the workflow need to be executed in different geographic regions due to data residency requirements. | |||
- An involved business process spans multiple teams or departments, each owning their own application. | |||
- Implementation of a workflow spans different programming lanaguages based on team expertise or existing codebases. | |||
- Different team boundaries or microservice ownership. | |||
- Shared activity pools where apps can expose activities and child workflows that can be called from multiple workflow orchestrators running in different applications, see image below: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't seem quite right to me.
Whether different app IDs share the same activity
code, cross workflow execution is based on definite routing, meaning the target app ID is explicit.
It is currently impossible for activity execution to be pooled, and it not something we would intentionally want to support. Execution pooling is done at the app ID level.
Workflows being durable, if the target activity or child workflow app ID is not available or has not been defined, the parent workflow retry until the target app ID becomes available, indefinitely. | ||
It is paramount that their is co-ordination between the teams owning the different app IDs to ensure that the activities and child workflows are defined and available when needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why has this been removed?
When calling cross-app activities or child workflows: | ||
- If the target application does not exist, the call will be retried using the provided retry policy | ||
- If the target application exists but doesn't contain the specified activity or workflow, the call will return an error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, let's keep using the same verbiage, which is "multi app", or "multiple application" execution. We will not be using "cross app".
- If the target application does not exist, the call will be retried using the provided retry policy | ||
- If the target application exists but doesn't contain the specified activity or workflow, the call will return an error |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- If the target application does not exist, the call will be retried using the provided retry policy | |
- If the target application exists but doesn't contain the specified activity or workflow, the call will return an error | |
- If the target application does not exist, the call will be retried using the provided retry policy. | |
- If the target application exists but doesn't contain the specified activity or workflow, the call will return an error. |
## Error handling | ||
|
||
When calling cross-app activities or child workflows: | ||
- If the target application does not exist, the call will be retried using the provided retry policy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This gives the impression that if a target app ID is not available, the call that application will not be tried forever. I did not think this was the case- I certainly think it should try forever!
|
||
## Multi-application activity example | ||
|
||
<img src="/images/workflow-overview/workflow-crossapp-callactivity.png" width=800 alt="Diagram showing cross-app call activity workflow pattern"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multi-application
|
||
The following example shows how to execute child workflows on different target app IDs. | ||
|
||
<img src="/images/workflow-overview/workflow-crossapp-suborchestrator.png" width=800 alt="Diagram showing cross-app child workflow pattern"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
multi application
@@ -38,9 +42,24 @@ Similarly, all app IDs must use the same actor state store. | |||
Finally, the target app ID must have the activity or child workflow defined, otherwise the parent workflow will retry indefinitely. | |||
{{% /alert %}} | |||
|
|||
## Multi-application activity examples | |||
{{% alert title="Important Limitations" color="warning" %}} | |||
- **Only some SDKs support cross-app calls** - Cross-app operations are dependent on the specific SDK implementation. Currently only available in the Java (partially) and Go SDKs. Other SDKs (Python, .NET, JavaScript) do not support any cross-app features at this time. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multi application
docs for this issue