TIBCO EBX®
Documentation > Developer Guide > Data model
Navigation modeDocumentation > Developer Guide > Data model

Triggers and functions

EBX® data model allows to define triggers and computed fields. It also provides auto-incremented fields

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 computation rules.

A computation rule is specified in the data model using the osd:function element (see example below).

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>

Disabling validation

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">
				...
			</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.

Trigger on dataset

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>

Trigger on table

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:

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:

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:

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.

Documentation > Developer Guide > Data model