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 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]
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:
The application-specific information (AppSpecificInfo = ) of an attribute for a simple tag must contain:
Table 25 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 25. 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 |
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.
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>
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
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:
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".
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".