Geneos ["Geneos"]
You are currently viewing an older version of the documentation. You can find the latest documentation here.
["Geneos > Gateway"]["Technical Reference"]
Recommended Reads

Static Variables

Overview

The Static variables section of the Gateway setup defines a number of static variables.

The main use of static variables is to allow a common set of configuration options to be referenced by samplers. These settings are available in a single place and can be easily updated, rather than having to alter the configuration of a number of samplers manually.

This section is divided into a number of sub-sections, which can only be referenced by plug-ins of a certain type. For example, FKM tables can only be referenced by samplers using the FKM plug-in.

Configuration

FKM Tables

staticVars > fkmTables

Defines all the FKM tables in the static variables section. The FKM tables section allows you to configure tables separately to an FKM plug-in instance. These tables can then be referenced by individual FKM files across multiple samplers / managed entities.

For more information about tables, see File Keyword Monitor (FKM).

Mandatory: No

staticVars > fkmTables > fkmTable

Defines an FKM table which can be referenced in FKM samplers.

Mandatory: No

staticVars > fkmTables > fkmTable > name

The name of the static FKM table. This name should be unique among all other FKM tables defined in the static variables section.

Mandatory: Yes

staticVars > fkmTables > fkmTableGroup

A grouping mechanism to allow FKM tables to be logically grouped together.

Mandatory: No

staticVars > fkmTables > fkmTableGroup > name

The name of the FKM table group.

Mandatory: Yes

Fix-analyzer Templates

staticVars > fix-analyzerTemplates

This section contains a set of templates for use with the Fix-analyzer plugin.

Mandatory: No

staticVars > fix-analyzerTemplates > fix-analyzerTemplateGroup

A grouping mechanism to allow Fix-analyzer templates to be logically grouped together.

Mandatory: No

staticVars > fix-analyzerTemplates > fix-analyzerTemplateGroup > name

The name by which the Fix-analyzer template group is referenced.

Mandatory: Yes

User View Templates

staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate

A template for a Fix-analyzer User View. User views are a customised view configured by the user. These views contain configuration settings for the rows and columns to be displayed. The column values can be computed statistics or values from either individual messages, or orders as detected by the plug-in.

Mandatory: No
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > name

The name by which the Fix-analyzer User View template is referenced.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > viewName

The viewName setting specifies the name of the view. View names must be unique across all views for a sampler, so that each view can be uniquely referenced.

Mandatory: Yes

Row configuration

staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > rowIdentifier

The row identifier setting specifies which part of a FIX message forms the row name which is displayed in a view.

For each message processed, the value for the configured FIX field is extracted, and each unique value creates a new row to be added to the view. Messages then go on to update the statistics (column values) for only the row whose field value it matches. If a message does not have the specified FIX field (or if the field has an empty value) the text "<none>" is used as the row name.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > rowIdentifier> custom

The custom row identifier allows the user to specify the FIX field tags, which will be extracted and used as the row name. Fixanalyzer allows for 2 levels of identifier tags, primary and secondary. Secondary tags can only be specified once a primary tag has been configured.

If both a primary and secondary row identifier is configured, then the result is a view with 2 levels of row name. Row names of the form "primaryValue#secondaryValue" are value rows, and the statistics (column values) on this row display values for those messages with matching identifier fields. Row names of the form "primaryValue" are summary rows, and summarise the data of the sub-rows with the same starting prefix.

Mandatory: Yes - one of custom or senderTarget must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > rowIdentifier> senderTarget

The senderTarget setting specifies that the view should use the FIX fields SenderCompId (49) and TargetCompId (56) for the row identifier.

If using these fields you may also optionally enable the session status columns, which allows you to create a customised session analysis view.

Mandatory: Yes - one of custom or senderTarget must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > rowIdentifier> senderTarget > showSessionStatus

If enabled, this setting adds the columns status, logon and logoff to the user view. These columns are normally displayed in a session analysis view, so enabling these allows the user to configure a customised session analysis view using the user view.

Mandatory: No
Default: false - session status columns are not displayed.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > rowIdentifier> senderTarget > showSessionStatus > sessionTimeout

The session timeout specifies a maximum period of inactivity for a session in seconds. If no messages are sent or received for this amount of time, then a session is considered to be timed out. This is displayed in the logoff column.

Timeouts are calculated by comparing the last message timestamp for that session against the local time on the Netprobe host.

