FIX Adapter Reference Documentation
- Software Design Considerations
About FIX Messages
- About the message structure
- Message structure: message header
- Message structure: message body
- Component block: Instrument (FIX clientrequest)
- Component block: Instrument (TT FIX Adapter response)
- Component block: Underlying instrument
- Component Block: Trader
- Component Block: Synthetic Order Properties
- Group: PartiesGrp
- Group: OrderAttributeGrp
- Understanding Account Defaults
- Account Defaults: Order Matching and Routing Examples
- Message structure: message footer
- Session Level Messages
- Application Level Messages
- Application Level Messages — Pre Trade
- Application Level Messages — Trade Related
- Application Level Messages — Post Trade
- Application Level Messages — Other
- FIX Message Conversations
- Enumerations And Codes
- Supported FIX Messages And Tags
- P&L Calculation Algorithm
- TT Gateway Specific Notes
Managing order book state: non-persistent FIX order sessions
Determining the order book state
During startup, the TT FIX Adapter queries the TT Gateways to determine the order book state of each FIX client. Then, when a FIX client initializes its connection, it queries the TT FIX Adapter for its order book state information. When using this model, the order book state and message sequence numbers stay synchronized only during a session, but not across sessions.
When a non-persistent FIX client initializes, it should use the following process to determine the current order book state:
- Send a Logon (A) message to the TT FIX Adapter with Tag 34 (MsgSeqNum)=1 and Tag 141 (ResetSeqNumFlag)=Y.
- Request the current state of all orders by sending an Order Status Request (H) message, omitting both Tag 11 (ClOrdID) and Tag 37 (OrderID).
- Determine the trader’s positions by sending a Request For Position (UAN) message with Tag 16724 (PosReqType)=0 (positions).
- Optionally request all fills, manual fills, SODs, and DSODs
that comprise this position by sending sequential Request For Position (UAN) messages
- Tag 16724 (PosReqType)=1 (trades)
- Tag 16724 (PosReqType)=4 (SOD)
- Tag 16724 (PosReqType)=5 (manual fills)
- Tag 16724 (PosReqType)=6 (DSOD)
The following example illustrates the exchange of messages between a FIX client and a TT FIX Adapter for non-persistent FIX order sessions. Every time the FIX client establishes a connection, it needs to start a new session (34=1, 141=Y) and request the current state of all working orders. Any changes that occurred while the FIX client was not connected are lost.
Note: After downloading orders that include Tag 37 (OrderID), traders can modify orders as long as all change order requests include Tag 37 (OrderID). For more information refer to the following section, Non-persistent FIX order sessions: using Tag 11 (ClOrdId) and Tag 37 (OrderId).
Handling missed messages
Non-persistent FIX order sessions support the standard message replay mechanism specified by the FIX Protocol. A TT FIX Adapter honors Resend Request (2) messages received from FIX clients because the TT FIX Adapter caches all messages that it sends on the order session.
Handling connection problems
During the course of normal operation, various problems, such as hardware failures, can occur. To account for the possibility of failures, TT recommends that you make two redundant TT FIX Adapters (primary and secondary) available to FIX clients. These redundant adapters should be configured identically so that FIX clients can interact with both in the same manner.
FIX clients that use non-persistent FIX sessions should automatically connect to its secondary TT FIX Adapter if it cannot connect to its primary TT FIX Adapter. Because both TT FIX Adapters deliver the same order book information, FIX clients do not need additional coding to handle this failover situation.