Merge branch 'v1.13' into issue_3868

daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-architecture.md

@@ -15,6 +15,7 @@ Dapr Workflow is currently in beta. [See known limitations for {{% dapr-latest-v
 - The architecture of the Dapr Workflow engine
 - How the workflow engine interacts with application code
 - How the workflow engine fits into the overall Dapr architecture
+- How different workflow backends can work with workflow engine
 
 For more information on how to author Dapr Workflows in your application, see [How to: Author a workflow]({{< ref "workflow-overview.md" >}}).
 
@@ -173,6 +174,24 @@ Also, the Dapr Workflow engine requires that all instances of each workflow app
 
 Workflows don't control the specifics of how load is distributed across the cluster. For example, if a workflow schedules 10 activity tasks to run in parallel, all 10 tasks may run on as many as 10 different compute nodes or as few as a single compute node. The actual scale behavior is determined by the actor placement service, which manages the distribution of the actors that represent each of the workflow's tasks.
 
+## Workflow backend
+
+The workflow backend is responsible for orchestrating and preserving the state of workflows. At any given time, only one backend can be supported. You can configure the workflow backend as a component, similar to any other component in Dapr. Configuration requires:  
+1. Specifying the type of workflow backend. 
+1. Providing the configuration specific to that backend.
+
+For instance, the following sample demonstrates how to define a actor backend component. Dapr workflow currently supports only the actor backend by default, and users are not required to define an actor backend component to use it.
+
+```yaml
+apiVersion: dapr.io/v1alpha1
+kind: Component
+metadata:
+  name: actorbackend
+spec:
+  type: workflowbackend.actor
+  version: v1
+```
+
 ## Workflow latency
 
 In order to provide guarantees around durability and resiliency, Dapr Workflows frequently write to the state store and rely on reminders to drive execution. Dapr Workflows therefore may not be appropriate for latency-sensitive workloads. Expected sources of high latency include:

daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-features-concepts.md

@@ -147,6 +147,18 @@ Workflows can also wait for multiple external event signals of the same name, in
 
 Learn more about [external system interaction.]({{< ref "workflow-patterns.md#external-system-interaction" >}})
 
+## Workflow backend
+
+Dapr Workflow relies on the Durable Task Framework for Go (a.k.a. [durabletask-go](https://github.com/microsoft/durabletask-go)) as the core engine for executing workflows. This engine is designed to support multiple backend implementations. For example, the [durabletask-go](https://github.com/microsoft/durabletask-go) repo includes a SQLite implementation and the Dapr repo includes an Actors implementation. 
+
+By default, Dapr Workflow supports the Actors backend, which is stable and scalable. However, you can choose a different backend supported in Dapr Workflow. For example, [SQLite](https://github.com/microsoft/durabletask-go/tree/main/backend/sqlite)(TBD future release) could be an option for backend for local development and testing.
+
+The backend implementation is largely decoupled from the workflow core engine or the programming model that you see. The backend primarily impacts:
+- How workflow state is stored 
+- How workflow execution is coordinated across replicas
+
+In that sense, it's similar to Dapr's state store abstraction, except designed specifically for workflow. All APIs and programming model features are the same, regardless of which backend is used.
+
 ## Limitations
 
 ### Workflow determinism and code restraints 

daprdocs/content/en/reference/components-reference/supported-workflow-backend/_index.md

@@ -0,0 +1,10 @@
+---
+type: docs
+title: "Workflow backend component specs"
+linkTitle: "Workflow backend"
+weight: 9000
+description: The supported workflow backend that orchestrate workflow and save workflow state
+no_list: true
+---
+
+{{< partial "components/description.html" >}}

daprdocs/content/en/reference/components-reference/supported-workflow-backend/actor-workflow-backend.md

@@ -0,0 +1,24 @@
+---
+type: docs
+title: "Actor workflow backend"
+linkTitle: "Actor workflow backend"
+description: Detailed information on the Actor workflow backend component
+---
+
+## Component format
+
+The Actor workflow backend is the default backend in Dapr. If no workflow backend is explicitly defined, the Actor backend will be used automatically.
+
+You don't need to define any components to use the Actor workflow backend. It's ready to use out-of-the-box.
+
+However, if you wish to explicitly define the Actor workflow backend as a component, you can do so, as shown in the example below.
+
+```yaml
+apiVersion: dapr.io/v1alpha1
+kind: Component
+metadata:
+  name: actorbackend
+spec:
+  type: workflowbackend.actor
+  version: v1
+```