mirror of https://github.com/dapr/docs.git
Add monitor diagram
Signed-off-by: Chris Gillum <cgillum@microsoft.com>
This commit is contained in:
parent
545cdd4159
commit
be9af3b979
|
|
@ -204,10 +204,14 @@ As you can see from the previous example, the runtime status of the workflow is
|
|||
The monitor pattern is recurring process that typically:
|
||||
|
||||
1. Checks the status of a system
|
||||
1. Takes some action based on that status
|
||||
1. Takes some action based on that status - e.g. send a notification
|
||||
1. Sleeps for some period of time
|
||||
1. Repeat
|
||||
|
||||
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"/>
|
||||
|
||||
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.
|
||||
|
||||
Dapr Workflow supports this pattern natively by allowing you to implement _eternal workflows_. Rather than writing infinite while-loops ([which is an anti-pattern]({{< ref "workflow-features-concepts.md#infinite-loops-and-eternal-workflows" >}})), Dapr Workflow exposes a _continue-as-new_ API that workflow authors can use to restart a workflow function from the beginning with a new input.
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 22 KiB |
Loading…
Reference in New Issue