diff --git a/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/POST.md b/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/POST.md index 04ef9f648e..ee885f0ce2 100644 --- a/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/POST.md +++ b/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/POST.md @@ -18,20 +18,7 @@ You define a [**workflow**](https://docs.dapr.io/developing-applications/buildin > **This is orchestration rather than choreography:** one place drives the process, instead of services reacting to each other's events. The definitions live in your app, but the engine that executes them runs in the Dapr sidecar next to it. -```mermaid -flowchart LR - subgraph App["Your ABP App"] - WF["OrderProcessingWorkflow"] - ACT["Activities
CheckInventory, ProcessPayment, NotifyCustomer"] - end - subgraph Sidecar["Dapr Sidecar"] - ENGINE["Workflow Engine
(durable execution)"] - end - STORE[("State Store
Redis")] - - App -->|gRPC| Sidecar - Sidecar -->|reads / writes history| STORE -``` +![mermaid1](./mermaid1.png) The key idea is **durable execution**. Dapr records every step to a state store, so the workflow can be replayed from history at any time. A crash, a deployment, or a scale-out event doesn't lose progress, and a workflow can run for seconds or for months. @@ -78,7 +65,7 @@ Before we start, make sure you have these installed: That last step matters. When you run `dapr init` in self-hosted mode, Dapr pulls a few containers (including Redis) and writes a default `statestore.yaml` component. That default state store already has `actorStateStore: "true"` set, which is exactly what Dapr Workflow needs. So once `dapr init` finishes, you can run workflows locally with zero extra configuration. -![dapr-init-run-result](dapr-init-run-result.png) +![dapr-init-run-result](./dapr-init-run-result.png) > **Pro Tip:** If you ever swap the default Redis store for your own component, double-check that it sets `actorStateStore: "true"`. Without it, workflows silently fail to start, and it's the line people forget most often. @@ -244,14 +231,7 @@ Each activity is isolated, so Dapr can retry a failed one without re-running the Here's the shape of the process we just wrote: -```mermaid -flowchart TD - A["Start workflow
(OrderPayload)"] --> B["CheckInventoryActivity"] - B -->|In stock| C["ProcessPaymentActivity"] - B -->|Out of stock| R["Return: Rejected"] - C --> D["NotifyCustomerActivity"] - D --> E["Return: Completed"] -``` +![mermaid2](./mermaid2.png) ## Register the Workflow @@ -348,7 +328,7 @@ After the workflow finishes, you'll see a `COMPLETED` status along with the seri If you check the terminal, you'll also see the log lines from the workflow and each activity in order: -![dapr-workflow-response](dapr-workflow-response.png) +![dapr-workflow-response](./dapr-workflow-response.png) The same management API also lets you `terminate`, `pause`, `resume`, and `purge` instances, and `raiseEvent` to send external events into a waiting workflow. For example: diff --git a/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/mermaid1.png b/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/mermaid1.png new file mode 100644 index 0000000000..5344a05f67 Binary files /dev/null and b/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/mermaid1.png differ diff --git a/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/mermaid2.png b/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/mermaid2.png new file mode 100644 index 0000000000..19ee74c1c5 Binary files /dev/null and b/docs/en/Community-Articles/2026-06-28-working-with-dapr-workflows/mermaid2.png differ