MDM Feed Adapters

Bloomberg adapter Copied

The Bloomberg feed adapter uses the Bloomberg API (BLPAPI) to subscribe to market data via B-PIPE, delivered by a managed Bloomberg Appliance.

This adapter is subject to the following deployment considerations.

1. The Netprobe must be able to create a TCP connection to the Bloomberg Appliance to obtain data.
2. The Market Data Monitor plugin must be authorised to subscribe to the monitored data (as determined by the specific user monitoring requirements).

Please contact your firm’s Bloomberg EMRS administrator to create the required permission entries. The examples in this document assume that MDM plugin is identified as the application “ITRS:market-data-monitor”. This application name is configured by a feed parameter, and so can be changed (for example) to match a company naming policy as desired.

Entitlements for the application must also be specified by the EMRS administrator. The MDM application must be granted entitlements for the EIDs corresponding to the instruments which will be monitored. Different EIDs may have restrictions on how they can be used; if in doubt discuss with your administrator or account manager.

Feed parameters Copied

The Bloomberg feed adapter is configured with connection details of the Bloomberg Applicance (the hostname/IP and port) and the application name used for permissioning. These are configured using the following parameters:

bloomberg.serverHost=<hostname/IP of the B-PIPE Appliance>
[default=127.0.0.1]
bloomberg.serverPort=<listen port of the server>
[default=8194]
bloomberg.applicationName=<name matching an application permissioned in EMRS>
[example=ITRS:market-data-monitor]

Instrument codes Copied

Bloomberg instrument codes within Geneos comprise a service and instrument name in the following format:

//service name/security

The service name for real-time market data is blp/mktdata.

A security must conform to the following syntax:

[/Topic Prefix]/SYMBOLOGY[@Pricing Source] [Exchange]

Where the topic prefix is one of the following (and may optionally be followed by an instrument identifier):

ticker cusip wpk isin buid sedol1 sedol2 sicovam common bsid svm cins cats bbgid

The default format for a security is the Bloomberg ticker format, for example: “IBM US Equity”. This format consists of:

SYMBOLOGY [Exchange] <Yellow Key>

• SYMBOLOGY is required and is the ticker name
• [Exchange] is optional and is a two character mnemonic for the exchange where the security is traded. If you do not specify [Exchange] then the default value for the user or for the Server API process will be used.
• is the text equivalent of one of the Bloomberg yellow function keys.

Govt Corp Mtge M-Mkt Muni Pfd Equity Comdy Index Curncy Client

The following table provides some example instrument codes.

Field codes Copied

Bloomberg field codes are identified by a descriptive string, some examples of which are given below.

Further information on available fields can be found by entering FLDS on a Bloomberg terminal.

Example adapter Copied

The example feed adapter is a compiled binary of the example code for the C++ feed adapter API. This feed simply logs any parameters passed to it and generates steadily increasing values for each field in any instrument subscriptions made. For more detail on the example, please see the Feed Adapter API documentation.

Feed parameters Copied

The example feed has a single optional parameter, which controls how often tick data is published for subscribed instruments (in milliseconds). By default the feed will publish a new tick every 1000 milliseconds (i.e. each second). Any other configured parameters will be logged but otherwise ignored.

# Optional example.publishingPeriod=<publish period in millseconds>

Instrument codes Copied

The example feed will accept any subscription made of it, so any instrument code is valid.

Field codes Copied

The example feed has two special field names:

DateTime

Publishes the current date and time as a string. e.g. FriOct1814:55:462013.

Partial

Publishes an initial string Updating (_) Item then performs partial updates to change the parenthesised content. Each new tick will substitute an upper-case letter A-Z into the string in place of the underscore _ character.

Any configured fields which are not one of these special names will be populated with numeric data, generated in an increasing sequence.

Exegy adapter Copied

The Exegy feed adapter uses the Exegy API (XCAPI) to subscribe to market data via an Exegy Appliance.

This adapter is subject to the following deployment considerations.

1. The Netprobe must be able to create a TCP connection to the Exegy Appliance to obtain data.
2. The Market Data Monitor plugin must be authorized to subscribe to the monitored data (as determined by the specific user monitoring requirements).

Please contact your firm’s Exegy administrator to create the required permission entries. Entitlements for the user account must be sufficient for the instruments which will be monitored. Different userids may have restrictions on how they can be used; if in doubt discuss with your administrator or account manager.

Compatibility Copied

The current version of the adapter was compiled with XCAPI 4.1.12. Install that version of the XCAPI rpm on the host running the adapter.

On Linux, specify the XCAPI library libxcapi64.so in the LD_PRELOAD path.

