Archive - release notes 2021
December 22, 2021 - Bosch IoT Things - service update
Our latest service release comes with the following new feature:
Live channel condition
With the latest release Bosch IoT Things supports you to automatically switch between twin and live channel when retrieving device data via API.
By using the new live-channel-condition
together with the use-twin
strategy,
in conjunction with the new response headers, your application can
transparently benefit from both channels with just one request. In case the
device cannot answer in time, your application will still retrieve a response
with the required value, and the response headers make it easy to find out who
responded: the live device or its digital twin.
This channel switch is supported via HTTP API, WebSocket, and Ditto protocol over all types of managed connection. With the upcoming Ditto release 2.3 the feature will also be supported via Ditto Java Client.
The conditions can be defined using RQL expressions. See details at HTTP API - Search resources for all Relational operators and Logical operators.
The following schematic overview illustrates the overall communication flow:
Example 1
Use the live-channel-condition
to retrieve data from the device itself, if a
specific attribute has a defined value.
GET .../things/{thingId}?live-channel-condition=eq(attributes/useLiveChannel,true)
If the condition matches, the retrieve command is forwarded to the device as live command defined as Ditto Protocol message, and the device can answer to that by creating a correlated response.
If the condition doesn’t match (e.g. the attribute does not exist or has another value), the service will provide the response data from the digital twin persisted in Bosch IoT Things.
Example 2
Use the ConnectionStatus
feature in the condition. If the device is
currently ready to receive messages, request live data, otherwise request twin
data.
GET .../things/{thingId}?live-channel-condition=gt(features/ConnectionStatus/properties/status/readyUntil,time:now)
New request header
You can additionally make use of the new header live-channel-timeout-strategy
.
The header value holds a strategy what to do in case a timeout (can also be
specified as header) was encountered.
- If the value cannot be retrieved live from the device itself during the
specified timeout, the request will
fail
(which is the default strategy if not specified otherwise) with a status code 408. - Alternatively, if you define
use-twin
as thelive-channel-timeout-strategy
strategy, the request will fall back to the persisted twin and return the latest value stored in the digital twin.
New response headers
The response includes two additional headers to indicate which channel was used to retrieve the thing data:
live-channel-condition-matched
– value could betrue
orfalse
and states whether the passed live-channel-condition was a match or notchannel
– value could betwin
orlive
and defines which channel was the origin of the returned data.
Twin update from live data
In line with the procedure described above on how to retrieve live data directly from your device, we have introduced a new type of pre-configured payload mapping, namely UpdateTwinWithLiveResponse.
Upon activation, the digital twin stored in Bosch IoT Things will implicitly be updated with the latest data from the live response sent by the device.
Tip: You can easily activate this mapper using the Connections UI. Select “Devices via Bosch IoT Hub” > Edit > “Payload mapping” > checkbox “Enable updating twins based on received live retrieve command responses”.
The new functionality is based on new features of our open source base Eclipse
Ditto.
Further details are described here:
- Basic concepts - Live channel condition
- Payload mapping
- Blog article for live channel conditions
- Blog article for HTTP live channel support
At this occasion, various minor bugs have also been fixed.
November 22, 2021 - Bosch IoT Things - service update
Our latest service release comes with various changes:
Trigger the de-provisioning with a live message
In some custom scenarios, the Device Provisioning API can not be requested directly to delete a thing, its policy, device and device credentials.
However, you can achieve the same result with a live message that is subscribed by a managed connection, which is empowered to request de-provisioning.
With the new service update, the Connections UI offers a new template for creating and configuring the connection.
Find a detailed description of all steps involved in such a procedure in our new how-to section: De-provisioning via Device Provisioning API.
Connection log publishing
Managed connections help you to integrate your custom applications with the digital twin service layer of Bosch IoT Device Management.
For development stages, you can activate logging via the Connections UI, however, this feature will only be active for one hour.
For production scenarios, a continuous logging might be necessary, however, as of now we don’t provide self-service for subscriptions to establish such forwarding of logs.
Customers of standard plans with a silver or gold support plan, who need to store the log files of their connections in a custom data store, can contact us via support channel to get such a forwarding of the log files.
Find details in our FAQ section Configure log forwarding.
At this occasion, various minor bugs have also been fixed.
November 4, 2021 - Bosch IoT Things - service update
Our latest service release comes with various changes:
New filter for lifecycle events
In case your business application needs to receive lifecycle events (e.g. thing created, thing deleted) you can activate a filter in your managed connections (and WebSockets) to get only those events forwarded automatically by Bosch IoT Things.
Of course, you can still be notified about ALL thing updates, if you don’t apply any restrictions.
New support of RQL-based filter for live messages
This new features helps to filter live messages based on information in the digital twin, and thus also helps to reduce traffic. Using the RQL filter, it is now also possible to subscribe only for specific message subjects, which allows a more fine-grained control of which subscriber handles which messages.
The RQL filter is applied to the “enriched” information pulled from the persistent digital twin.
The easiest way to configure such a RQL filter for live message targets is the Connections UI. Of course, the HTTP API has been enhanced accordingly.
Search index changes
The Namespace UI offers the possibility to re-configure the set of fields, which need to be indexed for search. With this service update we will activate the pricing model for search-updates and re-indexing. The same is valid if you request the respective HTTP API resources.
You can now decide to index a smaller set of thing attributes or feature properties, if your business application will not search for some fields, and thus save traffic and costs on both sides of the service.
Note: While updating the search index, your search results may be incorrect. Please wait some time before your next search. The costs will be charged in conformance with our pricing model.
Hub-to-Things connection changes
We are happy to announce that with this latest update we can soon offer Apache Kafka based connections between the device connectivity layer (Bosch IoT Hub) and the digital twin layer (Bosch IoT Things) of the Device Management service.
- All new connections which will be created automatically after November 3th, 2021 (all new subscriptions) will use Kafka.
- For the migration of the standard plans of all customers, we will proceed as announced via Email.
“We are going to perform these changes without any downtime and no activities to be done on the customer side.”
Migration activities on the production system are scheduled to start November, 15th, 2021.
Further changes
- For using the Bosch IoT Thing HTTP API documentation, the authorization options “Bosch-ID” as well as “API-Key” have been removed.
The API Token was deprecated since June 2020, now it’s time to delete it.
The Bosch-ID authorization itself will be available for other resources.
We recommend to use the Suite OAuth approach. - Throttling in connection metrics
The Connections UI, in particular the Metrics tab, now visualizes occurrences when an AMQP or Kafka-based connection cannot keep up with the actual message rate.
The number represents the amount of minute-intervals where the consumption was close to the limit, or was exceeding the expected number of messages per client.
This helps identifying situations, where messages queue up and in the worst case may be dropped.
Such warnings indicate that it might be necessary to scale out the connection by increasing the number of used clients.
At this occasion, various minor bugs have also been fixed.
September 29, 2021 - Bosch IoT Things - service update
Our latest service release comes with various changes:
Conditional requests on things
Bosch IoT Things supports modifying, deleting, and retrieving things based on specific conditions of the current thing state.
Conditions are based on RQL expressions and define that a request should be applied to a thing only if the condition is true. All fields of the thing can be used to define the condition.
- If the condition specified in the request is fulfilled, the thing will be updated and an event will be emitted.
- If the condition specified in the request is not fulfilled, the thing is not modified, and no event/change notification is emitted.
Conditional requests are supported via HTTP API, Ditto protocol and Ditto Java Client.
Examples: See concepts > conditional requests.
Event enrichment
Bosch IoT Things supports now to enrich even “deleted events” with data, which was available before deletion. The existing enrichment functionality (“extraFields” for connections, WebSockets, SSE) has been extended and now also supports to enrich “deleted events”. The data for enrichment is taken from the state just before the deletion is executed.
Example: Imagine that your application listens to the lifecycle events of a thing than is to be deleted,
and needs additional info in order to delete it from other systems as well.
For such a case, you can apply event enrichment. Find details at Protocol > Enrichment of events and messages.
Note: Deleted events are handled without special care for QoS-1 requirements, like all other events in Bosch IoT Things. Thus, if an IoT application needs to make sure to not miss a “deleted event”, it will need to take special care in the application itself (e.g. use requested-acks on the delete command, and special recovery handling in case of partial execution).
Eclipse Ditto version 2.1.0 has been released
Our open source base - Eclipse Ditto - has been released accordingly.
Read the full release notes at https://www.eclipse.org/ditto/release_notes_210.html.
At this occasion, various minor bugs have also been fixed.
September 9, 2021 - Bosch IoT Things - service update
Our latest service release comes with various changes:
Connections status details
To easy categorize the cause why a managed connection might not work as expected, we have introduced a “connection status”.
The connection status helps to distinguish between errors that are most probably “customer related” (i.e. in responsibility of the customer) vs. service related problems, which are in the responsibility of our backend. If an error cannot be distinguished, it is classified as “service related” for now.
Further, whenever connections are stuck in a service related failure state, we are alerted and will do best efforts to re-establish such connections.
Examples of customer related failures:
- authentication errors due to wrong credentials
- target host not reachable
- certificate errors
Examples of service related failures:
- internal required cluster communication failed
- unknown (no known live status within status aggregation)
- all other errors that cannot be identified as being caused by wrong usage
The easiest way to look up the newly introduced status is the Connections UI.
You can of course also retrieve the status via Bosch IoT Things HTTP API.
See GET /solutions/{solutionId}/connections/{connectionId}/status
{
"connectionId": "xxx",
"connectionStatus": "open",
"liveStatus": "open",
"clientStatus": [
{
"type": "client",
"client": "connectivity-xxx",
"address": null,
"status": "open",
"statusDetails": "[CONNECTED] Connected at 2021-09-09T11:19:10.459570814Z",
"inStateSince": "2021-09-09T11:19:07.857Z"
}
],
"sourceStatus": [],
"targetStatus": [
{
"type": "target",
"client": "connectivity-xxx",
"address": "Shared.things2di/{{ thing:id }}",
"status": "open",
"statusDetails": "Started at 2021-09-09T11:19:07.879082781Z",
"inStateSince": "2021-09-09T11:19:11.639Z"
}
],
"sshTunnelStatus": [],
"connectedSince": "2021-09-09T11:19:07.857Z"
}
Further changes
- Minor corrections in this documentation as well as in HTTP API docs
- Improved resilience of authentication chain
- Security relates changes
- Strict Transport Security (HSTS) configuration
- Check usage of x-forwarded-host & x-original-uri
- Improved Azure deployment
- Removed all references to the Bosch IoT Permissions service, which is retired
- Introduced basic tracing
At this occasion, various minor bugs have also been fixed.
July 27, 2021 - Bosch IoT Things - service update
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 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.
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 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.
{
"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.
June 24, 2021 - Bosch IoT Things - service update
Our latest service release comes with various changes:
Connection authentication for public clouds - Azure and AWS
Bosch IoT Things supports integration with the ecosystems of Microsoft Azure and Amazon Web Services (AWS). We have additionally introduced the HTTP push signature authentication using HMAC-SHA256. Further, we support connection authentication with Azure SASL for HTTP and AMQP connections.
Examples: The following examples demonstrate integration with Azure Monitor, Azure IoT Hub, Azure Service Bus, AWS SNS and AWS S3.
- Azure Monitor (HTTP): Publish twin events to Azure Monitor as custom log.
- Azure IoT Hub (HTTP): Invoke direct methods on Azure IoT Hub devices by sending live messages.
- Azure IoT Hub (AMQP 1.0): Send cloud-to-device messages to Azure IoT Hub devices.
- Azure Service Bus (HTTP): Publish live messages onto an Azure Service Bus queue.
- AWS SNS (HTTP): Publish twin events onto an AWS SNS topic.
- AWS S3 (HTTP): Publish each twin event as an object in an AWS S3 bucket.
Use organization roles for managing solution resources
To manage the Things solution by API (e.g. create connections, namespaces, etc.) you can now also authenticate with an SuiteAuth token comprising the organization roles.
New subscriptions will automatically add the subjects iot-suite:/organization.<org-guid>.Owner
, iot-suite:/organization.<org-guid>.Developer
and iot-suite:/organization.<org-guid>.Manager
into the solution policy.
For old subscriptions you will need to edit the solution policy manually. Find an example at Bosch IoT Suite for Device Management > Policy examples.
Use SuiteAuth OpenID Connect logout
The Bosch IoT Suite portal provides authorization functionality like creating OAuth2 clients. As SuiteAuth supports logout according to the OpenID Connect standard, with the latest service update Bosch IoT Things uses the SuiteAuth logout functionality for the Things UI.
Further improvements
- Improved rollback mechanism in Device Provisioning API
- Improved error handling for already existing devices and twins on device provisioning
- Relaxed JWT timestamp check to accept short system time differences
- Prepared for consuming from Apache Kafka.
The connection between Bosch IoT Hub and Bosch IoT Things is subject to change by Aug - Oct 2021.
We will announce the change and potential migration steps separately.
At this occasion, various minor bugs have also been fixed.
June 02, 2021 - Bosch IoT Things - service update
Our latest service release comes with various changes:
Connection management - new option to publish announcements
When a managed connection is opened or gracefully closed, the Things service can send a respective announcement.
Example - opened connection
{
"topic":"_/<connection-id>/connections/announcements/opened",
"headers":{"content-type":"application/json"},
"path":"/",
"value":{
"openedAt":"2021-06-01T17:06:15.789662330Z"
}
}
Example - closed connection
{
"topic":"_/<connection-id>/connections/announcements/closed",
"headers":{"content-type":"application/json"},
"path":"/",
"value":{
"closedAt":"2021-06-01T17:27:10.814860443Z"
}
}
You can activate and deactivate such announcements using the Connections/Integrations UI, as well as via Bosch IoT Things - HTTP API.
At this occasion, various minor bugs have also been fixed.
May 11, 2021 - Bosch IoT Things - service update
Our latest service release comes with various changes:
Namespace management - user interface
For package subscriptions, e.g. Bosch IoT Suite for Asset Communication and Bosch IoT Suite for Device Management, the user interface to manage namespaces as well as the search index settings per namespace are now available directly in Bosch IoT Suite Console.
Example:
The stand-alone Things UI remains available for customers who have booked their instance on the Bosch IoT Cloud.
Connection logging for new opened connections
In order to capture potential error logs related to establishing a connection (e.g. connection errors) when creating and opening the connection, the Things service automatically enables logging for one hour.
Bosch IoT Suite for Device Management - pricing
The usage-based pricing model for the standard plan of Bosch IoT Suite for Device Management is now better supported by Bosch IoT Things service usage measurements. In case your instance has been accounted for data volume only in the previous months, please expect that we henceforth also report transaction metrics such as Twin updates, Twin reads, Live messages, Search etc.
All details regarding the pricing are listed at Pricing & Conditions – Bosch IoT Suite for Device Management.
Ditto 2.0
We are happy to announce that our open source base, the Eclipse Ditto project, has released its major release 2.0.
Find a compact summary as Eclipse Ditto blog.
As Bosch IoT Things already provides all features announced there, the main impact on the commercial version are: the availability of the new Ditto client versions, as well as the end of support for API 1, things-client, and authentication via cryptographic challenge.
At this occasion, various minor bugs have also been fixed.
April 13, 2021 - Bosch IoT Things - service update
Our latest service release comes with various changes:
SSH tunneling
SSH tunneling is a method of transporting data over an encrypted SSH connection.
A connection managed within Bosch IoT Things supports establishing an SSH tunnel (local port forwarding) to connect to the target endpoint.
You can enable and configure it in the connection management section of the Things UI.
Example:
Once configured, Things service takes care of creating a tunnel and connecting to it, in order to establish a connection to the actual endpoint.
The state of the tunnel is reported in the connection logging section in the UI. This can be very helpful to diagnose connectivity problems.
Find details at Concepts > Connections > SSH tunneling.
Ditto 2.0 preparation
We are happy to announce that our open source base, the Eclipse Ditto project, is preparing for its next major release 2.0.
Find a compact summary at https://projects.eclipse.org/projects/iot.ditto/reviews/2.0.0-release-review.
As Bosch IoT Things already provides all features announced there, the main impact will be the availability of the new Ditto client versions, as well as the end of support for API 1, things-client, and authentication via cryptographic challenge.
End of support for various resources
The Bosch IoT Things HTTP API v1, things-client and authentication via cryptographic challenge have been announced deprecated in February 2020. Now the time has come to end support for these resources.
With this documentation update, we have also removed all sections describing the deprecated resources.
At this occasion, various minor bugs have also been fixed.
March 10, 2021 - Bosch IoT Things - service update
Our latest service release comes with various improvements:
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 activated 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"
]
}
}
Find a usage 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 thenull
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.
February 17, 2021 - Bosch IoT Things - service update
Our latest service release comes with various improvements:
New built-in acknowledgement: search-persisted
An acknowledgement with label search-persisted is issued when a modifying command has successfully updated the search index of the digital twin.
Read all about acknowledgements at Concepts > Acknowledgements.
New actions for policies
The policies resources allow automatically injecting or removing of a subject calculated with information extracted from the authenticated JSON Web Token (JWT).
Find details about the activateTokenIntegration
action and the
deactivateTokenIntegration
action at Concepts > Policy
as well as the Things HTTP API docs.
Search index fields per namespace
While creating a namespace for a subscription of the Bosch IoT Suite for Device Management package, you can select a new preset called “Comfort”.
This option holds following search fields:
- thingId
- _created
- definition
- attributes
- features/*/properties/status/agentName
- features/*/properties/status/softwareModuleType
Of course, you can add further search index fields, as needed for your business application.
Find all presets at Manage the search index of a namespace.
At this occasion, various minor bugs have also been fixed.
January 19, 2021 - Bosch IoT Things - service update
Our first service release in 2021 comes with various improvements:
Optional time limit in policy
In each policy entry you can add an expiry date to limit the validity for a specific subject.
Once the timestamp defined in the expiry field is reached, the Things service will automatically delete the specific subject field and thus prohibit the access for the specific subject.
The timestamp is set as string in ISO-8601 format. For simplicity, we will round it up to the next full hour.
Example: see https://docs.bosch-iot-suite.com/device-management/Policy-examples.html
Find more details at Policy > Subject expiry.
Custom search index per namespace
The Things UI and API offers the possibility to define which fields of the things to be included in the search index. This information is managed per namespace.
The fields thingId
, policyId
, definition
, attributes
and _created
are indexed per default.
This allows an out-of-the-box possibility to filter on these fields and always allows the search with an empty filter.
However, using the new dialog at Manage the search index of a namespace you can customize the index per namespace. The user interface provides various options:
- Minimal: includes
thingId
and_created
- Default: includes
thingId, policyId, definition, attributes
and_created
- Complete: includes all indexable fields
- Custom: includes
thingId
,_created
, and the fields of your choice.
Example with customized search index
The search fields can also be defined using the Things HTTP API with the “/solutions/{solutionId}/namespaces/...
” resources.
Find more details regarding search at Search resources.
A namespace that has been created before this update will not be changed automatically to the new defaults, and will thus continue indexing all fields. However, please respect the new settings in case you create a new namespace for an old solution.
Updated default header mapping for connections
Connection sources and targets used to contain a header mapping content-type: {{header:content-type}}
per default
setting. This led to mismatches when used together with payload mapping. Therefore the mapping will no longer be added
as default for new connections (old connections will still behave as known). We encourage setting the content-type in
the payload mapping rather than the header mapping.
As a result, the content-type
default mapping is no longer part of the UI modals, but can of course be added if needed.
It is also no longer part of the default for connections that are created via an API request and don’t contain an
explicit header mapping for connection targets. It is possible to add the old header mapping to the create connection
requests into each target:
// connection json
{
"targets":[{
"headerMapping": {
"content-type": "{{header:content-type}}",
"correlation-id": "{{header:correlation-id}}",
"reply-to": "{{header:reply-to}}"
},
// ...
}]
// ...
}
Eclipse Ditto Client 1.5.1
Latest bug-fixes in Ditto Clients are available with version 1.5.1.
See original release notes at https://www.eclipse.org/ditto/release_notes_151.html.
At this occasion, various minor bugs have also been fixed.