In this section: |
Currently, only the VLDB persistence should be used. If XML persistence was used before, it is recommended to drop it and process all the data again (matching ID will not be preserved). If the master ID and other inner values need to be preserved, you must proceed with the Migration Procedure.
Before proceeding to the next steps, make sure that:
Entity naming conventions are the same, and missing objects are added when the iWay MDS Server Version 9.0.1 and higher starts for the first time. In previous versions, all tables contained manually assigned origin IDs, but in version 9.0.1 and higher, hash keys are used, based on the origin.
Therefore, you must substitute the newly generated hash key codes in the <nme_prefix>_origin table with the original codes that were assigned manually in the previous iWay MDS configuration.
Sample Origin ID Update
The following syntax shows the old instance mapping definition in model.gen.xml:
<originId name="crm_customer#Party" entity="party" code="10"/> <originId name="life_contract#Address" entity="address" code="21"/>
The following syntax shows the new instance mapping definition in nme-model.gen.xml:
<originId name="crm_customer#Party" entity="party"/> <originId name="life_contract#Address" entity="address"/>
The Origin ID (code column) is available in <nme_prefix>_origin, as shown in the following table:
Code | Name |
---|---|
770337113944902314 | crm_customer#Party |
5828609280688235874 | life_contract#Address |
You can update <nme_prefix>_origin with codes that were used in the obsolete model.gen.xml for each related origin:
Code | Name |
---|---|
10 | crm_customer#Party |
21 | life_contract#Address |
Note: After the <nme_prefix>_origin table has been updated, restarting the server is necessary. Alternatively, <nme_prefix>_origin can be created manually before server startup to avoid restarting.
Starting with iWay MDS Version 9.0.1 and higher, only the Extended Unification, together with VLDB persistence, should be used. Once iWay MDS controls the Extended Unification repository, it will contain a different naming convention and different internal structure (NME Extended Unification repository). All other formats are not supported and need to be converted for all Unification step occurrences.
The Unification step is no longer compatible with the NME engine in terms of processing capability and repository format.
Before converting the repository, rename the unification repositories for each matched entity, for example, change the rep_ prefix (if was used) to rep2_ in the Extended Unification step in matching plans. Alternatively, remove the rep_ prefix in matching plans.
Note that the table-naming convention in the repository has changed: by default, the a_ prefix is added to each table, for example, from rep_party to a_rep_party. The prefix can be configured in nme-config.xml. For more information or a configuration sample, see the NME Configuration section in the iWay Master Data Server Reference Guide.
Follow one of the upgrade approaches described below:
insert into <prefix><repository_name>_meta select maxId, records, props from <repository_name>_meta insert into <prefix><repository_name>_form select fmid, format from <repository_name>_form insert into <prefix><repository_name>_data (pk, its, ots, fmid, data1, data2, xid, xctid) select pk, its, ots, fmid, data1, data2, row_number() over (order by pk), 0 from <repository_name>_data insert into <prefix><repository_name>_keys (pk, op, ukey, gid, center, xid, xctid) select pk, op, ukey, gid, center, row_number() over (order by pk), 0 from <repository_name>_keys
Full Reprocess
The NME Extended Unification repository will be created from scratch and master ID will not be preserved.
Use the following quick method if you do not need to preserve master IDs.
Notes:
iWay Software |