diff --git a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md index 8756c1f41..e4a5b8413 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md +++ b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-patterns.md @@ -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. + +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. diff --git a/daprdocs/static/images/workflow-overview/workflow-monitor-pattern.png b/daprdocs/static/images/workflow-overview/workflow-monitor-pattern.png new file mode 100644 index 000000000..52f63d7e7 Binary files /dev/null and b/daprdocs/static/images/workflow-overview/workflow-monitor-pattern.png differ