|Skip Navigation Links|
|Exit Print View|
|Maintaining Oracle Java CAPS Master Indexes (Repository) Java CAPS Documentation|
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 disable the master index server project, regenerate the application, and then redeploy the project. If any Java Collaborations in client projects reference the master index application, you must re-import the regenerated .jar files from the master index server project into the Java Collaboration.
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 EDM, make sure to add them to the first section of the Enterprise Data Manager file 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 the Match Field file.
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 the Match Field file.
If the new fields or objects will be included in incoming messages, add them to the inbound OTD structure (the outbound OTD will be updated when you regenerate the application).
If you define normalization, standardization, or phonetic encoding for fields that are not currently defined in the Match Field file, or if you change existing standardization structures, make sure to do the following.
Use the appropriate standardization type, domain selector, and field IDs.
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 the Candidate Select file 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.
Whenever changes are made to components of a master index project outside of the master index application, such as modifying the Connectivity Map, Adapter properties, Collaborations, or OTDs, the master index application does not need to be regenerated; however the project containing the changed components must be redeployed in order for the changes to take effect.
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 the Enterprise Data Manager file through the GlassFish 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. Any Collaborations that reference the master index application must also be recompiled and those projects redeployed. 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.