Mandatory: No
Default: 0 - no timeout
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > rowIdentifier> senderTarget > showExpectedStatus

This setting controls whether the expectedStatus column is displayed in the view. This column is normally present in a session analysis view if conversations have been configured. It can optionally be added to a user view to allow users to configure a customised session analysis view.

The expectedStatus column displays whether a session (senderTarget row) is expected to be up or down based on the time information configured in the conversation settings for the sampler. Values in this column will be empty unless conversations have been configured.

Mandatory: No
Default: false - expectedStatus column is not displayed.

Columns

The column configuration defines what data is displayed for each row in the dataview. Users can extract message or order values and compute selected statistics of these for display using the configuration described below.

User views currently support two types of column; message columns and order columns.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > displayName

Specifies the name of the column as it will appear in the dataview. The name must be unique among all other columns configured for the view.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > rollingPeriod

This setting allows a rolling period to be configured for the column. This allows you to - for example - configure a column that shows a count of messages received in the last 5 minutes.

Values are specified as an integer in 3 different units: seconds, minutes and hours. To configure a period of 1.5 hours for example, configure this as 90 minutes instead.

Mandatory: No
Default: No rolling period.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > filter

References a filter from the filters section by name. Filters are applied to the data before the column processes the update. See the message column and order column sections for more details.

Mandatory: No
Default: No filter - column will process all updates.

Message columns

staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > message

Message columns process FIX messages individually when computing their statistics. There are 3 types of message column which can be configured; sum, count and value columns.

If a message column is configured with a filter, then only messages which pass the filter are processed by the column. Therefore, a count column configured in this way would count the number of messages which passed the filter.

Mandatory: Yes - a valid column type must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > message > type > sum

The sum message column sums the values of the specified FIX fieldId, for all messages processed by this column (i.e. messages that passed the filter, if configured).

Summary rows for sum columns will display a sum of all values displayed for the sub-rows.

A sum message column could be used to obtain the total size (in bytes) of FIX messages processed for a particular party, by summing FIX field 9 (BodyLength).

Mandatory: Yes - one of sum, count or value must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > message > type > sum > fieldId

This setting specifies the FIX field code for a sum column. Values for this field will be extracted and summed; therefore only numerical fields should be configured.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > message > type > count

The count message column is an integer value which starts at zero, and increments by one for each message which is processed by the column (i.e. messages that passed the filter, if configured).

Summary rows for count columns will display a sum of all counts displayed for the sub-rows.

A count column could be used to could all rejected messages for a particular client, by configuring a filter to match on FIX field 35=9 (OrderCancelReject).

Mandatory: Yes - one of sum, count or value must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > message > type > value

The value message column stores the extracted FIX fieldId or named value of the last message which was processed by the column (i.e. messages that passed the filter, if configured).

Summary rows for value columns will display the latest value (using the message timestamp) of the values displayed by the sub-rows.

A message value column could be used to show the latest error for a particular session, by extracting FIX field 58 (Text). This field is typically used to describe the error for a Don't Know Trade (35=Q) or an order reject execution (35=8 and 150=8).

Mandatory: Yes - one of sum, count or value must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > message > type > value > fieldId

This setting specifies the FIX field code for a value column. Values for this field will be extracted, and the latest value will be displayed.

Mandatory: Yes - one of fieldId or named must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > message > type > value > named

This setting specifies an additional message property value to be used for a value column. Properties which can be configured are as follows:

Property Description
TimeStamp

The timestamp of the message in a human readable format.

e.g. Thu Aug 23 14:55:02.148 2010.

SecondsSince The number of seconds since the timestamp value, using the current local time of the Netprobe host.
MinutesSince The number of minutes since the timestamp value, using the current local time of the Netprobe host.
Mandatory: Yes - one of fieldId or named must be configured.

Order columns

staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order

Order columns display statistics for all orders which are applicable to the given dataview row. For example if the row configuration specifies that rows equate to exchanges, then order columns for a specific row will display statistics for orders to that exchange.

Order statistics can be filtered by current order status, as specified by the match states setting. This means that (unlike message columns) order columns can change value when a message is received but not processed for that particular row (since the message may change the order state). See the Order Tracking Appendix in the FIX-analyzer Plug-in User Guide for more details.

Filters for order columns are applied to the first message of the order seen for each dataview row, so that the order is only filtered once for that column.

Mandatory: Yes - a valid column type must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > count

