Migration from previous versions
From 1.31 to 1.32
The registered action "Send Notification" at Deviation Processor is now deprecated and will be shown as such in the "Registered Actions" view in Deviation Processor. However, therefore, the Notification Service must be started after Deviation Processor is running. In case, Notification Service was started prior to Deviation Processor, it must be restarted in order to correctly display the mentioned action as deprecated.
From 1.29 to 1.30
-
Bosch.Foundation.Messaging.RabbitMQ updated to the latest version (2502.7.1), which uses a current RabbitMQ.Client with support for RabbitMQ 4.
-
The use of the RabbitMQ 4 client is limited to the AMQP 0-9-1 protocol functions, which are compatible with both RabbitMQ 3 and 4.
From 1.28 to 1.29
RabbitMq message broker system will be used for processing the events and notifications asynchronously. The following exchanges and queues will be created in RabbitMq:
| Exchange | Type | Description |
|---|---|---|
x.notification.process |
direct |
Exchange for processing notifications asynchronously . All events will be sent to this exchange. |
x.notification.deadletter |
direct |
When a message is rejected, expires, or fails to be delivered to its intended queue, it can be routed to a designated Dead Letter Exchange for further inspection Moreover , the type of queue for q.notification.service was changed from classic mirror queue type to Quorum queue type |
| Queue | RoutingKey | Type | Description |
|---|---|---|---|
q.notification.direct |
nexeed.notification.direct.created |
quorum |
All direct message will be sent to this queue and notification service has a consumer to receive the message and process the direct notifications |
| Queue | RoutingKey | Type | Description |
|---|---|---|---|
q.notification.email |
nexeed.notification.email.created |
quorum |
All email message will be sent to this queue and notification service has a consumer to receive the message and process the email notifications |
| Queue | RoutingKey | Type | Description |
|---|---|---|---|
q.notification.push |
nexeed.notification.push.created |
quorum |
All push message will be sent to this queue and notification service has a consumer to receive the message and process the push notifications |
q.notification.deadletter |
q.notification.deadletter |
quorum |
All unprocessed or failed or rejected events will be sent to this queue for further inspection |
NOTE : When creating a DeadLetter queue, the default configuration sets the message TTL (Time To Live) to 14 days and the maximum message length to 1000. RabbitMQ policies allow operators to override these default values.
Steps to set RabbitMQ Policies:
-
Go to RabbitMQ management UI
-
Navigate to 'Admin' tab
-
Select the Policies from the right-side menu
-
Create or update the policies as needed
From 1.26 to 1.27
To migrate from version 1.26 to 1.27, follow the steps below:
Environment variable to be removed - enableswaggerUi
| Variable | Description | Required | Default |
|---|---|---|---|
|
Whether to enable the Swagger UI or not. |
No |
false |
Environment variable to be introduced - swagger_enabled
| Variable | Description | Required | Default |
|---|---|---|---|
|
Whether to enable the Swagger UI or not. Swagger UI is disabled by default |
No |
false |
Tenant migration
|
If you run any Nexeed IAS installation on Tenant ID The Tenant ID is conceptually the unique identifier for all data contained in Nexeed IAS in relation to other installations. This will lead to problems if dataflows meet on shared infrastructure (like e.g. RabbitMQ or Solace) or existing systems are to be merged on a shared installation with multiple tenants. Therefore, the Tenant ID has to be unique - for systems that have been erroneously installed with either Tenant ID The Migration instructions and scripts available from BCI are specific to that version and cannot be executed on prior or later versions. |
Database migration
Changes are made to both Oracle and SQL - A database schema migration has been updated successfully in version 1.29.0. The updates include changes to field properties such as data type conversions (e.g., nvarchar to varchar) and length adjustments (e.g., from nvarchar(max) to 36, 50, 200, 255, or 2000) of both Oracle and SQL database.
-
This migration introduces no breaking changes.
-
Existing integrations and functionality remain unaffected.
-
If you notice any unexpected behavior, please contact the development team at
Notification.Service@in.bosch.com.