Flat execution monitoring
In the previous sections we viewed the monitoring possibilities of the mass device management process from different perspectives and on different levels of granularity, namely rule, task, device, and partial execution of the management action script. The mass management layer (Bosch IoT Manager) provides also a possibility to monitor bulk executions from across all tasks and rules in the system, also called monitoring of 'flat' executions.
With flat execution monitoring you are able to:
list executions in bulk throughout the system at once
In other words, you can see an aggregated list of executions which took place in the context of various tasks and rules, and on various devices.
For comparison, with the monitoring perspectives described in the previous sections, this is possible only within the context of a particular rule, or of a particular task, or for a particular device.apply various sorting and filtering criteria on these executions depending on your use case.
For example, you may list all executions which finished with an error in all tasks and rules in the system in a given time frame. You can further filter the results to check this for devices x, y, and z.
With that, your point of interest is the execution, rather than the device, task, or rule.
The corresponding methods for flat execution monitoring in our Java and REST APIs, respectively are:
listExecutions
GET/mme/tasks/executions
When calling these methods, you always get a list of device task executions, however, from different origins (tasks and rules) and for different devices, depending on your filter.
Current vs historical data
There are two main use cases when listing flat executions, fulfilled by setting the loadHistoricalData flag:
current data - considering only the latest device executions within a rule
This is referred to as non-historical data, as only the latest execution statuses are reported.
This might be useful if you want to see all actual execution states across all the rules and tasks in the system, or when you need to filter device executions according to their error status, unfinished executions, etc.historical data - considering all executions, even those overridden by next rule execution over the same device
This is referred to as historical data.
This might be necessary when the list is filtered by a given task ID, which might not be the latest task launched by a rule. Thus some executions launched out of this task will not correspond to the real device execution state within the target rule.
In other words, this is useful when you are inspecting explicitly some potentially outdated and 'overridden' executions.