diff --git a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md index 095fc4d06..5eb80ac90 100644 --- a/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md +++ b/daprdocs/content/en/developing-applications/building-blocks/workflow/workflow-overview.md @@ -17,6 +17,7 @@ The workflow feature is comprised of the Workflow API and the workflow component *To Do:* - *Add diagram of how workflow API works?* - *Add explaination of how the API works* +- *[Reference](https://docs.dapr.io/developing-applications/building-blocks/service-invocation/service-invocation-overview/)* --- @@ -25,20 +26,21 @@ The workflow feature is comprised of the Workflow API and the workflow component The workflow API brings several core features executed by the Dapr sidecar: -- Invoking service methods using the Dapr service invocation building block. -- Invoking “activity” callbacks that execute non-orchestration logic locally inside the workflow pod. -- Sending or responding to external signals, including pub/sub events and bindings (input or output). +### Combine Dapr APIs +- Workflows allows users to combine Dapr APIs together in scheduled tasks +- Workflows compatible with pubsub, state store, bindings +- Can send/respond to external signals, including pub/sub events and bindings (input or output + +### Scheduled Delays and restarts - Scheduling reminder-like durable delays, which could be for minutes, days, or even years. -- Creating sub-workflows and reading their results, if any. -- Executing the above actions in sequence or in parallel. -- Saving custom state values to Dapr state stores - Restarting workflows by truncating their history logs and potentially resetting the input, which can be used to create eternal workflows that never end. -These capabilities are enabled by the sidecar-embedded DTFx-go engine and its Dapr-specific configuration. +### Sub-workflows +- Define subworkflow +- Executing multiple sub workflows in sequence or in parallel. -### Workflow as code - -"Workflow as code" refers to the developer-friendly implementation of a workflow’s logic using general purpose programming languages, allowing you to: +### Author workflows as code +Dapr workflow logic is implamented using general purpose programming languages, allowing you to: - Use your preferred programming language (no need to learn a new DSL or YAML schema) - Have access to the language’s standard libraries @@ -46,12 +48,7 @@ These capabilities are enabled by the sidecar-embedded DTFx-go engine and its Da - Use debuggers and examine local variables - Write unit tests for your workflows, just like any other part of your application logic -The Dapr SDK internally communicates with the DTFx-go gRPC endpoint in the Dapr sidecar to receive new workflow events and send new workflow commands, with these protocol details hidden. - -Due to the complexities of the workflow protocol, no HTTP API for this runtime feature is available at this time. - ### Declarative workflows support - Dapr provides an experience for declarative workflows as a layer on top of the "workflow as code" foundation, supporting a variety of declarative workflows, including: - The AWS Step Functions workflow syntax - The Azure Logic Apps workflow syntax @@ -59,12 +56,20 @@ Dapr provides an experience for declarative workflows as a layer on top of the " - The CNCF Serverless workflow specification #### Hosting serverless workflows - You can use the Dapr SDKs to build a new, portable SLWF runtime that leverages the Dapr sidecar. Usually, you can implement the runtime as a reusable container image that supports loading workflow definition files from Dapr state stores. The Dapr sidecar doesn’t load any workflow definitions. Rather, the sidecar simply drives the execution of the workflows, leaving all other details to the application layer. +*NEED MORE CLARIFICATION ON THESE FEATURES* +- Saving custom state values to Dapr state stores +- “Activity” callbacks that execute non-orchestration logic locally inside the workflow pod. + + + + + + ## Try out the workflow API