The new release of Bosch IoT Manager comes with the following improvements:
Introduced improvements in gRPC which will allow easier API changes, in particular adding and removing methods
Thanks to these changes, Bosch IoT Manager's gRPC support will now allow adding and removing of methods without breaking compatibility with older clients. In order to complete this transition, support for older gRPC clients will be dropped soon.
Old libraries will be deprecated at the end of May, therefore from June 1st onward, all customers should switch to the new gRPC client to prevent possible compatibility issues.
Added support for desired property/state in the Device Inventory API and via Groovy script
Bosch IoT Manager now supports desired properties, and respectively desired state, provided by Bosch IoT Things. Whereas with properties values are reported by the device, with desired properties you can remotely trigger the device integration layer to change the device configuration, even if the device is currently offline. Now you can get, set and delete them through the Device Inventory API methods, as well as via Groovy script as part of mass management operations.
For the time being, desired properties are persisted and used for filtering, however, no further processing is provided.
Extended the Device Inventory API with acknowledgement requirement
It is now possible to require an acknowledgement for the successful processing of your requests made via the Device Inventory API. This acknowledgement provides a QoS guarantee of "at least once" and is useful for operations/messages processing and tracking the successful delivery of an event you are listening for. For example, you may want to know if the command you sent has successfully updated the digital twin of your device. To find out more about the different types of acknowledgements, check the dedicated Acknowledgements page.
See the Bosch IoT Manager javadoc for further information.
Added confirmation of event consumption
As part of the activities dedicated to enhancement of the processing of event rule triggers, now events are acknowledged after they have been processed and thanks to that, in case of any failure in the processing, they can be retried.
Added blacklisting for services that are adding or executing malicious scripts
Blacklisted service instances will not be able to create new tasks and rules. Such blacklisting of a service will also stop the execution of any ongoing rules started by the respective service, for example rules with timer-based or event-based triggers.