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.

Examples:

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.

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>.

Examples:

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.

Defines a string that will cause the session to be terminated upon receiving a session level reject containing it.

Example:

In this case, the session will be terminated if the sequence number gap exceeds 2500.

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.

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.

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.