Constraints, triggers and functions

Last published : Aug 10, 2026
Related information

XML Schema supported facets

The tables below show the facets that are supported by different data types.
Key:
  • X - Supported
  • 1 - The whiteSpace facet can be defined, but is not interpreted by EBX®
  • 2 - In XML Schema, boundary facets are not allowed on the type string. Nevertheless, EBX® allows such facets as extensions.
  • 3 - The osd:resource type only supports the facet FacetOResource, which is required. See Extended Facets.
  • 4 - osd:dataspaceKey, osd:datasetName and osd:color types do not support facets. Only Programmatic constraints are supported on these types.
length minLength max Length pattern enumeration white Space
xs:string X X X X X 1
xs:boolean X 1
xs:decimal X X 1
xs:dateTime X X 1
xs:time X X 1
xs:date X X 1
xs:anyURI X X X X X 1
xs:Name X X X X X 1
xs:integer X X 1
osd:resource 3 1
osd:dataspaceKey 4 1
osd:datasetName 4 1
osd:color 4 1
fraction Digits total Digits max Inclusive max Exclusive min Inclusive min Exclusive
xs:string 2 2 2 2
xs:boolean
xs:decimal X X X X X X
xs:dateTime X X X X
xs:time X X X X
xs:date X X X X
xs:anyURI
xs:Name 2 2 2 2
xs:integer X X X X X X
osd:resource 3
osd:dataspaceKey 4
osd:datasetName 4
osd:color 4
Example:
<xs:element name="loanRate">
    <xs:simpleType>
        <xs:restriction base="xs:decimal">
            <xs:minInclusive value="4.5" />
            <xs:maxExclusive value="17.5" />
        </xs:restriction>
    </xs:simpleType>
</xs:element>

Uniqueness constraint

It is possible to define a uniqueness constraint, using the standard XML Schema element xs:unique. This constraint indicates that a value or a set of values has to be unique inside a table.
Example:
In the example below, a uniqueness constraint is defined on the 'publisher' table, for the target field 'name'. This means that no two records in the 'publisher' table can have the same name.
<xs:element name="publisher">
    ...
    <xs:complexType>
        <xs:sequence>
            ...
            <xs:element name="name" type="xs:string" />
            ...
        </xs:sequence>
    </xs:complexType>
    <xs:unique name="uniqueName">
        <xs:annotation>
            <xs:appinfo>
                <osd:validation>
                    <severity>error</severity>
                    <message>Name must be unique in table.</message>
                    <message xml:lang="en-US">Name must be unique in table.</message>
                    <message xml:lang="fr-FR">Le nom doit être unique dans la table.</message>
                </osd:validation>
            </xs:appinfo>
        </xs:annotation>
        <xs:selector xpath="." />
        <xs:field xpath="name" />
    </xs:unique>
</xs:element>
A uniqueness constraint has to be defined within a table and has the following properties:
Property Description Mandatory
name attribute Identifies the constraint in the data model. Yes
xs:selector element Indicates the table to which the uniqueness constraint applies using a restricted XPath expression ('..' is forbidden). It can also indicate an element within the table (without changing the meaning of the constraint). Yes
xs:field element Indicates the field in the context whose values must be unique, using a restricted XPath expression. It is possible to indicate that a set of values must be unique by defining multiple xs:field elements. Yes
Note:
Undefined values (null values) are ignored on uniqueness constraints applied to single fields. On multiple fields, undefined values are taken into account. That is, sets of values are considered as being duplicated if they have the same defined and undefined values.
Additional localized validation messages can be defined using the element osd:validation under the elements annotation/appinfo. If no custom validation messages are defined, a built-in validation message will be used.
Limitations:
  1. The target of the xs:field element must be in a table.
  2. The uniqueness constraint does not apply to fields inside an aggregated list.
  3. The uniqueness constraint does not apply to computed fields.
See also:

Extended facets

EBX® provides additional constraints that are not specified in XML Schema, but that are useful for managing master data.
In order to guarantee XML Schema conformance, these extended facets are defined under the element annotation/appinfo/otherFacets.

