Build workflow applications with Logic Apps

Learn how to build workflows applications using Dapr Workflows and Logic Apps runtime

Dapr Workflows is a lightweight host that allows developers to run cloud-native workflows locally, on-premises or any cloud environment using the Azure Logic Apps workflow engine and Dapr.

Benefits

By using a workflow engine, business logic can be defined in a declarative, no-code fashion so application code doesn’t need to change when a workflow changes. Dapr Workflows allows you to use workflows in a distributed application along with these added benefits:

• Run workflows anywhere: on your local machine, on-premises, on Kubernetes or in the cloud
• Built-in observability: tracing, metrics and mTLS through Dapr
• gRPC and HTTP endpoints for your workflows
• Kick off workflows based on Dapr bindings events
• Orchestrate complex workflows by calling back to Dapr to save state, publish a message and more

How it works

Dapr Workflows hosts a gRPC server that implements the Dapr Client API.

This allows users to start workflows using gRPC and HTTP endpoints through Dapr, or start a workflow asynchronously using Dapr bindings. Once a workflow request comes in, Dapr Workflows uses the Logic Apps SDK to execute the workflow.

Supported workflow features

Supported actions and triggers

• HTTP
• Schedule
• Request / Response

Supported control workflows

• All control workflows

Supported data manipulation

• All data operations

Not supported

• Managed connectors

Example

Dapr Workflows can be used as the orchestrator for many otherwise complex activities. For example, invoking an external endpoint, saving the data to a state store, publishing the result to a different app or invoking a binding can all be done by calling back into Dapr from the workflow itself.

This is due to the fact Dapr runs as a sidecar next to the workflow host just as if it was any other app.

Examine workflow2.json as an example of a workflow that does the following:

1. Calls into Azure Functions to get a JSON response
2. Saves the result to a Dapr state store
3. Sends the result to a Dapr binding
4. Returns the result to the caller

Since Dapr supports many pluggable state stores and bindings, the workflow becomes portable between different environments (cloud, edge or on-premises) without the user changing the code - because there is no code involved.

Get started

Prerequisites:

1. Install the Dapr CLI
2. Azure blob storage account

Self-hosted

1. Make sure you have the Dapr runtime initialized:

   dapr init

2. Set up the environment variables containing the Azure Storage Account credentials:

   • Windows
   • macOS/Linux

```
export STORAGE_ACCOUNT_KEY=<YOUR-STORAGE-ACCOUNT-KEY>
export STORAGE_ACCOUNT_NAME=<YOUR-STORAGE-ACCOUNT-NAME>
```
```
set STORAGE_ACCOUNT_KEY=<YOUR-STORAGE-ACCOUNT-KEY>
set STORAGE_ACCOUNT_NAME=<YOUR-STORAGE-ACCOUNT-NAME>
```

1. Move to the workflows directory and run the sample runtime:

   cd src/Dapr.Workflows
   dapr run --app-id workflows --protocol grpc --port 3500 --app-port    50003 -- dotnet run --workflows-path ../../samples

2. Invoke a workflow:

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

Kubernetes

1. Make sure you have a running Kubernetes cluster and kubectl in your path.

2. Once you have the Dapr CLI installed, run:

   dapr init --kubernetes

3. Wait until the Dapr pods have the status Running.

4. Create a Config Map for the workflow:

   kubectl create configmap workflows --from-file ./samples/workflow1.json

5. Create a secret containing the Azure Storage Account credentials. Replace the account name and key values below with the actual credentials:

   kubectl create secret generic dapr-workflows    --from-literal=accountName=<YOUR-STORAGE-ACCOUNT-NAME>    --from-literal=accountKey=<YOUR-STORAGE-ACCOUNT-KEY>

6. Deploy Dapr Worfklows:

   kubectl apply -f deploy/deploy.yaml

7. Create a port-forward to the dapr workflows container:

   kubectl port-forward deploy/dapr-workflows-host 3500:3500

8. Invoke logic apps through Dapr:

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

Invoking workflows using Dapr bindings

1. First, create any Dapr binding of your choice. See this How-To tutorial.

   In order for Dapr Workflows to be able to start a workflow from a Dapr binding event, simply name the binding with the name of the workflow you want it to trigger.

   Here’s an example of a Kafka binding that will trigger a workflow named workflow1:

   apiVersion: dapr.io/v1alpha1
   kind: Component
   metadata:
     name: workflow1
   spec:
     type: bindings.kafka
     metadata:
     - name: topics
       value: topic1
     - name: brokers
       value: localhost:9092
     - name: consumerGroup
       value: group1
     - name: authRequired
       value: "false"

2. Next, apply the Dapr component:

   • Self-hosted
   • Kubernetes

Place the binding yaml file above in a `components` directory at the root of your application.
```
kubectl apply -f my_binding.yaml
```

1. Once an event is sent to the bindings component, check the logs Dapr Workflows to see the output.

   • Self-hosted
   • Kubernetes

In standalone mode, the output will be printed to the local terminal.
On Kubernetes, run the following command:
```
kubectl logs -l app=dapr-workflows-host -c host
```

Example

Watch an example from the Dapr community call:

Additional resources

• Blog announcement
• Repo

Last modified June 23, 2022: Merge pull request #2550 from ItalyPaleAle/cosmosdb-harcoded-dapr-version (cf03237)