After a master index application has been in production, you might need to make changes to your project. For example, if you add a new external system, you need to add that system to the master index database and you might need to modify the object structure and OTDs as well as update the application files. Changes occur as the needs of your end users evolve and as additional external systems are added. Do not make changes to the system hastily. Handle changes using the same change management process that was originally used to deploy your project. Applying this same process of planning, configuration, testing, migration, monitoring, and reevaluation will help ensure successful updates.
Over time, you might need to make changes to your configuration files, such as adding fields or objects to the object structure, changing queries, or fine-tuning the matching process. Whenever you make a change to a master index configuration file, you must undeploy the master index server project, regenerate the application, and then redeploy the project.
This section provides tips for updating components of the configuration files. In order for any of these changes to take affect, you must regenerate the application and rebuild and redeploy the project.
If you make any changes to the object structure, keep the following in mind.
If you want the new fields or objects to appear on the MIDM, make sure to add them to the first section of midm.xml and to any of the page definitions later in the file (this includes search pages).
If the new fields require normalization, parsing, or phonetic encoding, define the new structures in mefa.xml.
If a new field will be used for matching, add it to the blocking query used for match processing as well as to the match string in mefa.xml.
If you define normalization, standardization, or phonetic encoding for fields that are not currently defined in mefa.xml, or if you change existing standardization structures, make sure to do the following.
Use the appropriate standardization type, domain selector, and field IDs.
Add the new fields that will store the standardized versions of the original field value to the appropriate objects in object.xml.
Add new columns to the database to store the standardized field values.
If you make changes to the match string, update the database indexes and the blocking query in query.xml accordingly. For example, if you remove a field from the match string, you might also want to remove that field from the blocking query and database indexes. If you add a field to the match string, add the field to the blocking query and to the appropriate database index to maintain performance.
There might be times when you need to modify the master index database. For example, you might need to add or modify a stored procedure or index, or you might need to add new external systems. You must modify the database if you add fields or objects to the object structure in order to reflect the new structure in the database tables. If you make changes to the database, rebuild and redeploy the master index server project to ensure the changes are picked up by the application.
You can define new users for the database at any time using standard SQL statements to create the type of user you want to define. You can also add new users for the midm.xml through the Sun Java System Application Server. Neither of these procedures require any stoppage of the database or of the master index application and redeployment is not required.
If you need to modify the local ID format for an external system, regenerate the application after you make the changes and then redeploy the project. If you extend the length of a local ID past 20 characters, make sure to increase the length of any database columns containing local IDs. Local ID columns are found in the following tables: sbyn_parent_object, sbyn_assumedmatch, sbyn_enterprise, sbyn_systemobject, and sbyn_transaction.