The count column shows the number of orders which pass the configured filter and order match states. An example usage of this column could be to display the number of open orders (i.e. states "new" or "partiallyFilled") for that row.

Mandatory: Yes - a valid order-column type must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > value

The value column shows the latest updated value for the specified FIX fieldId or named property, from orders which pass the configured filter and order match states.

Mandatory: Yes - a valid order-column type must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > value > fieldId

The fieldId setting specifies a FIX field id, which will be used to extract values from FIX messages for use by an order column.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > value > named

The named setting specifies a property which will be extracted from an order for use by an order column. Available properties are as follows:

State Description
ackLatency

The acknowledgement latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to the "new" state.

e.g. The time between a 35=D FIX (single order) message and the first 35=8 (execution) reply message.

fillLatency The fill latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to a finished state.
Status The current order status, which will be checked against the match states configured for each order column.
Tracking The current tracking status, used internally by Fix-analyzer. One of "New", "Acknowledged" or "Finished".

For more detail on the order status, see the Order Tracking Appendix of the FIX-analyzer Plug-in User Guide.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > sum

The sum column sums up the specified FIX fieldId or named properties extracted for all applicable orders, subject to the filters and order match states selected. Non-numeric values processed by this column may be converted to a number if they begin with a numeric prefix, but will otherwise be treated as zero.

An example usage for this column could be to sum FIX field 151 (LeavesQty) for all orders in states "new" or "partiallyFilled". This would then show the total quantity for all orders, which are the shares remaining to be executed (per dataview row).

Mandatory: Yes - a valid order-column type must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > sum > fieldId

The fieldId setting specifies a FIX field id, which will be used to extract values from FIX messages for use by an order column.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > sum > named

The named setting specifies a property which will be extracted from an order for use by an order column. Available properties are as follows:

State Description
ackLatency

The acknowledgement latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to the "new" state.

e.g. The time between a 35=D FIX (single order) message and the first 35=8 (execution) reply message.

fillLatency The fill latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to a finished state.
Status The current order status, which will be checked against the match states configured for each order column.
Tracking The current tracking status, used internally by Fix-analyzer. One of "New", "Acknowledged" or "Finished".

For more detail on the order status, see the Order Tracking Appendix of the FIX-analyzer Plug-in User Guide.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > max

The max column displays the maximum FIX fieldId or named property value extracted for all applicable orders, subject to the filters and order match states selected.

A column of this type could be configured to display the maximum acknowledgement-latency for all orders of a dataview row.

Mandatory: Yes - a valid order-column type must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > max > fieldId

The fieldId setting specifies a FIX field id, which will be used to extract values from FIX messages for use by an order column.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > max > named

The named setting specifies a property which will be extracted from an order for use by an order column. Available properties are as follows:

State Description
ackLatency

The acknowledgement latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to the "new" state.

e.g. The time between a 35=D FIX (single order) message and the first 35=8 (execution) reply message.

fillLatency The fill latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to a finished state.
Status The current order status, which will be checked against the match states configured for each order column.
Tracking The current tracking status, used internally by Fix-analyzer. One of "New", "Acknowledged" or "Finished".

For more detail on the order status, see the Order Tracking Appendix of the FIX-analyzer Plug-in User Guide.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > min

The min column displays the minimum FIX fieldId or named property value extracted for all applicable orders, subject to the filters and order match states selected.

A column of this type could be configured to display the minimum acknowledgement-latency for all orders of a dataview row.

Mandatory: Yes - a valid order-column type must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > min > fieldId

The fieldId setting specifies a FIX field id, which will be used to extract values from FIX messages for use by an order column.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > min > named

The named setting specifies a property which will be extracted from an order for use by an order column. Available properties are as follows:

State Description
ackLatency

The acknowledgement latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to the "new" state.

e.g. The time between a 35=D FIX (single order) message and the first 35=8 (execution) reply message.

fillLatency The fill latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to a finished state.
Status The current order status, which will be checked against the match states configured for each order column.
Tracking The current tracking status, used internally by Fix-analyzer. One of "New", "Acknowledged" or "Finished".

For more detail on the order status, see the Order Tracking Appendix of the FIX-analyzer Plug-in User Guide.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > average

The min column displays the average of the FIX fieldId or named property values extracted for all applicable orders, subject to the filters and order match states selected.

