Release history

For workflows, temporary errors could lead to very long sleep time.

Requests where delayed due to deadlock in database during the final clean up of a request.

Made the request dispatcher more robust against temporary database errors.

Subscriptions with a non-valid URL are now completely ignored. Could previously cause errors when distributing the event.
This includes empty URL:s as well as syntactically incorrect URL:s

Fix for a case where a detected oscillation was ignored (typically updates of key values or references).

Now detects oscillating values and stops those object from further updates.

Added Merge Information with information about the keys that where involved in a merge.

Cancellation from the client side now returns error 499 instead of 500.

The service now runs on .NET Framework version 4.8.1.

Added logging when GET RequestResponses/{id}/Response times out.

This service is based on .NET Framework, and we now bumped it to the latest (last?) version of that framework.

The business events application made calls to Async Caller. This was a rest from the older pattern and is now removed.

• Saves the response to storage before saving it to DB if allowed according to configuration. This means that if the DB write fails, we still have the response saved, so we don't need to send another request to get the response again.

• Added one property for HttpRequest metadata; WaitingRequestId, to make it possible for workflows to register a waiting workflow for a request.
• Added a method to get all completed responses that a workflow is waiting for.
• General performance optimizations

• Added database column FinalResponse.CreatedAt, to give an indication when the response was created as a request in the service.

• A response with status code 202, but not of the type that AM should manage, is now considered a success and will be returned to the calling client.

PublishedAt in the MetaData of en event publication was cached and not updated for 4 hours.

When a client tries to create a request and there is a DB bottleneck we now try to save that request in storage and add it to a queue of pending requests. These requests will be created later by a batch job when there is less pressure on the DB. (Today if you send more requests simultaneously than your DB is configured for, AM will throw exceptions like "Too many connections" and return errors, leaving it up to the client to retry again.)

When a client calls AM to create a request and there is a problem with the DB, AM will try to store the request to AzureStoragePendingContainerName and put a message on the PendingQueueName storage queue.
Every minute there is a batch job that retrieves the pending requests from the queue and storage and tries to save them to the database.

When a client polls for a request response, we will repeatedly try to get a response from the FinalResponse table, the OutRequest table and the pending request storage. This is done in a loop until we have tried for TimeLimitForGetResponseInSeconds.

As long as there are any items remaining on the pending request queue, the service health status will be Warning, with a message of the number of requests that are on the queue.

Better workflow engine support: When a response indicates that the job should be postponed and that we should try again later, we will now use exponential backoff, like for all other requests.

To minimize the probability that we get a racing condition, we now update the database before we we enqueue a callback, but commit after.

Corrected a bug that only appeared when the final response was HTTP status code 401 and could cause the request to never be completed.

Removed foreign key constraint on ActiveRequest (constraint FK_ActiveRequest_CurrentOutRequestId) that caused DB deadlocks when deleting OutRequests.

There were incorrect validations for the response of a request. We have removed all the validations, as we shouldn't have any opinions on the response content.

Completed requests are moved to new table FinalResponse, which has partitions to facilitate fast purging. There are 31 partitions, each representing a day in a 31 day cycle, letting us say how many days in the future a partition will be deleted (max 30).

This will significantly improve the performance of deleting old requests.

The old way of deleting old requests will still be in play for up to 90 days (depending on customer settings).

Note 1! The setting TimeBetweenRequestCompletedAndPurgeInDays now has a max value of 30. It can be set to a lower value to keep completed requests for shorter period of time. (If it is set to more than 30, the effective value will be 30.)

Note 2! When a request has been completed we create a record in FinalResponseand delete corresponding records from ActiveRequest, OutRequest, and InRequest. In earlier versions, these were not deleted until purge time.

Note 3! An exception to Note 2 is that when the final response code was 401 we keep the record in InRequest, and only delete it when a retry with new authentication is requested.

1. With version 2.7.0 of Async Manager the contract for retries because authentication failed has changed. This upgrade uses the new contract.
2. When parsing payload contract for translation, log parsing errors as Information instead of Error
3. Made distribution of events more robust

