Capital Markets Adapters 10.7 | Apama Capital Markets Adapters Documentation 10.7 | Apama Base FIX Adapter | IAF FIX adapter | FIX MDA Transport | Transport properties
 
Transport properties
Each transport can be configured through a number of properties as outlined below:
QuickFIX properties
The transport has been designed so that it is possible to configure the QuickFIX engine via the IAF configuration file by prefixing a transport property with “QuickFIX”. For example, the following transport property sets the target host of its embedded QuickFIX engine:
<property name="QuickFIX.SocketConnectHost" value="server1.abc.com"/>
Any QuickFIX property can be set in this way, a full list of which along with the rules for their use can be found at http://www.quickfixengine.org/quickfix/doc/html/configuration.html.
General transport properties
*Static fields
Allows static values to be defined for outgoing (upstream) messages. The definition specifies whether the field is inserted into the header or body, the message type and the tag number. Wildcards (“*”) can be specified for the message type and tag number.
StaticField.[header|body].[msg].[tag]
Examples:
<property name="StaticField.body.D.1" value="foo"/>
<property name="StaticField.header.*.50" value="bar"/>
The first example sets body tag 1 in msg type D (NewOrderSingle) to the value foo whereas the second example sets header tag 50 in all messages to the value bar.
Specific message types have precedence over the wildcard, and existing fields in the message will not be over-ridden. Note that if there are two StaticField entries which update the same tag and message type, the second is ignored.
*Header field maps
Maps a header field from an incoming (downstream) FIX message to the payload (extraParams) of the event sent to the correlator. The name of the generated payload field will be of the form Header:<tag>.
MapHeaderField.[msgType].[tag]
Examples:
<property name="MapHeaderField" value="D.52"/>
<property name="MapHeaderField" value="*.50"/>
In upstream messages, you can add this information along with extra parameters, which can be useful when you want to place a tag whose value is dynamic in the header part of the message.
To include a tag in the header part of outgoing (upstream) FIX messages, provide “Header:<tag>”:”<value>” in the extraParams of the event sent to the correlator.
*Fatal reject messages
Defines a string that will cause the session to be terminated upon receiving a session level reject containing it.
Example:
<property name="FatalRejectMessage" value="Range of messages to
     resend is greater than maximum allowed [2500]."/>
In this case, the session will be terminated if the sequence number gap exceeds 2500.
*Controlling FIX message replay
The FIX session protocol maintains a unique (within a session) sequence numbering of messages transferred in both directions between the FIX client and server. By default, when a connection is established both the client and server will resend any messages from the same FIX session that have not yet been acknowledged by the other party. This means that all messages sent by either party will be processed even if the session is unexpectedly disconnected (e.g. by a network failure) and later resumed.
However, it is sometimes not desirable for all “old” messages to be processed when a session is resumed. For example, orders submitted immediately before a disconnection but only processed when the session resumes might trade against stale prices. In the event that the FIX server does not automatically reject such stale orders, the FIX transport can be configured not to resend FIX New Order Single messages when the session is established. If the SendNewOrdersOnInitialResend transport property is set to true (the default), all unacknowledged messages will potentially be replayed by the transport when the session is established. If this property is set to false, unacknowledged New Order Single messages will not be replayed. All other messages types will still be replayed if requested by the server.
*Logging FIX messages
By default, the FIX transport logs all incoming and outgoing FIX messages at DEBUG level. The LogFixMsgAtInfoLevel transport property can be used to control this behavior. If the value of this property is false (the default), the transport will log all messages at DEBUG level as usual. If this property is set to true, incoming and outgoing FIX messages will be logged at INFO level instead.
*Calculating FIX adapter latency
The FIX transport supports the IAF adapter latency measuring framework introduced in Apama 4.0. Please see the IAF documentation for details of how to configure this feature in general.
If timestamp recording is enabled in the FIX transport, timestamps will be attached to FIX New Order Single, Order Cancel/Replace Request and Execution Report messages, and made available to the adapter service monitors on downstream messages.
If timestamp logging is enabled, the FIX transport will log upstream, downstream and round-trip latency for incoming and outgoing messages. In addition, the service monitors can be configured to add timestamps to outgoing orders and amend/cancel requests, allowing the round-trip latency for an order and subsequent acknowledgment or execution to be calculated. See the details of the OrderManager.LogLatency service monitor parameter for more information on this feature.