The end of life (EOL) date for this module was on 30 April, 2019.
The Geneos FIX plug-in is used to monitor sets of conversations that use the Financial Information eXchange (FIX) Protocol. This protocol was created in 1992 by (primarily) financial institutions with the aim of providing an open communication standard to streamline the trading process and enable communication links with the widest possible range of parties.
The FIX plug-in monitors and understands the state of conversations between parties in the FIX communication protocol. The Plug-in is currently tested and compatible with the Cameron Systems and Appia FIX engines and obtains information via the engine log files. The module can be extended to monitor other FIX engines as required.
The FIX plug-in produces a single view, with one row per detected FIX conversation. An example view is as follows:
|sessionsEstablished||Number of active FIX conversations.|
|sessionsDown||Number of previously active FIX conversations which are now inactive.|
|conversation||FIX conversation identifier.|
|partyOne||One of the parties involved in the FIX conversation.|
|partyTwo||Other party involved in the FIX conversation.|
|protocol||FIX protocol version.|
|secondsSinceLastActivity||Number of seconds since a message was last seen for this FIX conversation.|
|logonTime||Time at which the FIX conversation was established.|
|logoffTime||Time at which the FIX conversation was terminated.|
|timeConnected||Time elapsed since the logon time in seconds.|
|adminMsg||Description of the last FIX admin message seen during the conversation.|
|partyOneMsgCount||The number of messages sent by party one.|
|partyTwoMsgCount||The number of messages sent by party two.|
|sessionState||Up or Down depending on if there is an active session.|
|partyOneSeqNumber||Message sequence number for party one - the "sender" as configured by the file message direction setting.|
|partyTwoSeqNumber||Message sequence number for party two - the "receiver" as configured by the file message direction setting.|
The FIX plug-in can be configured to read conversation definitions from an Appia FIX initialisation (INI) file. This file contains the connections that the FIX engine will establish, listed alongside a user-defined connection name.
These definitions will be used by the FIX plug-in to provide conversation names for the given parties that define a connection, which are displayed when a conversation between those parties is detected.
The expected format of these files is as follows.
The MAIN section contains a list of connection names, which refer to a connection definition section. The connection name is then used as the conversation name.
[MAIN] comm_server = [...] license_key = ... connection = [NAME1] connection = [NAME2] ...
The connection names are then used to locate the corresponding definition section. The party names then come from the local_firm_id and remote_firm_id settings.
[NAME1] connection_type = FIX_40 remote_port = 9999 heartbeat_interval = 60 local_firm_id = PARTY1 net_address = 127.0.0.1 remote_firm_id = PARTY2 group = GLOB1
The FIX plug-in is configured in the fix configuration section. The supported parameters for this plug-in are described below.
Specifies the path to the FIX engine log file, which is read by the plug-in in order to populate a view.
Optional separator character to split FIX messages found in the log file. By default this is set to SOH as defined by the FIX protocol (ASCII 01), but can be changed using this parameter.
Appia FIX engines typically tend to use the pipe character | as a separator.
Specifies the path to an Appia FIX configuration file which lists the configured FIX connections. This configuration is then read to find the conversation names and parties, in addition to those configured by the conversations plug-in parameter.
Note: Definitions from the INI file take priority over those in the conversations parameter.
The wildcard mode specifies how files configured with a wildcard (contains * or ? characters) will behave. Available modes are as follows:
|MATCH_LATEST_MODIFIED||Only the file with the latest modification time will be read.|
|MATCH_LARGEST_GROWING||The file to have grown the most between this and the last check will be selected. First a find is issued to find all the files that match the filename then we select the file that has grown the most in bytes.|
By default the FIX plug-in will read a FIX log file from the start when the file is first located (e.g. when changing the setup).
This Boolean parameter specifies that FIX plug-in should start reading from the end of the log file, which requires less CPU since the file up to that point is not processes. This means existing conversations will not be displayed until their status changes, but new conversations will be added to the view as normal.
Specifies the maximum number of lines to read from the FIX engine log file in a single sample. This parameter can be used to reduce peaks in CPU usage for the FIX sampler when scanning large log files, by processing the log over a longer period of time. The minimum value for this parameter is 5000 lines.
Specifies the time in 24-hour clock at which message counts are reset. At this time, the message counts (in columns partyOneMsgCount and partyTwoMsgCount) for each conversation will be reset to 0.
Specifies the time in 24-hour clock at which message re-request counts are reset. At this time, the counts (in columns partyOneRerequestCount and partyTwoRerequestCount) for each conversation will be reset to 0.
Specifies whether to show a re-request count column for each conversation (the columns partyOneRerequestCount and partyTwoRerequestCount). If this parameter is not enabled, then these columns will not be available.
Specifies the time in seconds that a FIX administrative message will be displayed for a conversation - after this time the message will be cleared.
Specifies the format of a message timestamp present in the FIX message, which is used to calculate how old a message is.
This time format is specified using the standard C time formatting codes (also used in PHP and other scripting languages) which are explained here. For additional help on using and configuring this parameter, please contact ITRS Support.
An unspecified conversation is a conversation which has not been configured in an initialisation file, or in the conversations plug-in parameter - i.e. the combination of partyOne and partyTwo are unrecognized.
Unspecified conversations can be optionally ignored using this parameter, which means they will not be published by Netprobe and will hence be unavailable in Gateway for processing by rules.
This parameter controls how system-generated conversation names - which are used for an unspecified conversation - is created.
If numbered conversations are specified, then names are created of the form "Conv:XXX" where XXX is an number which is automatically incremented for each new unspecified conversation. Otherwise, conversation names are constructed using the party names, separated by a dash (-) character.
This parameter sets a global timeout for conversations in the plugin. If no activity is seen for a conversation for the specified number of seconds, that conversation will be marked as timed out. Setting this to 0 results in no timeout being applied.
This global setting can be overridden by a specific setting per configured conversation.
By default FIX plug-in will generate its own system-generated conversation names. Users can configure their own names by specifying conversations in this section, or use those already configured in an Appia FIX initialisation file.
Conversations are defined between two parties, which in the configuration is called the buy side and sell side. It does not matter which name is configured as the buy and sell sides; conversations between parties A and B for example will be checked with both A and B as the buy side when searching for a user-defined conversation.
This setting allows users to configure a list of conversations with their own names, to aid with recognition and also setting of rules in gateway.
The conversation name - this name will be used as the name of the conversation in the view.
One of the parties involved in the conversation.
One of the parties involved in the conversation.
This parameter sets a specific timeout for this conversation. If no activity is seen for a conversation for the specified number of seconds, that conversation will be marked as timed out. Setting this to 0 results in no timeout being applied.