Conditions on the data
Without a condition, a Collection pushes everything it collects to every destination, and a Delivery’s “Forward Response” does the same with the response. A condition decides by content: only forward if the temperature goes above 80, only send the MES the notification SAP accepted, open a PM notification if the status is not OK and the machine is running.
A condition is written once, in the same editor, and serves three places:
| Where | What it decides | Looks at |
|---|---|---|
| Collection forwarding — Collectors › Forward Collection | Whether that destination receives the reading | The collected data |
| Delivery Forward Response — Definitions | Whether that destination receives the response | The destination’s response |
| Condition Met alert — Alerts | Whether the alert fires (e-mail, WhatsApp, ticket) | The collected data |
How it is written
A condition is one or more rules, combined with AND (all of them must hold) or OR (one is enough):
| Part | What it is |
|---|---|
| Data field | The path in the data, with dots: temperatura, tags.Status, RETURN.TYPE, linhas.0.valor. Empty = the whole content, for data that is not JSON. input.<name> reads an Input Parameter |
| Operator | See the table below |
| Value | Text, a number or a Variable: {{LIMITE_TEMP}} |
| Operator | Met when |
|---|---|
| equals, not equal to | The value read is (or is not) the value |
| greater than, greater than or equal to, less than, less than or equal to | Comparison — numeric, when both sides are numbers |
| between | The number read is between the two values, inclusive |
| contains, does not contain | The text contains the value, case-insensitive |
| is empty, is not empty | Missing field, empty text, empty list or object |
| changed | The value differs from the previous reading |
The button next to the field suggests paths in three groups: From the last message (with the value read), Input Parameters and From the Observed Contract — the fields of the real messages of that Collection or of the responses of that Delivery, see Observed Contract. You can type any other.
What to know about the comparison
- Numbers compare as numbers.
"100" > "80"is true, even with both as text in the JSON. A decimal comma works:80,5is eighty and a half. - A missing field is neither greater than nor equal to anything, but it is different from everything, and it counts as empty.
- Variables are per Application.
{{LIMITE_TEMP}}resolves to the Variable of the Collection’s (or Delivery’s) Application when there is one, and to the Global one otherwise. That is how each machine gets its own limit with a single rule. A Variable that does not exist does not become “limit zero”: the comparison fails. changeddoes not fire on the first reading — there is nothing to compare with. The last reading of each field is stored and survives a restart. Saving the Collection, the Delivery or the alert resets that memory.
Input Parameters — input.
A plain field reads the data: the Collection’s reading, or the Delivery’s response. To decide by
what the caller sent, use the input. prefix with the Input Parameter name: input.sendToMES equals true forwards to the MES only the calls that asked for it.
| Where | Where input.<name> comes from |
|---|---|
| Collection | The call’s Input Parameters — through the dynamic API, MCP, Trigger or Test Bench —, with the default value already applied |
| Delivery (Forward Response) | The Definition’s Input Payload, read from the received message |
- The parameter shows up right away. The Input Parameters group comes from the form’s rows: a parameter just added is already offered, before saving and before any message.
- The prefix tells the two apart. If the data also has a
sendToMESfield,sendToMESreads the data andinput.sendToMESreads the parameter. - A scheduled Collection has no parameters: nobody called it. There
input.<name>is a missing field — and, in a Collection without Input Parameters,input.xis still an ordinary path in the data. - Messages collected before this version did not keep their parameters: for them,
input.<name>is missing.
Test with the last message
The Test with the last message button, in the editor, evaluates the condition on the screen —
even before applying it — against the most recent real data: the Collection’s last reading, or the
Delivery’s last response. The result shows whether it matches and, rule by rule, the value read and
the expected one, plus the data. Nothing is stored. The button shows up once the Collection or the
Delivery has been saved; Test Bench messages are left out. That message’s Input Parameters are listed
among the fields, as input.<name>, with the value received.
Conditional forwarding
On each Forward Collection row (in the Collection) and Forward Response row (in the Delivery), the Rules button, at the start of the row, opens the editor. When there is a condition, it turns blue and shows how many rules it has; the summary appears in the tooltip.
- No condition: the destination receives everything — as it always did.
- Condition true: it forwards, with the forwarding’s Transformer as usual.
- Condition false: that destination does not receive it, and a trace of the reason is kept.
The condition looks at the raw data, before the Transformer: the rule talks about the reading, not about the destination’s format.
When no destination of the Collection matches, the message ends Processed — the rule decided, it is not an error. On the Delivery, the message has already finished when the destination answered; the condition only decides what goes on from there.
The trace. Forwardings not made show up on the source message, in the Forwardings not made
(condition not met) box: in the popup and on the message page, and in the
Test Bench result. Each line gives the destination and the reason —
✗ temperatura = "72" (esperado > "80").
A typical use on the Delivery: the BAPI returns RETURN.TYPE. With RETURN.TYPE equals S on the
forwarding to the MES, only the notification SAP accepted goes on; the rejected one keeps the reason
on the message.
Condition Met alert
In Alerts, the Condition Met type applies to a Collection and has, besides the usual recipients and channels:
| Field | What it does |
|---|---|
| Condition on the collected data | The same editor, over the collected data |
| Split by (data field) | A data field (e.g. equipamento). Each value fires and normalizes on its own — see below |
| Minimum duration (s) | Only fires if the condition stays true for that long — temperature above 80 for 5 minutes, not a one-reading spike |
| Alert message | The text, with {{dado.campo}}, {{coleta}}, {{aplicacao}}, {{chave}} and the Variables. Empty = the Collection and the rules with the values read |
No avalanche
An MQTT source publishing every second with a high temperature would open one notification per second. The alert fires on the crossing from false to true, and stays quiet while the condition keeps holding. When it stops holding, the Condition Normalized notice goes out, and the next crossing fires again.
The minimum duration is checked on each new reading: there is no clock of its own. A source that stops publishing does not complete the duration.
Split by
A Collection that brings several pieces of equipment — one row per furnace, every cycle — with a
single state would flip between “met” and “normalized” every cycle: furnace 2 above the limit and
furnace 1 below it would contradict each other. With Split by equipamento, each furnace has its
own state: it fires when it crosses the limit and normalizes when it comes back. The message
and the ticket carry the value — Condição atendida na Coleta “FORNO_01” (equipamento = forno-2).
Choose a field that identifies the monitored thing, not the reading: a message id or a timestamp would create one state per reading.
Ticket
The alert opens tickets in Help Desk destinations like any other, and the
destination’s body can use the data that fired it: {{dado.equipamento}}, {{dado.tags.Status}}.
That is what lets the PM notification be opened on the equipment that came in the reading.
Each crossing opens its own ticket — and, split by key, each piece of equipment its own. The “one ticket at a time” lock of the other alerts does not apply here: with it, furnace 2’s notification would wait for furnace 1’s.
What does not fire
- Test message (Test Bench): conditional forwarding is evaluated and shown, but the alert does not fire.
- Resending an old reading: resending does not open the notification again.
- Query-only Collector, which returns the result to the caller and does not forward.