Constraints are used to ensure the accuracy and the reliability of the data in the database. If you enable constraint validation during delivery, i-refactory can prevent non-compliant data from being further processed. The constraints are defined in the Logical Validation Model. After a metadata import, you can configure the constraints settings that specify how the i-refactory engine should deal with constraint violations.
You can influence validation behaviour on two levels:
Constraints settings can be configured for each model separately.
Menu > Management > Constraint Settings
You can configure tresholds per constraint. Tresholds define the maximum number of errors i-refactory accepts, before a delivery is refused. If you want a signaling constraint, then you need to set the threshold to a high number. The records of a Refused
delivery will not be stored in the Logical Validation Layer (LVL) or Central Facts Layer (CFL).
{info} By default, no tresholds are set: any validation error results in a rejection of the delivery - assuming you execute the Validation Process where at least the Default or Mandatory option is selected.
If the validation errors do not exceed a threshold value, these errors can be mitigated by an assigned action. Dependent on the type of constraint, a different set of options is available to chose from.
{warning} Selection of the action Skip Row could have a cascading effect if other entities or rules depend on the row you just skipped.
For each of the models you have the ability to export the constraint settings and import them into another environment. This will ensure synchronization of the constraint settings between the environments. The settings are exported in a JSON format.
To export:
Download
icon next to the interface To import:
Import constraints
Add file
and browse for one or more files and then start the import. The import is successful if:
thresholdAbsolute
are specified as integers and the values of constraintViolationActionCode
are specified as string.{info} The values for
thresholdAbsolute
andconstraintViolationActionCode
are always updated with the values from the import file, regardless the fact that someone has made changes to these settings manually. In other words, we do not check on lost updates.
Constraints settings can be configured specific for a delivery agreement. For example, if the threshold setting for a constraint delivered by Tenant A is different than for Tenant B. These settings will overrule the constraints settings at the interface level.
Menu > Management > Delivery Agreement Constraint Settings
pencil
icon and put a checkmark in the default
box. Configure the threshold
and/or action
.Default Constraint: Yes
To revert the delivery agreement constraint
Default Constraint: Yes
, select the constraint you want to modify. Click on the pencil
icon and unselect the checkbox default
box. The settings will revert back to the model constraint settings.To enable delivery agreement constraints during delivery:
When you create a new delivery, select the option Default
in the dropdown menu below Constraints To Validate
.
Similar to the valid timeline, a transaction timeline consists of a start date
and end date
.
It is the period during which a fact is valid in the system.
In the i-refactory the transaction time is tracked with acm_start_dt
and acm_end_date
.
The transaction time in i-refactory is different from what is commonly understood by transaction time. Transaction time is usually seen as the moment when a fact was stored in the database. In i-refactory the transaction time is as dictated by the source system, not by the i-refactory database.
The delivery tenant can specify with the snap_shot_date what the transaction start date (acm_start_dt
) has to be.
{warning} The transaction start date of a new delivery has to be later than the transaction start dates of earlier deliveries.