Foreign keys

EBX® allows to create a reference to an existing table by means of a specific facet. See Foreign keys for more information.

Dynamic constraints

Dynamic constraint facets retain the semantics of XML Schema, but the value attribute is replaced with a path attribute that allows fetching the value from another element. The available dynamic constraints are:
  • length
  • minLength
  • maxLength
  • maxInclusive
  • maxExclusive
  • minInclusive
  • minExclusive
    Using these facets, the data model can be modified dynamically.
    Example:
    <xs:element name="amount">
        <xs:annotation>
            <xs:appinfo>
                <osd:otherFacets>
                    <osd:minInclusive path="/domain/Loan/Pricing/AmountMini/amount" />
                </osd:otherFacets>
            </xs:appinfo>
        </xs:annotation>
          ...
    </xs:element>
    In this example, the boundary of the facet minInclusive is not statically defined. The value of the boundary comes from the node /domain/Loan/Pricing/AmountMini/amount.
    Restrictions:
  • Target field cannot be an aggregated list. That is, it cannot define maxOccurs = 1.
  • Data type of the target field must be compatible with the facet. That is, it must be:
    • of type integer for facets length, minLength and maxLength.
    • compatible with the data type of the field holding the facet for facets maxInclusive, maxExclusive, minInclusive and minExclusive.
  • Target field cannot be in a table if the field holding the facet is not in a table.
  • Target field must be in the same table or outside a table if the field holding the facet is in a table.
  • If the target field is under one or more aggregated lists, the field holding the facet must also be under these aggregated lists. That is: the field holding the facet must be in the same list occurrence as the target field, or in a parent occurrence, so that the target field refers to a single value, from an XPath perspective.

FacetOResource constraint

This facet must be defined for every definition using the type osd:resource, to specify the subset of available packaged resource files as an enumeration. For more information on this type, see osd:resource type. It has the following attributes:
moduleName
Indicates, using an alias, the EBX® module that contains the resource. If the resource is contained in the current module, the alias must be preceded by "wbp". Otherwise, the alias must be one of the values defined in the element <dependencies> in the file module.xml.
resourceType
Represents the resource type that is one of the following values: 'Image', 'JavaScript', 'Style sheet', 'HTML'.
relativePath
Indicates in which directory the resources will be located. This directory must be located under the directory that corresponds to the resource type. For example, for an "Image" type resource, the directory www/common/images/, located at the same level as the directory WEB-INF/ of the target module, will be used and the relative path will have to be defined from this. Furthermore, if a resource is defined in a localized directory (www/fr/ for example), it will only be taken into account if another resource with the same name is defined in the directory www/common/.
This facet has the same behavior as an enumeration facet: the values are collected by recursively listing all the files in the local path in the specified resource type directory in the specified module.
Example:
<xs:element name="promotion" type="osd:resource">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:FacetOResource osd:moduleName="wbp"
                    osd:resourceType="ext-images" osd:relativePath="promotion/" />
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
</ xs:element>
For an overview of the standard directory structure of an EBX® module (Java EE web application), see Module structure.

excludeValue constraint

This facet verifies that a value is not the same as the specified excluded value.
In this example, the empty string is excluded from the allowed values.
Example:
<xs:element name="roleName">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:excludeValue value="">
                    <osd:validation>
                        <severity>error</severity>
                         <message>Please select address role(s).</message>
                    </osd:validation>
                </osd:excludeValue>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
    <xs:simpleType type="xs:string" />
</xs:element>

excludeSegment constraint

This facet verifies that a value is not included in a range of values. Boundaries are excluded.
Example:
In this example, values between 20000 and 20999 are not allowed.
<xs:element name="zipCode">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:excludeSegment minValue="20000" maxValue="20999">
                    <osd:validation>
                        <severity>error</severity>
                         <message>Postal code not valid.</message>
                    </osd:validation>
                </osd:excludeSegment>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
    <xs:simpleType type="xs:string" />
</xs:element>

Enumeration facet defined using another node

