- Release v8.0.0
- Release v7.4.0
- Release v7.3.0
- Release v7.2.0
- Release v7.1.0
- Release v7.0.0
- Release v6.1.0
- Release v6.0.0
- Release v5.10.0
- Release v5.9.0
- Release v5.8.0
- Release v5.7.0
- Release v5.6.0
- Release v5.5.0
- Release v5.4.x
- Release v5.3
- Release v5.2
- Release v5.1
- Release v5.0
- Release v4.0
- Release v3.2
- Release v3.1
- Release v3.0
The release workflow has switched to a continuous delivery workflow, where every commit will trigger a new release and result in a new artifact. If there are any manual migrations necessary, the documentation can be found right here.
|
Important
|
This release contains breaking changes. Please read the release notes carefully. |
The former profile azure has been renamed to mariadb-lt-10_5.
Please adapt the profile name in your configuration.
The former functionality of the status checking for endpoints has been enhanced. The status is now checked with the same mechanism as it is done for a single endpoint. This increases the reliability of the status checks since the internal caching is disabled and has removed the scheduled status checks from the middleware.
With the new release, the monitoring endpoints are secured by default. During startup, the middleware will generate a random password for the monitoring endpoints. You can see the password in the logs during startup, but it will be stored as a hash within the database. You can use the password to access the monitoring endpoints, like the health check, the metrics or the info endpoint.
If you lost the password, either delete the monitoring tenant from the database or set the password via maintenance endpoint.
With the new release, the message statistics have been enhanced. There is more structure and some additional information.
{
"connectionStatistics": {
"numberOfConnectionLosses": 0,
"numberOfCacheMisses": 1,
"numberOfClientInitializations": 1,
"numberOfDisconnects": 0
},
"mqttMessageStatistics": {
"numberOfMessagesArrived": 0,
"numberOfAcknowledgements": 0,
"numberOfPushNotifications": 0,
"numberOfCloudRegistrations": 0,
"numberOfEndpointListings": 0,
"numberOfUnknownMessages": 0
},
"contentMessageStatistics": {
"numberOfContentMessagesReceived": {}
},
"numberOfConnectedClients": 1,
"numberOfDisconnectedClients": 0
}With this release it will be no longer allowed to send messages without a router device. This is necessary to improve the performance of the middleware and to reduce the load on the agrirouter. You will need to provide a router device once and all of the endpoints will be updated and connected using this router device. If you did not provide a router device, the middleware will reject the message.
[ERR_00038] Could not find the router device for the endpoint with the external endpoint ID '492eda79-d787-46f5-a3b5-3bc9dcfe97fa'.You can see those error messages during startup within the logs of the middleware. The middleware will automatically update the former endpoints and connect them to the router device if it is provided.
If you try to send a message without a router device, the middleware will reject the message.
With this release the middleware will use new error codes for internal errors.
Please see the documentation of the ErrorMessageFactory for more information.
Specific error documentation will be added over the next releases.
With this release the middleware will reject onboarding requests in case of agrirouter outages. This will prevent the middleware from sending messages to the agrirouter in case of outages and will reduce the load on the agrirouter. This was necessary to reduce errors during onboarding and to improve the onboarding process.
With this release it is possible to configure the full database URL via environment variables. This is useful if you want to add custom parameters to the database URL. Both internal databases, the MariaDB and the MongoDB database, can be configured this way.
With the new release it is possible to check the status of the endpoints more easily. The check is performed live and not based on a cache.
The basic concept is that the middleware will check the status of the endpoints based on two components - the official status page of the agrirouter© and the echo mechanism of the outbox. At first the status page is checked, if there is an error a HTTP 502 is returned. If the status page is available, the echo mechanism is checked. If the echo mechanism is not available, a HTTP 503 is returned. If the echo mechanism is available, a HTTP 200 is returned. The echo mechanism is only checked if the status page is available, because the echo mechanism is only if the whole ecosystem is available.
If there is a timeout during the echo mechanism check, the status check will indicate, that the endpoint is no longer available.
The DDIs for subscriptions have been updated, the new end of the range is now set to 675 and the configuration is now stored in the environment / Spring profile.
This release was a hotfix release to fix a bug in the subscription mechanism and provide automated subscription updates without the need to inform the customers.
To see how the application is performing, there is a new endpoint to get the number of messages sent and received. You are not able to see how many messages per endpoint or per application were sent or received. The endpoint is available for the whole installation. You can find them in the Swagger documentation.
With the new release it is possible to delete a single message and all of the chunks the message brought with it. The endpoint is available for the whole installation. You can find them in the Swagger documentation.
There is a new endpoint for business events that occurred within the middleware. Each of the business events in the middleware is cached and can be received using the endpoint. The endpoint is available for the whole installation. You can find them in the Swagger documentation.
The former recipient checking was based on a 30 minute interval.
The default interval was decreased to a 15 minute interval.
The interval can be set via system property.
You can define the app.scheduled.recipient-query within your custom set of Spring properties, there is no environment variable to set the recipient check interval.
The default value is 15 minutes.
The endpoint is available for the whole installation.
You can find them in the Swagger documentation.
With the new release the current status of the agrirouter© is integrated into the whole business process. The status blocks message sending, scheduled checks and status updates in case the agrirouter© is not available. The status is checked every 5 minutes and will be hold within the cache to avoid constant calls to the agrirouter© status page. This allows to reduce the load on the agrirouter© in case the system has some problems.
The new version is able to cache messages in case of failure.
We added MicroStream as a dependency to the middleware.
The cache is stored in a file on the server, and you are able to set the path via system property.
You can either define the app.cache.message-cache.data-directory within your custom set of Spring properties or set the environment variable MESSAGE_CACHE_DATA_DIRECTORY.
A valid path is required to enable the cache.
You could - for example - use something like /opt/application/.message-cache to set the location of the cache.
With the new release the messages within the cache are send in batches.
The size of the batch can be set via system property.
You can define the app.cache.message-cache.batch-size within your custom set of Spring properties, there is no environment variable to set the batch size.
The default value is 100.
Since the agrirouter© was not happy with the former keep alive interval, we had to adapt it. The new value is 60 seconds.
With this release there are breaking changes, so please note the following migration guide.
With PR 167 the naming was updated.
The name applicationId has been misleading, and therefore it has been changed.
The new name is internalApplicationId.
Since the parameter names did not reflect the actual content, they have been changed.
The new names are base64EncodedPrivateKey and base64EncodedPublicKey for application registration.
The format is still the same, just the name has been changed.
This is no breaking change, but a new feature. The technical message types are now shown in the application details. This is useful for debugging and monitoring. You can find them either in the response of the application details or in the internal status page.
There are several new features in the internal status page. You can clear error several status messages / error messages and see the pending delivery tokens for the endpoints.
With the new release there comes a handy Postman collection for the agrirouter© middleware. You find the link right in the documentation.
The maintenance mode has a new endpoint to reset the password for a tenant. Please handle with care and only use them if you know what you are doing. Since the maintenance endpoints are available without any authentication, you should only expose them to internal networks.
There are no breaking changes in this release (as the version indicates already). Although there are some new features for efficiency and performance.
With the release 3.1 you can now access the internal status page of the agrirouter© middleware. You can find all your applications and their belonging endpoints there. Each of the endpoints has a detailed dashboard, where you can see the current status of the endpoint and the last messages that have been sent or received. Errors are also displayed there.
As you can see, there are small icons indicating the current status. You are able to hover over them and see the details of the status.
Each of the endpoints has a dedicated dashboard showing common errors, warnings, virtual endpoints and much more. The sections are only displayed if there is any data to show.
The maintenance mode has some new endpoints to reset the state of an endpoint, remove an endpoint completely or to remove the whole application. Please handle with care and only use them if you know what you are doing. Since the maintenance endpoints are available without any authentication, you should only expose them to internal networks.
There are some breaking changes in release 3.0 and therefore the documentation has been updated.
With PR 87 there was a change in the way the HTTP status codes are handled. The response does not contain a real HTTP status code and no longer the literal. Please see the Swagger documentation for more information.
With PR 89 there was a change regarding the search of time logs. The search is now based on the timestamp of the message and searching for an ID is not supported anymore.
The former search query did look like this:
The new search query looks like this:
With PR 103 the monitoring for endpoints has been changed. This is the main reason why this release is a breaking change. If you did not include the monitoring in any of your tools you can now ignore the rest of this section.
The endpoint "status" has been modified and was replaced by several, more detailed endpoints to lower the amount of data transferred during the monitoring. The common endpoint "status" is still available, but some details where cut out and moved to specific endpoints. Please see the updated Swagger documentation for details.
The former endpoint status did look like this:
The new endpoint status looks like this:
