The Data Delivery Register
provides metadata about deliveries in general, delivery agreements, delivered entities and tenants.
To retrieve the current state of each element, i.e., all the metadata related to that element, you can use the i-refactory REST API or the views available in the Data Delivery Register
.
View: [acm_datadel].[tenant]
id
: identifier of the tenantcode
: tenant codename
: name of delivering partdescription
: tenant descriptionView: [acm_datadel].[delivery]
id
: This the id of a deliverydelivery_agreement_id
: Every delivery needs to assigned to a delivery agreementreceived_dt
: This a timestamp of the delivery. This field is required. It needs to be always later vis-a-vis previous deliveries per delivery agreementsent_dt
: This timestamp refers to the time when the delivery was sent to the I-refact application so that it can be processed. It is optional and it has no consequencesstatus_code
: This is the status of a delivery.message_nbr
: Optional. Solely for housekeeping/notetaking purposes.message_text
: Optional. Solely for housekeeping/notetaking purposes.constraints_to_validate
violated_constraint_max_sample_size
: Optional. The default size of the violated constraints is 1000.logical_validation_delivery_delete_type
: There are two options Logical
and Physical
generic_data_access_delivery_physical_delete_allowed
: Indicates whether physical deletes are allowed on a CRUD deliverylog_info_cleaned
: it shows whether the log with violation constraints are deletedcontext_related_entities_contain_new_rows
include_existing_data_for_skipped_rows_in_set_validation
include_existing_data_for_skipped_rows_in_set_validation_conclusion
max_concurrent_entity_updates
reserved_entity_updates
View: [acm_datadel].[delivery_agreement]
id
: idinterface_id
: id of [acm_datadef].[interface]tenant_id
: id of [acm_datadel].[tenant]description
: descriptioneffective_from_dt
: start of agreementeffective_to_dt
: end of agreementcode
: delivery code agreementinclude_existing_data_for_skipped_rows_in_set_validation
include_existing_data_for_skipped_rows_in_set_validation_conclusion
max_concurrent_entity_updates
default_max_concurrent_entity_updates
max_reserved_entity_updates
default_reserved_entity_updates
View: [acm_datadel].[delivered_entity]
id
: identifier of the delivered entitydelivery_id
: delivery identity_id
: entity idsnapshot_dt
: this returns the time for the snapshot of the entity within a deliveryis_complete
: whether the entity is delivered full or partial.View: [acm_datadel].[agreement_based_constraint]
id
: iddelivery_agreement_id
: the id of [acm_datadel].[delivery_agreement]
constraint_id
: the id of [acm_datadef].[constraint]
threshold_absolute
: the maximum constraint violation thresholdapplicable_constraint_violation_action_id
: the id of [acm_datadef].[applicable_constraint_violation_action]
View: [acm_datadel].[delivery_violated_constraint_count]
id
: the delivery idconstraint_id
: the id of [acm_datadef].[constraint]
entity_id
: the id of [acm_datadef].[entity]
violation_count
: violation count-- Select details of delivery agreements
SELECT id
, interface_id
, tenant_id
, description
, effective_from_dt
, effective_to_dt
, code
, include_existing_data_for_skipped_rows_in_set_validation
, include_existing_data_for_skipped_rows_in_set_validation_conclusion
, max_concurrent_entity_updates
, default_max_concurrent_entity_updates
, max_reserved_entity_updates
, default_reserved_entity_updates
, acm_exists_ind
, acm_last_created_dt
, acm_start_dt
, acm_end_dt
, acm_record_ind
, acm_modifier_id
, acm_entity_id
FROM ACME.acm_datadel.delivery_agreement
;
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.