Skip to content

Durable Task Framework allows users to write long running persistent workflows in C# using the async/await capabilities.

License

Notifications You must be signed in to change notification settings

Azure/durabletask

Durable Task Framework

The Durable Task Framework (DTFx) is a library that allows users to write long running persistent workflows (referred to as orchestrations) in C# using simple async/await coding constructs. It is used heavily within various teams at Microsoft to reliably orchestrate long running provisioning, monitoring, and management operations. The orchestrations scale out linearly by simply adding more worker machines. This framework is also used to power the serverless Durable Functions extension of Azure Functions.

By open sourcing this project we hope to give the community a very cost-effective alternative to heavy duty workflow systems. We also hope to build an ecosystem of providers and activities around this simple yet incredibly powerful framework.

This project has adopted the Microsoft Open Source Code of Conduct.

For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Supported persistance stores

Starting in v2.x, the Durable Task Framework supports an extensible set of backend persistence stores. Each store can be enabled using a different NuGet package. The latest version of all packages are signed and available for download at nuget.org.

Package Latest Version Details Development Status
DurableTask.ServiceBus NuGet Orchestration message and runtime state is stored in Service Bus queues while tracking state is stored in Azure Storage. The strength of this provider is its maturity and transactional consistency. However, it is no longer in active development at Microsoft. Production ready but not actively maintained
DurableTask.AzureStorage NuGet All orchestration state is stored in Azure Storage queues, tables, and blobs. The strength of this provider is the minimal service dependencies, high efficiency, and rich feature-set. This backend is available for Durable Functions. Production ready and actively maintained
DurableTask.AzureServiceFabric NuGet All orchestration state is stored in Azure Service Fabric Reliable Collections. This is an ideal choice if you are hosting your application in Azure Service Fabric and don't want to take on external dependencies for storing state. Production ready and actively maintained
DurableTask.Netherite NuGet An ultra-high performance backend developed by Microsoft Research where state is stored in Azure Event Hubs and Azure Page Blobs using FASTER database technology from Microsoft Research. This backend is available for Durable Functions. 👉 GitHub Repo Production ready and actively maintained
DurableTask.SqlServer NuGet All orchestration state is stored in a Microsoft SQL Server or Azure SQL database with indexed tables and stored procedures for direct interaction. This backend is available for Durable Functions. 👉 GitHub Repo Production ready and actively maintained
DurableTask.Emulator NuGet This is an in-memory store intended for testing purposes only. It is not designed or recommended for any production workloads. Not actively maintained

The core programming model for the Durable Task Framework is contained in the DurableTask.Core package, which is also under active development.

Learning more

There are several places where you can learn more about this framework. Note that some are external and not owned by Microsoft:

Development Notes

To run unit tests, you must specify your Service Bus connection string for the tests to use. You can do this via the ServiceBusConnectionString app.config value in the test project, or by defining a DurableTaskTestServiceBusConnectionString environment variable. The benefit of the environment variable is that no temporary source changes are required.

Unit tests also require Azure Storage Emulator, so make sure it's installed and running.

Note: While it's possible to use in tests a real Azure Storage account it is not recommended to do so because many tests will fail with a 409 Conflict error. This is because tests delete and quickly recreate the same storage tables, and Azure Storage doesn't do well in these conditions. If you really want to change Azure Storage connection string you can do so via the StorageConnectionString app.config value in the test project, or by defining a DurableTaskTestStorageConnectionString environment variable.