Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
<field_type> <field_name> : <field options> ;

Primitive Field Types

The following primitive types are supported:

Primitive Field TypeDescription

ascii

ASCII encoded string. This type may also be used for other types of string encodings with the character_encoding option. The default encoding used is ISO8859-1.

asn_length

Special type used to encode a BER encoded size specification. It decodes to the BER length specification as well as the length of the length specification itself. The type makes it possible to decode some special cases of BER encoded data without using ASN.1 format specifications. The special option content_only could also be used to only get the BER length specification.

bcd

Array of digits encoded in BCD. Nibble order can be specified as bcd(msn_fd) or bcd(lsn_fd). The msn_fd means that the most significant nibble is the first digit, while lsn_fd uses the least significant nibble as first digit. The msn_fd is default.

bytearray

Byte array.

ebcdic

A special case of ascii type, equivalent to ascii: character_encoding("Cp1047"). All options available for ascii fields are also available for ebcdic fields.

float types (floatdouble)

Binary encoded float value. This type supports IEEE754 standard 32-bit and 64-bit data encodings. The only difference between float and double is that the field is automatically mapped to their corresponding internal type.

integer types ( byte short , int long , bigint )

Binary coded integer value. The first byte is the most significant (that is, big endian order). The field can be used with the field options unsigned or signed to specify if the data will be decoded unsigned (which is the default) or two-complement signed. The byte order can also be explicitly specified by, for instance, using int(little_endian) or int(big_endian) as the type name.

The only difference between the types, when using an automatic in_map, is that the field is automatically mapped to their corresponding internal type.

Note
titleNote!

Since the integer types are handled internally as fixed-length signed integers (except for bigint), there can be overflows in both decoding and encoding. If this occurs the integer values are truncated.


msp_length

Special type used to decode the length field in a Siemens MSP billing event. The length field specifies the event length excluding the length field itself.

Code Block
external MSP_BILLING_EVENT 
 { 
 msp_length l : external_only; 
 ascii v : dynamic_size(l); 
 };


list

Type that can be used to decode a list of elements.

Code Block
external MySubUDR { 
  int  dataLength : static_size(1); 
  ascii secretData : dynamic_size(dataLength); 
 }; 
 external MyUDR { 
  int elementCount  : terminated_by(":"); 
  list<MySubUDR> myList : element_count(elementCount); 
  int userType  : terminated_by(0xA); 
 };

The list can have any of the following field size options static_size, dynamic_size, terminated_by or element_count. For further information, see the section below, Field Size Specifications

Primitive Field Options 

Primitive Field OptionDescription

character_encoding(<encoding_name>)

Specifies that the field is encoded with the encoding named <encoding_name>, using the standard Java encoding support.

encode_value(<expr>)

Specifies that the encoded value of the field always is <expr>, regardless of whether decoded or set value is chosen during the processing. This is used for encoding only.

floatdouble

Informs the decoder that the value is actually a float value specified as a string and that the automatic mapping of the field is the internal type float or double. Only applicable for ascii fields.

int(base10)int(base16)

Informs the decoder that the value is actually an integer of decimal or hexadecimal base and that the automatic mapping of the field is of the internal type int. The integer types (byteshort, longbigint) can be used instead of int, in which case automatic mapping is done to the specified type. Only applicable for ascii and bcd fields.

lsb(<int_constant>)

The least significant bit of the field is <int_constant>. Value range is zero (0) to seven (7) (both inclusive). Only applicable for size one (1) integer type fields. This option is typically used together with the lsb option.

msb(<int_constant>)

The most significant bit of the field is <int_constant>. Value range is zero (0) to seven (7) (both inclusive). Only applicable for size one (1) integer type fields. This option is typically used together with the lsb option.

native_size(<expr>)

Specifies the number of BCD digits for a bcd declared field. This size does not cover field size calculation and dynamic_size must generally also be specified.

byte_alignment(<int_constant>)

Specifies that a field begins at the next even multiple of an alignment byte size. The value must be an even power of 2 (for example 1, 2, 4, or 8). This field option can also be used in a bit_block or repeat_block . For an example of how this option can be used, see the section below, Bit Blocks.

Note
titleNote!

The byte_alignment field option is used for decoding only, and counts from the start of the UDR.



Field Size Specifications


Field Size SpecificationDescription

static_size(<constant>)

Used to specify a static size of a field (in bytes)

dynamic_size(<expr>)

Used to specify a dynamic size of a field (in bytes)

element_count(<expr>) 
Used to specify the size of a list field (in number of elements)

terminated_by(<constant>)

Used to specify a dynamic field terminated by a specific constant

bit_size(<expr>)

Used to specify a size of a field (in bits). This size specification can only be used inside a bit_block.

padded_with(<constant>)

Used to specify padding character

align(left)

Specifies that the field is left aligned, default

align(right)

Specifies that the field is right aligned

