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. Currently,
the only values allowed are Oracle and 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 Oracle or SQL Server naming conventions,
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 EDM 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 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. 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.
|