Configuring Sun Master Indexes (Repository)

Master Index Field Properties and Name Restrictions (Repository)

Once you create the object structure of the master index application, you can customize several properties for each field, such as whether the field is required, will include a drop-down menu on the EDM, will be used in a blocking query, and so on. There are also some restrictions for how fields can be named and how the properties are defined on the Configuration Editor and in the configuration files.

The following topics provide information about the naming restrictions and about the field properties of the wizard.

Master Index Field Name Restrictions (Repository)

When you name the fields in your object structure, be sure to keep the following guidelines in mind to avoid errors when compiling or running the master index application.

Master Index Configuration Editor Field Properties (Repository)

The following table lists and describes the properties you can define on the Field Properties page of the Configuration Editor.

Property

Description 

Name

A name for the field. See Master Index Field Name Restrictions (Repository) for information on valid field names.

Data Type

The data type for each field. Possible data types are: 

  • string - Fields of this type contain a string of characters.

  • date - Fields of this type contain a date value.

  • float - Fields of this type contain a floating point integer.

  • int - Fields of this type contain an integer.

  • char - Fields of this type contain a single character.

  • boolean - Fields of this type can contain either true or false.

Match Type

The type of matching to be performed against the field, if the field is to be used for match weight generation. You must define at least one field for matching or no weights will be generated. 


Note –

The match types you specify here define the structure of the Match Field file, including the match string. The match types in the Match Field file might differ from the match types specified here. See Master Index Match Types and Field Names (Repository), in Understanding Sun Master Index Processing (Repository) for information about the available options for this field.


Blocking

An indicator of whether the field will be used in the blocking query. Select this option to add the field to the blocking query; deselect this option to omit the field from the blocking query. 

Key Type

An indicator of whether the field is used to identify unique objects. For example, a business index might store several addresses for each business. Each address is assigned an address type and each business can only have one address of each type. Select this option if the field is a unique record identifier; otherwise, deselect it. 

Key type fields should also be required fields unless a combination of fields are specified as key types for an object. 


Note –

It is recommended that each child object contain a key type field, but this is not required. If child objects do not contain one or more key type fields, each enterprise object might accumulate a very large number of child objects depending on the survivor strategy used.


Updateable

An indicator of whether the field can be updated from the EDM and external system messages. Select this option if the field can be updated; otherwise deselect it. 

Required

An indicator of whether the field is required in order to save an enterprise object to the database. Select this option if the field is required; otherwise, deselect it. 

Field Size

The number of characters allowed in each field. This determines the number of characters allowed in the database columns and defines the maximum number of characters that can be entered into each field on the EDM. 

Pattern

The required data pattern for the field. For more information about possible values and using Java patterns, see “Patterns” in the class list for java.util.regex in the Javadocs provided with the J2SE Platform. You might want to define patterns for date, telephone, or SSN fields. Note that for the EDM, the pattern is further restricted by the value entered for the input mask described later in this table. If no input mask is specified, all regex patterns are supported.

Code Module

The identification code for the drop-down list that appears for this field in the EDM. 


Note –

This must match an entry in the code column of the sbyn_common_header database table and, by default, an entry for the code you enter is created in the Code List database script. You can further customize code lists directly in the Code List script.


User Code

The processing code for the drop-down list that appears on the EDM for the fields defined by the constraint–by property, described below. These codes are used for non-unique IDs, such as account numbers, insurance policies, credit cards, and so on.


Note –

This must match an entry in the code_list column of the sbyn_user_code database table.


Constrained By

The name of the field that contains the corresponding User Code value (described above) to use to validate the current field. The User Code and Constrained By properties are used in conjunction to define non-unique ID types, such as credit card numbers or account numbers. The first purpose is to define a drop-down list for the field that contains the User Code value. The second purpose is to validate the field that contains the Constrained By value against definitions for the field with the user code value. 

For example, if you store non-unique IDs such as credit card numbers or insurance policy numbers, you could create a field named ID Type with a User Code of CREDCARD (CREDCARD also needs to be defined as a code in the sbyn_user_code table). This gives the ID Type field a drop-down list based on the definitions for CREDCARD in the sbyn_user_code table. Definitions would be VISA, MASTERCARD, AMEX, and so on. You could then create a field named ID that would be constrained by the formats defined for the ID Type field. Any credit card numbers you enter would be validated against the format defined for the type of credit card you selected in ID Type.