When decoding a field, the size calculation is done in two steps. First the occupying size is calculated. This is the required field size in the record. After that the core size and offset is calculated, which is the part of the field actually decoded into the internal field.

...

  1. For a BCD field, with native_size specified, this along with the alignment specification is used.
     

  2. If terminated_by is used to find the occupying size, this terminator char (or nibble for BCD) is removed.
     

  3. Any padding is removed (while considering the alignment specification). The padding is either specified with padded_with or with terminated_by providing the occupying size is not calculated using the terminator (this case is present due to historical reasons and in current versions padded_with should be used instead). If the field is an ASCII field, space is used as default padding.
     

Field Options for Optional Fields

The following field options are used to specify when a field is present.


Field OptionDescription

present if(<condition>)

The field is present if the <condition> evaluates to true.

trailing_optional

The field is present unless the end of the UDR data has been reached. This is a convenient option equivalent to present if(remaining_size >0).

Other Field Options

Field OptionDescription
external_only

The field will not be automatically created in the target_internal when performing automatic mapping. This is useful for fields containing “decoding logic” and provide no useful information after decoding. Typical examples could be recordLength and recordType fields.


udr_size and remaining_size

Fields may need to use the size of the containing record in expressions. This is done by using the udr_size keyword.

...

Info
titleExample - remaining_size


Code Block
external SimpleSequential {
    int recordType : static_size(1);
    ascii secretData : dynamic_size(remaining_size);
};


Bit Blocks

Bit blocks are used when the data record contains fields that are not byte aligned. When declaring fields in bit blocks there are two ways to specify which bits to use for the field content. When using a bit_block of a single byte, it is possible to specify the most and least significant bit of the field using msb and lsb, as previously described. The alternative is to use the bit_size option to specify the number of bits spanned by the field.

...

Except for simple fields, a bit_block can contain repeat_block constructs in the contents part. For a description of repeat_block see the section below, Repeat Blocks.

Repeat Blocks

A repeat_block can be used to specify that a group of fields is to be repeated a specified number of times. Currently this construct can only be used inside bit_block structures or another repeat_block structure. However this is restricted to a maximum of two levels of repeat_block. See the example below.

...


Info
titleExample - repeat_block


Code Block
external BitBlockTest {
   bit_block : dynamic_size(remaining_size){
    int string_count: bit_size(8); 
    repeat_block(string_count) {
       int string_length: bit_size(8);
       repeat_block(string_length) {
         int character: bit_size(8);
       };
     };
   };
};

In the UDR Internal Format Browser, the structure of the UDR Type for this example appears as shown below:


Note
titleNote!

It is not possible to encode to a structure containing a  repeat_block .

Constructed Types

A sequential field can be a type that is an instance of another external format.


Info
titleExample - Constructed types


Code Block
external MyParentFormat {
  int field1 : static_size(4);
  MyEnclosedFormat field1;
};


Here MyEnclosedFormat can be any external format.

set Construct

The set construct is used for decoding formats containing optional blocks of additional data. The syntax of the set Construct is declared as follows:

...

If a size is not specified on the set level, Ultra cannot validate that all the data in the UDR has been decoded. The user is therefore recommended to specify the size, unless the set size in advance is unknown (for instance if the record is terminated by a terminator package or the set size calculation is needed for the record size calculation). The dynamic_size(remaining_size) specification used in the previous example is often correct.

switched_set Construct

The switched_set construct can often be used instead of the set construct. It has advantages (in performance and in ease of usage) especially when the separate sub-packages are simple. The syntax is however more complex compared to the basic set construct. The syntax of the switched_set construct is declared as follows:

...

Info
titleExample - Format with a switched_set:


Code Block
external SwitchedSetExample: terminated_by(0xA) { 
   // Size is remaining_size -1 (minus the terminator linefeed) 
    switched_set( packageId ): 
        dynamic_size( remaining_size - 1 ) { 
      ascii packageId: int(base10), static_size(1); 
      ascii packageLength: static_size(1), int(base10), 
         encode_value( case_size - 2 ); 
      case(1) { 
         list<ascii> list1: 
            dynamic_size( packageLength ); 
      }; 
      case(2): include_prefix { 
         ascii packageId_3: int(base10), static_size(1), 
               encode_value(3), external_only; 
         ascii packageLength_3: int(base10), static_size(1), 
               encode_value(case_size - 2), external_only; 
         ascii body_3: dynamic_size( packageLength_3 ); 
      }; 
      default: include_prefix { 
       list<ascii> defaultContent: 
             dynamic_size( packageLength + 2 ); 
      }; 
   }; 
 };


Encoding Specifications and Expressions

To support encoding to binary formats, it is often necessary to explicitly specify which value to be encoded in the external fields. Normally the value is taken from the corresponding internal field, however there are cases when this is not desirable. For instance, if there is no mapped internal field (because the external_only option has been used), or the value must be calculated from information about the encoding (for instance, udr_size). This is done through the encode_value option and there are several special constructs that may be used in the value expression (see the section above, Primitive Field Types).

...