Edit

Route readings by severity

Send high-severity readings through an alert path, then merge them with normal readings. This example first drops readings with temperature > 1000. It adds alert: true when severity > 5 and renames fields on both paths.

Prerequisites

This standalone example uses the existing default MQTT endpoint, the default profile and registry endpoint, telemetry/sensors as input, and telemetry/processed as output. For deployment prerequisites, Bicep parent resources, and Azure CLI environment variables (AIO_INSTANCE_NAME and RESOURCE_GROUP), see Create a data flow graph.

The Azure CLI examples in this article use environment variables so that you can set each value once and then copy and paste the commands as-is. If you're using the Azure IoT Operations Codespaces environment from the quickstart, these variables are already set for you and you can skip this step. Otherwise, set the following environment variables in your shell before you run the commands.

The following scripts set the most commonly used environment variables:

Environment variable Description
SUBSCRIPTION_ID The ID of the subscription that contains your Azure IoT Operations instance.
RESOURCE_GROUP The name of the resource group that contains your Azure IoT Operations instance.
AIO_INSTANCE_NAME The name of your Azure IoT Operations instance. To list your instances, run az iot ops list -o table.
CLUSTER_NAME The name of the Azure Arc-enabled Kubernetes cluster that hosts your instance.
LOCATION The Azure region to use for new resources, for example eastus.
SUBSCRIPTION_ID=<subscription-id>
RESOURCE_GROUP=<resource-group-name>
AIO_INSTANCE_NAME=<instance-name>
CLUSTER_NAME=<cluster-name>
LOCATION=<region>

You only need to set the variables that this article uses. This article might use additional environment variables for resource names that you choose. The article explains how to set them where they're introduced.

The example assumes numeric temperature and severity fields and a deviceId; it doesn't perform schema validation.

Configure the severity routes

Diagram showing a filter dropping temperatures above 1000, a branch sending severity above 5 to an alert map and other readings to a normal map, and concatenate forwarding both paths to telemetry/processed.

Concatenate forwards each processed message independently; it doesn't join records or guarantee ordering across paths. The example renames fields but doesn't convert temperature units.

Synthetic input on telemetry/sensors Output on telemetry/processed
{"deviceId":"sensor-01","temperature":20,"severity":2} {"id":"sensor-01","temp":20}
{"deviceId":"sensor-01","temperature":20,"severity":8} {"id":"sensor-01","temp":20,"alert":true}
{"deviceId":"sensor-01","temperature":1001,"severity":8} Dropped

Screenshot of the operations experience canvas showing a filter, branch, map, concat, and destination pipeline.

To build this pipeline in the operations experience:

  1. Create a data flow graph and add a source that reads from telemetry/sensors.
  2. Add a filter transform. Configure a rule that drops messages where temperature > 1000.
  3. Add a branch transform. Configure the condition severity > 5 to route high-severity messages to the true path.
  4. Add a map transform on the true path. Configure rules to rename deviceId to id, temperature to temp, and add a field alert set to true.
  5. Add a map transform on the false path. Configure rules to rename deviceId to id and temperature to temp.
  6. Add a concatenate transform to merge both paths.
  7. Add a destination that sends to telemetry/processed.
  8. Connect the elements: source → filter → branch → (true path: alert map, false path: normal map) → concatenate → destination.