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: live response and twin update

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 the live-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 be true or false and states whether the passed live-channel-condition was a match or not
  • channel – value could be twin or live 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:

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.

connection-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.

Automatically create things

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.

tip 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.

tip 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.

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:

namespace

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.

tip 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.

tip 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:

SSH-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.

tip 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.

tip 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.

note 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.

note 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.

tip 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).

tip 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 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.

tip 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.

Corporate information Data protection notice Legal information Support Free plans