Connections between models

You can connect multiple models together using output blocks and input blocks. A model that contains an output block such as Output Measurement (for Measurement objects of Cumulocity IoT) will generate a series of events, and this can be consumed by a suitable input block (such as Device Measurement Input) in another model.

Input and output blocks identify a series of events by specifying a key for the series of events. This key can be made up of multiple block parameters, and identifies that series of events distinct from other series of events through the same block type. For example:

For Measurement object input and outputs, the key would be the device, the fragment, the series, and the measurement type. The Unit parameter specified in an output block is not considered part of the key (it is for information only) and is not required to match the parameters of the measurement input block.

When one model has an output block generating a series of events for a given key and a second model has an input block consuming from that same series of events (that is, with the same key parameters), then this forms a connection from the first model to the second. When the first model triggers the output block, this causes the second model to be evaluated with a new input on its input block.

Similar to the processing order of wires within a model (see also Processing order of wires), the following applies when an output block in one model generates a series of events that an input block in another model consumes:

A single model can send the same events to more than one other model. This means, it is possible to have a single model perform some common pre-processing, such as unit conversion or calculating an average (with the Average (Mean) block), and that value to be used by multiple other models.

Models are executed in order with respect to the connections between models so that the source of a connection is always evaluated before the target of a connection. If a model has connections from multiple blocks all triggered from the same initial event, then they will all evaluate first, and the receiving model will evaluate with all of the inputs once.

Similar to the wire restrictions within a model (see also Wire restrictions), there are restrictions on how output blocks and input blocks can be used to connect models together:

No cycles can be created between models. A model that receives events via an input block from another model cannot include an output block that generates events that the other model would consume. This applies even if one of the models contains two separate parts, such that there is no actual cycle in terms of wires and connections between models.

Any model that does not meet these restrictions when used in combination with the already activated models will cause an error on trying to activate it. This will count for the last element in a cycle of models. For such errors, the problem may be in interactions between models rather than a problem specific to a single model, but existing models that have already been activated will not automatically be deactivated. For example, if multiple models all generate the same series of events (with the same key), then the first model to be activated can be deployed, but all subsequent models will report an error upon trying to activate them.

For example, there are three models: Model1, Model2, and Model3. A cycle may exist if:

An output block of Model1 produces a series of events that is consumed by an input block in Model2, and Model2 contains an output block that generates a second series of events, and

Model3 contains an input block that consumes a series of events from Model2, and Model3 also contains an output block that generates a series of events used by an input block in Model1.

Note that only activating any two of these models can be done without error. If activated in order, only Model3 would have an error. But if Model1 or Model2 were deactivated, then Model3 could be activated. The error will occur even if one of the models does not contain a link from the input block that is part of the chain to the output block that forms part of the chain, such as the example for Model3 below: the events from Model2 do not form a cycle to the To Model1 Measurement output block, but they count as a cycle as they are both in the same model. (In this case, the issue could be resolved by splitting that model into two models, thus removing the cycle).