By default, an enumeration facet is described statically in XML Schema.
The content of an enumeration facet can also be provided dynamically by a list of simple elements in the data model.
Example:
In this example, the content of an enumeration facet is sourced from the node CountryList.
<xs:annotation>
    <xs:appinfo>
        <osd:otherFacets>
            <osd:enumeration osd:path="../CountryList" />
        </osd:otherFacets>
    </xs:appinfo>
</xs:annotation>
The referred node CountryList:
  • Must be an aggregated list, that is, maxOccurs > 1.
  • Must be a list of elements of the same type as the node with the enumeration facet.
  • Must be a node outside a table if the node with the enumeration facet is not inside a table.
  • Must be a node outside a table or in the same table as the node with the enumeration facet if the node with this enumeration is inside a table.
  • If the target field is under one or more aggregated lists, the field holding the facet must also be under these aggregated lists. That is: the field holding the facet must be in the same list occurrence as the target field, or in a parent occurrence, so that the target field refers to a single value, from an XPath perspective.
Example:
<xs:element name="FacetEnumBasedOnList">
    <xs:complexType>
        <xs:sequence>
            <xs:element name="CountryList" maxOccurs="unbounded">
                <xs:simpleType>
                    <xs:restriction base="xs:string">
                        <xs:enumeration value="DE" osd:label="Germany" />
                        <xs:enumeration value="AT" osd:label="Austria" />
                        <xs:enumeration value="BE" osd:label="Belgium" />
                        <xs:enumeration value="JP" osd:label="Japan" />
                        <xs:enumeration value="KR" osd:label="Korea" />
                        <xs:enumeration value="CN" osd:label="China" />
                    </xs:restriction>
                </xs:simpleType>
            </xs:element>
            <xs:element name="CountryChoice" type="xs:string">
                <xs:annotation>
                    <xs:appinfo>
                        <osd:otherFacets>
                            <osd:enumeration osd:path="../CountryList" />
                        </osd:otherFacets>
                    </xs:appinfo>
                </xs:annotation>
            </xs:element>
        </xs:sequence>
    </xs:complexType>
</xs:element>

Programmatic facets

A programmatic constraint can be added to any XML element declaration for a simple type.
In order to guarantee XML Schema conformance, programmatic constraints are specified under the element annotation/appinfo/otherFacets.

Programmatic constraints

A programmatic constraint is defined by a Java class that implements the interface Constraint.
As additional parameters can be defined, the implemented Java class must conform to the JavaBean protocol.
Example:
In the example below, the Java class must define the methods: getParam1(), setParam1(String), getParamX(), setParamX(String), etc.
<xs:element name="amount">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:constraint class="com.foo.CheckAmount">
                    <param1>...</param1>
                    <param...n>...</param...n>
                </osd:constraint>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
    ...
</xs:element>
See also:

Programmatic enumeration constraints

An enumeration constraint adds an ordered list of values to a basic programmatic constraint. This facet allows selecting a value from a list. It is defined by a Java class that implements the interface ConstraintEnumeration.
Example:
<xs:element name="amount">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:constraintEnumeration class="com.foo.CheckAmountInEnumeration">
                    <param1>...</param1>
                    <param...n>...</param...n>
                </osd:constraintEnumeration>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
    ...
</xs:element>

Constraint on 'null' values

In some cases, a value is only mandatory if some conditions are satisfied, for example, if another field has a given value. In this case, the standard XML Schema attribute minOccurs is insufficient because it is static.
In order to check if a value is mandatory according to its context, the following requirements must be satisfied:
  1. A programmatic constraint must be defined by a Java class (see above).
  2. This class must implement the interface ConstraintOnNull.
  3. The XML Schema cardinality attributes must specify that the element is optional ( minOccurs="0" and maxOccurs="1" ).
Note:
By default, constraints on 'null' values are not checked upon user input. In order to enable a check at the input, the 'checkNullInput' property must be set. Also, if the element is terminal, the dataset must also be activated.
Example:
<xs:element name="amount" minOccurs="0" maxOccurs="1">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:constraint class="com.foo.CheckIfNull">
                    <param1>...</param1>
                    <param...n>...</param...n>
                </osd:constraint>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
    ...
