Attribute-Tag Mapping

Business object attribute mapping is based on FIX standards that define message types. (For more information, see the FIX documentation available at http://www.fixprotocol.org/cgi-bin/Welcome.cgi.)

Each attribute in a FIX business object is mapped to a tag within a FIX message. FIX message tags, in turn, observe the FIX protocol, which is implemented in two syntaxes:

The connector for FIX Protocol processes messages that use the tag=value syntax.

The rules for mapping business object attributes reflect the kinds of tags found in FIX messages:

These kinds of tags, which appear in standard message headers and trailers as well as the body text of FIX messages, are discussed below.

Simple Tags

Simple tags are mapped to simple attributes in the business object definition and must be defined as follows:

Name = <Name defined in FIX message definition>
 Type = String
 MaxLength = 255
 IsKey = (see note below)
 IsForeignKey = false
 IsRequired = (see below)
 AppSpecificInfo = (see below)
 IsRequiredServerBound = false
 [End]
 
Note:
See note in "Business object-Message Mapping".

IsRequired

If a simple tag is defined as mandatory in the FIX message type definition, the corresponding attribute in the business object must be marked as required. Otherwise, the required flag must be set to false:

AppSpecificInfo

The application-specific information (AppSpecificInfo = ) of an attribute for a simple tag must contain:

Table 17 lists FIX fields for which FIX refers to ISO codes or FIX-defined value sets in order to validate the data content. For these tags, the FIX type definition must be mapped to a specific IBM CrossWorlds type value.

Table 17. FIX-IBM CrossWorlds Data Type Correspondence

FIX fields FIX Attribute Type FIX Version IBM CrossWorlds Type value
ANY
Exchange
 
4.0 - 4.2
Exchange
 
ANY
Exchange/
 ISO 10383
 
4.3
Exchange43
 
ANY
Char
 
4.0 or 4.1
String
 
SettlBrkrCode SettlInstCode SecuritySettlAgentCode CashSettlAgentCode ISO 9362 4.3
ISO9362
 
CFICode
4.0 - 4.2
CFICode
 
CFICode ISO 10962 4.3
CFICode43
 
Currency ISO 4217 4.2-4.3
Currency
 
Country ISO 3166 4.3
Country
 
SecurityID UnderlyingSecurityID ISO 6166 4.3
ISO6166
 
SecurityType Any Any
SecurityType
 
YieldType Any Any
YieldType
 
Note:
The names of attributes in the FIX data handler child meta-object must correspond to the IBM CrossWorlds data type values shown in Table 17. For more information on the data handler meta-object attributes, see Table 19.

MultipleValueString

For FIX version 4.0 and 4.1 messages, the data type char can contain multiple values. In order to correctly process tags that are defined as char and that also can contain multiple values, the data type specification in TYPE= must be MultipleValueString instead of char.

The FIX data type MultipleValueString is special case of a simple tag. Because this type can contain multiple values, it must be defined as a cardinality n container business object. This business object is available via the IBM CrossWorlds Exchange and shown below:

[BusinessObjectDefinition]
 Name = FIX_MultipleValueString
 Version = 1.0.0
  
    [Attribute]
    Name = Value
    Type = String
    MaxLength = 255
    IsKey = true
    IsForeignKey = false
    IsRequired = false
    IsRequiredServerBound = false
    [End]
    [Attribute]
    Name = ObjectEventId
    Type = String
    MaxLength = 255
    IsKey = false
    IsForeignKey = false
    IsRequired = false
    IsRequiredServerBound = false
    [End]
  
    [Verb]
    Name = Create
    [End]
  
    [Verb]
    Name = Delete
    [End]
  
    [Verb]
    Name = Retrieve
    [End]
  
    [Verb]
    Name = Update
    [End]
 [End]
 

Every FIX tag of type MultipleValueString must be mapped to a business object container attribute of type FIX_MultipleValueString. This applies for FIX message tags for version 4.0 and 4.1 tags that are defined as char but can contain multiple values separated by commas.

Repeating Groups

A repeating group is a set of tags that can occur multiple times within a single FIX message. A counter provides the exact number of instances of a particular repeating group. In FIX version 4.3 this counter is mandatory and must precede the repeating group. For repeating groups in older FIX versions, a counter is not mandatory, but nevertheless is used with most repeating groups.

In a FIX business object definition, repeating groups are defined as child business objects. A repeating group can contain other repeating groups. The same applies to FIX business object definitions: a FIX business object can have multiple child business objects, which, in turn, can have multiple child business objects, and so on.

The child business object attribute in the top-level business object must be defined as follows:

Name = <name of repeating group>
 Type = <name of child business object definition>
 ContainedObjectVersion = 1.0.0
 Relationship = Containment
 Cardinality = N
 MaxLength = 0
 IsKey = false
 IsForeignKey = false
 IsRequired = false
 AppSpecificInfo = (see below)
 IsRequiredServerBound = false
 

If one or more mandatory tags are in the repeating group, the attribute characteristic AppSpecificInfo must contain the following:

If IsRequired = false in the repeating group attribute, AppSpecificInfo must contain the corresponding counter for this repeating group: CounterTag=<tag number of counter that contains number of instances for this repeating group>

A semicolon is used to delimit name-value pairs.

The naming convention for the child BO definitions is as follows:

<Top-level business object name>_RepGroup_<group description>

Components

The FIX version 4.3 protocol defines Components as logical groupings of tags within message definitions.

In business object definitions, components are mapped to single cardinality child objects.

The child attribute in the top-level business object must be defined as follows:

Name = <Component Name>
 Type = <Name of child business object definition>
 ContainedObjectVersion = 1.0.0
 Relationship = Containment
 Cardinality = 1
 MaxLength = 0
 IsKey = false
 IsForeignKey = false
 IsRequired = (see below)
 AppSpecificInfo = (see below)
 IsRequiredServerBound = false
 
Note:
A component can be marked as mandatory (IsRequired=true) if and only if it possesses at least one mandatory tag. If none of the tags is explicitly defined as mandatory, but only conditionally mandatory based on the business description, the IsRequired characteristic must not be set to true for the attribute in the top-level business object.

If there is one or more mandatory tag in the component, the AppSpecificInfo of the child attribute must contain the tag number of the first mandatory tag in the component:

TAG=<tag number>
 

The naming convention for the child business object definitions must be:

Standard Message Header Attribute

An attribute in the top-level business object is mapped to the FIX standard message header. That attribute points to a child business object that defines the FIX header.

The naming convention for the standard message header attribute is as follows:

FIX<FIX_version>_StandardMessageHeader

For example: FIX43_StandardMessageHeader is the name of an attribute and a child business object that map to a FIX version 4.3 message header.

The attribute corresponding to the standard message header must be defined as follows:

Name = Header
 Type = FIX<FIX version>_StandardMessageHeader
 ContainedObjectVersion = 1.0.0
 Relationship = Containment
 Cardinality = 1
 MaxLength = 0
 IsKey = false
 IsForeignKey = false
 IsRequired = false
 AppSpecificInfo = (see below)
 IsRequiredServerBound = false
 

The application-specific information must contain the string TYPE=HEADER, which identifies this attribute as the header attribute. The type of the attribute points to the child business object definition. For a sample definition, see "Sample Message Header Child business object".

Note:
Standard message headers can contain more than one tag. Accordingly, each tag in that message header must be mapped to an attribute in the child business object that defines the header. The standard message header attribute in the top-level business object points to this definition.

Standard Message Trailer

An attribute in the top-level business object is mapped to the FIX standard message trailer. That attribute points to a child business object that defines the FIX trailer.

The naming convention for the standard message trailer attribute is as follows:

FIX<FIX_version>_StandardMessageTrailer

For example: FIX42_StandardMessageTrailer is the name of an attribute and a child business object that map to a FIX version 4.2 message trailer.

The attribute corresponding to the standard message trailer must be defined as follows:

Name = Header
 Type = <Name of BO definition for Standard Message Trailer>
 ContainedObjectVersion = 1.0.0
 Relationship = Containment
 Cardinality = 1
 MaxLength = 0
 IsKey = false
 IsForeignKey = false
 IsRequired = false
 AppSpecificInfo = (see below)
 IsRequiredServerBound = false
 

The type of the attribute points to the child business object definition. For a sample definition, see "Sample Message Trailer Child business object".

Note:
Standard message trailers can contain more than one tag. Accordingly, each tag in that message trailer must be mapped to an attribute in the child business object that defines the trailer. The standard message trailer attribute in the top-level business object points to this definition.

Copyright IBM Corp. 1997, 2003