|
name
|
The name of the master index application. This name must match
the name of the parent object.
|
|
database
|
The database platform used by the master index application.
Specify MySQL, Oracle or SQL Server.
|
|
dateformat
|
The date format to use for the master index application. Three
formats are allowed for the date: MM/dd/yyyy, yyyy/MM/dd, and dd/MM/yyyy.
|
|
nodes
|
The configuration information for an object. There can be multiple nodes elements, each defining one parent or child object
in the object structure. Each nodes element
also defines the fields contained in each object along with the field
attributes. The object structure must include one parent object and
can include several child objects or no child objects.
|
|
tag
|
The name of the parent or child object defined by the nodes element.
Note –
Due to database naming constraints, the length of the
name of the parent object plus the length of any child object name
must be 21 characters or less.
|
|
fields
|
The configuration information for a field. There can be multiple fields elements.
|
|
field-name
|
The name of the field. Follow these guidelines when naming fields.
-
The name cannot be longer than 30 characters.
-
The name cannot be objectId,
where object is the name of an object in
the data structure. For example, you cannot create a field named AddressId
if there is an Address object in the structure.
-
Field names must conform to naming conventions for
the database your are using, must conform to Java naming standards,
and cannot contain XML reserved characters.
|
|
field-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.
-
byte - 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 value, be sure to modify the corresponding database column accordingly.
|
|
updateable
|
An indicator of whether the field can be updated using the MIDM or
from 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 MIDM. This must match a value in the code column
of the sbyn_common_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. 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.
This element is optional.
Note –
Each child object should contain at
least one field that is a unique object identifier, but it 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.
|
|
relationships
|
The configuration information for the hierarchy of the objects
you defined in the nodes elements. Only one
object can be the parent object; the remaining objects must be defined
as children. The relationship definition allows a record to contain
multiple instances of each child object. For example, if you define
Address and Telephone child objects, the record can contain multiple
addresses and telephone numbers.
|
|
name
|
The name of the parent object, as defined in the nodes elements.
|
|
children
|
The name of a child object, as defined in the nodes elements.
You can define multiple children elements.
|
