uses internal formats to represent data entities that it can process. All processing agents (for instance, Analysis and Aggregation) work with these internal formats.
A syntax for the internal format is declared as follows:
internal <name> [: (<class specifications> | <format inheritance>) ] { <field_type> <field_name> [:optional] ; ... };
The field types may be any of the following:
Field Type | Description |
---|---|
| Any type. |
| Big integer. |
bigdec | Big decimal. |
| Boolean. |
| Byte array. |
| Integer type (8-bit signed). |
| Integer type (16-bit unsigned). |
| Integer type (16-bit signed). |
| Integer type (32-bit signed). |
| Integer type (64-bit signed). |
| Float type (32-bit). |
| Float type (64-bit). |
| Date type, with capability to hold date parts, time parts or both. |
| A set of bits. |
| An IP address. |
| An instance of any other internal (all internal are drudr instances). |
| String. |
can also be any other internal or list type that is defined in either the same ultra file or in another. See the example below.
field_type
Example - Internal formats
Case 1:
internal I1 { I2 f1; }; internal I2 { list<int> f1; };
Case 2:
In file A internal I1 { <foldername>.<filename>.I2 f1; //When referring an internal from another file that is in the same folder, the folder name can be omitted. }; In file B internal I2 { list<int> f1; };
List types are declared as follows:
list< ElementType >
where ElementType
may be any of the previous, including an internal format identifier, or another list type.
Example - List type
internal I1 { list<list<I2> > f1; };
It is also possible to specify a field as optional:
Example - Specifying a field as optional
internal I1 { drudr f1: optional; };
Similarly, you declare a map
field type this way:
map< ElementType, ElementType >
Example - Declaring a map field
internal I1 { map<string, int> f1; };
Internal formats can also be automatically generated from in_map
definitions. For further information, see target_internal specification in In-maps.
Class Specifications
All internal formats will be compiled into Java classes. It is possible to specify additional interfaces for the class to implement:
Example - Class specifications
internal I1 : implements("Interface1"), implements("Interface2") { ... };
However, this requires that Interface1
and Interface2
only declare methods that are later generated by Ultra when it creates the Java class. For further information about methods and types for UDR type methods, see the /wiki/spaces/MD82/pages/3779155.
Format Inheritance
It is possible to use alternative base UDR definitions for the generated Ultra classes by use of the extends_class
or extends
option.
extends_class
is used by some agents (for instance, the HTTP agent) for better processing support.
Example - extends_class
internal I1 : extends_class( com.mysite.myDTKUltraFormat ) { ... };
extends
lets a format inherit fields defined in an ancestor.
Example - extends
internal A { int a; ... }; internal B : extends ( A ) { int b; ... };
Multiple inheritances is not supported, i e you can only use the extends
or extends_class
option once in the definition of an internal format.
Event Types
It is possible to declare user-defined event types in Ultra by using the event
keyword instead of internal
. Such an event is a special type of internal format with added event processing support.