Display Name

The name of the field as it will appear on the EDM. 

Input Mask

A mask used by the GUI to add punctuation to a field. For example, if users enter the date in the format MMDDYYYY, you can add an input mask to display the dates as MM/DD/YYYY. Use the value mask (described below) to strip the punctuation from the value before storing it in the database. 

To define an input mask, type a character type for each character in the field and place any necessary punctuation between the character types. For example, the input mask for the above date format is DD/DD/DDDD. 

Note that the value you enter can further restrict the data pattern for the field (this is the Pattern property). The following character types can be used. 

  • D – indicates a numeric character.

  • L – indicates an alphabetic character.

  • A – indicates an alphanumeric character.

Value Mask

A mask used by the index to strip any extra characters that were added by the input mask (see above). This mask ensures that data is stored in the database in the correct format. 

To specify a value mask, type the same value as is entered for the input mask, but type an “x” in place of each punctuation mark. For example, if an SSN field has an input mask of DDD-DD-DDDD, specify a value mask of DDDxDDxDDDD to strip the dashes before storing the SSN. A value mask is not required for date fields.  

Master Index Field Property Elements (Repository)

The following table lists and describes the properties you can define for each field inthe Object Definition file.

Element 

Description 

field-name

The name of the field. Follow the guidelines under Master Index Field Name Restrictions (Repository) when naming fields.

field-type

The data type of the field. Possible values are: 

  • string - Fields of this type contain a string of characters.

  • date - Fields of this type contain a date value.

  • float - Fields of this type contain a floating point integer.

  • int - Fields of this type contain an integer.

  • char - Fields of this type contain a single character.

  • boolean - Fields of this type can contain either “true” or “false”.

size

The number of characters allowed in each field. If you modify this element, be sure to modify the length of the corresponding database column accordingly. 

updateable

An indicator of whether the field can be updated from the EDM or by back-end messages. Specify true if the field can be updated, or specify false if it cannot.

required

An indicator of whether the field is required in order to save an enterprise object in the database. Specify true if the field is required, or specify false if it is not.

code-module

The identification code for the menu list that appears for this field in the EDM. This must match a value in the code column of the sbyn_comment_header database table. This element is optional. 

maximum-value

The maximum value allowed in the field. To specify a value for a date field, use the format YYYY-MM-DD. This element is optional. 

minimum-value

The minimum value allowed in the field. To specify a value for a date field, use the format YYYY-MM-DD. This element is optional. 

pattern

The required pattern for the field. For more information about possible values and using Java patterns, see “Patterns” in the class list for java.util.regex in the Javadocs provided with J2SE Platform. You might want to define patterns for date, telephone, or SSN fields. Note that for the EDM, the pattern is further restricted by the value entered for the input mask. If no input mask is specified, all regex patterns are supported.

This element is optional. 

user-code

The processing code for the drop-down list that appears on the MIDM for the fields defined by the constraint–by property, described below. These codes are used for non-unique IDs, such as account numbers, insurance policies, credit cards, and so on.


Note –

This must match an entry in the code_list column of the sbyn_user_code database table.


constraint-by

The name of the field that contains the corresponding user–code value (described above) to use to validate the current field. The user–code and constraint-by properties are used in conjunction to define non-unique ID types, such as credit card numbers or account numbers. The first purpose is to define a drop-down list for the field that contains the user code value. The second purpose is to validate the field that contains the constraint value against definitions for the field with the user code value.

For example, if you store non-unique IDs such as credit card numbers or insurance policy numbers, you could create a field named ID Type with a user–code of CREDCARD (CREDCARD also needs to be defined as a code in the sbyn_user_code table). This gives the ID Type field a drop-down list based on the definitions for CREDCARD in the sbyn_user_code table. Definitions would be VISA, MASTERCARD, AMEX, and so on. You could then create a field named ID that would be constrained by the formats defined for the ID Type field. Any credit card numbers you enter would be validated against the format defined for the type of credit card you selected in ID Type.

key-type

An indicator of whether the field is used to identify unique objects. Specify true if the element is a unique object identifier; specify false if it is not. Key type fields should also be required fields unless a combination of fields are specified as key types for an object. This element is optional.


Note –

Each child object should contain at least one field that is a unique object identifier, but this is not required. If two or more fields are unique identifiers, the combined value of these fields must be unique in a given enterprise record.