2. Components
Architecture diagram
Read it left to right. People and programs on the left call the engine in the middle. The engine keeps its records in the stores on the right.
Component reference
Callers and integrations
| Part | Kind | Description |
|---|---|---|
| Operators | People | Watch runs and fix problems. |
| Developers | People | Write workflow definitions. |
| Engine UI | Interface for people | Operator and developer interface: the Durable Task Scheduler dashboard and Azure Monitor workbooks initially, a Static Web App later. |
| Task Workers | Programs, part of the platform | Implement step types the engine cannot perform itself, such as document parsing. They run anywhere and call the engine over HTTPS. |
| External Eventing Integrations | Azure services | Deliver messages to the engine: Event Grid, Service Bus topics, Event Hubs. |
| External Storage Integrations | Azure services | Azure Blob for large data and archives; Key Vault and App Configuration for settings. |
| Metrics Integrations | Azure services | Application Insights, Log Analytics, and Managed Grafana for measurements and logs. |
Engine
| Part | What it does |
|---|---|
| APIs | The single entry point. Every call from every caller goes through it. |
| Task Service | Gives work to workers and takes their results. |
| Distributed Queues | One waiting line per worker task type, in Service Bus. Work waits here until a worker takes it. |
| Workflow Execution Service | Runs each workflow from its first step to its last. |
| State Machine Evaluator | The part of the execution service that decides which step comes next. |
| Event adapters and Event Handlers | Receive messages from outside and turn them into "start a run" or "continue a run". |
| Payload Offload | Moves large inputs and outputs to Blob so records stay small. |
| System Task Workers | The engine's own code for generic steps: call an API, transform JSON, call a model, call a tool, call an agent, publish an event. |
| Metrics | Sends measurements to the metrics integrations. |
Stores
| Store | Contents | Service |
|---|---|---|
| Workflow Execution History | One record per run and per step | Azure SQL |
| State Persistence | What a run needs to continue after an interruption | Durable Task Scheduler |
| Workflow Execution Index | The same history, indexed for search, and mirrored to Fabric for analytics | Azure SQL |
| Workflow, Task, Schedule Metadata | The workflow definitions, task settings, and timers | Azure SQL |
| Queue Persistence | The waiting lines | Service Bus |
Core terms
Workflow definition: the JSON file that describes a workflow. Written once, versioned.
Run: one execution of a definition with one specific input. A definition for "approve an engagement" has one run per engagement.
The next page follows one run through the diagram.