Converting FIX messages to business objects

The FIX data handler performs validation of business object configuration and compliance as well as of FIX message format and syntax. For error reporting and more on validation, see "Error handling".

Note:
Validation is primarily based on business object definitions. If the business object definition is incorrect, an incoming FIX message may be rejected even though its syntax and format are correct.

The FIX data handler extracts data from a FIX message and sets corresponding attributes in business objects as described below.

Message Parsing

The data handler parses an incoming data stream into tag=value fields. These fields are delimited by the non-printing ASCII character SOH (Start Of Header), except for tag=value fields of type data, which allow other kinds of embedded delimiters. Accordingly, the data handler distinguishes between two types: tag=value pairs of type data and all others. Data of type data is parsed using the length parameter. Tag fields of all other types are parsed by means of the SOH delimiter. For more on tags of type data and delimiting rules, see FIX documentation.

Note:
The type information is stored in the application-specific text of the business object definition that corresponds to the FIX message being parsed.

Determining the message Header business object Name

The header uses the BeginString in the FIX message (tag 8) to determine the version of the FIX message. The version is pre-pended to the name of the standard message header business object. For example, the FIX tag 8=4.3 indicates FIX version 4.3. The data handler converts 4.3 into 43 and then uses the header configuration meta-object attribute to determine the name of the business object to represent the message header (FIX43_StandardMessageHeader). The data handler then uses the message header business object to determine whether the FIX message is in the tag=value format or the FIXML format. (The connector for FIX does not support FIXML formatted FIX messages.)

If the FIX standard message header cannot be parsed, a MalFormDataException is thrown. However, if a FIXException is thrown while processing the message header, the data handler flags the error but continues to parse the message until the header passes validation or until the end of the data stream is reached. The data handler continues processing in order to aid the construction of an ErrorReport business object. For more on ErrorReport business object, see "Validation Errors".

Determining the Top-Level business object Name

Having parsed the standard message header, the data handler uses the FIX version number to read bonames.cfg, a local configuration file that the data handler meta-object attribute BO_NAMES points to. The bonames.cfg file contains the names of all supported business objects. The data handler uses the message type and the version to find the top-level business object name in the bonames.cfg file. For example, the following entry in a bonames.cfg file lists FIX43_ExecutionReport, the name associated with a version 4.3 FIX message of type ExecutionReport:

FIX43   8   N   FIX43_ExecutionReport

where N = not a FIXML object

Note:
You must add the names of all supported business objects and their corresponding version and message type to the bonames.cfg file.

FIX-Tag-to-business-object-Attribute Mapping

The data handler uses FIX syntax rules to map message tags to business object attributes. Specifically, the FIX data handler uses the attribute application-specific text property TAG=nn to map FIX tags to business object attributes. For more on this attribute property, see Attribute-Tag Mapping.

The following rules are observed when setting business object attribute values:

  1. If the attribute for the tag is a simple attribute, the value of the attribute is set to the value of its type. For more information on simple attributes, see Simple Tags.
  2. If the attribute is not of type MultipleValueString and a cardinality n container, the data handler infers that the current tag indicates the start of each instance of a repeating group. For repeating groups, the data handler validates the order of the attributes. For more on repeating groups, see Repeating Groups.
    Note:
    Each instance of a repeating group must contain the same tag sequence.
  3. If the attribute is of type MultipleValueString and a cardinality n container, value is parsed using ' ' (a space) as a delimiter. For more information, see MultipleValueString.
    Note:
    For the data handler, the difference between repeating groups and all other child business objects is that the order of the attributes must be validated.

    Otherwise, if the attribute is a single cardinality container, the attribute represents a Component and processed recursively. If the Component is in a repeating group, the order of attributes is preserved. For more information, see Components.

  4. The data handler traverses through the business object to match a tag to an attribute. If no attribute matching the tag is found in the current business object, the recursive processing stops and the method returns. If the tag is not found in any business object, an error is registered.

Copyright IBM Corp. 1997, 2003