The object structure is defined in object.xml. The information entered into the default configuration file is based on the objects and fields you defined in the wizard. Depending on how completely you defined the object structure in the wizard, this file should not require customization.
The following topics provide information about working with object.xml:
When you use the wizard to define the object structure, all the configuration files for the master index application are automatically generated based on the information you provide. You can modify object.xml at any time prior to deploying the associated project, but you must regenerate the application and redeploy the project after doing so. If you modify the object structure using the configuration editor, the remaining configuration files are updated accordingly to keep them synchronized. If you update object structure by modifying the file directly, you also need to update the remaining configuration files. For example, if you modify the file directly and you delete a field from the object structure that also appears on the MIDM, appears in the SBR, and is defined for standardization and matching, you must remove the field from midm.xml, update.xml, and mefa.xml. Any changes made to the file without regenerating the project will not take effect.
The possible modifications to this file are restricted by the schema definition, so be sure to validate the file after making any changes.
This topic discusses MySQL configurastion. MySQL is only supposed in Java CAPS 6 Update 1.
This topic describes the structure of the XML file, general requirements, and constraints. It also provides a sample implementation.
Table 1 lists each element in object.xml and provides a description of each element along with any requirements or constraints for each element.
Table 1 object.xml File Structure
Following is a short sample illustrating the elements in object.xml. The DOB field shows usage of the minimum-value element, the SSN field shows usage of the pattern element, and the AddressType field illustrates the code-module element. The AddressType field also has the key-type set to true, meaning that each record can only contain one address of each address type.
<name>Person</name> <database>oracle</database> <dateformat>MM/dd/yyyy</dateformat> <nodes> <tag>Person</tag> <fields> <field-name>LastName</field-name> <field-type>string</field-type> <size>40</size> <updateable>true</updateable> <required>true</required> <key-type>false</key-type> </fields> <fields> <field-name>FirstName</field-name> <field-type>string</field-type> <size>40</size> <updateable>true</updateable> <required>true</required> <key-type>false</key-type> </fields> <fields> <field-name>DOB</field-name> <field-type>date</field-type> <updateable>true</updateable> <required>true</required> <minimum-value>1900-01-01</minimum-value> <key-type>false</key-type> </fields> <fields> <field-name>SSN</field-name> <field-type>string</field-type> <size>16</size> <updateable>true</updateable> <required>false</required> <pattern>[0-9]{9}</pattern> <key-type>false</key-type> </fields> </nodes> <nodes> <tag>Address</tag> <fields> <field-name>AddressType</field-name> <field-type>string</field-type> <size>8</size> <updateable>true</updateable> <required>true</required> <code-module>ADDRTYPE</code-module> <key-type>true</key-type> </fields> ... </nodes> <nodes> <tag>Phone</tag> ... </nodes> <relationships> <name>Person</name> <children>Address</children> <children>Phone</children> </relationships> |