export LD_PRELOAD=/usr/local/exegy/lib/libxcapi64.so

Feed parameters Copied

The Exegy feed adapter is configured with connection details of the Exegy Applicance (the hostname or IP), an optional port number and the username and password. These are configured using the following parameters:

exegy.serverHost=<hostname/IP of the Appliance(:optional port number)>
[hostname(:port) exegy.username=<name of the permissioned user>
[example=test exegy.password=<password for the user>

Instrument codes Copied

Exegy instrument codes within Geneos comprise a service and instrument name in the following format:

`instrumentclass:`countrycode:exchangeid:symbol

• instrumentclass — Code for the instrument that the Exegy adapter subscribes to. Possible values are: - CMTY for commodities. - EQTY for equities.
• countrycode — ISO 3166 two-letter country code.
• exchangeid — One- or two-character Exegy exchange identifier.
• symbol — String of up to 250 characters, uniquely identifying a financial instrument on the exchange.

For example, an IBM common stock on the New York Stock Exchange would have the following instrument code:

EQTY:US:N:IBM

The instrument symbol (the last portion of the key) conforms to the Exegy symbology conventions. In general, Exegy instrument symbols include an exchange-provided base or root symbol to identify the underlying instrument (e.g., “IBM”). If the instrument is a common stock, then the base symbol generally comprises the entire symbol.* “IBM” is the symbol for IBM common stock, and a user can request data for that instrument on NYSE using the key “US:N:IBM”.

For securities other than common stocks, Exegy follows a variety of conventions to express identifying characteristics such as subordinate class (for equities); expiration month, strike price, and whether a put or call (for equity options); contract delivery year and month (for CME futures contracts); expiration year and month, put-or-call, and strike price (for EUREX commodity options).

Please see the Exegy Symbology Guide (part of the XCAPI documentation) for more information.

Here are some example instrument codes:

Note

There are cases when Exegy omits the exchangeid if its value is “\”. In these cases, do not specify “\” in the instrument code. For example, instead of specifying “US:\:IBM” as instrument code, use “US::IBM” instead.

Field codes Copied

In addition to instrument codes, you can specify the field codes to indicate the particular information you want out of the instrument you are subscribing to.

For equities Copied

The following table lists codes supported for the equity instrument class:

For commodities Copied

The following table lists codes supported for the commodity instrument class:

Status values Copied

The following table lists the possible values for the InstStatus and MarketStatus field codes:

Symbol type values Copied

The following table lists the possible values for the SymbolType field codes:

Bid-ask-trade values Copied

The following table lists the possible values for the HighBate, LastBate, LowBate, and SetlBate field codes:

Tick flag values Copied

The following table lists the possible values for the TickFlags and TradeTickFlags field codes:

GL adapter Copied

The GL feed adapter connects to the feed infrastructure now known as SunGard Global Trading, but still generally referred to as GL Trade. (The acronym GL was formed from the initials of the founders’ surnames.)

Note that the GL feed adapter, running in the context of the Netprobe, needs to be able to establish a TCP/IP connection to the P3 routing process identified in its configuration.

Feed parameters Copied

The feed-specific settings for the GL adapter are concerned with connecting to a GL SLC (the inbound GL server) via a P3 routing process. They specify the host and port of the routing process and the GL sub-node index that identifies the SLC.

A GL feed accepts the following parameters:

gl.p3host=<hostname / IP-address of P3 host>
gl.p3port=<port number of P3 routing process>
gl.slcNode=<sub-node index of SLC>

Instrument codes Copied

GL instrument codes are formed from by the symbol code prefixed by the exchange and market indexes.

These indexes can be found using the GL Win client application. Alternatively, they are can be found in the licsym.ini file within the GL Win installation folder. Entries starting PlaceX= are exchanges, while items starting MchY= are markets.

For example, 41,4,LFI081200000F identifies a Futures (market 4) contract on LIFFE (exchange 41).

Field codes Copied

Fields on GL are identified by numeric GL feed codes, which are non-negative integers. The first 22 of these are listed, for full details please consult the GL documentation.

ICE adapter Copied

The ICE Data Services or IDC consolidated feed adapter uses the IDC Consolidated Feed Token Format (CTF) Wire Protocol. This technology was acquired when ICE bought the Interactive Data Corporation (IDC).

This adapter must follow the deployment requirements:

• The Netprobe must establish a TCP connection to the specified ICE Data Services feed server to obtain data.

• The Market Data Monitor plugin must be authorized to subscribe to the monitored data, as determined by the specific user monitoring requirements.

Feed parameters Copied

The ICE feed adapter is configured with connection and authentication details.

Use the following parameters to configure this adapter:

ice.serverHost=<hostname/IP>
[required]
ice.serverPort=<listen port of the server>
[required]
ice.username=<username to access the server>
[required]
ice.password=<password to access the server>
[required]
ice.instrumentCheck=full|none
[default=full]

Instrument codes Copied

Instrument codes within Geneos comprise a series of identifiers in this format:

token=value | token=value

You can select the following tokens:

4=627|5=E:BP.

Use this format to use the ISIN code to identify the same instrument in LSE:

4=627|3125=GB0007980591

You may use any combination of the above token numbers, but the end result must be a unique instrument.

The subscription and data returned will always be resolved to a source and symbol.

The most specific way of providing a unique instrument is to provide a 4 (ENUM.SRC.ID) and a 5 (SYMBOL.TICKER) number as part of the instrument code.

Field codes Copied

Numeric codes are use to identify the fields on ICE, which are non-negative integers. There are several thousand codes.

Refer to the table below to view the list of some numeric codes.

The Lua script code uses the data subscription API to configure and subscribe to an ICE feed, as shown below.

The connection to the ICE feed host allows only one (1) unique user at a time. If you connect to another machine using the same credentials, it will disconnect.

If this occurs, Feed:getStatus() returns “Connection dropped” instead of “OK”.

Note

The Feed:getStatus() gets the status reported by feed adapter if the connection has started or is disconnected.

local md = require 'geneos.marketdata'
local iceConfiguration = {
feed = { type = "ice", ["library.filename"] = "geneos-feed-ice.so" }, ice = { serverHost      = "11.22.3.4", serverPort      = "4001", username        = "username", password        = "password" }, instruments = { AA  = "4=627|5=E:AA.", ASC = "4=627|5=E:ASC", BP  = "4=627|5=E:BP.", JE  = "4=627|5=E:JE." }, fields = { Bid      = 12, Ask      = 10, Trade    = 8 }
}
local ice = md.addFeed("ICE Adapter", iceConfiguration)
ice:start()

Lua adapter Copied

The Lua feed adapter provides a Lua environment and API allowing users to write Lua scripts to publish tick data for a feed. For more information on this topic, please see the Geneos Feed Adapter API documentation.

Feed parameters Copied

The Lua feed requires a single argument, specifying the location of the Lua script to execute. If any other parameters are defined they are passed directly to the script for evaluation.

# Required lua.script=path/to/script.lua

Instrument codes Copied

Instrument codes are passed directly to the lua.script as part of a subscription request. Therefore the script author can define any formatting they require.

Field codes Copied

As for instrument codes, field codes are also passed through directly to the lua.script.

NYXT adapter Copied

The NYXT adapter supports the NYSE Technologies Middleware Agnostic Messaging API, better known as NYXT MAMA. This API was also previously named Wombat, after the firm that originally developed the software (Wombat Financial Software).

Configuring an NYXT feed adapter consists of the following steps:

1. Select the middleware(s) to connect with, and configure these as transports in the mama.properties file.
2. Configure your Netprobe to add the WOMBAT\_PATH environment variable, which is the directory containing the properties file.
3. Configure your Netprobe LD\_LIBRARY\_PATH environment variable, with the locations of the MAMA and middleware shared object (.so file) libraries.
4. Reference the transports from the mama.properties file in your MDM sampler (Lua) script.

Feed parameters Copied

Configuration for the NYXT feed adapter is primarily performed in the mama.properties configuration file. This file should contain configurations for all the transports to be used by the NYXT feeds. The Lua configuration for feeds then relates to referencing the transports from this file by name.

The NYXT feed accepts the following parameters:

# Required
nyxt.middleware=wmw|lbm|tibrv
nyxt.transport=<name of the transport>

# Optional
nyxt.dictionary.download=true|false
nyxt.dictionary.service=<name of dictionary service>
nyxt.dictionary.transport=<name of dictionary transport>

The feed adapter can optionally use a MAMA data dictionary to map symbolic names for fields to numeric field identifiers (FIDs).

This dictionary is not used by default, and use of the dictionary can be manually prevented by configuring the setting nyxt.dictionary.download as false. Otherwise, configuring any values for the nyxt.dictionary.\* will enable dictionary use.

If nyxt.dictionary.download is set to true, then by default the feed will attempt to retrieve the dictionary using the feed transport (as defined by the nyxt.transport setting) from the “WOMBAT” service. These locations can be overridden as necessary using the appropriate settings.

Instrument codes Copied

Instruments are configured as a multi-part string comprising the namespace and the instrument code. The namespace is taken to be all non-quoted text before the first dot (.) character.

Some examples of instrument codes:

Note

The MAMA documentation defines a namespace as:

The publisher specific source name for the source.
e.g. This could be "NASDAQ" for a UTP PAPA publisher.

This is the equivalent of a service name in other market data systems.

Field codes Copied

NYXY field codes may be specified either using the field name, or by FID number. If the MAMA data dictionary is not available for the feed (either because it is disabled or failed to download - see Feed parameters above) then only FID numbers can be used.

mama.properties configuration file Copied

The mama.properties file is a global configuration file used by all configured NYXT feeds. This file must be located in the directory specified by the WOMBAT\_PATH environment variable.

An example configuration file can be found in the Netprobe package in the flm/mama folder. This file can be referenced by setting the WOMBAT_PATH as below, assuming the Netprobe is running from the package folder. If not, you will need to modify your environment accordingly.

export WOMBAT_PATH=./flm/mama/config

The configuration file should contain a single Geneos-specific setting geneos.middlewarelist which defines the middleware libraries to be used. If not specified the feed will by default attempt to load the wmw library. This setting accepts a comma-separated list of values, so multiple middlewares (including lbw or tibrv) can loaded by specifying the following:

geneos.middlewarelist=wmw,lbm,tibrv

Other settings in the configuration file will be specific to each middleware being used. Please refer to the MAMA and the middleware bridge documentation for full details. The transport name for each configuration will then be referenced from the feed configuration in the Lua script.

An example configuration for the default middleware wmw is shown below. This file is packaged with the Netprobe but may also be downloaded here.

MAMA shared libraries Copied

When loading an NYXT feed, the MAMA libraries and any required middleware libraries must be available to the Netprobe in the folders specified by the LD\_LIBRARY\_PATH environment variable.

OpenMAMA requires access to the following library files, which are also packaged with the Netprobe in the flm/mama folder:

• libmama.so
• libmama.so.0
• libmama.so.0.0.0
• libwcache.so
• libwcache.so.0
• libwcache.so.0.0.0

OpenMAMA will initialise each configured middleware by loading an bridge library as an entry point. These libraries have the naming convention libmama<MWNAME>impl.so, for example the wmw type will load libmamawmwimpl.so. Each bridge library may itself have dependencies on underlying middleware libraries, which must also be available in the LD_LIBRARY_PATH.

For example, the full set of libraries required to load the Data Fabric / Wombat middleware (mwm) would be:

• libmamawmwimpl.so
• libmamawmwimpl.so.0
• libmamawmwimpl.so.0.0
• libwombattcp.so
• libwombattcp.so.0
• libwombattcp.so.0.0

Similarly the full set of libraries for the lbm middleware would be provided by the vendor.

QuantFeed adapter Copied

The QuantFeed feed adapter uses the FeedOS API to subscribe to Level1 data for instruments using QuantFeed Local Code and provide ticks to the Geneos Market Data Monitor.

This adapter is subject to the following deployment considerations.

1. The Netprobe must be able to create a TCP connection to the QuantFeed server to obtain data.
2. The Market Data Monitor plugin must be authorized to subscribe to the monitored data (as determined by the specific user monitoring requirements).

Feed parameters Copied

The QuantFeed adapter is configured with connection details of the (the hostname/IP and port) and the application name used for permissioning. These are configured using the following parameters:

quantFeed.serverHost=<hostname/IP of the QuantFeed Appliance>             [default=127.0.0.1]
quantFeed.serverPort=<listen port of the server>                              [default=8194]quantFeed.username=<username to access the server>
quantFeed.password=<password to access the server>

Instrument codes Copied

This is a proprietary market-dependent string, computed from a subset of instrument’s characteristics (symbol, expiry date, etc). The syntax for the textual representation of this kind of instrument codes is as follows: 1. marketid - the parent marketid, in textual form. 2. @ - used as a delimiter 3. LocalCodeStr - identifier for the instrument within the given market.

In QuantFeed, each market has its own rules for building LocalCodeStr. This may be as simple as using exchange Symbol or ISIN, but could may be more or less complex depending on the nature of instruments present on the market. For example, Local Codes for PUT options on EUREX have the form: XEUR @ symbol mm yy P strike Where symbol is the EUREX “product id”, mm and yy are the expiry date, and strike is the strike price without decimal point. An optional “generation number” could even appear after a split event on the underlying.

Field codes Copied

QuantFeed field codes are identified by descriptive strings called ’tags’ in FeedOS documentation. Some of the accepted fields are listed below. For full details, please consult the FeedOS documentation.

Aside from the fields mentioned in the FeedOS documentation, the following custom fields are also supported.

RFA adapter Copied

The Refinitiv Robust Foundation API (RFA) feed adapter allows connection to a Refinitiv RTDS system.

2 types of feed are currently supported by the RFA Adapter

• Streaming feeds are those that send a streaming request to the publisher. After such a request is sent, the adapter receives regular multiple responses from the publisher.
• Non-streaming feeds are those that send a non-streaming request, also called a snapshot request. This is a request for only one response from the publisher. No further updates will be received.

Note that the RFA feed adapter, running in the context of the Netprobe, typically needs to be able to establish a TCP/IP connection to the RMDS infrastructure to be monitored.

When installing the RFA adapter on a Windows platform, the Visual Studio C++ 2010 runtime must be installed to satisfy the RFA libraries dependencies. Please see http://www.microsoft.com/en-gb/download/details.aspx?id=5555 or contact your system administrator for assistance.

In Geneos 4.8.0 version, the RFA version 8 supports the microseconds and nanoseconds timestamps.

You can access the timestamp through all APIs from an OMM source.

Feed parameters Copied

The majority of the configuration for the RFA feed adapter is contained within an RFA configuration file. A single file can be used to configure all RFA-type feeds, and the file must be accessible by Netprobe in order for it to read the configuration. RFA feed configuration in the MDM Lua script is related to specifying the location of this file, and referencing the sessions within it.

When configuring the feed, you must also specify whether the data the specific feed provides will be using the RFA Object Message Model (OMM) or the legacy Market Data Interface (MDI). MDI is only supported on 32-bit platforms, and is the default data type to provide backwards compatibility with older Netprobe versions. 64-bit platforms will default to OMM connections.

An RFA feed accepts the following parameters:

rfa.configFile=<relative or absolute path to the RFA configuration file>
rfa.session=<session name>
rfa.connectionType=OMM|MDI
rfa.messageModelType=MARKET_PRICE|DOMAIN_TYPE_11
rfa.mapEntry.keys={<list of map-value keys to subscribe to>}
rfa.mapEntry.fields={<list of map-value fields to subscribe to>}

The RFA feed supports two message model types: “MARKET_PRICE” and “DOMAIN_TYPE_11”. By default, if this parameter is not set, the message model type will be “MARKET_PRICE”.

An RFA feed with an OMM connection type also supports map values obtained from the server. To set which map-value keys and fields to subscribe to, the rfa.mapEntry.keys and rfa.mapEntry.fields must be set. If the rfa.mapEntry.keys parameter is not set, it will subscribe to all the keys of the map-value. If the rfa.mapEntry.fields parameter is not set, it will subscribe to all the fields of the map-value. These keys are only supported for RFA feeds using OMM connection type on Linux and Windows platforms.

To set an adapter as non-streaming, the feed.streaming parameter should be set to false. By default, if this parameter is not set, the adapter is considered streaming.

feed.streaming=false

Non-streaming adapter is only applicable for OMM connections. This parameter is ignored when rfa.connectionType is set to MDI.

Instrument codes Copied

RFA instrument codes are formed of a RIC prefixed by the service name. For example, IDN\_SELECTFEED.BP.L represents market data from IDN SelectFeed about BP, traded on the London stock exchange.

Field codes Copied

RFA field codes are identified by a descriptive string, some examples of which are given below.

Geneos-specific RFA settings Copied

The following session-specific settings can be configured in the RFA configuration file. These settings are read and processed by the RFA feed adapter. The fields should be configured under the \Geneos\FLM\SessionName tree. For example, the OMM_ADS session might be configured with the line:

\Geneos\FLM\OMM_ADS\DacsUsername = "SomeUser"

The available fields are as follows:

Metadata fields Copied

To provide additional information about the tickstream at runtime the following meta-data fields can be subscribed to. These are not market data values but information about the tickstream accessed via the RFA.

RFA data from an ADS Copied

The following configuration settings can be used to connect to a ADS or P2PS and receive OMM data. The Lua configuration for this feed must set the connection type to OMM (or left to default on 64-bit platforms).

# Session configuration. #   The feed rfa.session parameter should match the session name "OMM_P2PS" defined below.
#   The connectionList setting references a connection defined below.
#   The threading model is set to "Single" to minimise message latency for more accurate timestamps.
\Sessions\OMM_P2PS\connectionList = "Connection_RSSL"
\Sessions\OMM_P2PS\threadModel    = "Single"

# P2PS connection details.
#   RSSL type must be specified for OMM data.
#   The host and port settings specify how to connect to the P2PS for this data.
\Connections\Connection_RSSL\connectionType = "RSSL"
\Connections\Connection_RSSL\rsslPort       = "14002"
\Connections\Connection_RSSL\hostName       = "host.example.com"

# Disables singleton usage of the RSSL connection, allowing multiple RSSL connections to be used.
# This setting must be disabled (default is true) when using a session ThreadModel of "Single".
\Adapters\RSSL_Cons_Adapter\singleton = false

# OMM message queuing settings
#   These settings allow fine-grained control over incoming OMM data.
#   enableOMMEventAge should be enabled where possible, for more accurate message timestamps.
\Control\MessagePools\OMMItemEventPool\InitialSize       = 10000
\Control\MessagePools\OMMItemEventPool\Increment         = 10000
\Control\MessagePools\OMMItemEventPool\MaximumSize       = 0
\Control\MessagePools\OMMItemEventPool\enableOMMEventAge = true

# API Logging and error message configuration
#   If not using internal logging strings, you will need to configure settings within
#   \Logger\ComponentLoggers to specify message file locations
\Logger\AppLogger\windowsLoggerEnabled  = false
\Logger\AppLogger\fileLoggerEnabled     = true
\Logger\AppLogger\useInternalLogStrings = true

# Geneos-specific settings for the "OMM_P2PS" session.
#   Uncomment the settings below and configure as required.
#\Geneos\FLM\OMM_P2PS\RDMFieldDictionaryFilename = "./flm/rfa7/RDMFieldDictionary"
#\Geneos\FLM\OMM_P2PS\EnumtypeDefFilename = "./flm/rfa7/enumtype.def"
#\Geneos\FLM\OMM_P2PS\DacsApp             = "app_name"
#\Geneos\FLM\OMM_P2PS\DacsPosition        = "position"
#\Geneos\FLM\OMM_P2PS\DacsUsername        = "username"

RFA configuration containing multiple sessions Copied

An RFA configuration file can contain multiple sessions, which are then referenced in the Lua script as normal. An example of such a file can be made by creating a file containing both of the P2PS example configurations shown above.

It is also possible to configure sessions which share the same underlying connection but use different services. These sessions would then be configured as individual feeds, allowing comparison between services (assuming they can provide data for the same instrument). In this configuration, the connection service list must contain the names of all services in use. An example is shown below:

# Session configuration.
\Sessions\SERV1_P2PS\connectionList = "Connection_SSLED"
\Sessions\SERV2_P2PS\connectionList = "Connection_SSLED"
\Sessions\SERV3_P2PS\connectionList = "Connection_SSLED"

# Connection definition (P2PS details).
#   This connection will be shared by all the sessions defined above.
#   Each session can reference a different service as defined by the MDM instrument configuration.
\Connections\Connection_SSLED\connectionType = "SSLED"
\Connections\Connection_SSLED\PortNumber     = 8101
\Connections\Connection_SSLED\ServerList     = "host.example.com"
\Connections\Connection_SSLED\UserName       = "SomeUser"
\Connections\Connection_SSLED\logEnabled     = true
\Connections\Connection_SSLED\serviceList    = "SERV1,SERV2,SERV3"

# Service definitions
\Services\SERV1\dataFormat   = "marketfeed"
\Services\SERV1\dataDictList = "MF"
\Services\SERV2\dataFormat   = "marketfeed"
\Services\SERV2\dataDictList = "MF"
\Services\SERV3\dataFormat   = "marketfeed"
\Services\SERV4\dataDictList = "MF"\DataDictionaries\MF\dataDictType = "marketfeed"

# Legacy DACS settings
\Control\Entitlements\dacs_CbeEnabled        = false
\Control\Entitlements\dacs_SbeEnabled        = false
\Control\Entitlements\dacs_NewsCbeEnabled    = false
\Control\Entitlements\dacs_NewsCbeLogEnabled = false
\Control\Entitlements\dacs_SbeSubEnabled     = false
\Control\Entitlements\dacs_SbePubEnabled     = false

# API Logging and error message configuration
\Logger\AppLogger\windowsLoggerEnabled  = false
\Logger\AppLogger\fileLoggerEnabled     = true
\Logger\AppLogger\useInternalLogStrings = true

Refinitiv RTO adapter Copied

The Refinitiv RTO feed adapter allows connection to the Refinitiv Real Time Optimised (RTO) system. This adapter is subject to the following deployment considerations:

• The Netprobe must be able to establish a connection to Refinitiv RTO, which is hosted on AWS.
• The credentials used with the feed adapter must be authorized to subscribe to the data that you want to monitor.

Before running the Netprobe, ensure that the flm/refinitiv directory has been added to the LD_LIBRARY_PATH environment variable for the RTO feed.

Feed parameters Copied

To connect to Refinitiv using version 2 authentication, use the following feed parameters:

refinitiv.cliendId=<client ID or AppKey generated by Thomson Reuters AppGenerator>
refinitiv.clientSecret=<client secret

If clientSecret is not specified, the Refinitiv RTO Adapter will default to version 1 authentication, which can be set as follows:

refinitiv.machineId=<machine ID provided by Thomson Reuters>
refinitive.password=<password of the provided machine ID>
refinitiv.cliendId=<client ID or AppKey generated by Thomson Reuters AppGenerator>

Below are the optional parameters you can define:

Refinitiv configuration file Copied

The Refinitiv RTO Feed Adapter uses the Real Time SDK (RTSDK), which makes use of a configuration file. This configuration file defines the type of connection the Feed Adapter will use, the RTSDK logger configuration, and the location of the Dictionary.

The default configuration file is in <Netprobe package>/flm/refinitiv/DefaultEmaConfig.xml. You can copy and modify the file and specify the location in feedConfiguration.refinitiv.configFile setting.

Most of the settings in this default configuration file can be left as is.

local feedConfiguration {}
feedConfiguration.feed = {
     type = "refinitiv",
     ["library.filename"] = "flm/geneos-feed-refinitiv-rto.so",
}
feedConfiguration.refinitiv = {
      clientId = "GE-AB4CDEFGHIJK", -- [REQUIRED] Service ID
      clientSecret = "5c43b2a1-zz12-3456-y789-a1b23c45d67e", -- [REQUIRED] The corresponding password of the Service ID
      -- configFile = "EmaConfig.xml", -- [OPTIONAL] Path/Filename of the configuration file. Default: flm/refinitiv/DefaultEmaConfig.xml
      -- consumerName = "DefaultConsumer", -- [OPTIONAL] Name of the consumer defined in configFile to be used during connection. Default: the <DefaultConsumer> defined in the xml configFile
      -- ssl = {
      --           libsslName = "./lib64/libssl.so",      -- [OPTIONAL] Default: System openssl library with filename libssl.so.1.1
      --           libcryptoName = "./lib64/libcrypto.so", -- [OPTIONAL] Default: System crypto library with filename libcrypto.so.1.1
      --           CAStore = "/etc/ssl/certs/ca-bundle.crt", -- [OPTIONAL] Path to the CA Store to be used by openssl. Default: default location used by openssl library      
      -- },
      -- libcurlName = "./lib64/libcurlgeneos.so", -- [OPTIONAL] Path to the curl library.
},
feedConfiguration.instruments = {
    AUD = "ELEKTRON_DD.AUD=",
    JPY = "ELEKTRON_DD.JPY=",
    EUR = "ELEKTRON_DDx.EUR="
},
feedConfiguration.fields = {
    DisplayName = "DSPLY_NAME",
    Bid = "BID",
    Ask = "ASK",
}

Location Copied

This setting specifies the cloud location of the service provider endpoint to which the adapter establishes a connection. The default setting is us-east-1.

<ChannelGroup>  <ChannelList>    <Channel>   <Name value="Channel_1" />   <!-- Other config here-->   <Location value="us-east-1" />   <!-- Other config here--> </Channel>  </ChannelList>
</ChannelGroup>

Dictionary Copied

The default dictionary configuration used is Dictionary_Download, which is defined in the DictionaryList at the bottom of the XML file. This configuration downloads dictionaries by requesting them from the upstream provider.

<ConsumerList>  <Consumer>    <!-- Other config here-->    <Dictionary value="Dictionary_Download"/>    <!-- Other config here-->  </Consumer>
</ConsumerList>

If you want to use a dictionary from a file, then you can change the setting to Dictionary_File and provide the path to the files in the DictionaryList part of the configuration.

<DictionaryGroup>  <DictionaryList> <!--- Dictionary_Download setting here --> <Dictionary>   <Name value="Dictionary_File"/>   <DictionaryType value="DictionaryType::FileDictionary"/>
   <!-- dictionary names are optional: defaulted to RDMFieldDictionary and enumtype.def -->   <RdmFieldDictionaryFileName value="./flm/rfa8/RDMFieldDictionary"/>   <EnumTypeDefFileName value="./flm/rfa8/enumtype.def"/> </Dictionary>  </DictionaryList>
</DictionaryGroup>

Instrument codes Copied

The Refinitiv RTO feed adapter instrument codes follow the <service name>.<Thomson Reuters instrument code> syntax. For example, ELEKTRON_DD.EUR= represents market data from the Elektron service (ELEKTRON_DD) for Euro/US Dollar FX Spot Rate (EUR=).

Field codes Copied

Refinitiv field codes are identified by a descriptive string, some examples of which are given below.

TestFile adapter Copied

The test file feed adapter allows MDM tick history file output to be replayed as input for testing purposes.

Feed parameters Copied

The test file feed accepts the following parameters:

testfile.feed=<feed name in input file to be read>
testfile.filename=<relative or absolute path to input file>
testfile.format=3|4

Note that the feed parameter specifies the name of the feed in the input data file. This does not necessarily have to be the same as the MDM feed name, but is recommended to avoid confusion.

The testfile supports two formats (version 3 and 4) of the tick history file. Only tick data is captured; informational messages (such as a sample or log rolling) are ignored. Example version 3 output is shown below. Version 4 output looks similar, but has tick timestamps in microsecond resolution.

==== Started logging: Tue 11 May 2012, 08:46:01 ====
== Sample, 08:46:07 ==
Time:08:46:03.002  Feed:SSL-REUT  Inst:LLOY
Field:Ask       Value: 99.65000000  U
Field:AskSize   Value:10322.00000000  U
Field:Bid       Value: 99.56000000  U
Field:BidSize   Value:39704.00000000  U
Field:Trade     Value: 99.57000000  U
Field:Volume    Value:1556.00000000  U*
Time:08:46:03.013  Feed:LSEPERF   Inst:BLT
...etc

Instrument codes Copied

Since this feed reads tick history files as input data, the instrument codes for a test feed should be configured to match the instrument codes as recorded in the input file.

Field codes Copied

As per instrument codes above, field codes should be configured to match those present in the input file.

TT adapter Copied

The TT feed adapter allows subscription of market data from Trading Technologies (TT) using the XTrader API. This adapter is available only for the Windows platform.

The TT adapter can be run in one of two modes:

Standard Mode

In this mode the Netprobe runs on the desktop of an X_Trader Pro user (not as a service) and shares the license of the running X_Trader application.

Server Mode

In this mode the Netprobe can be run as a Windows service. The TT feed must then be configured with its own TT universal login credentials, which will be used to authenticate with TT. In this mode the Netprobe will consume its own X_Trader Pro license.

Note

The XTrader API used by the TT feed adapter does not support unsubscribe operations. This means that unsubscribing from instruments using the MDM market data API will only prevent publishing of updates. Processing of updates for the unsubscribed instruments will still occur and consume CPU.

If you make large-scale changes to instrument configurations for TT feeds, it is advised to restart the Netprobe following the change.

Feed parameters Copied

A TT adapter requires the name of the exchange gateway to be configured. TT universal login credentials are optional settings which are only required if the Netprobe will be running in server mode.

# Required
tt.exchange=<name of the exchange>

# Optional
tt.global.com.verbose=true|false
tt.global.universal.username=<username>
tt.global.universal.password=<password>
tt.global.universal.encoding=std|plaintext

The com.verbose setting controls debug output for the Windows COM handler thread, which is shared by all TT feeds. Verbose (debug) output is disabled by default.

The login password can be configured as either plaintext or using the Geneos standard encoding.

To configure a plaintext version specify the following:

tt.global.universal.username=myUser
tt.global.universal.password=myPassword
tt.global.universal.encoding=plaintex

To configure an encoded password, first generate your password using a Geneos gateway binary ./gateway2.linux-en <password> then specify the following:

tt.global.universal.username=myUser
tt.global.universal.password=<encoded password text from gateway>
tt.global.universal.encoding=std

Instrument codes Copied

TT instrument codes are specified as a multi-part dotted string, consisting of the Product Name, Product Type and Contract ID (exchange identifier for contract). i.e. ProductName.ProductType.ContractID - for example KERO.FUTURE.2014/01.

Alternatively, an RTD code can be generated from the X_Trader GUI for an instrument and configured as the instrument code. This feature is normally used by X_Trader for Excel data linking. When using an RTD code, the generated result must be for an instrument and the exchange name must match that which configured exchange of the feed.

e.g. =RTD("XTAPI.RTD","","Instr","TOCOM","KERO","FUTURE","2014/01","ASK")

Field Codes Copied

TT field codes are identified by a descriptive string. Some examples of this are given below.

TT field names may optionally be specified with a format modifier postfix (e.g. & for integer, # for decimal, $ for string). If no postfix is given the TT feed will use the default # for decimal notation. For normal use it is recommended not to specify a format.

Depth and Order Set data is not available via the TT feed adapter.