</xs:element>

Constraints on table

A constraint on table is defined by a Java class that implements the interface ConstraintOnTable. It can only be defined on table nodes.
As additional parameters can be defined. the implemented Java class must conform to the JavaBean protocol.
Example:
In the example below, the Java class must define the methods: getParam1(), setParam1(String), getParamX(), setParamX(String), etc.
<xs:element name="myTable" type="MyTableType" minOccurs="0" maxOccurs="unbounded">
    <xs:annotation>
        <xs:appinfo>
            <osd:table>
                <primaryKeys>/key</primaryKeys>
            </osd:table>
            <osd:otherFacets>
                <osd:constraint class="com.foo.checkTable">
                    <param1>...</param1>
                    <param...n>...</param...n>
                </osd:constraint>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
</xs:element>
Attention:
For performance reasons, constraints on tables are only checked when getting the validation report of a dataset or table. This means that these constraints are not checked when updates, such as record insertions, deletions or modifications, occur on tables. However, the internal incremental validation framework will optimize the validation cost of these constraints if dependencies are defined. For more information, see Validation.
See also:

Control policy

Blocking and non-blocking constraints

When an update in the repository is performed, and this update adds a validation error according to a given constraint, it is possible to specify whether the new error blocks the update (and cancels the transaction) or if it is considered as non-blocking (so that the update can be committed and the error can be corrected later). The element blocksCommit within the element osd:validation allows this specification, with the following supported values:
onInsertUpdateOrDelete
Specifies that the constraint must always remain valid after an operation (dataset update, dataset deletion, record creation, update or deletion). In this case, any operation that would violate the constraint is rejected and the values remain unchanged.
This is the default and mandatory policy for primary key constraints, data type conversion constraints (an integer or a date must be well-written) and also structural constraints in mapped tables.
This is also the default policy for foreign key constraints that are automatically set in blocking mode (because of a table in relational mode involved in the relationship) and that do not define a control policy.
onUserSubmit-checkModifiedValues
Specifies that the constraint must remain valid whenever a user modifies the associated value and submits a form. In this case, any form input that would violate the constraint is rejected and the values remain unchanged.
This is the default policy for all blocking constraints mentioned in the previous case. For example, a foreign key constraint is by default not blocking (a record referred to by other records can be deleted, etc.), except in the context of a form submit.
never
Specifies that the constraint must never block operations. In this case, any operation that would violate the constraint is allowed. In the context of the user interface, this constraint does not block the form submission if the user sets a value that violates this constraint.
On foreign key constraints, the control policy that blocks all operations does not apply to filtered records. That is, a foreign key constraint is not blocking if a referenced record exists but does not satisfy a foreign key filter. In this case, updates are not rejected and a validation error occurs.
It is not possible to specify a control policy on structural constraints that are defined on relational data models or in mapped tables. That is, this property is not available for fixed length, maximum length, maximum number of digits, and decimal place constraints due to the validation policy of the underlying RDBMS blocking constraints.
This property does not apply to archive imports and when merging dataspaces. That is, all blocking constraints, except structural constraints, are always disabled when importing archives and merging dataspaces.
See also:

XML Schema facet

The control policy is described by the element osd:validation in annotation/appinfo under the definition of the facet.
Example:
<xs:element name="zipCode">
    <xs:simpleType>
        <xs:restriction base="xs:string">
            <xs:minInclusive value="1000">
                <xs:annotation>
                    <xs:appinfo>
                        <osd:validation>
                            <blocksCommit>onInsertUpdateOrDelete</blocksCommit>
                        </osd:validation>
                    </xs:appinfo>
                </xs:annotation>
            </xs:minInclusive>
        </xs:restriction>
    </xs:simpleType>
</xs:element>

XML Schema enumeration facet

