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.
In combination with Bosch IoT Hub – the device connectivity layer of 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 Bosch IoT Things UI and via HTTP API.
See Concepts > Connections > Automatically create things when a new device is registered.
Examples: See Bosch IoT Device Management documentation
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 Bosch IoT Things service as well as emitting them from the Bosch IoT 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.
{
"subjects": {
"integration:<iot-things-solution-id>:<jwt-client-id>": {
"type": "my-custom-connection",
"expiry": "2021-08-01T12:00:00Z",
"announcement": {
"beforeExpiry": "1d",
"whenDeleted": false,
"requestedAcks": {
"labels": ["my-connection-id:my-issued-acknowledgement"],
"timeout": "5s"}
}
}
},
"resources": {
"thing:/": {
"grant": [
"READ"
],
"revoke": []
}
}
}
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.