iWay MDS Storage

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:


Top of page

x
iWay MDS Repository

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.



x
Unification Repository Conversion

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.



x
Unification Step Procedure

The Unification step is no longer compatible with the NME engine in terms of processing capability and repository format.

  1. Replace the Unification step with the Extended Unification step.
  2. Map the configuration of the old Unification step to the new Extended Unification step.
  3. Follow one of the upgrade procedures designed for the Extended Unification step:
    • Full Reprocess.
    • Migration Procedure (you can use the Unification Reader step instead of the Extended Unification Reader step).


x
Extended Unification Step Procedure

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:


iWay Software