The control policy is described by the element osd:enumerationValidation in annotation/appinfo under the definition of the field.
Example:
<xs:element name="Gender">
    <xs:annotation>
        <xs:appinfo>
            <osd:enumerationValidation>
                <blocksCommit>onInsertUpdateOrDelete</blocksCommit>
            </osd:enumerationValidation>
        </xs:appinfo>
    </xs:annotation>
    <xs:simpleType>
        <xs:restriction base="xs:string">
            <xs:enumeration value="0" osd:label="male" />
            <xs:enumeration value="1" osd:label="female" />
        </xs:restriction>
    </xs:simpleType>
</xs:element>

EBX® facet

The control policy is described by the element osd:validation under the definition of the facet (which is defined in annotation/appinfo/otherFacets).
The control policy with values onInsertUpdateOrDelete and onUserSubmit-checkModifiedValues is only available on osd:excludeSegment, osd:excludeValue and osd:tableRef EBX® facets.
The control policy with the value never can be defined on all EBX® facets. On programmatic constraints, the control policy with the value never can only be set directly during the setup of the corresponding constraint. See ConstraintContext.setBlocksCommitToNever and ConstraintContextOnTable.setBlocksCommitToNever in the Java API for more information.
Example:
<xs:element name="price" type="xs:decimal">
    <xs:annotation>
        <xs:appinfo>
            <osd:otherFacets>
                <osd:minInclusive path="../priceMin">
                    <osd:validation>
                        <blocksCommit>onInsertUpdateOrDelete</blocksCommit>
                    </osd:validation>
                </osd:minInclusive>
            </osd:otherFacets>
        </xs:appinfo>
    </xs:annotation>
</xs:element>

Check 'null' input

According to the EBX® default validation policy, in order to allow temporarily incomplete input, a mandatory element is not checked for completion upon user input. Rather, it is verified at the dataset validation only. If completion must be checked immediately upon user input, the element must additionally specify the attribute osd:checkNullInput="true".
Note:
A value is mandatory if the data model specifies a mandatory element, either statically, using minOccurs="1", or dynamically, using a constraint on 'null'. For terminal elements, mandatory values are only checked for an activated dataset. For non-terminal elements, the dataset does not need to be activated.
Example:
<xs:element name="amount" osd:checkNullInput="true" minOccurs="1">
    ...
</xs:element>
See also:

EBX® whitespace management for data types

