Thea latest service update of Bosch IoT Things comes with various changes
Expiring policy with announcements
Bosch IoT Things introduces a new type of notification for scenarios, where a policy contains a subject with temporally limited access to a thing, and the access will expire.
This way, an application has the possibility to react and might extend the access for a longer time period.
The request of a subject authenticated with a JSON Web Token (JWT) which was deleted from the policy (due to expiration) will be rejected with status code 401. The Bosch IoT Things service doesn’t have the possibility to restore an expired subject entry.
An announcement would look like the following snippet.
{
"topic": "your.namespace/the_policy_id/policies/announcements/subjectDeletion",
"headers": {
"correlation-id": "xxx",
"content-type": "application/json"
},
"path": "/",
"value": {
"deleteAt": "2021-05-01T16:05:55Z",
"subjectIds": [
"integration:your-service-instance-id:your-client-1",
"integration:your-service-instance-id:your-client-2"
]
}
}
How to use it
Find an example at Optional time limit in policy.
Merge functionality for things resources
The Things service supports a new way to update existing things, namely via merge request (with patch semantics).
This allows to simultaneously create, update and delete various parts to the thing’s attributes and features with just one request, and without the need to mention all the parts of the thing which don’t need to change.
For example, it is now possible to update multiple properties of different features in a single request while not touching unchanged properties. Or you may add or update an attribute and a feature property in the same request without overwriting the complete thing.
Concerning the permissions required to execute a merge command, the authorized subject needs to have WRITE permission at all resources that are changed by the merge.
Consequently, if the permissions is missing for some part of the merge, the merge is rejected and not applied at all.
HTTP API
The things resource and all of its sub-resources allow to merge an existing thing with the thing provided in the request payload by using the newly introduced HTTP PATCH method. Those parts that are not affected by the merge are not changed.
The request payload of such a merge update has to be provided in JSON merge patch format. In short, a JSON merge patch resembles the original JSON structure of a thing and the fields provided in the patch are added to or updated in the existing thing.
Please note however, that null values have a special meaning when applying a merge patch. A null value indicates the removal of existing fields in the updated thing. For more details and examples please refer to RFC-7396.
Please also refer to the API documentation of the new PATCH method for more information.
Example: to apply a merge at the things root resource, see PATCH /things/{thingId}.
Ditto protocol
Devices can report their changed values via merge or modify commands.
- merge: The new value provided in JSON merge patch (RFC 7396) format will be merged with the existing thing.
In case the path does not match to the existing thing, the sub-structures will be added.
Notice that the null value in the JSON body will delete the specified JSON key from the thing. For further documentation of JSON merge patch see RFC 7396. - modify: The new value provided in JSON will update the existing thing.
In case the path does not match to the existing thing, you will get an error.
In case your application needs to react on changes of a thing, please note that since introducing merge commands additionally to modify, your application should be able to react on “events/merged” and “events/modified” likewise.
Support the service plans of Bosch IoT Suite for Device Management
As already announced in November 2020 a new package named Bosch IoT Suite for Device Management is available.
The Bosch IoT Thing as part of the package supports the new Device Management package service plans.
Find details at Pricing & Conditions for Bosch IoT Things.
Fixed misleading content type header inside Ditto Protocol JSON
Previously, Ditto Protocol JSON messages with a “content-type” field in the “headers” section did not always correctly reference to the content type of the “value” contained in the Ditto Protocol message, but did always include application/vnd.eclipse.ditto+json
. This is wrong, as the content type “application/vnd.eclipse.ditto+json
” describes the content type of the complete Ditto Protocol JSON message instead.
With this bugfix, we ensure that the Ditto Protocol message provides in the header the “content-type” which now reflects the content type of the “value”.
At this occasion, various minor bugs have also been fixed.