Editing Configuration Files

In this section:

Model Project Verification Checkpoint

Before editing files described in this section, you must first re-generate the whole project.

To change a configuration file, see the General MDM project: CDI example template, or see the iWay Master Data Server Reference Guide for the current form of configuration. You can also see the iWay MDS Product Help by clicking Help, selecting Help Contents, iWay Master Data Server, Advanced Usage, and clicking Server Configuration.

It is recommended that if your current server configuration is not too complicated, you can copy mdm.serverConfig, mdm.runtimeConfig, and nme-config.xml from the General MDM project: CDI example template, and edit them according to your previous configuration.

Editing nme-config.xml

Configure the VLDB persistence and use the already configured Apache Derby as storage, as shown in the following persistence layer configuration:

<persistenceLayer class="com.ataccama.nme.persistence.vldb.
VldbPersistenceFactory">
	<dataSource>mds_db</dataSource>
	<prefix>A_</prefix>
</persistenceLayer>

Change the naming convention of related configuration files to the new naming convention:
- nme-model.gen.xml
- nme-batch.gen.xml
- nme- executor.xml
- nmeservice.gen.xml

Configuring default.serverConfig

If XML persistence was used:

Add DerbyServerComponent into serverConfig, as shown in the following DerbyServerComponent configuration syntax:

<component class="com.ataccama.server.component.derby.
DerbyServerComponent">
	<port>1527</port>
	<dataDir>../storage/derby</dataDir>
</component>

Create a *.runtimeConfig file and configure a connection string to the Derby DB. You can also run a *.runtimeConfig export from the developer GUI.

<dataSource>
	<name>mds_db</name>
	<driverclass>org.apache.derby.jdbc.ClientDriver</driverclass>
	<url>jdbc:derby://localhost:1527/mds;create=true</url>
	<user>admin</user>
	<password>admin</password>
</dataSource>

If XML Persistence was not used:
1. Move the databaseConnections and pathvars section to a newly created *.runtimeConfig file, as shown in the following pathVariable configuration syntax:
```
<pathVariables>
	<pathVariable name="EXT" value="../data/ext"/>
	<pathVariable name="DATA" value="../data"/>
</pathVariables>
```
2. Replace the databaseConnection and pathvars section by a link to the *.runtimeConfig file.
```
<runtimeConfiguration>mdm.runtimeConfig
</runtimeConfiguration>
```
Adjust some server components to a multi-folder version (for example, workflow and online services).

Load Plans

Move the column mapping from a custom step (for example, Alter Format) to map_<entityname>_source_columns (you can leave the origin since it is mapped automatically in map_internal_columns_from_<source table>_to_<entity name>).
Remove the old steps and connect the new generated steps to the input and output steps.
If some pre-generated steps are missing, check the load plan definition by clicking on ConnectedSystems, selecting your system [system], Load Operations, and clicking [load operation].

Top of page

Model Project Verification Checkpoint

At this stage, you can validate that all the changes you have made to the metadata, plans, components, and so on, are correct (for example, relative paths, path variables, lookups, and more). Create a copy of mdm.runtimeConfig called mdm_test.runtimeConfig, which will be used for testing, and change the dataSources elements connecting to a clean (empty) DB environment. If you run the iWay MDS application using the testing runtimeConfig, the application should start up correctly, creating a new empty iWay MDS storage in the new format.

All the configured interfaces should also be working properly. You check this by viewing the Administration Console. You can manually test the iWay MDS process (data load, export, online WS, and so on) with small data sets (tens or hundreds of records) to confirm that everything runs accordingly.

iWay Software