In this section we show how to create a new delivery agreement. In order to be able to receive data from a specific tenant, a delivery agreement between i-refactory and the tenant must be created.
{warning} A delivery agreement can only be created if an interface and a tenant already exists.
To create a new delivery agreement:
Management > Delivery Agreement
New
Only for Delivery Agreements on the Logical Validation Layer (HSTGIN)
include Existing Data For Skipped Rows In Set Validation
:
In a delivery, if basic constraints are violated and rows are rejected, i-refactory will by default try to fetch the known data of these rejected rows from previous deliveries. The default behavior can be changed for deliveries see i-refactory server release notes v.3.2.0 for more details
Default
: inherits the value from the interfaceYes
: i-refactory tries to fetch the known data of these rejected rows from previous deliveries. This data is then used to perform set validations on rows in the current delivery that did not get rejected.No
: If this flag is set to 'NO' the i-refactory will not fetch the data of skipped rows for set validation.include Existing Data For Skipped Rows In Set Validation Conclusion
shows the computed value for this Delivery Agreement.
The table below shows how includeExistingDataForSkippedRowsInSetValidationConclusion
is computed for a Delivery Agreement vis-a-vis the Interface.Delivery Agreement value | Interface value | Delivery Agreement Conclusion |
---|---|---|
DEFAULT | YES | YES |
DEFAULT | NO | NO |
YES | NO | YES |
NO | YES | NO |
{note} This setting can also be found when creating an individual delivery, the setting there takes precedence over the delivery agreement.
maxConcurrentEntityUpdates
. The sum of entity updates used by this delivery shall not exceed this limit.defaultMaxConcurrentEntityUpdates
. Value used for a delivery if the delivery doesn't specify a maximum of entity updates.defaultReservedEntityUpdates
. The number of entity updates that should be reserved for this delivery agreement. If the delivery doesn't specify a reservation, this value is used.maxReservedEntityUpdates
. The sum of reservations made by deliveries for this delivery agreement cannot exceed the number speficied here.Effective From
and Effective To
dates)Save
buttonAfter these steps, you have successfully created a new delivery agreement. You can modify the delivery agreement by using the pencil icon.
You can use our API /acmDatadel/deliveryAgreement
to create, read, update and delete delivery agreement data.
The main purpose of the Logical Validation Layer (LVL) is to transform the data received from external data sources to fit into the logical data model structure. It is also responsible for validating deliveries. The Logical Validation Layer is also known as the Historical Staging In (HSTGIN) Layer.
A schema is a set of database objects, such as tables, views, triggers, stored procedures, etc. In some databases a schema is called a namespace
. A schema always belongs to one database. However, a database may have one or multiple schema's. A database administrator (DBA) can set different user permissions for each schema.
Each database represents tables internally as <schema_name>.<table_name>
, for example tpc_h.customer
. A schema helps to distinguish between tables belonging to different data sources. For example, two tables in two schema's can share the same name: tpc_h.customer
and complaints.customer
.
A Physical Data Model (PDM) represents how data will be implemented in a specific database.
{note} The i-refactory uses four PDMs: technical staging model, logical validation model, central facts model and generic access model. Each one of these models is implemented as an additional database, which is used to store data from external and internal data sources.
After you have changed the data model, you need to update the data model version. This way, you can keep track of the model releases.
Model > Properties
. Model Properties
. Model Properties
window opens. Change the version number next to Version
. OK
.It is a good practice to change the model version of every physical data model. The standard for versioning depends on the client. In most cases a version number such as 1.0.0 is used, where the third digit is updated during minor changes and the second digit by major changes.
{info} The model version of the logical validation model is displayed in the i-refactory monitor.
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.