Update workflow diagrams (#4682)
* Update workflow pattern diagrams Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com> * Update workflow diagrams to new style Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com> * Update diagrams Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com> * Update workflow k8s diagram Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com> --------- Signed-off-by: Marc Duiker <marcduiker@users.noreply.github.com> Co-authored-by: Mark Fussell <markfussell@gmail.com>
|
@ -31,7 +31,7 @@ When a workflow application starts up, it uses a workflow authoring SDK to send
|
||||||
|
|
||||||
The workflow app executes the appropriate workflow code and then sends a gRPC request back to the sidecar with the execution results.
|
The workflow app executes the appropriate workflow code and then sends a gRPC request back to the sidecar with the execution results.
|
||||||
|
|
||||||
<img src="/images/workflow-overview/workflow-engine-protocol.png" alt="Dapr Workflow Engine Protocol" />
|
<img src="/images/workflow-overview/workflow-engine-protocol.png" width=500 alt="Dapr Workflow Engine Protocol" />
|
||||||
|
|
||||||
All interactions happen over a single gRPC channel and are initiated by the application, which means the application doesn't need to open any inbound ports. The details of these interactions are internally handled by the language-specific Dapr Workflow authoring SDK.
|
All interactions happen over a single gRPC channel and are initiated by the application, which means the application doesn't need to open any inbound ports. The details of these interactions are internally handled by the language-specific Dapr Workflow authoring SDK.
|
||||||
|
|
||||||
|
@ -91,7 +91,7 @@ Workflow actor state remains in the state store even after a workflow has comple
|
||||||
|
|
||||||
The following diagram illustrates the typical lifecycle of a workflow actor.
|
The following diagram illustrates the typical lifecycle of a workflow actor.
|
||||||
|
|
||||||
<img src="/images/workflow-overview/workflow-actor-flowchart.png" alt="Dapr Workflow Actor Flowchart"/>
|
<img src="/images/workflow-overview/workflow-actor-flowchart.png" width=600 alt="Dapr Workflow Actor Flowchart"/>
|
||||||
|
|
||||||
To summarize:
|
To summarize:
|
||||||
|
|
||||||
|
@ -113,7 +113,7 @@ Each activity actor stores a single key into the state store:
|
||||||
|
|
||||||
The following diagram illustrates the typical lifecycle of an activity actor.
|
The following diagram illustrates the typical lifecycle of an activity actor.
|
||||||
|
|
||||||
<img src="/images/workflow-overview/workflow-activity-actor-flowchart.png" alt="Workflow Activity Actor Flowchart"/>
|
<img src="/images/workflow-overview/workflow-activity-actor-flowchart.png" width=600 alt="Workflow Activity Actor Flowchart"/>
|
||||||
|
|
||||||
Activity actors are short-lived:
|
Activity actors are short-lived:
|
||||||
|
|
||||||
|
|
|
@ -710,7 +710,7 @@ The monitor pattern is recurring process that typically:
|
||||||
|
|
||||||
The following diagram provides a rough illustration of this pattern.
|
The following diagram provides a rough illustration of this pattern.
|
||||||
|
|
||||||
<img src="/images/workflow-overview/workflow-monitor-pattern.png" width=600 alt="Diagram showing how the monitor pattern works"/>
|
<img src="/images/workflow-overview/workflow-monitor-pattern.png" width=800 alt="Diagram showing how the monitor pattern works"/>
|
||||||
|
|
||||||
Depending on the business needs, there may be a single monitor or there may be multiple monitors, one for each business entity (for example, a stock). Furthermore, the amount of time to sleep may need to change, depending on the circumstances. These requirements make using cron-based scheduling systems impractical.
|
Depending on the business needs, there may be a single monitor or there may be multiple monitors, one for each business entity (for example, a stock). Furthermore, the amount of time to sleep may need to change, depending on the circumstances. These requirements make using cron-based scheduling systems impractical.
|
||||||
|
|
||||||
|
@ -953,7 +953,7 @@ Here's an example workflow for a purchase order involving a human:
|
||||||
|
|
||||||
The following diagram illustrates this flow.
|
The following diagram illustrates this flow.
|
||||||
|
|
||||||
<img src="/images/workflow-overview/workflow-human-interaction-pattern.png" width=600 alt="Diagram showing how the external system interaction pattern works with a human involved"/>
|
<img src="/images/workflow-overview/workflow-human-interaction-pattern.png" width=800 alt="Diagram showing how the external system interaction pattern works with a human involved"/>
|
||||||
|
|
||||||
The following example code shows how this pattern can be implemented using Dapr Workflow.
|
The following example code shows how this pattern can be implemented using Dapr Workflow.
|
||||||
|
|
||||||
|
|
Before Width: | Height: | Size: 17 KiB After Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 48 KiB |
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 99 KiB |
Before Width: | Height: | Size: 37 KiB After Width: | Height: | Size: 96 KiB |
Before Width: | Height: | Size: 72 KiB After Width: | Height: | Size: 62 KiB |
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 70 KiB |
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 135 KiB |
Before Width: | Height: | Size: 118 KiB After Width: | Height: | Size: 49 KiB |
Before Width: | Height: | Size: 16 KiB After Width: | Height: | Size: 89 KiB |
Before Width: | Height: | Size: 89 KiB After Width: | Height: | Size: 146 KiB |
Before Width: | Height: | Size: 21 KiB After Width: | Height: | Size: 110 KiB |
Before Width: | Height: | Size: 34 KiB After Width: | Height: | Size: 161 KiB |
Before Width: | Height: | Size: 8.7 KiB After Width: | Height: | Size: 32 KiB |
Before Width: | Height: | Size: 12 KiB After Width: | Height: | Size: 48 KiB |