Feature | Summary |
---|---|
Web UI | Several usability improvements. |
Current Time Option | A business rule helper defined in a central facts model is now able to execute with current time in addition to least and greatest time. |
Cleanup of database objects | Several database objects (views, stored procedures, ...) generated for an entity are now removed during metadata import when the entity is removed from the model. |
DDL in sync | Checks on metadata and DDL synchronization. |
Unique Context Setting | You have the ability to create a logical delivery as a unique context in which case you make a promise that the delivered data contains new data only. This vastly improves the process of validation and data maintenance. |
Agreement Based Constraint Settings | Are automatically removed if the related system or user defined constraint is removed from a model. |
When a delivery or task is cancelled or retried a confirmation dialog is shown if you want to proceed. This feature was requested by our clients to not accidently cancel a delivery.
Improved the file name when downloading the errors of a metadata import. The file name now contains the end date and time of the import, the user that requested the import, and the name of the database were the imported metadata is stored.
The progress of the metadata import is displayed in a way that is more suitable/recognizable for users.
In the delivery statistics page you can now view the complete history of executed tasks, besides teh complete history of entity updates.
The setting Transactional Consistent Filter
can now be set to Current Time
as well.
In a Central Facts Model you have the ability to create Derived Datasets
by creating what we call a Helper Entity
. A Helper Entity
is a calculation of facts given a set of Input Datasets
. The calculation is automatically triggered by the i-refactory engine if it detects that one of the Input Datasets
used in the Helper Entity
are changed or delivered.
Because the Fact Store
stores a temporal view of all facts delivered over time the calculation of Derived Datasets
needs to take into account temporal consistency as well.
We've added a new option to the temporal consistent calculation of Derived Datasets
. Besides the options Least
and Greatest
we now also support Current Time
.
If Current Time
is chosen the variable @time_consistent_transaction_dt
will be set to the current time.
Note: you should always filter your context in the query specification on a consistent point in time as shown in the example query below.
WITH QRY AS
( SELECT @time_consistent_transaction_dt AS acm_start_dt
, 'N' AS acm_record_ind
, [h_order].[nbr] AS order_nbr
, [h_order].[id] AS order_id
, COUNT([l_order_line_items].[id]) AS nbr_of_lines
, SUM([l_order_line_items].[quantity]) AS quantity
, SUM([l_order_line_items].[revenue]) AS revenue
, SUM([l_order_line_items].[discounted_revenue]) AS discounted_revenue
, SUM([l_order_line_items].[discounted_revenue_plus_tax]) AS discounted_revenue_plus_tax
FROM [tpc_h].[h_order] AS [h_order]
LEFT
JOIN [tpc_h].[l_order_line_items] AS [l_order_line_items]
ON [l_order_line_items].[id] = [h_order].[id]
AND [l_order_line_items].[acm_start_dt] <= @time_consistent_transaction_dt
AND [l_order_line_items].[acm_end_dt] > @time_consistent_transaction_dt
WHERE [h_order].acm_exists_ind = 1
GROUP BY [h_order].[nbr], [h_order].[id]
)
During a metadata import of either a logical model or a generic data access model the i-refactory engine generates several SQLServer database objects. For a logical model this includes the generation of the intermediate storage tables to enable the validation of constraints. For a generic data access model this includes the generation of views and stored procedures.
However if your models change and certain metamodel objects are removed the generated objects for these removed metamodel objects were not automatically removed. From this release we will automatically remove the SQLServer objects for which no related metadata object exists anymore.
The i-refactory engine processes and stores data in a SQLServer database.
The required SQLServer objects are created with Data Definition Language
statements, in short DDL
.
Currently the creation of SQLServer objects is a 2 phase process:
When a model in Powerdesigner is changed and the Export DDL and Metadata
command is executed files are generated on the filesystem. This command will generated DDL scripts for the tables in a Technical, Logical Implementation and Fact Model and will also generate several installer scripts which will execute the DDL scripts in the proper order.
It's the responsibility of the modeller to:
Delta deployment script
in case of full/initial install of the tables is not desired for the mentioned models.For a Generic Data Access Model the generation of the relevant database objects is the responsiblity of the i-refactory engine. The metadata specification of a Generic Data Access Model and the related metadata (mapped) of the Fact Model are used to generate the Generic Data Access objects (views, triggers, stored procedures).
For a Logical Implementation model we have the same approach. In order to be able to validate all the constraints defined on a Logical Model we need intermediate storage. These intermediate storage tables are generated when the metadata specification of a Logical Model is processed with the i-refactory Rest API.
The generation of database object artefacts for a Generic Data Access Model or a Logical Implementation model might however fail (most often caused by the fact that the basic DDL statements for the Powerdesigner model have not been executed).
From this release on we will check if the i-refactory related DDL generation of a model is in sync with the metadata imported for the specific model. This status can be seen in the Web UI or can be requested through the Rest API.
In case the DDL is not in sync you cannot create deliveries on either a Generic Data Access or Logical Implementation Model (as it will definitly result in processing errors).
Note: in a future release of the i-refactory we will eliminate the DDL generation from Powerdesigner completely and generate all the DDL from the i-refactory engine. This will result in a more smooth deployment process of database related objects.
A new option is added to the creation of a Logical Delivery: contextRelatedEntitiesContainNewRows
. If this property is set to True
you make a promise that the set of delivered records for each context entity contain new records.
For example: Assume a "Unified Logical Data Model" for which several external Parties can deliver data for a given Report Period. And asssume that for each Party/Report Period the deliverd data set contains a disjunct set of records compared to all previous delivered data sets (in fact all the delivered data can be uniquely identified by Party/Report Data) you can mark the delivery as such.
If the property contextRelatedEntitiesContainNewRows
is set to True the i-refactory engine is able to optimize the generated code, taking into account this setting. Because a promise is made that the delivered data for a context entity contains new data only we are able to optimize the validation queries and the comparison of the delivered set of records against the previously delivered data sets.
Note: it is the responsibility of the system or person make the decision to set the property contextRelatedEntitiesContainNewRows
to true. It will vastly improve the processing speed at a certain risk of getting incorrect results if the delivered data does not hold it's promise that it contains new records for the given context.
When you've created a list of Agreement Based Constraint Settings
you manually needed to delete some of them if a constraint was removed from a Logical Implementation Model.
From now on we will automatically delete an Agreement Based Constraint Setting
if the related constraint is removed from the model.
/acmDatadef/interface
and /acmDatadef/deliverableInterface
New properties:
ddlGeneratedAT
: DateTime at which the i-refactory engine related DDL generation was succesfully executed for a Logical Implementation or Generic Data Access Model.metadataImportedAt
: DateTime at which the i-refactory engine succesfully imported the metadata for a given Interface.isDdlInSync
: False
if ddlGeneratedAt is less than metadataImportedAt./acmDatadel/delivery
and /acmDatadel/activeDelivery
New property:
False
/acmDatadef/helperEntity
CURRENT
for property transactionalConsistentFilter
The i-refactory runtime engine runs on NodeJS LTS version 10, 12 and 14.
Issue | Summary |
---|---|
196 | Server throws error “TypeError: Cannot set property 'Symbol(public)' of undefined” when a get request is executed that includes a left join or select to an i-refactory entity for which one of the selected records has no join. Example: https://localhost:3000/v1/acmDatalog/taskRun?select=["id","taskRunIdParent","startDt","sourceArchitectureLayerCode","statusCode","context","sourceNamespaceCode","sourceEntityCode","targetNamespaceCode","targetEntityCode","entityUpdate.id"]. Not all the task runs are entity updates. If the result set contains a task run without an entity update, the error is triggered. |
198 | When a delivery for a certain context contained records on a child entity outside the context of the parent entity then those rows were not skipped and always added as new rows which could result into errors when the rows were loaded into the central facts layer. |
202 | A killed database session was not correctly released, which resulted in less sessions available for other processes. |
206 | The value of an optional attribute with an enumeration, could not be set to null. For example: the value of “executeRowCount” of an interface could, once set, not be set to null. |