Callback mechanics
This page details how a Callback actually behaves once it carries a condition, a transformation, or several Outputs.
Conditions and transformations
It is possible to specify a condition for triggering an Output so it is only triggered if the condition is fulfilled. It is also possible to specify a transformation to apply to the Value before it is forwarded to the Output.
Warning
Transformation are only executed if the corresponding condition is fulfilled (return true).
Conditions and Transformation are expressed using the
Expression language. These expressions have access to the variables value,
error and mode containing the content, error and mode of the Value
bound to the Callback, and they can also access any
Values present in the OnSphere
configuration hierarchy.
Note
Values must be declared in accessedValues to be used inside a condition.
Tip
accessedValues field supports wildcards. root.*.test will match for example root.device.1.test, root.server.test.
The wildcard can also be used on root.serial1020*.test to match for example serials.
Output retries
If an output fails, the action is retried based on the retry configuration. By default, there are 3 retries, each separated by 10 seconds. Each linkedOutputs can override the retry configuration defined in callback.ospp.
Each output processes the triggers of its value one after the other: a new trigger waits until the previous execution of this output is finished, including its retries. The other outputs of the same value do not wait for it and process their own triggers.
When a new trigger arrives while a retry is pending, the behavior depends on the retention of the Value:
STEADY: the pending retry is cancelled, since the new value replaces the previous state. The new trigger is executed at the end of the current retry delay.FIRE_AND_FORGET: each trigger is an event of its own, so the retries are kept. The new trigger is executed once the previous one has succeeded or has used all its retries.