A column of this type could be configured to display the average acknowledgement-latency for all orders of a dataview row.

Mandatory: Yes - a valid order-column type must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > average > fieldId

The fieldId setting specifies a FIX field id, which will be used to extract values from FIX messages for use by an order column.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > average > named

The named setting specifies a property which will be extracted from an order for use by an order column. Available properties are as follows:

State Description
ackLatency

The acknowledgement latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to the "new" state.

e.g. The time between a 35=D FIX (single order) message and the first 35=8 (execution) reply message.

fillLatency The fill latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to a finished state.
Status The current order status, which will be checked against the match states configured for each order column.
Tracking The current tracking status, used internally by Fix-analyzer. One of "New", "Acknowledged" or "Finished".

For more detail on the order status, see the Order Tracking Appendix of the FIX-analyzer Plug-in User Guide.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > stdDev

The min column displays the standard deviation of the FIX fieldId or named property values extracted for all applicable orders, subject to the filters and order match states selected.

A column of this type could be configured to display the standard deviation of acknowledgement-latency for all orders of a dataview row.

Mandatory: Yes - a valid order-column type must be configured.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > stdDev > fieldId

The fieldId setting specifies a FIX field id, which will be used to extract values from FIX messages for use by order column.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > type > stdDev > named

The named setting specifies a property which will be extracted from an order for use by an order column. Available properties are as follows:

State Description
ackLatency

The acknowledgement latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to the "new" state.

e.g. The time between a 35=D FIX (single order) message and the first 35=8 (execution) reply message.

fillLatency The fill latency in milliseconds. The time taken for an order to go from the "unacknowledged" state to a finished state.
Status The current order status, which will be checked against the match states configured for each order column.
Tracking The current tracking status, used internally by Fix-analyzer. One of "New", "Acknowledged" or "Finished".

For more detail on the order status, see the Order Tracking Appendix of the FIX-analyzer Plug-in User Guide.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-user-viewTemplate > columns > column > columnType > order > matchStates

This setting specifies the states of orders which will contribute towards the column value. Orders with a state that has not been configured here will not be considered by the column.

Possible states include:

State Description
unacknowledged An order which has not been acknowledged by the other party. E.g. A Single Order message (35=D) for which no corresponding Execution message (35=8) has been seen.
new An acknowledged order.
partiallyFilled An order which has been partially filled.
filled An order which has been completely filled. This state will also apply to an Order Cancel Request (35=F) which has succeeded.
replaced An order which was replaced by a successful Order Cancel / Replace Request (35=G).
cancelled An order which was cancelled by a successful Order Cancel Request (35=F).
rejected An order which was rejected, or an Order Cancel Request (35=F) which was rejected by an Order Cancel Reject message (35=9).
finished Provided for convenience of configuration - this state will match all filled, replaced, cancelled or rejected orders.

For example, a count order column configured for the "unacknowledged" state would show a count of all unacknowledged orders. Orders which were subsequently acknowledged would then be removed from the count. By adding a filter to this count, we could (for example) count all unacknowledged orders to a particular exchange.

Mandatory: Yes

Message Detector View Templates

staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate

A template for a Fix-analyzer Message Detector View. Message detector views extract and display the contents of "interesting" messages. They do this by dynamically adding new rows to the dataview when a message is detected which matches a configured filter. Each row in the dataview represents a message which passed the filter. The values displayed for the rows are determined by the user column configuration as detailed below.

Mandatory: No
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > name

The name by which the Fix-analyzer Message Detector template is referenced.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > viewName

The viewName setting specifies the name of the view. View names must be unique across all views for a sampler, so that each view can be uniquely referenced.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > filter

The filter setting specifies the filter which will be used to determine "interesting" messages. Messages which pass the filter will be added to the message detector view as a new row.

The filter is referenced by name from the filters available to the plug-in. To filter on multiple "interesting" message types, combine multiple filters using the Boolean filter types (see the FIX-analyzer Plug-in User Guide for more information on filters).

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > messageTimeout

The message timeout setting specifies how old a message can be (in seconds) before it is removed from the message detector view.

If the difference between the current time (obtained from the Netprobe host local time) and the message timestamp is larger than this threshold, then the row representing this message is removed from the view.

Mandatory: No
Default: 0 seconds - no timeout
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > messageCount

The message count setting controls the maximum number of messages which will be displayed in a message group. A message group is a set of messages which share the same unique id. If the maximum limit is reached, a new incoming message will replace the oldest message in the group.