According to XML Schema (see https://www.w3.org/TR/xmlschema-2/#rf-whiteSpace), whitespace handling must follow one of the procedures preserve, replace or collapse:
preserve
No normalization is performed, the value is unchanged.
replace
All occurrences of #x9 (tab), #xA (line feed) and #xD (carriage return) are replaced with #x20 (space).
collapse
After the processing according to the replace procedure, contiguous sequences of #x20 are then collapsed to a single #x20, and any leading or trailing #x20s are removed.

General whitespace handling

EBX® complies with the XML Schema recommendation:
  • For fields of type xs:string, whether a primary key element or not, whitespaces are always preserved and an empty string is never converted to null.
  • For other fields (non- xs:string type), whitespaces are always collapsed and empty strings are converted to null.
Attention:
Exceptions:
  • For fields of type osd:html or osd:password, whitespaces are always preserved and empty strings are converted to null.
  • For fields of type xs:string that define the property osd:checkNullInput="true", an empty string is interpreted as null at user input by EBX®.

Whitespace handling upon user input

The rules described in the previous section are applied in the user interface, but leading and trailing whitespaces are removed upon user input. That is, in the user interface, whitespaces are by default always trimmed upon user input. Other input methods (Import XML/CSV, Data services, API updates) are not trimmed from the user interface.
Attention:
Exceptions:
  • For fields of type osd:password, whitespaces are not trimmed upon user input.
  • For foreign key fields, whitespaces are not trimmed upon user input.
It is possible to indicate in a data model that whitespaces should not be trimmed upon user input. The attribute osd:trim="disable" can be set on the fields that allow leading and trailing whitespaces upon user input.
Example:
<xs:element name="field" osd:trim="disable" type="xs:string">
    ...
</xs:element>

Whitespace handling for primary keys of type string

For primary key columns of type xs:string, a default EBX® constraint is defined. This constraint forbids empty strings and non-collapsed whitespace values when creating a record. That is, any record creation that would violate this constraint is rejected.
However, if the primary key node specifies its own xs:pattern facet, this facet overrides the default EBX® constraint. For example, the specific pattern ".*" would accept any string, although this is not recommended.
The default constraint allows handling certain ambiguities. For example, it would be difficult for a user to distinguish between the following strings: "12 34" and "12  34". For generic values, this would not create conflicts, however, errors would occur for primary keys.
See also:

Empty string management

Default conversion

For nodes of type xs:string, no distinction is made at user input between an empty string and a null value. That is, an empty string value is automatically converted to null at user input.

Distinction between empty strings and 'null' value

There are certain cases where the distinction is made between an empty string and the null value, such as when:
  • A primary key defines a pattern that allows empty strings.
  • An element defines a foreign key constraint and the target table has a single primary key defining a pattern that allows empty strings.
  • An element defines a static enumeration that contains an empty string.
  • An element defines a dynamic enumeration to another element with one of the aforementioned cases.
    If the distinction is made between an empty string and a null value, this implies the following behaviors:
  • An empty string will not be converted to null at user input,
  • Input fields for nodes of type xs:string will display an additional button for setting the value of the node to null,
  • At validation time, an empty string will be considered to be a compliant value with regard to the minOccurs="1" property.
Attention:
In relational mode, the Oracle database does not support the distinction between empty strings and null values, and these specific cases are not supported.

Triggers and functions

Computed values

By default, data is read and persisted in the XML repository. Nevertheless, data may be the result of a computation and/or external database access, for example, an RDBMS or a central system.
EBX® allows taking into account other data in the current dataset context.
This is made possible by defining functions.
A function is specified in the data model using the osd:function element (see example below).
  • The value of the class attribute must be the qualified name of a Java class that implements the Java interface ValueFunction.
  • Additional parameters may be specified at the data model level, in which case the JavaBean convention is applied.
Example:
<xs:element name="computedValue">
    <xs:annotation>
        <xs:appinfo>
            <osd:function class="com.foo.ComputeValue">
                <param1>...</param1>
                <param...n>...</param...n>
            </osd:function>
        </xs:appinfo>
    </xs:annotation>
    ...
</xs:element>
In some cases, it can be useful to disable the validation of computed values if the execution of a function is time-consuming. Indeed, if the function is attached to a table with N records, then it will be called N times when validating this table. The property osd:disableValidation= "true" specified in the data model allows to disable the validation of a computed value (see example below).
Example:
<xs:element name="computedValue" osd:disableValidation="true">
    <xs:annotation>
        <xs:appinfo>
            <osd:function class="com.foo.ComputeValue">
                <param1>...</param1>
                <param...n>...</param...n>
            </osd:function>
        </xs:appinfo>
    </xs:annotation>
    ...
</xs:element>

Triggers

Datasets or table records can be associated with methods that are automatically executed when some operations are performed, such as creations, updates, or deletions.
In the data model, these triggers must be declared under the annotation/appinfo element using the osd:trigger element.
For dataset triggers, a Java class that extends the abstract class InstanceTrigger must be declared inside the element osd:trigger.
In the case of dataset triggers, it is advised to define annotation/appinfo/osd:trigger tags just under the root element of the data model.
Example:
<xs:element name="root" osd:access="--">
   ...
   <xs:annotation>
        <xs:appinfo>
            <osd:trigger class="com.foo.MyInstanceTrigger">
                <param1>...</param1>
                <param...n>...</param...n>
            </osd:trigger>
        </xs:appinfo>
    </xs:annotation>
    ...
</xs:element>
For the definition of table record triggers, a Java class that extends the abstract class TableTrigger must be defined inside the osd:trigger element. It is advised to define the annotation/appinfo/osd:trigger elements just under the element describing the associated table or table type.
Examples:
On a table element:
<xs:element name="myTable" type="MyTableType" minOccurs="0" maxOccurs="unbounded">
    <xs:annotation>
        <xs:appinfo>
            <osd:table>
                <primaryKeys>/key</primaryKeys>
            </osd:table>
            <osd:trigger class="com.foo.MyTableTrigger" />
        </xs:appinfo>
    </xs:annotation>
</xs:element>
On a table type element:
<xs:complexType name="MyTableType">
   ...
   <xs:annotation>
       <xs:appinfo>
          <osd:trigger class="com.foo.MyTableTrigger">
             <param1>...</param1>
             <param...n>...</param...n>
          </osd:trigger>
       </xs:appinfo>
   </xs:annotation>
   ...
</xs:complexType>
As additional parameters can be defined, the implemented Java class must conform to the JavaBean protocol. In the example above, the Java class must define the methods: getParam1(), setParam1(String), getParamX(), setParamX(String), etc.

Auto-incremented values

It is possible to define auto-incremented values. Auto-incremented values are only allowed inside tables, and they must be of the type xs:int or xs:integer.
An auto-increment is specified in the data model using the element osd:autoIncrement under the element annotation/appinfo.
Example:
<xs:element name="autoIncrementedValue" type="xs:int">
    <xs:annotation>
        <xs:appinfo>
            <osd:autoIncrement />
        </xs:appinfo>
    </xs:annotation>
</xs:element>
Also, there are two optional elements, start and step:
  • The start attribute specifies the first value for this auto-increment. If this attribute is not specified, then the value 1 is set by default.
  • The step attribute specifies the step for the next value to be generated by the auto-increment. If this attribute is not specified, then the value 1 is set by default.
    Example:
    <xs:element name="autoIncrementedValue" type="xs:int">
        <xs:annotation>
            <xs:appinfo>
                <osd:autoIncrement>
                    <start>100</start>
                    <step>5</step>
                </osd:autoIncrement>
            </xs:appinfo>
        </xs:annotation>
    </xs:element>
    A field specifying an osd:autoIncrement has the following behavior:
  • The computation and allocation of the field value are performed whenever a new record is inserted and the field value is undefined.
  • No allocation is performed if a programmatic insertion already specifies a non- null value. For example, if an archive import or an XML import specifies the value, that value is preserved.
    Consequently, the allocation is not performed for a record insertion in occulting or overwriting modes.
  • A newly allocated value is, whenever possible, unique in the scope of the repository. More precisely, the uniqueness of the allocation spans over all the datasets of the data model, and it also spans over all the dataspaces. The latter case allows the merge of a dataspace into its parent with a reasonable guarantee that there will be no conflict if the osd:autoIncrement is part of the records' primary key.
    This principle has a very specific limitation: when a mass update transaction that specifies values is performed at the same time as a transaction that allocates a value on the same field, it is possible that the latter transaction will allocate a value that will be set by the first transaction (there is no locking between different dataspaces).
    Internally, the auto-increment value is stored in the 'Auto-increments' table of the repository. In the user interface, it can be accessed by administrators in the 'Administration' area. This field is automatically updated so that it defines the greatest value ever set on the associated osd:autoIncrement field, in any instance or dataspace in the repository. This value is computed, taking into account the max value found in the table being updated.
    In certain cases, for example when multiple environments have to be managed (development, test, production), each with different auto-increment ranges, it may be required to avoid this "max value" check. This particular behavior can be achieved using the disableMaxTableCheck property. It is generally not recommended to enable this property unless it is absolutely necessary, as this could generate conflicts in the auto-increment values. However, this property can be set in the following ways:
  • Locally, by setting a parameter element in the auto-increment declaration: <disableMaxTableCheck>true</disableMaxTableCheck>,
  • For the whole data model, by setting <osd:autoIncrement disableMaxTableCheck="true"/> in the element xs:appinfo of the data model declaration, or
  • Globally, by setting the property ebx.autoIncrement.disableMaxTableCheck=true in the EBX® main configuration file.
    See TIBCO EBX® main configuration file.
Note:
When this option is enabled globally, it becomes possible to create records in the table of auto-increments, for example by importing from XML or CSV. If this option is not selected, creating records in the table of auto-increments is prohibited to ensure the integrity of the repository.