Note: This release introduces a new database table SuccessfulDistribution to keep track of successful event distributions when there are multiple subscribers and one of them fails temporarily. This table should normally be empty and records older than 30 days can be deleted.

• When there is an internet problem during the serivce initial authentication, we will return a FulcrumResourceException instead of a FulcrumAuthenticationException.
• When this type of problem is found, it will now also be reported in Service Health, so that it can be detected faster.

There were incorrect validations for the response of a request. We have removed all the validations, as we shouldn't have any opinions on the response content.

There were four different retry mechanisms when we had internal problems, like database timeouts, etc. This could result in thousands of retries per hour for just one request. We have consolidated the retry mechanisms into two and made them much more conservative, so now there should be no more than a maximum of 12 retries per hour for one request due to internal problems.
We also fixed a potential bug regarding dead locks in the DB.

The web job schedule has been updated from ever 2 minute for all jobs to different prime numbers (2, 5, 7, 13, 17) to make the different jobs less prone to run at the same time. The configuration setting LimitForDeletingCompletedActiveRequestRecordsInDays, default value 1, was actually translated into seconds, i.e. 1 second instead of 1 day."

Handle that the ActiveRequest can be set to state Awake when OutRequest is in state Sending

The function app will auto-heal the database inconsistencies when ActiveRequest was forced to state Enqueued by limbo detection.

The support for specifying the schedule for background tasks has been revoked. The cron expression for all functions is now set to every second minute:

0 */2 * * * *

Background tasks now have the possibility to specify its schedule. See Upgrade to 2.6.0

Support for setting 'PurgeReadBatchSize' and 'PurgeCommitBatchSize' to optimize purging of old data

Background tasks were split into six jobs

Added the IX_OutRequest_InRequestId index to improve purge performance

Correcting bug introduced in 1.9.3. After correction, the batch translations where source and target have the same context or same client will now be handled correctly (and faster)

Fix: Optimized batch translate to avoid individual translations for the translations that failed.

Moved delete of completed requests from batchjobs to new purge method, meaning that those two don't fight over maximum time constraints,
Bugfix: Purging now uses the configured setting for how old the items should be to be purged.
Bugfix: Now we don't lock when reading responses and we retry for up to 500 ms.

Version back to 2.4.1, after unintentional release 2022–08–30.

Unintentionally reverted to version to 2.3.0. Discovered at 2022–10–19. Fixed in release 2022-10-19.

Updated URLs for internal communication with Nexus Link Services.

URLs to Nexus Link Services

Updated URLs for internal communication with Nexus Link Services.

URLs to Nexus Link Services

Don't regard missing tenant configuration a 500 error, but rather a 502

Updated URLs for internal communication with Nexus Link Services.

URLs to Nexus Link Services

Updated URLs for internal communication with Nexus Link Services.

URLs to Nexus Link Services

Updated URLs for internal communication with Nexus Link Services.

URLs to Nexus Link Services

NLS URLs updated
Updated URLs for internal communication with Nexus Link Services

URLs to Nexus Link Services

Deleting Old Requests
Depending on the number of requests and the tier of the database, deleting old request could take a longe time.

• Handled problems with deleting old requests as DB grows: Added stored procedure DeleteSomeOldRequests that is used for deletion
• Added a DB index for InRequest.CompletedAt

Locked Errors
In error reporting, error 500 was reported although the cause was resource lock that is handled at a later stage.

• Now throws FulcrumResourceLockedException instead of FulcrumTryAgainException if a resource is locked

Misc.

• Save client tenant configuration in in-pipe now fails fast if the configuration could not be fetched from Fundamentals

Now logs 423 errors as Information instead of Warning

Now uses a BatchLogger (with threshold Warning)

Had warnings about authorization even if authorization existed. Was only checking for tokens. Now only warning when no authorization.

Memory leak after upgrading Microsoft.IdentityModel.Tokens, it now enables signature provider caching by default.
This release prevents the memory leak by disabling the cache.

