ViolatedRecord
and ViolatedConstraint
is optimized to immutable. This is a new feature in release 2.5.0. Immutable data cannot be changed (as is the case with registering constraint violations).transactionalConsistentFilter
with valid values: LEAST
| GREATEST
.transactionalConsistentFilter
property registers whether LEAST
| GREATEST
is used in determining the proper time consistency for a helper.SetConstraint
in HelperEntity
is removed. This uniqueness constraint is now checked as a deferred constraint when importing metadata.uiServer.apiUrl
is changed. The value: https://localhost:3000/v1 should be changed to https://localhost:3000.application.disabledRoles
is added. A list of disabled roles on server level can be registered here. For example: application.disabledRoles
: [Developer
].application.lockManager
via the following properties:
lockWaitTimeOut
lockWaitTimeOutCheckIntervallockPendingWarningInterval
.httpRestApi.options.keepAliveInterval
httpRestApi.options.stream.maxTransformableRows
.{editorial} [KD] Missing instructions in link: For more info regarding configuration options see the documentation: ---i-refactory config file options---()
A new server role is added in our nodeJS backend application: Developer
.
Users assigned to this privilege are allowed to cancel running deliveries. It's also possible to disable this role on server level. For example: A user is granted the Developer
role but on a production environment it is never allowed to cancel a delivery. The Developer
role can be disabled by setting this value in the config file: application.disabledRoles
.
An example script createApplicationUser.sql
is added in the i-refactory-sqlserver/initialize folder.
With this example script a server login account is created together with user accounts on each database with the proper (and required) permissions. In the config file you should change the connection user to this application user login instead of using an account with too much permissions.
To do so modify the property: boot.database.connection.driverConnectionProperties.username
and password
accordingly.
{warning} Custom functions and procedures.
Be aware that the granted permissions do not allow for the execution of custom functions and/or procedures. Execute rights on functions and/or procedures should be granted explicitly.
{editorial} [KD] Missing instructions in link: See ---Initial installation of the i-refactory repository---() for more information regarding creating an application user.
When creating a new delivery you can now register a customer specific message number and message text.
You can now view delivery related statistics and history information.
You have the ability to select a given timeframe and a maximum amount of deliveries that should be returned.
If you open the detailed page for a logical validation models an overview of all executed deliveries within the given timeframe filter and max number of deliveries is shown.
And for each specific delivery you have the ability to view the detailed results of executed validations, retrieve a sample of violated records and have a look at the details (throughput, rows processed, executed code, ...) of each executed entityUpdate.
The filtering capability in the browser is enhanced.
We now have the ability to specify for example: "contains", "starts with", ... for string values.
The version of the running application can be retrieved.
You now have the ability to cancel an active delivery.
If an active delivery is cancelled, IDLE
and SCHEDULED
tasks will not be executed anymore. The already PROCESSING
tasks are completed. The intermediate status (as long as not all processing tasks are either succeeded or failed) is CANCELLING
.
Cancelling a delivery is only allowed if a user has been granted the role of Developer
and the Developer
role is disabled ats server level.
We now support querying metadata with our Rest API on all the i-refactory metadata entities. For example you could retrieve a list of completed entityUpdates for a given delivery. Or you could retrieve a list of persisted deliveries within a given timeframe with all the entityUpdates for each delivery nested. The results of these queries are automatically formatted as JSON documents with the proper nesting of detailed information for each root instance.
You now have the ability to set the time consistency to either LEAST
or GREATEST
for business rule helpers in a central facts model.
When executing a central facts business rule helper we must ensure that time consistent data is guaranteed. The most consistent setting for this option is using LEAST
. But this setting might result in less accurate data. Setting the time consistent filter to GREATEST
will result in more accurate data but may result in consistency problems.
You can change the setting with our Rest API or with the Web Application: Settings Menu -> Helper Entity.
Change | Summary |
---|---|
[IREFACTORY-1073] | Helpers in the central facts are not executed if the transaction datetime isn't greater than the last transaction datetime for the helper. The helper is however set to SUCCEEDED. In case of a least setting on a helper this reduces unnecessary processing time as no new facts will be created if the input hasn't changed the transaction time. In case of a greatest setting on a helper this prevents updating facts in the past (which is not allowed). |
[IREFACTORY-1002] | When starting the i-refactory backend server a check is now executed if an active server is not already running with a connection to the same sql server instance and the same i-refactory repository. This check prevents starting 2 or more servers on the same repository. |
[IREFACTORY-1045] | You can enter a message number and message text when creating a delivery. |
[IREFACTORY-1058] | Blocked interfaces in the monitor are now shown with a different colour. |
[IREFACTORY-1164] | An upgrade of the i-refactory backend took a long time because of updating entity-ids. Some entities are now excluded from this update which should result in faster upgrade times. |
[IREFACTORY-1169] | When verbose logging was turned on the database password was written to the logfile. |
[IREFACTORY-1178] | In context based filters code was generated with duplicate exists queries. Although not incorrect these duplicate paths are now eliminated. Sometimes the generated code resulted in SQL Server not being able to generate an explain plan resulting in an error: query too complex. |
[IREFACTORY-1149] | More verbose logging is now generated in debug modus allowing for a more detailed analysis of what is going on in the execution of entity updates. |
Issue | Summary |
---|---|
[IREFACTORY-895] | Grid row remains in edit state if the contents of the row did not change. |
[IREFACTORY-921] | Both client and serverside errors are not cleared when clicking on the cancel button. |
[IREFACTORY-964] | (User)Grouped tables are indented wrong. |
[IREFACTORY-1019] | Status gauges not on "red" if there is a failed task. |
[IREFACTORY-1074] | Reference lookup doesn't open on focus. |
[IREFACTORY-1110] | Locking: lock on completion of process task. |
[IREFACTORY-1112] | ModelSql: error message "Duplicate interface on architecturelayer" throws. |
[IREFACTORY-1124] | Duplicate key error when importing metadata related to helperEntities linked to a set based constraint in logical staging. |
[IREFACTORY-1132] | Metadata import - upgrade error namespace already exists. |
[IREFACTORY-1133] | Metadata import - entityId for iRefactory metadata is not updated on upgrade. |
[IREFACTORY-1139] | Triggers on bi-temporal, multi-active entities not generated correctly. |
[IREFACTORY-1150] | DNB CBS: Validation entity updates succeeded twice. |
[IREFACTORY-1171] | Read request: TypeError: Cannot read property 'isDerivedSubtype' of undefined. |
[IREFACTORY-1185] | ConnectionQueue: fatal lock timeout while processing task. |