If the message count is set to zero, then the message group feature will be disabled and all messages displayed individually. If using this option, then it is recommended to ensure the row names are guaranteed to be unique by using the autoGenerated id type.

Mandatory: No
Default: 10 messages per group maximum

Row configuration

staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > uniqueId

The uniqueId setting specifies how to construct a unique row id (rowname) from a message for display in the message detector view.

The uniqueId is made up of one or more id elements, each of which can extract a FIX field or named property from the message. If using more than one id, the field values will be compounded together separated by dashes (the - character) to form the uniqueId.

If several messages are found with the same id, then the message detector will display these as sub-rows under a group row. This set of messages is then called a message group. The maximum number of messages per group can be configured using the messageCount setting.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > uniqueId > id > fieldId

The fieldId setting specifies which FIX field to extract from a message. This value will then be used to form the uniqueId (the row name) in the message detector view.

Mandatory: Yes - one of fieldId, named or autoGenerated must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > uniqueId > id > named

The named setting specifies a named FIX message property to extract. This value will then be used to form the uniqueId (the row name) in the message detector view.

Available properties are as follows:

Property Description
TimeStamp

The timestamp of the message, in the format:

Mon Sep 06 11:42:37.084 2010

SecondsSince

The number of seconds elapsed since the message timestamp.

Note: This value is only computed at the point when the row is created. The row name will not update to reflect time changes.

Mandatory: Yes - one of fieldId, named or autoGenerated must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > uniqueId > id > autoGenerated

The autoGenerated setting generates a series of incrementing numbers starting from 1. These values will then be used to form the uniqueId (the row name) in the message detector view.

Users can use this setting if they are unsure whether the FIX fields they have specified as ids will be unique. If using only autoGenerated to create a unique id, it is recommended to disable the message group feature via the messageCount setting.

Mandatory: Yes - one of fieldId, named or autoGenerated must be specified.

Column configuration

staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > columns

The columns setting specifies the columns which will be displayed in this message analyzer view. For each message which passes the filter, fields from the message are extracted as per the column configuration and displayed as a new dataview row.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > columns > column > displayName

Specifies the name of this column as it will appear in the dataview. Column names must be unique amongst all other columns configured for this message detector view.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > columns > column > value

This setting specifies single column which will extract a value from the FIX message for display in a row. Values can be specified either as a FIX fieldId, or a named message property.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > columns > column > value > fieldId

The fieldId setting specifies which FIX field to extract from a message. The resulting value will then be displayed as a column value in a new message detector row.

Mandatory: Yes - one of fieldId or named must be specified.
staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > columns > column > value > named

The named setting specifies which named message property to extract from a message. The resulting value will then be displayed as a column value in a new message detector row.

Available properties are as follows:

Property Description
TimeStamp

The timestamp of the message, in the format:

Mon Sep 06 11:42:37.084 2010

SecondsSince The number of seconds elapsed since the message timestamp, using the Netprobe host local time.
MinutesSince The number of minutes elapsed since the message timestamp, using the Netprobe host local time.
Mandatory: Yes - one of fieldId or named must be specified.

Session Analysis View Templates

staticVars > fix-analyzerTemplates > fix-analyzer-session-analysis-viewTemplate

A template for a Fix-analyzer Session Analysis View. The session analysis view displays the current status for the conversations on a monitored FIX engine. This view is useful for ensuring that specific connections remain up throughout the trading day. For more information, please refer to the Appendix on Session State Tracking in the FIX-analyzer Plug-in User Guide.

Each Fix-analyzer plug-in can have a single session analysis view, which is created when this setting is enabled.

Expected FIX conversations can be configured using the conversations sampler setting. This also allows other properties such as an alias to be specified. A start and end time can be specified for a conversation. Please see the FIX-analyzer Plug-in User Guide for more information about conversations.

Mandatory: No
staticVars > fix-analyzerTemplates > fix-analyzer-session-analysis-viewTemplate > name

The name by which the Fix-analyzer Session Analysis template is referenced.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-session-analysis-viewTemplate > viewName

The viewName setting specifies the name of the view. View names must be unique across all views for a sampler, so that each view can be uniquely referenced.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-session-analysis-viewTemplate > showSessionStatus

Session settings

