Static Variables

Overview Copied

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 Copied

FKM Tables Copied

staticVars > fkmTables Copied

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) Plug-In - User Guide.

Mandatory: No

staticVars > fkmTables > fkmTable Copied

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

For more information, refer to the key table setting.

Mandatory: No

staticVars > fkmTables > fkmTable > name Copied

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 Copied

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

Mandatory: No

staticVars > fkmTables > fkmTableGroup > name Copied

The name of the FKM table group.

Mandatory: Yes

Fix-analyzer Templates Copied

staticVars > fix-analyzerTemplates Copied

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

Mandatory: No

staticVars > fix-analyzerTemplates > fix-analyzerTemplateGroup Copied

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

Mandatory: No

staticVars > fix-analyzerTemplates > fix-analyzerTemplateGroup > name Copied

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

Mandatory: Yes

User View Templates Copied

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

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 Copied

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

Mandatory: Yes

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

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 Copied

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 “” is used as the row name.

Mandatory: Yes

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

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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

Mandatory: Yes - one of fieldId or named must be configured.

Order columns

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

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 Copied

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 Copied

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 Copied

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 Copied

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

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 Copied

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 Copied

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 Copied

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

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 Copied

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 Copied

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 Copied

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

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 Copied

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 Copied

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 Copied

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

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 Copied

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 Copied

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 Copied

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

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 Copied

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 Copied

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 Copied

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

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 Copied

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:

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 Copied

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

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 Copied

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

Mandatory: Yes

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

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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:

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

staticVars > fix-analyzerTemplates > fix-analyzer-message-detector-viewTemplate > uniqueId > id > autoGenerated Copied

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 Copied

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 Copied

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 Copied

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 Copied

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 Copied

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:

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

Session Analysis View Templates Copied

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

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 Copied

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

Mandatory: Yes

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

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 Copied

Session settings.

Mandatory: No

staticVars > fix-analyzerTemplates > fix-analyzer-session-analysis-viewTemplate > showSessionStatus > sessionTimeout Copied

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 Copied

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

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 Copied

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

Mandatory: Yes

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

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 Copied

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

Mandatory: Yes

GL-names Copied

staticVars > gl-names Copied

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

Refer to for further information on GL names.

Mandatory: No

staticVars > gl-names > gl-names Copied

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 Copied

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 Copied

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

Mandatory: No

staticVars > gl-names > gl-namesGroup > name Copied

The name of the GL names list group.

Mandatory: Yes

Process Descriptors Copied

staticVars > processDescriptors Copied

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 Plug-in for further information on process descriptors.

Mandatory: No

staticVars > processDescriptors > processDescriptor Copied

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 Copied

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 Copied

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

Mandatory: No

staticVars > processDescriptors > processDescriptorGroup > name Copied

The name of the process descriptor group.

Mandatory: Yes

RMC Templates Copied

staticVars > rmcTemplates Copied

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 Copied

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 Copied

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 Copied

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

Mandatory: No

staticVars > rmcTemplates > rmcTemplateGroup > name Copied

The name of the RMC template group.

Mandatory: Yes

Message Tracker Format Types Copied

staticVars > messageTrackerFormatTypes Copied

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 Copied

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

Mandatory: No

staticVars > messageTrackerFormatTypes > messageTrackerFormatType > name Copied

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

Mandatory: Yes

staticVars > messageTrackerFormatTypes > messageTrackerFormatTypeGroup Copied

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

Mandatory: No

staticVars > messageTrackerFormatTypes > messageTrackerFormatTypeGroup > name Copied

The name of the message tracker format type template group.

Mandatory: Yes

staticVars > messageTrackerFormatTypes > messageTrackerFormatType > timestamp Copied

This specifies the location and format of the message timestamp.

Mandatory: Yes

staticVars > messageTrackerFormatTypes > messageTrackerFormatType > timestamp > regexPattern Copied

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 Copied

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 Copied

staticVars > messageTrackerTagMappings Copied

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 Copied

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 Copied

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

Mandatory: Yes

staticVars > messageTrackerTagMappings > messageTrackerTagMappingGroup Copied

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

Mandatory: No

staticVars > messageTrackerTagMappings > messageTrackerTagMappingGroup > name Copied

The name of the message tracker format type template group.

Mandatory: Yes

staticVars > messageTrackerTagMappings > messageTrackerTagMapping > IDs > item Copied

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 Copied

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 Copied

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 Copied

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

Database Connections Copied

Basic tab Copied

Connect to a Db2 database Copied

Sample dataview Copied

Connect to a MySQL database Copied

Sample dataview Copied

Connect to an Oracle database Copied

MYALIAS =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = MYHOST)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SID = MYDATABASE)
      (SERVICE_NAME = MYDATABASE)
    )
  )

(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=MYHOST)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SID=MYDATABASE)(SERVICE_NAME=MYDATABASE)))

export ORACLE_HOME=/usr/local/oracle/instantclient_11_2
export LD_LIBRARY_PATH=${ORACLE_HOME}/lib64:${LD_LIBRARY_PATH}

Sample connection string: (DESCRIPTION =   (
ADDRESS = (PROTOCOL = TCP)
HOST = 192.168.100.87)(PORT = 1521))
(CONNECT_DATA =   (SERVER = DEDICATED)
(SERVICE_NAME = geneosdb.mnl.itrsgroup.com)     )   )

Connection timeout configuration for Oracle database Copied

You can configure connection timeout using the sqlnet.ora or tnsnames.ora file to define how long the Oracle client will wait for a connection to be established before reporting an error. This is useful to manage network delays and ensure responsive Oracle database connections within the SQL Toolkit plugin.

Set the timeout value in seconds (X) in either of the following:

• sqlnet.ora

  SQLNET.OUTBOUND_CONNECT_TIMEOUT = X
  

• tnsnames.ora

  DESCRIPTION = (CONNECT_TIMEOUT = X)
  

Connect to an Oracle database with Kerberos authentication Copied

1. Login via SSH as a user that is a part of the Active Directory.
2. Run the kinit command.
3. Configure an Oracle SQL Toolkit sampler without setting the username and the password.

Sample dataview Copied

Connect to a PostgreSQL database Copied

Note

• PostgreSQL is not supported in IBM AIX platforms.
• PostgreSQL connections configured with SSL or TLS are not supported in SUSE 12 platforms.

Sample dataview Copied

Connect to a SQL Server database Copied

Sample dataview Copied

Connect to a Sybase database Copied

Sample dataview Copied

Advanced tab Copied