Announcing cloud-native workflows using Dapr and Logic Apps

The Distributed Application Runtime (Dapr) project is growing rapidly are we’re grateful for all the community support and customer feedback. While working with customers building business applications, we find that one of the most frequent needs is the ability to schedule, automate, and orchestrate business processes. This is often called a business workflow. Workflows also frequently integrate with other apps, data, systems, and services across organizations. To enable developers to easily build workflow applications that use Dapr’s capabilities, including diagnostics and multi-language support, we are excited to announce Dapr Workflows.

Dapr workflows using Azure Logic Apps

With Dapr, we have seen a growing list of customers using workflows in their applications. Some have used open source workflow engines, such as Workflow Core. Azure Logic Apps provides extensive workflow capabilities and recently the Logic Apps team decoupled their engine into a set of reusable libraries that can be hosted in many different environments. This provided the ideal opportunity to combine the capabilities of Dapr with Logic Apps to enable a whole new class of business processing applications that can now be built and run on any hosting platform, such as Kubernetes, IoT Edge, or VMs. Logic Apps has now become another application framework that is integrated with Dapr, taking advantage of Dapr’s building blocks.

Invoking a Logic Apps workflow

Logic App workflows are extremely flexible enabling you to build a variety of different workload applications and at their core consist of triggers, actions, and connectors. Triggers fire when events or new data meet specified conditions. For example, an event might be getting an email, detecting changes in your Azure Storage account or an incoming HTTP request. Each time the trigger fires, the Logic Apps engine creates a new logic app instance that runs the workflow.

Actions are all the steps that happen after the trigger and enable you to compose data, set conditions, or send HTTP requests. Connectors are how your workflow can get access to data, services, and systems, where you can use pre-built connectors that take care of serializing/deserializing data correctly.

By integrating Logic Apps workflow with Dapr, you can now take advantage of the Dapr’s service invocation and input bindings building blocks to trigger workflows. Let’s look at an example of how this works.

Below is a simple workflow that is triggered by an incoming HTTP request and the workflow action composes a response message that contains the text message:

“Hello from Logic App workflow running with Dapr!”

You can run this workflow easily on your local machine by using the Dapr CLI, like this:

dapr run --app-id myWorkflow --protocol grpc --port 3500 --app-port 50003 -- dotnet run --workflows-path ../workflows

This command launches a workflow host called myWorkflow (accessed over port 50003), with a Dapr sidecar and the workflows-path flag is the path to the workflow file called workflow1.json that is loaded on startup. This workflow example is shown below or you can view it here. You can have as many workflow files in the workflows-path directory as you wish. You can now invoke a specific workflow file like this using the Dapr invoke method capability with curl:

curl http://localhost:3500/v1.0/invoke/myWorkflow/method/workflow1
{"value":"Hello from Logic App workflow running with Dapr!"}  

Or using the Dapr CLI:

dapr invokePost --app-id myWorkflow --method workflow1 
{"value":"Hello from Logic App workflow running with Dapr!"}

This ability to easily invoke workflows from Dapr opens up a world of possibilities, including rapid no-code or low-code development, where the Logic Apps workflow, along with its connectors, does all the processes orchestration and integration to external systems and services for you. And, creating the workflows is as simple as opening up the workflow designer, either in the Azure portal or with the Visual Studio Code extension.

Workflow1.json created using the Azure portal Logic Apps designer

Triggering a workflow using Dapr input bindings

Workflows can also be triggered from Dapr input bindings and then within a workflow you can take advantage of the Dapr building blocks. To trigger a workflow from an input binding the name of the workflow must match the name of the input binding.

The workflowTopic.json file below shows how a message arriving on say, a Kafka queue as a Dapr input binding called workflowTopic, triggers this workflow to run. In this workflow, the action that runs takes the body of the input request and saves this to a Dapr state store called mystatestore, thereby showing how you can also call back out to Dapr from the workflow itself to take advantage of Dapr’s state management building block.

WorkflowTopic.json shows how a workflow is triggered by an input binding and then calls Dapr state management

Putting this all together you can create some very powerful workflows. For example, workflow2.json below shows how a workflow can first invoke an Azure Function, save the result to a Redis store using Dapr’s state management, and then send a request to both Azure Service Bus with the body from the Function call, as well as return the body value to the caller.

Workflow2.json combines multiple HTTP requests to external services

How does it work?

Let’s take a deeper look at how this all works and at the same time check out the new repo in the Dapr org called Workflows with all the source code. In the repo there is a .NET Dapr-Logic App host, which loads the Logic Apps engine and runs a gRPC server hosting the Dapr client. When you launch this host process with Dapr as a sidecar, Logic Apps loads any workflow files it finds in the given directory (or via a volume mount if running in a container with Kubernetes) and then waits to receive an invocation or input binding call from Dapr to start any of the workflows. This is shown in the diagram below.

Dapr and application frameworks

As mentioned at the beginning of this post, Logic Apps is now another application framework integrated with Dapr. It is worth spending a moment to look at the developer layers that Dapr provides, as illustrated in the diagram below. At the lowest layer you can use any of the API building blocks over HTTP and gRPC, which means Dapr is accessible from virtually any language. On this is layered gRPC proto generated SDKs for several languages. On top of the gRPC proto layer are crafted SDKs for .NET, Java, and Python (as of today, with others coming), which provide an improved usability experience for developers. Finally, at the highest layer, Dapr integrates with specific application frameworks such as ASP.NET Core, Spring Boot, virtual actors, and now Logic Apps to provide workflows. As a developer you can choose to build against any of these layers, depending on your app requirements.

Future roadmap

This preview release enables the power of workflows with Dapr. On the roadmap is to enable the ability to use the Azure managed connectors (currently only the built-in connectors and actions are available). Managed connectors provide triggers and actions for accessing cloud services, on-premises systems, including Office 365, Azure Blob Storage, SQL Server, Dynamics 365, Salesforce, SharePoint, and more. Currently in this preview, the state of the workflow is saved to Azure Storage for failover recovery. We are exploring using Dapr’s state management building block to save the state of the workflow, meaning that you can take advantage of any of the supported Dapr component state stores and make your code more portable.

Give it a try!

We’d love for you to try out Dapr workflows. You can go to the Getting Started overview in the repo, give feedback by raising issues, and become a member of the Dapr community on the Dapr community Gitter channel. You can also join the community calls held every two weeks. We would greatly enjoy hearing about the applications that you build and where you see Dapr workflows being useful.

Dapr continues to evolve rapidly, integrating with developer frameworks such as ASP.NET, Spring Boot, and now Logic Apps. You will see more of these framework integrations that open up new capabilities and scenarios using the power of Dapr’s building blocks to enable you, the developer, to easily write apps that are portable, event-driven, and resilient.

Mark Fussell

Principal PM manager, Azure Incubations

See more articles from this author

Yaron Schneider

Principal Software Engineer, Azure Serverless

See more articles from this author