Build workflows with Logic Apps

    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.

    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 control workflows

    Not supported

    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 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.

    1. Install the Dapr CLI

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

    2. export STORAGE_ACCOUNT_KEY=<YOUR-STORAGE-ACCOUNT-KEY>
    3. export STORAGE_ACCOUNT_NAME=<YOUR-STORAGE-ACCOUNT-NAME>
    4. ```
    7. ```
    8. set STORAGE_ACCOUNT_KEY=<YOUR-STORAGE-ACCOUNT-KEY>
    9. set STORAGE_ACCOUNT_NAME=<YOUR-STORAGE-ACCOUNT-NAME>
    10. ```

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

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

    2. Invoke a workflow:

      1. curl http://localhost:3500/v1.0/invoke/workflows/method/workflow1

    Kubernetes

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

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

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

    4. Create a Config Map for the workflow:

      1. 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:

      1. kubectl create secret generic dapr-workflows    --from-literal=accountName=<YOUR-STORAGE-ACCOUNT-NAME>    --from-literal=accountKey=<YOUR-STORAGE-ACCOUNT-KEY>
      1. kubectl apply -f deploy/deploy.yaml

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

    Invoking workflows using Dapr bindings

    1. First, create any Dapr binding of your choice. See 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:

      1. apiVersion: dapr.io/v1alpha1
      2. kind: Component
      3. metadata:
      4.   name: workflow1
      5. spec:
      7.   metadata:
      8.   - name: topics
      9.     value: topic1
      10.   - name: brokers
      11.     value: localhost:9092
      12.   - name: consumerGroup
      13.     value: group1
      14.   - name: authRequired
      15.     value: "false"

    2. Next, apply the Dapr component:

    1. Place the binding yaml file above in a `components` directory at the root of your application.
    4. ```
    5. 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.

    Watch an example from the Dapr community call:

    Additional resources