This offer is only addressed to commercial customers including freelancers and entrepreneurs. All prices are exclusive of value added tax (VAT).
  • Share via email
  • Subscribe to blog alert

Bosch IoT Manager: listing “flat” mass management executions and other service improvements

The new release of Bosch IoT Manager, part of Bosch IoT Device Management, comes with the following improvements:

Listing “flat” mass management executions

With this new functionality, Bosch IoT Manager is now able to return a list of flat executions, in other words device executions from all tasks and rules in the system. This list can be filtered globally, among all executions in the system.

An execution is considered to be a single run of a mass management task over one device. This means that a task which has a scope of 100 devices will produce 100 executions. Since every trigger of a rule launches a new task, there might be many tasks launched out of a single rule, each of which producing executions. Hence, a device might have only one execution in a task, but many executions in a rule. Generally, only the latest device execution within a rule is of monitoring interest, as it overrides the previous executions of the same action script and defines the device rule execution status. However, in specific cases, older device executions within a rule may also be of interest.

There are two main use cases when listing executions:

(i) 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 executions 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.

(ii) considering all executions, even those overridden by next rule execution over the same device
This is referred to as “historical” data and can be turned on with the corresponding flag.
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.

See the corresponding methods in our Java and REST APIs respectively:

  • listExecutions 
  • GET /mme/tasks/executions

At this occasion, various minor bugs have also been fixed.