Skip to main content
A Devset workflow is a single JSON document that describes everything needed to drive an event-driven test scenario: which broker to target, how many times to run, what state to track, and the ordered sequence of stages that produce messages. You author workflows by hand or generate them from templates, then hand them to the Devset engine or Playground to execute.

​
Full Example

The following workflow publishes fifty order-created events to a Kafka topic, accumulating a running total and message count in shared state between each execution. 
{
  "id": "order-flow",
  "messageType": "kafka",
  "contentType": "application/json",
  "producerName": "local-kafka",
  "topic": "orders.events",
  "schemaId": "order-created",
  "executions": 50,
  "state": {
    "order": { "total": 0, "count": 0 }
  },
  "pipeline": [
    {
      "stage": "order-created",
      "event": "order-created",
      "emit": true,
      "set": {
        "id": { "$fn": "uuid()" },
        "amount": { "$fn": "int(10, 500)" },
        "status": "PENDING"
      },
      "state": {
        "order.total": { "$fn": "add(state.order.total, .amount)" },
        "order.count": { "$fn": "add(state.order.count, 1)" }
      }
    }
  ]
}

​
Top-Level Fields

​
id
string
required
A unique identifier for this workflow. Used in logs, metrics, and the Playground UI to distinguish one workflow from another. Keep it short and descriptive — for example "order-flow" or "user-signup-v2".
​
messageType
"kafka" | "rabbit"
default:"\"kafka\""
The broker type this workflow targets. Set to "kafka" for Apache Kafka and "rabbit" for RabbitMQ. This controls which routing fields are relevant (topic for Kafka; exchange and routingKey for RabbitMQ).
​
contentType
"application/json" | "application/x-protobuf"
default:"\"application/json\""
The payload encoding format. Use "application/json" for human-readable JSON payloads. Use "application/x-protobuf" for binary Protobuf payloads — when using Protobuf you will also need to configure the wireFormat block on each stage.
​
producerName
string
required
The name of a configured broker connector to use when dispatching messages. This must match a connector you have registered in your Devset environment.
​
topic
string
The Kafka topic to publish messages to. Required when messageType is "kafka". You can override this per-stage if your workflow publishes to multiple topics.
​
exchange
string
The RabbitMQ exchange to publish messages to. Used only when messageType is "rabbit".
​
routingKey
string
The RabbitMQ routing key attached to every outbound message. Used only when messageType is "rabbit".
​
schemaId
string
The default schema identifier applied to every stage in the pipeline. Individual stages can override this with their own schemaId field. The schema ID is used for payload validation and, when using Protobuf, for resolving the type descriptor.
​
executions
integer
default:"1"
The number of times Devset runs the entire pipeline from start to finish. Setting this to 50 causes every stage in the pipeline to execute fifty times in order, with workflow state persisting and accumulating across all executions. See Execution Model below for details.
​
state
object
default:"{}"
The initial mutable state object shared across all stages and all executions. Declare your starting values here — for example counters, accumulators, or lookup results. Stages mutate state via their own state block using DSL functions.
​
pipeline
Stage[]
required
An ordered array of Stage objects. Devset executes stages in the order they appear, passing context from one stage to the next. At least one stage is required.

​
Execution Model

When you set executions to a value greater than 1, Devset runs the entire pipeline array that many times in sequence. Think of one execution as a single “scenario run” — for example, one full order lifecycle. State declared at the top level persists across executions. This means you can accumulate totals, counts, or other cross-run statistics. In the example above, order.total and order.count grow with every execution because each stage’s state block adds to the running values rather than replacing them. 
{
  "executions": 10,
  "state": {
    "sentCount": 0
  },
  "pipeline": [
    {
      "stage": "ping",
      "emit": true,
      "set": { "msg": "hello" },
      "state": {
        "sentCount": { "$fn": "add(state.sentCount, 1)" }
      }
    }
  ]
}
After all ten executions complete, state.sentCount equals 10.
State is reset to its initial values only when you start a new workflow run. Within a single run, all executions share and mutate the same state object.

​
Kafka vs RabbitMQ

The top-level routing fields differ depending on your messageType. Kafka workflows use topic to identify the destination: 
{
  "id": "kafka-example",
  "messageType": "kafka",
  "topic": "orders.events"
}
RabbitMQ workflows use exchange and routingKey instead: 
{
  "id": "rabbit-example",
  "messageType": "rabbit",
  "exchange": "orders.exchange",
  "routingKey": "order.created"
}
You can omit exchange if you are publishing to the RabbitMQ default exchange, and rely purely on routingKey for routing.
  • Stage Fields — full reference for every field a pipeline stage supports, including set, state, repeat, and query.
  • Functions — complete catalog of built-in $fn expressions you can use in stage field values.
  • Wire Format — Protobuf binary framing configuration for Confluent Schema Registry compatibility.