How to overcome platform dependency while using Azure Durable Functions?

Question

I am already using regular Azure Functions extensively in my project for image processing, order processing, etc., and implementing them in.Net 3.1

Recently I've realized that using durable functions can be a great solution to the problems I'm having in some scenarios. I've watched some courses on Pluralsight about durable functions and scanned the documentation and the web for some guidance and examples but there is something I couldn't figure out and is not mentioned at all anywhere. The durable functions are extremely platform-dependent and I couldn't figure out a way to abstract the business logic from the orchestrater function itself.

Let me explain with an example. Let's say we have an orchestrator function that is responsible for processing orders and it has the following steps that have to be executed in order; check inventory, charge the customer using a payment provider, update the inventory, update the order status. In this scenario, each step will be an activity function and we can create a service layer put the actual logic there and use interfaces to inject the service layer into activity functions, and have platform-independent code for each activity function.

The problem I'm having with this approach is even though individual steps for each activity function are platform-independent, the workflow itself is extremely dependent on Azure Functions since we have to use the IDurableOrchestrationContext for implementing the workflow. For instance, if we would like to call the same workflow from a console application for whatever reason we have to write the workflow itself again and we cannot guarantee that it is exactly following the same flow with the orchestrator function. Also when we made a change to the flow we have to remember to go and update both places. Is there a way to overcome this shortcoming of durable functions and make the underlying code more platform-independent?

In a summary, I'm looking for a way to separate business logic from Durable Functions and make it platform-independent.

Answer 1

I believe that you want to move out the business logic from Azure Durable Functions.

In this case, Durable Task Framework is the right choice I believe because The Durable Task Framework runs orchestrator code on a single thread. It can't interact with any other threads that might be called by other async APIs.

As you are saying,

the workflow itself is extremely dependent on Azure Functions since we have to use the IDurableOrchestrationContext for implementing the workflow.

await on task objects created by IDurableOrchestrationContext are only call by asynchronous helper methods and also technically safe to await on as well.

As long as that asynchronous method follows all of the normal orchestration code constraints, call to await_myOrchestratorService.RunAsync(context); works well.

When using this, ConfigureAwait(false) not to be used. Else, can cause the MultiThreaded Execution was detected error.

As a result, the DTF will no longer consider it in the context of orchestrators.

Refer this informative thread gives more information related to using async helper functions in an Azure Durable Functions Orchestrator safe or not.