In this section we explain how to import the metadata generated by the i-refactory modeller into the i-refactory server.
Make sure the datamodel version is already implemented in the database with a full deployment or delta deployment.
To update the i-refactory metadata repository you need to import the metadata files created in PowerDesigner. It compares the metadata repository with the imported metadata and it will update the metadata repository, generate or alter constraints, views and functions.
You can import multiple metadata files for different models at the same time.
The import proces consists of the following steps:
On successful completion of each step, the changes will be saved. During the metadata import the SQL query will be checked. If there are any syntax errors, the metadata import will fail.
{warning} Be aware that a metadata-import is successful if all files are processed. If one file generates an error, the script will rollback to the earlier saved step and give the status Failed. So it's possible that step 1 (importing metadata) succeeds, but that an error occurs during step 2 (generate views). In that case, we advise you to import a new correct metadata file.
The i-refactory engine will do the following action if the metadata of a specific layer is imported:
object / layer | TSL | LVL | CPL | GDAL |
---|---|---|---|---|
entity | update metadata | update metadata | update metadata | NA |
view | update metadata | NA | update metadata | create / alter / drop |
BR helper | NA | create / alter / drop | create / alter | NA |
constraint | NA | update metadata | NA | NA |
function | NA | NA | NA | create / alter / drop |
{warning} Make sure the i-refactory metadata repository is up to date with the objects in the database, otherwise it may lead to unexpected errors. The i-refactory engine will call the objects in the database according to the metadata repository. If the corresponding metadata objects don't exists or are changed in the database, this may lead to unexpected results during data delivery. The order of the deployment is also important. Make sure the objects exists in the database, before you import the metadata. For example, if you import a GDAL view and it references a CPL object that not (yet) exists, the metadata import will result in an error.
To import metadata through the UI:
Datamodel > Import
.
NEW
.ADD FILE
.Garbage
icon to remove a file from the import list.
START IMPORT
. The import is added to the overview of imports and the import process starts.CLOSE
if you want to close the window.CLOSE
without starting the import process.As long as the import is running it will have the status Processing, when it is finished it either has the status Succeeded or Failed.
In case of a failed import you can download the results of the failure as a JSON file. It will contain (as far as possible) all the encountered errors on the most detailed level (file level, record level or attribute level.
Below you see an example of an data import error:
IR_CFPL.tpc_h.h_region
which doesn't seem to exists. Based on the error message we can infer that this is probably because the entityh_region
does not exists in the IR_CFPL
database.{
"@error": {
"onRequest": [
{
"context": "support.iRefactory.RestfulInterface",
"code": 16,
"message": "An error occurred while creating the gdal-views for interface TPC_H_GDAL.",
"data": [
{
"entity": "gdal.tpcHGdal.tpcH.region",
"error": {
"message": "A database error occured:\nRequestError: Invalid object name 'IR_CFPL.tpc_h.h_region'.",
"sql": "ALTER VIEW \"tpc_h\".\"region\" AS\nSELECT \n \"A\".\"id\" AS \"id\",\n \"A\".\"nbr\" AS \"nbr\",\n \"C1\".\"name\" AS \"name\",\n \"C1\".\"comment\" AS \"comment\",\n \"A\".\"acm_exists_ind\" AS \"acm_exists_ind\",\n \"A\".\"acm_last_created_dt\" AS \"acm_last_created_dt\",\n \"A\".\"acm_latest_start_dt\" AS \"acm_start_dt\",\n CASE \"A\".\"acm_latest_start_dt\"\nWHEN \"C1\".\"acm_start_dt\" THEN \"C1\".\"acm_end_dt\"\nEND AS \"acm_end_dt\",\n CASE\nWHEN \"A\".\"acm_latest_start_dt\" = \"A\".\"acm_last_created_dt\" THEN 'N'\nELSE 'A'\nEND AS \"acm_record_ind\",\n CASE \"A\".\"acm_latest_start_dt\"\nWHEN \"C1\".\"acm_start_dt\" THEN \"C1\".\"acm_modifier_id\"\nEND AS \"acm_modifier_id\"\nFROM \"IR_CFPL\".\"tpc_h\".\"h_region\" \"A\"\nLEFT JOIN \"IR_CFPL\".\"tpc_h\".\"h_region_s_properties\" \"C1\" ON \"A\".\"id\" = \"C1\".\"id\" AND ((\"C1\".\"acm_record_ind\" <> 'R')\n AND (\"C1\".\"acm_start_dt\" = (SELECT \n MAX(\"MC1\".\"acm_start_dt\") AS \"max_acm_start_dt\"\nFROM \"IR_CFPL\".\"tpc_h\".\"h_region_s_properties\" \"MC1\"\nWHERE \"MC1\".\"id\" = \"A\".\"id\"\n)))\nWHERE \"A\".\"acm_exists_ind\" = 1\n"
}
}
Importing the metadata through api calls is a two step asynchronous process:
acmDatacon/application/startImport
acmDatacon/application/importResults
When the import fails, you need to examine the root-cause and take appropriate actions to make sure next import will succeed.
{warning} The SQL code in your PowerDesigner models, for instance in (business rule) helpers, are not checked for correctness during the model check in PowerDesigner. During metadata import, the SQL syntax will be checked. If there are syntax mistakes, this will lead to an failed metadata import.
Context | Message Description | Possible Resolution | |
---|---|---|---|
support.iRefactory.Attribute | Missing Value | A mandatory attribute value is missing | This can happen in almost every object, entities, keys, relationships etc. You have to look for the context and target entity this attribute is related to. Then determine the object where the attribute is missing in Powerdesigner |
support.iRefactory.Record | Record already exists | A duplicate record is created, for example a duplicate relation or business key that has the same name | Remove duplicate |
support.iRefactory.Record | Referenced record not found | A Mapping is not found where is was expected | Check your mappings |
support.iRefactory.RestfulInterface | User errors encountered | There is an error in the restful interface | Take a look in the i-refactory log for errors |
support.iRefactory.RestfulInterface | Database error occurred:\nRequestError: Invalid object name | The object name is not found in the database | Check if the object exists in the database |
support.iRefactory.RestfulInterface | Cannot execute the request: action is blocked by another process | There is another process blocking the metadata import | |
acmDatadef.setConstraint | Referenced record not found. Relationship: Set Based Entity Constraint to Helper Entity Auxiliary | The set constraint is not found. Is the constraint helper available and the set constraint correctly attached? | |
support.iRefactory.MetadataImport | File is not valid JSON | The selected file is not an i-refactory metadata-file | Select the correct file |
support.iRefactory.MetadataImport | Entity does not exist | A referenced entity does not exist | When using shortcuts, or key-roots the referenced entity should exist in the metadata before importing your model |
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.