4.2 KiB
| type | title | linkTitle | weight | description |
|---|---|---|---|---|
| docs | Workflow management building block overview | Overview | 1000 | Overview of the workflow management API |
{{% alert title="Note" color="primary" %}} The Workflow building block is currently in alpha state supporting .NET. {{% /alert %}}
The Dapr Workflow Management API strives to make orchestrating logic for messaging, state management, and failure handling across various microservices easier for developers. Prior to adding workflows to Dapr, you'd often need to build ad-hoc workflows behind-the-scenes in order to bridge that gap.
The durable, resilient Dapr Workflow Management API:
- Provides a workflow management API for running workflows
- Offers a built-in workflow runtime to write Dapr workflows (of type
workflow.dapr) - Will integrate with future supported external workflow runtime components
The Workflow building block can assist with scenarios like:
- Order processing involving inventory management, payment systems, shipping, etc.
- HR onboarding workflows coordinating tasks across multiple departments and participatns
- Orchestrating the roll-out of digital menu updates in a national restaurant chain
- Image processing workflows involving API-based classification and storage
How it works
The Dapr Workflow engine runs in the Dapr sidecar and consists of:
- SDKs for authoring workflows in code, using any language
- APIs for managing workflows (start, query, suspend/resume, terminate)
The workflow engine is internally powered by Dapr's actor runtime. In the following diagram demonstrates the Dapr Workflow architecture in Kubernetes mode:
Essentially, to use the Dapr Workflow building block, you write workflow code in your application using the SDK and connect to the sidecar using gRPC stream.
Notice that the engine itself is embedded directly into the sidecar and implemented by the durabletask-go framework library. This framework allows you to swap out different storage providers, including a storage provider created specifically for Dapr that leverages internal actors behind the scenes. Since Dapr Workflows use actors, you can store workflow state in variety of Dapr-supported state stores, like Redis, CosmosDB, etc.
Features
HTTP/gRPC API calls to start or terminate any workflow
Once you create an application with workflow code and run it with Dapr, you can make HTTP/gRPC calls to Dapr to run specific tasks/workflows that reside in the application. Each individual workflow can be started or terminated through a POST request.
You can also get information on the workflow (even if it has been terminated or it finished naturally) through a GET request. This GET request will send back information, such as:
- The instance ID of the workflow
- The time that the run started
- The current running status, whether that be “Running”, “Terminated”, or “Completed”
Runing a workflow
When you run dapr init, Dapr creates a default workflow runtime. This component is written in Go and implements workflow instances as actors to promote placement and scalability.
Start
To start your workflow, run:
POST http://localhost:3500/v1.0/workflows/{workflowType}/{instanceId}/start
Terminate
To terminate your workflow, run:
POST http://localhost:3500/v1.0/workflows/{workflowType}/{instanceId}/terminate
Get metadata
To fetch workflow outputs and inputs, run:
GET http://localhost:3500/v1.0/workflows/{workflowType}/{instanceId}
Watch the demo
Watch this video for an overview on Dapr Workflows:
Next steps
- [Learn how to set up a workflow]({{< ref howto-workflow.md >}})
- [Supported workflows]({{< ref supported-workflows.md >}})
- Learn more about authoring workflows for the built-in engine component
- Learn more about supported workflow components