Memory leak after upgrading Microsoft.IdentityModel.Tokens, it now enables signature provider caching by default.
This release prevents the memory leak by disabling the cache.

Support for retrying as the time specified by a RequestPostponedError. This is important for Workflow Engine, to implement a maximum wait time for asynchronous calls

Memory leak after upgrading Microsoft.IdentityModel.Tokens, it now enables signature provider caching by default.
This release prevents the memory leak by disabling the cache.

Support for refreshing authentication
When a requests yields a 401 response, Async Manager will let the initiater know this in the (optional) Callback. The initater can then take action to make use of the new endpoint for retrying the request with new authentication.

Support for saving payloads to either database, storage or both
When using blob storage there is a overhead of approx. 200–250 ms when creating a request. Using only database will therefore be faster. However, you might want to save to storage for other reasons, such as security or long term storage.

Bug fixes
Corrected a bug, where the configuration settings LimitForDeletingCompletedInRequestRecordsInDays and LimitForDeletingCompletedActiveRequestRecordsInDays where interpreted as seconds instead of days.
A workflow can now requests the AM to retry and give a specified time to wait before the retry.

Support for refreshing authentication
When sending an event, Nexus Business Events authenticate itself towards the subscriber. In case the subscriber component can't handle the event right away, and the authentication should expire, there is now automatic support for refreshing the authentication.

(Requires use of Async manager. I.e. no support when using Async Caller.)

502 response instead of 500 when database failure
If there is a problem with connectivity to customer's database, response is now 502 instead of 500.

This can happen when Fundamentals tries to access the customer's configuration database and there is a temporary failure, or if the database does not exists.

Support for FulcrumResourceLockedException
If a database lock occurs in DSE a FulcrumResourceLockedException will be thrown.

(Requires update of Nexus.Link.AsyncCaller.Distribution to version 1.2.0 if used)

Support for FulcrumResourceLockedException
If Async Caller now encounters FulcrumResourceLockedException or HttpStatusCode Locked (423), it will try calling again.

(Requires update of Nexus.Link.AsyncCaller.Distribution to version 1.2.0 if used)

Improved performance for create request by reducing SQL calls
An optimization to reduce the number of SQL queries made during an event publish. Even though each query takes about 20 ms, a few of them stack up and adds to the total request time.

Improved performance for create request by reducing SQL calls and storage calls
An optimization to reduce SQL queries and blob storage access to a minimum.

Fixed problem with validation of OutRequestRecord.SendStartedAt
Technical bugfix.

Fix for huge memory footprint
A third party library changed it's way of handling cached authentication tokens so that it used up a lot more memory.

Fixed problem with service dependency routes for tenant
As part of the Service Health contract, a service tells which dependencies it has to other services. There is two versions, one for the service itself and one for a specific tenant.

Fix for service dependencies in Tenant mode (use either AM or AC)
As part of the Service Health contract, a service tells which dependencies it has to other services. There is two versions, one for the service itself and one for a specific tenant. Business Events now takes into account only the dependency which the tenant uses (Async Manager or Async Caller).

Individual requests can now be paused manually
This is done by setting ActiveRequest.State = 'Paused' in the database.

Every 5 minutues there is a number of batch jobs that are run:

• Wake up requests that have been "lost" from processing
• Awake sleeping requests
• Snooze awaken requests for hosts that are inactive
• Enqueue awaken requests
• Delete old ActiveRequests
• Delete old InRequests (and the corresponding OutRequests)

Support for the new version of Async Manager
The release of Async Manager 2.2.0 meant a change in the API.

A code library for programming asynchronous, long running processes.

This is the first official release of the Async Manager
It has been in PRDSIM for beta testing a couple of months. AsyncManager is planned to replace Async Caller. The main difference with Async Caller is that Async Manager stores all requests and responses in a database, while AC only stored them in a queue. This makes administration and problem solving for requests much easier.

Workflow engine
Another important addition is support for the Workflow Engine, which is currently in beta test and is planned for release later in January.