...

Finally, the in_map and out_map definitions are used when creating decoder and encoder definitions to be used in Image Added.

UFDL code of the example is described as follows:

external recA { 
    int      type : static_size(1); 
    ascii Anum : static_size(8); 
    ascii Bnum : terminated_by(0xA);
};

internal recA_int { 
   int field1; 
   int field2; 
};

external recB { 
   int   type   : terminated_by(";"); 
   ascii Anum   : terminated_by(";"); 
   ascii Bnum   : terminated_by(";"); 
   int   field1 : terminated_by(";"); 
   int   field2 : terminated_by(0xA); 
}; 

in_map A_map : external(recA), 
               internal(recA_int), 
               target_internal(recA_TI) { 
                 automatic; 
               };

decoder decode_A : in_map(A_map);

out_map B_map : internal(recA_TI), 
                external(recB) { 
                   automatic; 
                };
encoder encode_B : out_map(B_map);

External

Network elements delivering data to produce to  Image Added produce records in various physical formats. An external format describes the physical structure of the incoming data, as well as the data delivered by the the  Image Added system. It can be any type of ASCII, XML or binary data. Typically, one external block per record type is defined. File headers and trailers are also considered being records.

The external formats are described through a number of different methods with different syntax. The external formats, currently supported by the Platformthe Image Added Platform, are:

Records of different format types may exist in the same record. An example of this could be a BER (ASN.1) record that contains a field whose format is a sequential record (specified through an external block). The image below, A definition of a sequential external record, illustrates the syntax for a sequential record type.

...

There are two ways to define an internal UDR format in UFDL. Either by using the automatic generation through an in_map specification, or through an internal declaration block. For more complex formats it is often impractical to manually write an internal format if all that is desired is a direct mapping from the fields in the external format. In these cases the target_internal specification in the in_map is used. An additional internal block can be specified in the in_map if additional processing fields are needed.

...

For information about how to specify an internal format, see Internal Formats[hide](3.0[/hide]). For information about in_map specifications, see In-maps[hide](3.0[/hide]).

internal    AXE_DAM { 
  string ANumberAreaCode; 
  string ANumberClass : optional; 
  string BR_IncomingPQR; 
  string BR_NumberClass; 
  intLen ANumber; 
  intLen BRNumber; 
  intLen BSNumber; 
  string PreProcRecordClass; 
 }; 

The target_internal is the format used by the processing agents in Image Added. It can be a direct representation of the external incoming format, or a combination of the external and additional fields from an internal definition. An internal definition is needed in case any changes to the default mapping from the external format are required or if several externals are mapped to the same UDR.

...

In the image above, a resulting target_internal, a combination of explicit (the e: and i: specifications) and automatic mapping is used to create the resulting target_internal CDR_TI.

Event Types

Event format types are special internal types that can be sent to the  Image Added Event Server. Events store additional internal information used during the event processing. For performance reasons, and in order to avoid confusion, event types should only be used as  “message UDRs”  dispatched to the Event Server. In other words, do not use event UDRs to transport ordinary UDR data.

Event types are declared in the same way as internal types, except for the keyword event, which is used instead of internal. For further information, see Internal Formats[hide](3.0[/hide]).

The following code will result in the events shown in the image below, Event format showing added fields:

event AMA_Event {

      int  anum;
      int  bnum;
      ...
}   

Decoder 

A Decoder defines what external records to accept, and describes any additional file structure information, such as whether file blocking is used in the input data.

...

The first case, TTFile1, will require a batch to start with a header, end with a trailer, and contain any number of UDRs in between. The second decoder definition (TTFile2) ignores the order and occurrence of arriving records. For further information about decoder specifications, see Decoders[hide](3.0[/hide]).

Out-map

An out-map defines how the internal data will be mapped to the outgoing format. It requires an internal and an external definition as arguments and maps fields either automatically or through explicit field mappings.

...

In the image above, The minimum required to define an out-map, it is shown how an external Access_Reject_Ext is created using the internal Access_Reject_Int. The automatic keyword map all fields with the same name, while field names present in the internal, but not the external, are ignored. For further details about how to specify an out_map see Out-maps[hide](3.0[/hide]).

Encoder

Encoders define the rules for mapping internal UDRs to external data structures (raw data).

...

encoder myEncoder : out_map( my_out_map );