Introduction
The IXWatch Message analyser plug-in allows you to analyse and monitor the contents of market data trading messages in a user-configurable manner.
Views
View
The headline and table values are user-defined for this plugin.
| Name | Description |
|---|---|
| ctrchecker |
Counter checker counts the number of messages passing through this plugin. Each row is uniquely identified by the message number. |
| col | List of column headers for the table. |
| timestamp | Specifies the format of the message timestamp. |
| sumTracker | Total sum of the values returned by another tracker. |
| avgTracker | Total average of the values returned by another tracker. |
| ctrTracker | Counter tracker is a counter which is incremented every time a message is received which passes the filter. |
Plug-in configuration
The following parameters can be configured for this plug-in:
adapters
Adapters are responsible for obtaining messages from a data-source. These messages are then processed by the plug-in. To prevent excessive CPU usage, it is possible to limit the number of messages read from an adapter in a single poll interval by using the maxAdapterMessages parameter.
At present, only two adapters are available: FIX (fix) and TEXT (text).
Mandatory: No
adapters > fix
The FIX adapter is capable of reading FIX messages from a Cameron Systems log file.
Mandatory: No
adapters > fix > source
Source of log file.
Possible values are:
| Setting | Description |
|---|---|
| CameronSystems | Cameron System Log File (does not strip null characters) |
| Appia | Appia Log File (strip null characters) |
Mandatory: Yes
adapters > fix > rewind
The rewind parameter controls how the file is read. If this is set to true, then reading of the file will begin from the start of the file, otherwise the file will be read from the end (i.e. only new data added to the file is read and processed).
adapters > fix > maxLinesPerSample
The maxLinesPerSample parameter controls how the log file is read. Every sample, the adapter will read up to the number of lines set with this parameter, looking for messages. This is to prevent excessive CPU usage when monitoring fast updating files, or when processing a file from the beginning. The minimum value is 5000.
adapters > fix > seperatorChar
The separatorChar parameter controls the parsing for a FIX message. If unspecified, this defaults to SOH (start of header) or ASCII character 01, as defined in the FIX protocol. This character can be specified either by typing the character directly, or as a value in octal (e.g. \040 is ASCII character 32, a space) or a hexadecimal value (e.g. \0x20 is also ASCII character 32).
adapters > fixAdapter
The fixAdapter is now deprecated, please use adapters > fix for new configurations.
The FIX adapter is capable of reading FIX messages from a Cameron Systems log file.
Mandatory: No
adapters > fixAdapter > source
The fixAdapter is now deprecated, please use adapters > fix for new configurations.
Source of log file.
Possible values are:
| Setting | Description |
|---|---|
| CameronSystems | Cameron System Log File (does not strip null characters) |
| Appia | Appia Log File (strip null characters) |
Mandatory: Yes
adapters > fixAdapter > logFile
The fixAdapter is now deprecated, please use adapters > fix for new configurations.
Path to log file
Mandatory: Yes
adapters > fixAdapter > rewind
The fixAdapter is now deprecated, please use adapters > fix for new configurations.
The rewind parameter controls how the file is read. If this is set to true, then reading of the file will begin from the start of the file, otherwise the file will be read from the end (i.e. only new data added to the file is read and processed).
adapters > fixAdapter > maxLinesPerSample
The fixAdapter is now deprecated, please use adapters > fix for new configurations.
The maxLinesPerSample parameter controls how the log file is read. Every sample, the adapter will read up to the number of lines set with this parameter, looking for messages. This is to prevent excessive CPU usage when monitoring fast updating files, or when processing a file from the beginning. The minimum value is 5000.
adapters > fixAdapter > seperatorChar
The fixAdapter is now deprecated, please use adapters > fix for new configurations.
The separatorChar parameter controls the parsing for a FIX message. If unspecified, this defaults to SOH (start of header) or ASCII character 01, as defined in the FIX protocol. This character can be specified either by typing the character directly, or as a value in octal (e.g. \040 is ASCII character 32, a space) or a hexadecimal value (e.g. \0x20 is also ASCII character 32).
adapters > text
The TEXT adapter is a generic text adapter for reading text files.
Mandatory: No
adapters > text > source
Source of log file.
For TEXT adapters this option is ignored and can be anything.
Mandatory: Yes
adapters > text > rewind
The Rewind parameter controls how the file is read. See If this is set to true, then reading of the file will begin from the start of the file, otherwise the file will be read from the end (i.e. only new data added to the file is read and processed).
adapters > text > handlePartialLines
This setting controls how the text file is read by the plug-in.
Some processes write data to log files as blocks
of data, rather than on a line-per-line basis. If
your data source is from such a process, then you
should
adapters > text > maxBufferSize
Controls how much of the file to buffer while scanning for messages. In bytes.
adapters > text > messageDelimiter
start and end specify the message start and end delimiters. The file is then scanned for these, and any text found between instances of these two strings are then taken to be a message. If both of these parameters are empty, which they are by default, the adapter simply returns the lines of the file as messages. If only the start token is empty, then text between end token instances will be messages.
adapters > text > fieldDelimiter
The fieldDelimiter parameter specified how to parse a message into fields. If this is empty (and is by default), then the message is not tokenized, otherwise the message is split into fields around the delimiter.
When used in filters (see section below) these fields are then identified as "field_<x>" where x is the field's position in the message, indexed from 1. The message as a whole can also be referred to using the identifier "Message". No other names are supported since there is no set protocol when reading from text files.
adapters > textAdapter
The textAdapter is now deprecated, please use adapters > text for new configurations.
The TEXT adapter is a generic text adapter for reading text files.
Mandatory: No
adapters > textAdapter > source
The textAdapter is now deprecated, please use adapters > text for new configurations.
Source of log file.
For TEXT adapters this option is ignored and can be anything.
Mandatory: Yes
adapters > textAdapter > filename
The textAdapter is now deprecated, please use adapters > text for new configurations.
Path of text file.
Mandatory: Yes
adapters > textAdapter > rewind
The textAdapter is now deprecated, please use adapters > text for new configurations.
The Rewind parameter controls how the file is read. See If this is set to true, then reading of the file will begin from the start of the file, otherwise the file will be read from the end (i.e. only new data added to the file is read and processed).
adapters > textAdapter > maxBufferSize
The textAdapter is now deprecated, please use adapters > text for new configurations.
Controls how much of the file to buffer while scanning for messages. In bytes.
adapters > textAdapter > messageDelimiter
The textAdapter is now deprecated, please use adapters > text for new configurations.
start and end specify the message start and end delimiters. The file is then scanned for these, and any text found between instances of these two strings are then taken to be a message. If both of these parameters are empty, which they are by default, the adapter simply returns the lines of the file as messages. If only the start token is empty, then text between end token instances will be messages.
adapters > textAdapter > messageDelimiter > start
The textAdapter is now deprecated, please use adapters > text for new configurations.
Message start delimiter.
Mandatory: Yes
adapters > textAdapter > messageDelimiter > end
The textAdapter is now deprecated, please use adapters > text for new configurations.
Message end delimiter.
adapters > textAdapter > fieldDelimiter
The textAdapter is now deprecated, please use adapters > text for new configurations.
The fieldDelimiter parameter specified how to parse a message into fields. If this is empty (and is by default), then the message is not tokenized, otherwise the message is split into fields around the delimiter.
When used in filters (see section below) these fields are then identified as "field_<x>" where x is the field's position in the message, indexed from 1. The message as a whole can also be referred to using the identifier "Message". No other names are supported since there is no set protocol when reading from text files.
trackers
Trackers are the main component of the plug-in, they perform configurable analysis based on the messages passing through the tracker. These values are then used when producing the view.
trackers > counter
A counter which is incremented every time a message is received which passes the filter. This counter has an optional parameter ResetTime, which can be specified to reset the counter to 0 at this time of day. The initial value is 0.
ResetTime should be set to a time in 24-hour clock. E.g. ResetTime = 14:30
Mandatory: Yes
trackers > counter > name
Specifies the field name for the tracker which uniquely identifies the tracker. Tracker names should consist only of alphanumeric characters (i.e. Digits and letters in both upper and lower case) and the underscore and dash characters (_ or -). This name is then used to reference the tracker value in filters (see below) and in the table template (see next section).
Mandatory: Yes
trackers > counter > filter
Define a filter for the tracker. See Defining filters for Trackers for further information.
Mandatory: Yes
trackers > rolling
Similar to a counter above, but only counts messages for the last N seconds. This tracker requires an additional parameter RollInterval, which should be set to the number of seconds N to count for. E.g. RollInterval = 10 for a 10 second interval.
Mandatory: Yes
trackers > rolling > name
Specifies the field name for the tracker which uniquely identifies the tracker. Tracker names should consist only of alphanumeric characters (i.e. Digits and letters in both upper and lower case) and the underscore and dash characters (_ or -). This name is then used to reference the tracker value in filters (see below) and in the table template (see next section).
Mandatory: Yes
trackers > rolling > filter
Define a filter for the tracker. See Defining filters for Trackers for further information.
Mandatory: Yes
trackers > fieldValue
This extracts the value of the specified field from any message which passes the filter. The initial value is blank, and if the specified field does not exist in a message which passes the filter, then the value is set to blank when processing that message. This tracker requires an additional parameter FieldName which specifies the field. This field can be identified using any of the forms listed above for using message fields in a filter.
Mandatory: Yes
trackers > fieldValue > name
Specifies the field name for the tracker which uniquely identifies the tracker. Tracker names should consist only of alphanumeric characters (i.e. Digits and letters in both upper and lower case) and the underscore and dash characters (_ or -). This name is then used to reference the tracker value in filters (see below) and in the table template (see next section).
Mandatory: Yes
trackers > fieldValue > filter
Define a filter for the tracker. See Defining filters for Trackers for further information.
Mandatory: Yes
trackers > regexValue
Similar to the field value above. Once the field is extracted, it is then processed by a user-defined regular expression (regex). If the field matches this regex, the text matching the numbered sub-expression of the regex is extracted, and used as the tracker value.
Mandatory: Yes
trackers > regexValue > name
Specifies the field name for the tracker which uniquely identifies the tracker. Tracker names should consist only of alphanumeric characters (i.e. Digits and letters in both upper and lower case) and the underscore and dash characters (_ or -). This name is then used to reference the tracker value in filters (see below) and in the table template (see next section).
Mandatory: Yes
trackers > regexValue > filter
Define a filter for the tracker. See Defining filters for Trackers for further information.
Mandatory: Yes
trackers > regexValue > fieldName
Specifies the message field the tracker takes its value from.
Mandatory: Yes
trackers > regexValue > regexPattern
The regex pattern used to process a message field.
Mandatory: Yes
trackers > regexValue > regexSubExpression
The regex sub-expression index in the regex pattern, for extracting data from a message field.
Mandatory: Yes
trackers > regexValue > regexCaseSensitive
Whether the regex pattern specified is case sensitive or not.
trackers > counterTracker
The counterTracker is now deprecated, use trackers > tracker > counter for new configurations.
A counter which is incremented every time a message is received which passes the filter. This counter has an optional parameter ResetTime, which can be specified to reset the counter to 0 at this time of day. The initial value is 0.
ResetTime should be set to a time in 24-hour clock. E.g. ResetTime = 14:30
Mandatory: Yes
trackers > counterTracker > name
The counterTracker is now deprecated, use trackers > tracker > counter for new configurations.
Specifies the field name for the tracker which uniquely identifies the tracker. Tracker names should consist only of alphanumeric characters (i.e. Digits and letters in both upper and lower case) and the underscore and dash characters (_ or -). This name is then used to reference the tracker value in filters (see below) and in the table template (see next section).
Mandatory: Yes
trackers > counterTracker > filter
The counterTracker is now deprecated, use trackers > tracker > counter for new configurations.
Define a filter for the tracker. See Defining filters for Trackers for further information.
Mandatory: Yes
trackers > counterTracker > resetTime
The counterTracker is now deprecated, use trackers > tracker > counter for new configurations.
Time at which to reset the tracker value (to 0). If this setting is not specified, the count will increment indefinitely. The time should be specified in 24-hour clock. E.g. 14:30
Mandatory: No
trackers > rollingCounterTracker
rollingCounterTracker is now deprecated, please use trackers > tracker > rolling for new configurations.
Similar to a counter above, but only counts messages for the last N seconds. This tracker requires an additional parameter RollInterval, which should be set to the number of seconds N to count for. E.g. RollInterval = 10 for a 10 second interval.
Mandatory: Yes
trackers > rollingCounterTracker > name
rollingCounterTracker is now deprecated, please use trackers > tracker > rolling for new configurations.
Specifies the field name for the tracker which uniquely identifies the tracker. Tracker names should consist only of alphanumeric characters (i.e. Digits and letters in both upper and lower case) and the underscore and dash characters (_ or -). This name is then used to reference the tracker value in filters (see below) and in the table template (see next section).
Mandatory: Yes
trackers > rollingCounterTracker > filter
rollingCounterTracker is now deprecated, please use trackers > tracker > rolling for new configurations.
Define a filter for the tracker. See Defining filters for Trackers for further information.
Mandatory: Yes
trackers > rollingCounterTracker > rollInterval
rollingCounterTracker is now deprecated, please use trackers > tracker > rolling for new configurations.
The number of seconds the tracker counts for.
Mandatory: Yes
trackers > fieldValueTracker
fieldValueTracker is now deprecated, please use trackers > tracker > fieldValue for new configurations.
This extracts the value of the specified field from any message which passes the filter. The initial value is blank, and if the specified field does not exist in a message which passes the filter, then the value is set to blank when processing that message. This tracker requires an additional parameter FieldName which specifies the field. This field can be identified using any of the forms listed above for using message fields in a filter.
Mandatory: Yes
trackers > fieldValueTracker > name
fieldValueTracker is now deprecated, please use trackers > tracker > fieldValue for new configurations.
Specifies the field name for the tracker which uniquely identifies the tracker. Tracker names should consist only of alphanumeric characters (i.e. Digits and letters in both upper and lower case) and the underscore and dash characters (_ or -). This name is then used to reference the tracker value in filters (see below) and in the table template (see next section).
Mandatory: Yes
trackers > fieldValueTracker > filter
fieldValueTracker is now deprecated, please use trackers > tracker > fieldValue for new configurations.
Define a filter for the tracker. See Defining filters for Trackers for further information.
Mandatory: Yes
trackers > fieldValueTracker > fieldName
fieldValueTracker is now deprecated, please use trackers > tracker > fieldValue for new configurations.
Specifies the message field the tracker takes its value from.
Mandatory: Yes
trackers > regexValueTracker
The regexValueTracker is now deprecated, please use trackers > tracker > regexValue for new configurations.
Similar to the field value above. Once the field is extracted, it is then processed by a user-defined regular expression (regex). If the field matches this regex, the text matching the numbered sub-expression of the regex is extracted, and used as the tracker value.
Mandatory: Yes
trackers > regexValueTracker > name
The regexValueTracker is now deprecated, please use trackers > tracker > regexValue for new configurations.
Specifies the field name for the tracker which uniquely identifies the tracker. Tracker names should consist only of alphanumeric characters (i.e. Digits and letters in both upper and lower case) and the underscore and dash characters (_ or -). This name is then used to reference the tracker value in filters (see below) and in the table template (see next section).
Mandatory: Yes
trackers > regexValueTracker > filter
The regexValueTracker is now deprecated, please use trackers > tracker > regexValue for new configurations.
Define a filter for the tracker. See Defining filters for Trackers for further information.
trackers > regexValueTracker > fieldName
The regexValueTracker is now deprecated, please use trackers > tracker > regexValue for new configurations.
Specifies the message field the tracker takes its value from.
Mandatory: Yes
trackers > regexValueTracker > regexPattern
The regexValueTracker is now deprecated, please use trackers > tracker > regexValue for new configurations.
The regex pattern used to process a message field.
Mandatory: Yes
trackers > regexValueTracker > regexSubExpression
The regexValueTracker is now deprecated, please use trackers > tracker > regexValue for new configurations.
The regex sub-expression index in the regex pattern, which is extracted as the tracker value.
Mandatory: Yes
trackers > regexValueTracker > regexCaseSensitive
The regexValueTracker is now deprecated, please use trackers > tracker > regexValue for new configurations.
Whether the regex pattern specified is case sensitive or not.
trackers > sum
The Sum tracker is used to calculate the sum of the values returned by another tracker.
The options below are the fields that you can configure for Sum Tracker:
trackers > sum > name
Name of the tracker. The name for the tracker should only consist of alphanumeric characters (numbers and letters in upper or lower case). Other special characters can be used, such as an underscore (_) and a dash (-).
Mandatory: Yes
trackers > sum > source tracker
Name of the tracker where the plug-in retrieves the values to be computed.
Note: Do not use an average tracker or a sum tracker in the Source Tracker field.
Mandatory: Yes
trackers > average
The Average tracker is used to calculate the average of the values returned by another tracker.
The options below are the fields that you can configure for Average Tracker:
trackers > average > name
Name of the tracker. The name for the tracker should only consist of alphanumeric characters (numbers and letters in upper or lower case). Other special characters can be used, such as an underscore (_) and a dash (-).
Mandatory: Yes
trackers > average > source tracker
Name of the tracker where the plug-in retrieves the values to be computed.
Note: Do not use an average tracker or a sum tracker in the Source Tracker field.
Mandatory: Yes
table
This section allows the user to configure how the plug-in view is constructed. This section defines Headline Variables, Table Columns and Table Cells of the view.
There are two modes for constructing the view - using fixed rows or dynamic rows. In fixed rows mode, a fixed number of rows are defined which remains constant while the plug-in is running. Dynamic mode generates rows based on a 'seed' row during run-time; hence the number of rows is dynamic.
Mandatory: Yes
table > tableHeadlines
Configures headline variables.
Mandatory: No
table > headlines
Deprecated, see table > tableHeadlines
Configures headline variables.
Mandatory: No
table > headlines > headline
Deprecated, see table > tableHeadlines
Defines a headline variable.
Mandatory: No
table > headlines > headline > name
Deprecated, see table > tableHeadlines
Name of headline variable. This should be unique and not contain spaces.
Mandatory: Yes
table > headlines > headline > value
Deprecated, see table > tableHeadlines
Value of headline variable. This can either be a literal value or a tracker name prefixed by a $, in which case the value of that tracker at the time of sampling will be used.
Mandatory: Yes
table > tableColumnLabels
List of column headers for the table. It is recommended that items in the list not contain spaces, to aid in the specification of rules in the Geneos Rule Manager at a later date. If this is required however, or to include commas in a header, the label can be enclosed in double quote characters ( " ) as required. A minimum of two labels must be specified, and the table section overall must contain either a valid headline or columnLabels declaration to be valid.
Mandatory: Yes
table > columnLabels
Deprecated, see table > tableColumnLabels
List of column headers for the table. It is recommended that items in the list not contain spaces, to aid in the specification of rules in the Geneos Rule Manager at a later date. If this is required however, or to include commas in a header, the label can be enclosed in double quote characters ( " ) as required. A minimum of two labels must be specified, and the table section overall must contain either a valid headline or columnLabels declaration to be valid.
Mandatory: Yes
table > tableRows
Specifies the rows to be added to the table. These rows are added in the order that they appear.
Mandatory: No
table > rows
Deprecated, see table > tableRows.
Specifies the rows to be added to the table. These rows are added in the order that they appear.
Mandatory: No
table > rows > row > values
Deprecated, see table > tableRows.
The values in a table row, referenced by the tracker name prefixed by a $ character. (e.g. $myTracker).
Mandatory: Yes
table > rowSeedFilter
The row seed filter for a table is used when running in dynamic mode. In this mode, IX-MA will dynamically create new rows in the dataview based on the data received. This setting allows users to specify under which conditions to create a new row.
This parameter is required if no rows configuration is provided.
table > rowSeedFilter > rowSeedSelection
In dynamic rows mode, the table produced in the view is generated at run-time from the messages it processes, based on a 'seed' row specified by the user.
The rowSeedSelection parameter specifies a filter, using the same format as the Filter parameter of a tracker. This filter is then applied to each message processed. If the message passes the filter, a new table row is generated using the row seed (see below) which is then added to the view.
Mandatory: No
table > rowSeedFilter > rowSeedCells
The rowSeedCells parameter is similar to the table rowparameter above. This is a list of values which will be used to create each dynamic row. When a dynamic row is generated, the values specified are copied from this parameter to the new row. If a tracker value is referenced (using the tracker name prefixed by a $ character) then the current value of that tracker is added to the new row. This value then remains constant for the lifetime of the generated row - it will not change with the tracker values, unlike when using a fixed mode table.
Note: The value in the first column of the dynamic row must be unique and non-empty. This is required so that the row can be uniquely identified when removing dynamic rows, and also for setting rules. An easy way to accomplish this would be to add a counter tracker which just counts the number of messages passing through the plug-in. Rows will then be uniquely identified by the message number.
Mandatory: No
table > rowSeedFilter > maximumRows
The maximumRows parameter allows the users to limit the number of dynamic rows which are shown in the table view. If this parameter is absent or incorrectly specified, then the maximum number of rows is "unlimited", although in practise the gateway limit is applied which is typically set to 1000. When this limit is reached, a new row being added to the table will replace the oldest row in the table.
table > rowSeedFilter > rowTimeout
The rowTimeout parameter is an optional parameter which causes automatic removal of a dynamic row from the view after a specified interval. The interval refers to the time since the row was created, in seconds. As such, depending on the timings of the sample interval and the message poll interval, it is possible that a row will be created, and then timeout and disappear before a sample and hence will not be displayed. If this parameter is absent or incorrectly specified, then the interval is counted as "infinity" and hence the rows will not be removed from the view automatically.
table > rowSeedSelection
Deprecated, see table > rowSeedFilter.
In dynamic rows mode, the table produced in the view is generated at run-time from the messages it processes, based on a 'seed' row specified by the user.
The rowSeedSelection parameter specifies a filter, using the same format as the Filter parameter of a tracker. This filter is then applied to each message processed. If the message passes the filter, a new table row is generated using the row seed (see below) which is then added to the view.
This parameter is required if no rows section is provided.
Mandatory: No
table > rowSeedCells
Deprecated, see table > rowSeedFilter.
The rowSeedCells parameter is similar to the table rowparameter above. This is a list of values which will be used to create each dynamic row. When a dynamic row is generated, the values specified are copied from this parameter to the new row. If a tracker value is referenced (using the tracker name prefixed by a $ character) then the current value of that tracker is added to the new row. This value then remains constant for the lifetime of the generated row - it will not change with the tracker values, unlike when using a fixed mode table.
Note: The value in the first column of the dynamic row must be unique and non-empty. This is required so that the row can be uniquely identified when removing dynamic rows, and also for setting rules. An easy way to accomplish this would be to add a counter tracker which just counts the number of messages passing through the plug-in. Rows will then be uniquely identified by the message number.
This parameter is required if no rows section is provided.
Mandatory: No
table > maximumRows
Deprecated, see table > rowSeedFilter.
The maximumRows parameter allows the users to limit the number of dynamic rows which are shown in the table view. If this parameter is absent or incorrectly specified, then the maximum number of rows is "unlimited", although in practise the gateway limit is applied which is typically set to 1000. When this limit is reached, a new row being added to the table will replace the oldest row in the table.
This parameter required if no rows section is provided.
table > rowTimeout
Deprecated, see table > rowSeedFilter.
The rowTimeout parameter is an optional parameter which causes automatic removal of a dynamic row from the view after a specified interval. The interval refers to the time since the row was created, in seconds. As such, depending on the timings of the sample interval and the message poll interval, it is possible that a row will be created, and then timeout and disappear before a sample and hence will not be displayed. If this parameter is absent or incorrectly specified, then the interval is counted as "infinity" and hence the rows will not be removed from the view automatically.
This parameter required if no rows section is provided.
template
Deprecated, was never used.
Reference to an external data section that contains settings required to configure this plugin, this should replace the adapters, trackers and table sections.
Mandatory: No
dynamicCheckInterval
Specifies how often, in seconds, the plug-in will check for dynamic rows which have exceeded their timeout. When such a row is found during a check, it is subsequently removed. IX-MA configurations specifying a fixed rather than dynamic table will not perform any checks, and so this parameter will have no effect.
maxAdapterMessages
Specifies the maximum number of messages to process from a single adapter in a single poll interval.
maxMessages
Specifies the maximum number of messages to process in a single poll interval.
Defining filters for Trackers
Tracker filters define which messages the tracker should track, based on the value of the message fields. Filter expressions are written in a similar manner to arithmetic expressions, using operators and values, and expressions can be enclosed in brackets as required. Filter expressions must produce a Boolean value. i.e. The topmost operator must be a Boolean operator (see below). The exception to this is the special filter value "all", which indicates that all messages should be processed.
Constant values which can be entered are as follows:
-
Integers - a number consisting of an optional sign character followed by one or more digits (e.g. 10266 or -7).
-
Floating point values - a number consisting of an optional sign character followed by one or more digits, then a decimal point and one or more digits again. (e.g. 150.0 or -0.277)
-
String values - a string literal enclosed in double quotes. A backslash character '\' indicates the start of an escape sequence which is expanded as follows:
- \\ - A backslash character ( \ )
- \' - A single quote character ( ' )
- \" - A double quote character ( " )
- \b - A backspace character
- \f - A form feed character
- \n - A newline character
- \r - A carriage return character
- \t - A horizontal tab character
- \ooo - A character which corresponds to the octal number specified in the ASCII table. The octal number must be 1 to 3 digits long, the digits ranging from 0 to 7. So for example the sequence \101 is expanded to the character 'A'.
Dynamic values which can be entered are as follows:
-
Trackers - Tracker values can be used inside tracker calculations. When this is performed, the tracker value reported is the value of the tracker at the start of processing of the current message. Thus, it does not matter in which order the trackers are evaluated. Trackers are referenced by prefixing the tracker name with a $ character. E.g. If the tracker name is myTracker, it can be referenced using $myTracker.
-
Message field values - Message fields can be referenced in a filter by three methods, which are listed below. For each message, in the event of ambiguities, the name lookup is done in top-to-bottom order, searching for the name as a protocol name first, and the message index last.
- Protocol field name - Some message protocols have descriptive names for their fields. For example, the FIX protocol states that every message begin with a BeginString field, so specifying BeginString would produce the value of this field from the message.
- Protocol field ID - Some message protocols have a unique field ID to identify message fields. Again, in the case of FIX, these are identified by integers. Taking the example above, the BeginString field has an ID of 8, so to reference this field users should specify fieldID_8. Similarly other field IDs can be referenced using fieldID_<id>.
- Field position - It is also possible to extract the value of a field based on its position in the message. This is used by specifying field_<index>, so from our example as BeginString is the first field in a FIX message, this could be accessed using field_1.
The Boolean operators available are as follows:
| Symbol | Alternate Symbol | Description | Syntax |
|---|---|---|---|
| AND | && | And | bexp AND bexp |
| OR | || | Or | bexp OR bexp |
| NOT | ! | Not | NOT bexp |
| != | Not equals | exp != exp | |
| = | Equals | exp = exp | |
| < | Less than | exp <exp | |
| <= | Less than or equal | exp <=exp | |
| > | Greater than | exp >exp | |
| >= | Greater than or equal | exp >= exp | |
| LIKE | Wildcard string comparison | exp LIKE exp | Only the right-hand expression should contain wildcard characters. |
| UNLIKE | The opposite of the above | exp UNLIKE exp | As above. |
Where bexp denotes a Boolean expression which results from using a Boolean operator, and exp denotes an expression resulting from using normal operators.
Normal operators are as follows:
| Symbol | Description | Syntax | Notes |
|---|---|---|---|
| + | Addition | exp + exp | Performs string concatenation if both expressions are strings. |
| - | Subtraction | exp - exp | |
| / | Division | exp / exp | Division by 0 results in 0 |
| * | Multiplication | exp * exp | |
| ABS | Absolute value | ABS exp | |
| STR | Convert to string | STR exp | Does not affect strings |
Where exp denotes an expression resulting from using normal operators.
Type conversions
Since the types of all variables are not known at the time the plug-in is initialised, the plug-in will attempt to convert types on either side of a binary operator so that they are comparable.
If the types cannot be converted and the operator is meaningless for the types involved, or if a specified message field or tracker value is not present, then the filter will evaluate to False and the tracker will not process that message.
Type conversion is performed according to the following table:
| Type 1 | Type 2 | Result |
|---|---|---|
| Integer | Integer | Integer |
| Integer | String | Integer |
| Float | Float | Float |
| Float | Integer | Float |
| Float | String | Float |
| String | String | String |
Thus, it is not possible to automatically convert from a number type to a String - the STR operator is provided for this purpose.
In the cases where one of the types is a string and the other a number, conversion of the string to a number is attempted. This conversion stops at the first non-number character of the string, so for example the string "-1005 unack'd" will be converted to the number -1005, and the string "144.78" to 144.78. If the string is being converted to an integer this will then be truncated to 144.