Skip to content
View as markdown Ask ChatGPT Ask Claude

Zones#

Many Data Generator Tasks emit data known as a zone, a context-based data structure that groups together every value produced by one specific occurrence of a workflow trigger. Connect IoT workflows run asynchronously: each task's own execution is synchronous, but there is no guarantee about the timing between one task and the next, particularly under high message volume. Without a way to tell which outputs belong to the same occurrence, a task that consumes several inputs together, for example a Log Message task logging two related properties, could combine values produced by different, unrelated occurrences: some already up to date, some not produced yet, and some left over from an occurrence that took longer to process than a more recent one. A zone solves this by tagging every value produced from the same occurrence with the same execution context, so a task consuming multiple correlated values only ever reads values that genuinely belong together.

A zone is created automatically whenever one of the tasks listed under Tasks that Emit Zones fires, and every value produced from that point onward, by that task and by whatever it triggers, carries the occurrence's execution context. A few non-trigger tasks can also start a new zone explicitly through an Emit in new context setting, for example the Retrieve Data task when it reacts to a value stored from outside its own trigger chain. When no zone applies, values run in the root context and are not correlated with one another.

Zones and Control Flow#

Note

You do not need to manage zones when working within Control Flow.

Control Flow is deterministic: every occurrence of a trigger runs its own branch, a private set of task instances created specifically for that occurrence, executed from a Start task through to an End task, and discarded once it finishes. Because no two occurrences ever share the same task instances, there is nothing for a zone to correlate; each branch's data is already isolated by construction, so Control Flow authors never need to configure or reference a zone directly.

Data Flow works differently: the tasks placed on the canvas are instantiated once, when the workflow starts, and that same set of task instances stays in place and keeps receiving and processing events for as long as the workflow runs. Because those instances are shared across every occurrence, when the time each task takes to execute varies, for example under high message volume, or when one branch of the flow is slower than another, values produced by different occurrences can reach a shared task out of step with one another. Zones exist to solve exactly this: by tagging every value with the execution context of the occurrence that produced it, a Data Flow task consuming several inputs can tell which of them actually belong together.

Example#

Consider a workflow with an Equipment Event task listening for a piece of equipment that reports both a Temperature and a Humidity property together, feeding a Log Message task that logs both values. The Log Message task is instantiated once and is shared by every occurrence of the event.

Each event occurrence gets its own zone, so the Temperature and Humidity values read by the shared Log Message task are always the pair produced by that same occurrence, even if the equipment raises two occurrences close together, or one property takes longer to reach Log Message than the other. Without this correlation, a second occurrence arriving quickly could overwrite Temperature before Humidity from the first occurrence has been processed, and Log Message could end up logging a Temperature/Humidity pair that never actually occurred together.

Tasks that Emit Zones#

Core Tasks#

Equipment#

File Drivers Tasks#

OIB Tasks#

SECS/GEM Tasks#