Mandatory: No
staticVars > fix-analyzerTemplates > fix-analyzer-session-analysis-viewTemplate > showSessionStatus > sessionTimeout

The session timeout specifies a maximum period of inactivity for a session in seconds. If no messages are sent or received for this amount of time, then a session is considered to be timed out. This is displayed in the logoff column.

Timeouts are calculated by comparing the last message timestamp for that session against the local time on the Netprobe host.

Mandatory: No
Default: 0 - no timeout

Filter List Templates

staticVars > fix-analyzerTemplates > fix-analyzer-filter-listTemplate

A template for a Fix-analyzer Filter List. Filter lists allow filter definitions to be shared between samplers. This can help reduce the configuration burden (less filters need to be configured) and also increase maintainability by providing a single place to update when filters need to be changed.

Filters lists are configured in the top-level "Static variables" section of the gateway setup, inside the "Fix-analyzer templates" sub-section.

To use a filter list in a Fix-analyzer plug-in the list must be referenced by name. Filters defined in this list are then available for use by other parts of the plug-in setup, and are referenced by name in the same was as for normal filters.

Filter names inside a single sampler definition must be unique. If a filter in a filter list has the same name as another filter (defined in the same filter list, another referenced filter list, or directly in the plug-in configuration) then this is an error. The Netprobe log will contain diagnostic errors in this case

Mandatory: No
staticVars > fix-analyzerTemplates > fix-analyzer-filter-listTemplate > name

The name by which the Fix-analyzer Filter List template is referenced.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-filter-listTemplate > filters

List of filters held in a static variable. See the FIX-analyzer Plug-in User Guide for more information on filters.

Mandatory: Yes
staticVars > fix-analyzerTemplates > fix-analyzer-filter-listTemplate > filters > filter

A filter within the list. See the FIX-analyzer Plug-in User Guide for more information on filters.

Mandatory: Yes

GL-names

staticVars > gl-names

The GL names section contains name lists which can be referenced by the GL‑Router or GL‑Permissions plug-ins.

Refer to GL Router Plug-in for further information on GL names.

Mandatory: No

staticVars > gl-names > gl-names

A GL names list contains a mapping of identifiers to strings.

These lists allow users to configure meaningful names for their GL users, processes and connections, which are then displayed as part of the monitoring data produced by the GL plug-ins.

Mandatory: No

staticVars > gl-names > gl-names > name

The name of this GL name list. This name should be unique among all other name lists defined in the static variables section.

Mandatory: Yes

staticVars > gl-names > gl-namesGroup

A grouping mechanism to allow GL names lists to be logically grouped together.

Mandatory: No

staticVars > gl-names > gl-namesGroup > name

The name of the GL names list group.

Mandatory: Yes

Process Descriptors

staticVars > processDescriptors

The process descriptors section contains a set of process descriptors. Each descriptor describes a particular process, and can be referenced by a Processes plug-in to start monitoring this process.

Refer to Processes for further information on process descriptors.

Mandatory: No

staticVars > processDescriptors > processDescriptor

A process descriptor describes a process running on a machine, in such a way that the Processes plug-in can monitor it. This typically involves selecting unique elements of the executable name or command-line.

Mandatory: No

staticVars > processDescriptors > processDescriptor > name

Each process descriptor in the static variables section must be uniquely named, so that the descriptor can be referenced uniquely from a Processes plug-in.

Mandatory: Yes

staticVars > processDescriptors > processDescriptorGroup

A grouping mechanism to allow process descriptors to be logically grouped together.

Mandatory: No

staticVars > processDescriptors > processDescriptorGroup > name

The name of the process descriptor group.

Mandatory: Yes

RMC Templates

staticVars > rmcTemplates

This section contains a set of RMC templates, which can be referenced by RMC‑Interface plug-ins. Each template describes a set of RMC variables, which will be displayed by the plug-in.

See the XML-RPC Instrumentation API for further information on RMC templates.

Mandatory: No

staticVars > rmcTemplates > rmcTemplate

An RMC template is used by the RMC‑Interface plug-in to describe what the plug-in should monitor. The template picks out a set of RMC variables as published by the data-source, which then form a view in the order specified in the template.

Mandatory: No

staticVars > rmcTemplates > rmcTemplate > name

Each RMC template in the static variables section must be uniquely named among all other templates. This allows the template to be unambiguously referenced from within an RMC‑Interface plug-in setup.

Mandatory: Yes

staticVars > rmcTemplates > rmcTemplateGroup

