Our latest service release comes with various changes:
Automatic creation of things
Stand-alone devices and gateway devices which use proper device certificates for authentication can auto-register as things, based on a template, which can be configured at the “Device via Bosch IoT Hub” connection.
Later, in combination with Bosch IoT Hub - the device connectivity layer of the Bosch IoT Suite - the automatic creation of a thing is done automatically, when the device connects for the first time.
The feature can easily be enabled and disabled via the Things UI and via HTTP API.
Consume incoming messages from managed Apache Kafka connections
For managed Apache Kafka connections, you can now configure “sources” in order to consume messages from Kafka topics.
You can use Apache Kafka for ingesting messages/events/operations into the Things service as well as emitting them from the Things service.
Currently consuming from Kafka is only supported with at-most-once semantics (QoS 0). We are working on to also support at-least-once semantics (QoS 1).
The “Device via Bosch IoT Hub” connection is subject to change from AMQP to Apache Kafka in the future. The migration will be prepared thoroughly and will be announced separately.
Enhanced policy expiration announcements with acknowledgements
To guarantee an “at-least-once delivery” semantic for policy expiration announcements we have extended the respective APIs.
A policy entry with expiring access for a specific subject now looks like in the following example.
The example shows a timely limited “guest” entry of a client, which authenticated with a JWT. The subject will be automatically deleted from the policy once the expiry timestamp is reached.
To give the subject a chance to prolong the access he can configure a connection to get announcements. Policy announcements are published to websockets and connections that have the relevant subject ID.
The settings under announcement control when a policy announcement is published (before expiry or when deleted). If the field requestedAcks is set, then the announcements are published with at-least-once delivery until the acknowledgement requests under labels are fulfilled.
If a beforeExpiry announcement was sent without acknowledgement requests, or the a beforeExpiry announcement was acknowledged, the “whenDeleted” announcement will not be triggered, even if it was set true in the policy.
The previous configuration to round up the timestamp for the expiry has also been changed, to avoid massive announcements for clients with JWTs, which are about to expire at nearly the same time.
At this occasion, various minor bugs have also been fixed.