A grouping mechanism to allow RMC templates to be logically grouped together.

Mandatory: No

staticVars > rmcTemplates > rmcTemplateGroup > name

The name of the RMC template group.

Mandatory: Yes

Message Tracker Format Types

staticVars > messageTrackerFormatTypes

This section contains a set of Message Tracker Format Type templates, which can be referenced by the Message Tracker plug-in. Each message tracker format type template specifies a type of message to read.

Mandatory: No

staticVars > messageTrackerFormatTypes > messageTrackerFormatType

A message tracker format type template. This specifies a type of message to read.

Mandatory: No

staticVars > messageTrackerFormatTypes > messageTrackerFormatType > name

The name by which the message tracker format type template is referenced.

Mandatory: Yes

staticVars > messageTrackerFormatTypes > messageTrackerFormatTypeGroup

A grouping mechanism to allow message tracker format type templates to be logically grouped together.

Mandatory: No

staticVars > messageTrackerFormatTypes > messageTrackerFormatTypeGroup > name

The name of the message tracker format type template group.

Mandatory: Yes

staticVars > messageTrackerFormatTypes > messageTrackerFormatType > timestamp

This specifies the location and format of the message timestamp.

Mandatory: Yes

staticVars > messageTrackerFormatTypes > messageTrackerFormatType > timestamp > regexPattern

This specifies the location of the timestamp with the message. Data extracted by the applying the regular expression to the message and extracting the first group (the data the matches the regular expression within the first bracket) from the message. The system uses Perl regular expressions.

More information can be found at http://www.perl.com/doc/manual/html/pod/perlre.html

Mandatory: Yes

staticVars > messageTrackerFormatTypes > messageTrackerFormatType > timestamp > format

This specifies the format of the timestamp.

For a full list of the available Time Formatting Parsing Codes, see Time Zones and Time Formats.

Mandatory: Yes

Message Tracker Tag Mappings

staticVars > messageTrackerTagMappings

This section contains a set of Message Tracker Tag Mapping templates, which can be referenced by the Message Tracker plug-in. Each message tracker tag mapping template specifies a set of mappings from the tags provided by the formatType to a normalised message.

Mandatory: No

staticVars > messageTrackerTagMappings > messageTrackerTagMapping

A message tracker tag mapping template. This specifies a set of mappings from the tags provided by the formatType to a normalised message.

Mandatory: No

staticVars > messageTrackerTagMappings > messageTrackerTagMapping > name

The name by which the message tracker tag mapping template is referenced.

Mandatory: Yes

staticVars > messageTrackerTagMappings > messageTrackerTagMappingGroup

A grouping mechanism to allow message tracker tag mapping templates to be logically grouped together.

Mandatory: No

staticVars > messageTrackerTagMappings > messageTrackerTagMappingGroup > name

The name of the message tracker format type template group.

Mandatory: Yes

staticVars > messageTrackerTagMappings > messageTrackerTagMapping > IDs > item

This creates a named ID from a set of tags. These tags will be user defined if the format type selected was Regex. The tags will be defined by the format type reader for other format types. For example, when using Fix the tags will be the numeric FIX tags. Please see the ITRS provided documentation for the format type being used (see the information on Data Normalization in the Message Tracker Plug-in User Guide). An ID should be unique for the message. Two messages are considered to be the same message if they share an ID with the same name and the same value.

Mandatory: No

staticVars > messageTrackerTagMappings > messageTrackerTagMapping > IDs > item > format

This allows the tags to be combined together in a user specified way. If the format is not specified then the tag values are placed together space separated (see the information on User defined Tag combining in the Message Tracker Plug-in User Guide).

Mandatory: No

staticVars > messageTrackerTagMappings > messageTrackerTagMapping > attributes > item

This creates a named attribute from a set of tags. These tags will be user defined if the format type selected was Regex. The tags will be defined by the format type reader for other format types. For example, when using Fix the tags will be the numeric FIX tags. Please see the ITRS provided documentation for the format type being used (see the information on Data Normalization in the Message Tracker Plug-in User Guide).

Mandatory: No

staticVars > messageTrackerTagMappings > messageTrackerTagMapping > attributes > item > format

This allows the tags to be combined together in user specified way. If the format is not specified then the tag values are placed together space separated (see the information on User defined Tag combining in the Message Tracker Plug-in User Guide).

Mandatory: No