BM&FBovespa UMDF Input Adapter

Introduction

The TIBCO StreamBase® Adapter for BM&FBovespa UMDF allows a StreamBase application to connect to BM&FBovespa's Unified Market Data Feed to receive market data in the form of FIX/FAST messages. The adapter is intended for use with the high-speed, low-latency TIBCO StreamBase® High-Performance FIX Engine to decode the incoming FAST messages. The TIBCO StreamBase High-Performance FIX Engine is available as a separate product. Contact TIBCO StreamBase Technical Support if you need additional information.

The adapter has the following capabilities:

  • Can establish all the necessary UDP and TCP connections to UMDF to obtain market data information.

  • Automatically manages instrument definition, market recovery, message replay and book reset procedures, establishing (and later closing) the necessary connections on the fly.

  • Can be set to automatically handle Feed A – Feed B arbitration procedures.

  • Converts incoming market data FAST messages to tuples and sends them to the application. The adapter routes tuples from different message types (snapshot, incremental updates, and so on) to dedicated output ports.

  • Can receive commands from the application to subscribe and unsubscribe to individual instruments or all instruments on a given market data channel.

Properties

Settings are used to control most of the behavior of the adapter. The settings are grouped under several tabs in the Properties view in StreamBase Studio.

These sections list the name of each property setting in two forms. One is the name of the property in the StreamBase Studio Properties view, while the other is the name of the property used in StreamSQL programs. If no StreamSQL name is listed for a property, then its StreamSQL name is the same as its StreamBase Studio Properties view name.

General Tab

Name: Use this field to specify or change the component's name, which must be unique in the application. The name must contain only alphabetic characters, numbers, and underscores, and no hyphens or other special characters. The first character must be alphabetic or an underscore.

Adapter: A read-only field that shows the formal name of the adapter.

Class: A field that shows the fully qualified class name that implements the functionality of this adapter. Use this class name when loading the adapter in StreamSQL programs with the APPLY JAVA statement. You can right-click this field and select Copy from the context menu to place the full class name in the system clipboard.

Start with application: If this field is set to Yes or to a module parameter that evaluates to true, an instance of this adapter starts as part of the containing StreamBase Server. If this field is set to No or to a module parameter that evaluates to false, the adapter is loaded with the server, but does not start until you send an sbadmin resume command, or until you start the component with StreamBase Manager. With this option set to No or false, the adapter does not start even if the application as a whole is suspended and later resumed. The recommended setting is selected by default.

Enable Error Output Port: Select this check box to add an Error Port to this component. In the EventFlow canvas, the Error Port shows as a red output port, always the last port for the component. See Using Error Ports and Error Streams to learn about Error Ports.

Description: Optionally enter text to briefly describe the component's purpose and function. In the EventFlow canvas, you can see the description by pressing Ctrl while the component's tooltip is displayed.

Adapter Properties Tab

FAST Channel Definition File

StreamSQL name: fastConfigFileName

Default: none

Specifies the name of the XML file used to define the UMDF channels to which to connect. See the Channel Definition File section below for details on the format of this file.

FAST Template File

StreamSQL name: fastTemplateFileName

Default: none

Specifies the name of the FAST template definition file to use to decode incoming FAST messages. This file is usually obtained from BM&FBovespa directly (see the File Formats section below).

Recovery Type

StreamSQL name: recoveryType

Default: History

Specifies the preferred strategy to use for recovering missing FAST messages. Select History to specify using the FIX-based TCP Historical Replay channel, or select Market to select the FAST-based UDP Market Recovery channel.

Log Level

StreamSQL name: logLevel

Default: INFO

Controls the level of verbosity the adapter uses to send notifications to the console. This setting can be higher than the containing application's log level. If set lower, the system log level will be used. Available values, in increasing order of verbosity, are: OFF, ERROR, WARN, INFO, DEBUG, TRACE, and ALL.

Edit Schemas Tab

Use the Edit Schemas tab to specify the schemas of the output tuples for this adapter.

For general instructions on using the Edit Schemas tab, see the Properties: Edit Schema Tab section of the Defining Input Streams page.

Of the five available output ports exposed by the adapter, only one (the Events output port) has a fixed schema. For every other port you must define its schema in the Edit Schemas tab. Remember that even if the routing map is empty, there is still one default output port for application-level messages. This means you must define at least one schema in this tab. The schemas do not need to be the same for every port, but there is one mandatory field that must be present in each schema. This field is:

  • ChannelID (string)

Additionally, the Incremental Update output port (see the "Incremental Refreshes Port" section below) may have the following field to help identify the correct order in which updates are to be applied:

  • MsgSeqNum (long)

Every other field you define in each of the output ports' schema is expected to have a corresponding field in the incoming FAST message directed to that port. When the adapter receives such a message, it iterates through all the fields in your schema, gets the corresponding value in the FAST field, and sets the tuple's field to that value. Any field in the incoming FAST message that has no corresponding field in the schema is ignored and is not passed on to the application. In this way, you can maximize the efficiency of your application by only defining the FAST fields of interest in your schema.

The adapter uses an algorithm to identify a corresponding FAST field, given a StreamBase field. That algorithm is as follows:

  • The FAST template XML file (described in the "Template Definition File" section below) is queried for a field with the same name as the StreamBase field. If a match is found, that FAST field is used.

  • If no match is found, the StreamBase field is examined to see if its name conforms to the pattern __tag_nnn, where nnn is an integer. If it does, the FAST template is examined for a FAST field with tag nnn. If a match is found, that FAST field is used.

  • If no match has been found at this point, a warning is issued at the console when the application starts and the unmatched StreamBase field remains null when a FAST message is received.

Field Type Mapping

The FAST protocol uses a small number of data types to represent the values contained in its messages. You can use the following type mappings between FAST and StreamBase fields:

FAST Data Type StreamBase Data Type
String string
UnicodeString string
ByteVector blob
Decimal double
Int32 int
UInt32 long
Int64 long
UInt64 long
Sequence list(tuple), where the tuple contains one or more of the fields in this repeating group. Each instance of the repeating group is placed in a tuple in the list. See "Accessing Repeating Groups" below for more details.

Note

Conspicuously missing from the list above are any time-based formats such as the FIX UTCTimestamp and LocalMarketDate data types. Such values are mapped to a UInt64, encoded by removing all separator characters and converting the resulting decimal string to an number. For instance, if the field SendingTime (52) has the value 20081007-09:12:08.008 (format YYYYMMDD-HH:MM:SS.sss), it is encoded to the integer 20081007091208008. The adapter expects such fields in the corresponding StreamBase schema to be declared as a long into which this numerical value is placed. It is the responsibility of the application to correctly interpret this number into a valid time-based value as needed.

Accessing Repeating Groups

Access to FAST sequence (also known as repeating group) fields is done through fields of type list in a manner similar to that used by the FIX Input adapter. Consider the example of a MarketDataSnapshotFullRefresh (MsgType=W) message for equities (template ID 20) and its MDEntries sequence. The group contains (among others) the following fields:

  • NoMDEntries (268) — this is of type Length, which announces the number of repeating groups in the sequence in a manner similar to FIX fields of type NumInGroup

  • MDEntryType (269)

  • MDEntryPx (270)

To access these fields in your StreamBase application, start by creating a named schema (such as NoMDEntriesGroup) with the following fields:

  • MDEntryType (string)

  • MDEntryPx (double)

Then you must add the following field to your top-level schema for the Snapshot output port (which receives messages of type W):

  • NoMDEntries (list of NoMDEntriesGroup)

Note

Do not name the top-level field after the FAST field of type sequence (MDEntries in this case), but rather after the sequence's length field (NoMDEntries here).

Once you have these schemas and fields defined, you are ready to access the values contained therein using standard list and tuple expression idioms, such as NoMDEntries[2].MDEntryPx.

Note

When creating your schema for a repeating group you do not need to include every field or the group in your schema. Those FAST fields in the sequence that do not have a corresponding field in the schema will be ignored.

Concurrency Tab

Use the Concurrency tab to specify parallel regions for this instance of this component, or multiplicity options, or both. The Concurrency tab settings are described in Concurrency Options, and dispatch styles are described in Dispatch Styles.

Caution

Concurrency settings are not suitable for every application, and using these settings requires a thorough analysis of your application. For details, see Execution Order and Concurrency, which includes important guidelines for using the concurrency options.

Adapter Ports And Schemas

Output Ports

The adapter has five output ports, listed here in the order in which they appear on the adapter:

  1. Events

  2. Instrument Definitions

  3. Snapshots

  4. Incremental Refreshes

  5. All Other Messages

Of these, only the Events port has a fixed schema, determined by the adapter. The other ports require you to define the schema you wish to use based on the FAST fields which are of interest to your application. The only mandatory field on these ports is ChannelID (string), which identifies which FAST channel originated the message.

Events Port Schema

The Events port issues tuples describing events that may be of interest to your application. These events include when a symbol subscription has succeeded, when an error occurs during normal operation, or to answer requests for the current connection status of a given FAST channel. The schema for this port is preset by the adapter, and is described in the following table:

Field Name Field Type Description
ChannelID string The ID of the FAST channel to which this event pertains, as defined in the <channel> tag's ID attribute in the FAST channel definition file. This field is set for all event types.
Event string The type of event this tuple represents. This field is set for all event types. Possible values include:
  • Subscribed — The referenced instrument has been successfully subscribe to. The tuple's SymbolID and SecurityID fields will be set to define this instrument.

  • Unsubscribed — The referenced instrument has been successfully unsubscribed from. The tuple's SymbolID and SecurityID fields will be set to define this instrument.

  • BookReset — A book reset event has occurred. If SymbolID and SecurityID are non-null, they identify the instrument for which the book has been corrupted and needs to be reset. If those fields are left null, then all subscribed symbols are affected.

  • RecoveryStarted — Recovery procedures have started for the instrument identified by the tuple's SymbolID and SecurityID fields.

  • RecoveryStopped — Recovery procedures have ended for the instrument identified by the tuple's SymbolID and SecurityID fields.

  • Error — An error has occurred. The tuple's InfoText field will contain the error message.

  • ConnectionStatus — The status of the connection to this FAST channel. This event will be sent in response to a ConnectionStatus command sent to the adapter's Command input port (see Command Input Port below). The tuple's InfoText field will be set to either Connected or Disconnected.

SymbolID string If non-null, this field identifies the instrument referred to by this event.
SecurityID string If non-null, this field identifies the instrument referred to by this event.
InfoText string If non-null, this field identifies the instrument referred to by this event.

Instrument Definitions Port

When a subscription to an instrument is made, the adapter first connects to the FAST feed's Instrument Definition stream to obtain the desired instrument's SecurityList (MsgType=y) entry. The entry is sent to this port when available. Similarly, when a ListInstruments command is sent to the adapter the resulting list of securities (again in the form of one or more SecurityList (MsgType=y) entries) will be sent to this port when available

The schema for this port is left to the user to define. The fields in this schema determine which fields from the incoming FAST message are passed to the StreamBase application. Not all of the SecurityList message's fields are made available, but rather only the content of this particular instrument's RelatedSym entry. This is because a single SecurityList message may contain information on multiple instruments in the form of multiple RelatedSym entries, and one tuple is emitted to this port for each subscribed (or listed) symbol.

Only one field is mandatory and expected by the adapter to be present in the schema: ChannelID (string), which identifies the ID of the FAST channel on which this instrument was defined.

Snapshots Port

Once an instrument has been successfully subscribed to, a MarketDataSnapshotFullRefresh (MsgType=W) message is sent to this port to define the current state of the book for this instrument.

The schema for this port is left to the user to define. The fields in this schema determine which fields from the incoming FAST message are passed to the StreamBase application.

Only one field is mandatory and expected by the adapter to be present in the schema: ChannelID (string), which identifies the ID of the FAST channel on which this instrument was defined.

Incremental Refreshes Port

After a subscribed instrument's Snapshot has been received the feed will start sending MarketDataIncrementalRefresh (MsgType=X) messages to update the book as appropriate. Those updated will be sent to this port when available.

The schema for this port is left to the user to define. The fields in this schema determine which fields from the incoming FAST message are passed to the StreamBase application. It is to be noted that, as is the case with the Instrument Definitions port, not all of the MarketDataIncrementalRefresh message's fields are made available but rather only the content of this particular instrument's MDEntries entry. This is because a single MarketDataIncrementalRefresh message may contain information on multiple instruments in the form of multiple MDEntries entries, only some of which is of interest to this particular tuple. Because of this, one tuple will be emitted to this port for each relevant entry in the received message's MDEntries sequence.

As an example, let's say that the application subscribed to two instruments, SYM1 and SYM2. After the snapshots are received from the Recovery Stream for these symbols (and forwarded to the application via the Snapshots output port) the adapter begins to listen to the channel's Incremental Stream. As MarketDataIncrementalRefresh messages are received their MDEntries sequence is inspected for entries concerning either SYM1 or SYM2. Let's say that a MarketDataIncrementalRefresh message is received containing 4 entries in its MDEntries sequence: two relating to SYM1, one for SYM2 and one for SYM3 (to which that application has not subscribed). In this case 3 separate tuples will be sent to the Incremental Refreshes output port: Two will contain one of the entries for SYM1 and the last one will have the entry for SYM2. The entry for SYM3 will be ignored since the application has not subscribed to this instrument.

Only one field is mandatory and expected by the adapter to be present in the schema: ChannelID (string) which identifies the ID of the FAST channel on which this instrument was defined. In addition, another field may be added, MsgSeqNum (long), to double-check the correct ordering of incoming refresh messages. This may become useful during recovery procedures.

Other Messages Port

The previous three ports (Instrument Definitions, Snapshots, Incremental Refreshes) cater to specific FAST message types (SecurityList, MarketDataSnapshotFullRefresh and MarketDataIncrementalRefresh respectively). The fifth output port of the adapter is used to communicate to the application the messages of all other types (such as News (B), SecurityStatus (f), and so on).

The schema for this port is left to the user to define. The fields in this schema determine which fields from the incoming FAST message are passed to the StreamBase application.

Only one field is mandatory and expected by the adapter to be present in the schema: ChannelID (string), which identifies the ID of the FAST channel on which this instrument was defined.

Input Ports

The Adapter defines two input ports:

  1. The Command port is used to control some behaviors of the adapter, such as to cause the adapter to disconnect from a specific channel or to obtain the connection status of a given channel.

  2. The Subscription port is used to subscribe to and unsubscribe from some (or all) the instruments available on a given channel.

Command Input Port

The schema for the Command input port is expected to contain the following fields:

Field Name Field Type Field Description
Command string Always required. Contains the name of the command to execute (see below for a list of available commands).
ChannelID string Contains the ID of the FAST channel to which this command applies. This is required in the case of most commands,

Available commands include:

  • ListInstruments: List all instruments available on the specified channel ID. If the channel ID is not specified (that is, the field is left null) then instruments for all configured channels are listed.

    Requires the following field to be filled:

    • Command: Set to the value ListInstruments.

    If you wish to list the instruments available on a particular channel, the following field should be non-null:

    • ChannelID: Set to the ID of the channel for which to list instruments.

    If ChannelID is left null, instruments for all configured channels will be listed.

    One tuple will be emitted on the Instrument Definitions Port for each instrument available on the given channel.

  • Disconnect: Sever connections to all streams for the specified channel ID.

    Requires the following fields to be filled:

    • Command: Set to the value Disconnect.

    • ChannelID: Set to the ID of the channel to disconnect.

    If the configured connections to a given channel are already stopped, invocations of this command for the same channel are ignored.

  • DisconnectAll: Sever connections to all streams for all configured channels.

    Requires the following field to be filled:

    • Command: Set to the value Disconnect.

  • Connection Status: Issue a Connection Status tuple for the specified FAST channel. The status tuple is emitted on the adapter's Events port (see the Events Port Schema section above). The status tuple contains a non-null value in its InfoText field of either Connected or Disconnected.

    Requires the following fields to be filled:

    • Command: Set to the value ConnectionStatus.

    • ChannelID: Set to the ID of the channel to disconnect.

Note

There is no Connect command, because it is not really needed: No connection to a given FAST channel is opened unless and until at least one instrument subscription has been made on that channel. When a subscription is made the necessary connections are established (and subsequently severed) as needed — for example, the Recovery stream is only opened when instrument snapshots are needed, and once they are obtained the connection is closed automatically.

Incidentally, the net effect of the Disconnect command is to unsubscribe to all instruments on that channel and is functionally equivalent to sending the UnsubscribeAll command for that channel on the Subscription Input Port, as described in the next section.

Subscription Input Port

The schema for the Subscription input port is expected to contain the following fields:

Field Name Field Type Field Description
Command string Always required. Contains the name of the subscription command to execute (see below for a list of available commands).
ChannelID string Always required. Contains the ID of the FAST channel to which this command applies.
SymbolID string Conditionally required. Contains the symbol name of the instrument to which this command applies. (CME FIX/FAST Adapter only: May be left empty, in which case all traffic on the specified ChannelID will be subscribed to.)

Available commands include:

  • Subscribe: Subscribe to the instrument specified in the SymbolID field.

    Requires the following fields to be filled:

    • Command: Set to the value Subscribe.

    • ChannelID: Set to the ID of the channel for this instrument.

    • SymbolID: Set to a comma-separated list of instruments to which to subscribe.

    If the specified instrument has already been subscribed to, this command will have no effect.

  • Unsubscribe: Unsubscribe from the instrument specified in the SymbolID field.

    Requires the following fields to be filled:

    • Command: Set to the value Unsubscribe.

    • ChannelID: Set to the ID of the channel for this instrument.

    • SymbolID: Set to a comma-separated list of instruments from which to unsubscribe.

    If the specified instrument has already been subscribed to, this command will have no effect.

  • SubscribeAll: Subscribe to all the instruments handled by this FAST channel.

    Requires the following fields to be filled:

    • Command: Set to the value SubscribeAll.

    • ChannelID: Set to the ID of the channel to which to subscribe for all instruments.

  • UnsubscribeAll: Unsubscribe from all the instruments handled by this FAST channel.

    Requires the following fields to be filled:

    • Command: Set to the value UnsubscribeAll.

    • ChannelID: Set to the ID of the channel from which to unsubscribe for all instruments.

Using the Adapter in a StreamBase Application

This section demonstrates how to use the adapter in a StreamBase application. As shown in the EventFlow diagram below, the adapter has a specific set of input and output ports to communicate with the surrounding application. As with other StreamBase adapters and operators, you can optionally enable an Error Output Port, as described in Using Error Ports and Error Streams.

Adding the Adapter to an EventFlow Application

Add an instance of the adapter to a new StreamBase EventFlow application as follows:

  1. In StreamBase Studio, create a project, including an empty StreamBase EventFlow application file to host the adapter.

  2. From the Operators and Adapter drawer of the Palette view, drag a an Input Adapter component to the canvas. In the pop-up dialog listing all the available adapters, select UMDF Input.

  3. Select the adapter's icon on the canvas, and select the Adapter Properties tab.

  4. Enter the name of the FAST Channel Definition file this adapter should use to connect to UMDF. See the Channel Definition File section below for details on creating this file.

  5. Enter the name of the FAST template file this adapter should use to connect to UMDF. See the Template Definition File section below for details on obtaining this file.

  6. Select the Edit Schemas tab, and define a schema for the adapter's Instrument Definitions, Snapshots, Incremental Refreshes and Other Messages ports. See the Edit Schemas Tab section above for details. The adapter generates typecheck errors when the schemas are missing required fields or when fields are of the wrong type or size.

    Note

    You may find it useful to use a named schema for this port, which would allow you to reuse the same schema for different ports or different instances of the adapter.

  7. Connect Input and Output Streams to the adapters' input and output ports.

  8. Select the Input stream connected to the adapter's Command (first) input port, and define its schema. Refer to the Command Input Port section above for details on this schema.

  9. Select the Input stream connected to the adapter's Subscriptions (second) input port, and define its schema. Refer to the Subscription Input Port section above for details on this schema.

Authentication Material

If your UMDF account requires authentication material to be included at logon, you must specify this material in the adapter's configuration file. Add a <raw-data>MyPassword</raw-data> entry in each <session> section.

File Formats

This section describes the format of the Channel Definition and Engine Configuration files used by the UMDF adapter, as well as how to obtain a copy of the most current UMDF FAST Template file.

Channel Definition File

In order to know which IP addresses and ports to connect to the various data streams exposed by UMDF, the adapter requires them to be defined in an XML file. This file may define one or more channels, each of which describe how to connect to the Incremental, Instrument and Recovery UDP streams as well as the Replay TCP stream. All four connections must be defined in order for the channel to be properly defined and operated.

The following shows an example of a properly-configured channel definition file. Change this file for your own use by updating the values in bold text to reflect the proper settings for your organization:

<?xml version="1.0"?>
<configuration environment="AutoCert" updated="2011/04/30-21:13:22">
    <channel id="050" label="Futures Interest rates">
        <connections>
            <connection id="AI1"> <!-- ID attribute may have any value but 
                                       should be unique across the file -->
                <type feed-type="I">Incremental</type>
                <protocol>UDP/IP</protocol>
                <ip>233.111.180.113</ip>
                <port>20050</port>
                <feed>A</feed> <!-- Use B instead if this connection represents 
                                    the backup feed of UMDF for this channel -->
            </connection>
            <connection id="BD"> <!-- ID attribute may have any value but should be 
                                      unique across the file -->
                <type feed-type="D">Instrument</type>
                <protocol>UDP/IP</protocol>
                <ip>233.111.180.112</ip>
                <port>10050</port>
                <feed>A</feed> <!-- Use B instead if this connection represents the 
                                    backup feed of UMDF for this channel -->
            </connection>
            <connection id="R"> <!-- ID attribute may have any value but should be 
                                     unique acrYou may aoss the file -->
                <type feed-type="R">Recovery</type>
                <protocol>UDP/IP</protocol>
                <ip>233.111.180.112</ip>
                <port>30050</port>
                <feed>A</feed> <!-- Use B instead if this connection represents 
                                    the backup feed of UMDF for this channel -->
            </connection>
            <connection id="N"> <!-- ID attribute may have any value but should be 
                                     unique across the file -->
                <type feed-type="N">Replay</type>
                <protocol>TCP/IP</protocol>
                <ip>10.244.0.12</ip>
                <port>10050</port>
                <!--Sender target for replay fix session-->
                <sender>Sender</sender>
                <target>Target</target>
                <feed>A</feed> <!-- Use B instead if this connection 
                                    represents the backup feed of UMDF for this channel -->
            </connection>
        </connections>
    </channel>
    <!-- Add more channels here -->
</configuration>

Template Definition File

You must also obtain a valid and up-to-date UMDF FAST template definition file from BM&FBovespa. As of this writing, the template file can be obtained from the following locations:

BM&FBovespa recommends synchronization of the template file at the start of every trading week.

FAST Engine Configuration Files

In addition to the above configuration files the adapter also requires the presence of two files named fixengine.properties and fast.properties, which help specify engine-wide settings. Place these files in your project's top-level directory. The following shows an example of a typical fixengine.properties file:

# Name of the custom package. This property is using for the extending the 
# count of admin-commands. By default, package is null, but if custom commands 
# are present, initialize this property. For example:
# (autostart.acceptor.command.package=com.admin.commands)
autostart.acceptor.commands.package=

autostart.acceptor.targetIds=
autostart.acceptor.FIXADMIN.login=usr
autostart.acceptor.FIXADMIN.password=psw
autostart.acceptor.FIXADMIN.ip=*
autostart.acceptor.FIXADMIN.fixServerListener=com.epam.admintool.AdminTool

# autostart.acceptor.targetIds=admin,admin1
autostart.acceptor.admin.login=admin
autostart.acceptor.admin.password=admin
autostart.acceptor.admin.ip=*
autostart.acceptor.admin.fixServerListener=com.epam.admintool.AdminTool
# Storage type, supported values: Transient or Persistent
# Default values: Transient
#autostart.acceptor.admin.storageType=Transient

# Raw tags. List all tags here engine should treat as raw.
# Raw tag may contain SOH symbol inside it
# and it should be preceided by rawTagLength field.
rawTags=96, 91, 213, 349, 351, 353, 355, 357, 359, 361, 363, 365, 446, 619, 622

# Engine's local IP address to send from. It can be used on a multi-homed host
# for a FIX Engine that will only send IP datagrams from one of its addresses.
# If this parameter is commented, the engine sends IP datagrams from all
# local addresses.
#connectAddress=192.168.0.1

# Limits maximum number of messages during the resend request.
resendRequestNumberOfMessagesLimit=1000

# Reset sequences on switch to backup.
resetOnSwitchToBackup=true

# Reset sequences on switch back to primary connection.
resetOnSwitchToPrimary=true

# Sets disconnect timeout in seconds for Logout ack only when waiting for 
# Logout ack from the counterparty caused due incoming sequence number 
# is less than expected.
forcedLogoffTimeout=60

# Specifies delay between autoreconnect attempts in milliseconds.
autoreconnectDelayInMs=5000

# Specifies number of autoreconnect attempts before give up.
# Negative number = no reconnects, 0 - unlimited number of reconnects,
# positive number = number of reconnect attempts.
# Please use 0 wisely - it means reconnect without limits.
autoreconnectAttempts=0

# Maximum message size supported by this FIX engine instance.
# Should be greater than expected by approximately 1-5%.
maxMessageSize=1048576

# Sends reject if user application is not available.
# If false and client application isn't available acts like
# a "black hole" - accepts and ignores all valid messages.
sendRejectIfApplicationIsNotAvailable=true

# Enable/disable message rejecting. Default value: false.
enableMessageRejecting=true

# Sets queue mode. Set to "false" for persistent queue (slower but no 
# messages will be lost), "true" for in-memory queue (faster but less 
# safe, some messages may be lost).
inMemoryQueue=false

# Sets timeout interval after which connected acceptor session is timed out
# and disposed if logon wasn't received for this session.
loginWaitTimeout=30000

# Include last processed sequence 369 tag in every message for FIX versions >4.2.
includeLastProcessed=true

# Maximum number of messages in a queue before we pause pumper thread to 
# let queued message to be sent out. Set rather high for max performance 
# set 1 or pretty low for realtime experience. 
# 0 - disable queue control, do not pause pumper thread.
queueThresholdSize=3

# The maximum number of messages in buffer before we
# write message to transport.
# Default value is 100
#maxMessagesToSendInBatch=100

# Outgoing storage index. True to support resend request,
# false to never resend messages and always send gap fill.
outgoingStorageIndexed=true

# Enable/Disable force sequence number reset.
# Supported values: Always, OneTime, Never. Default value is: Never.
forceSeqNumReset=Always

# Allows user to replace storage factory with user own implementation.
#storageFactory=com.epam.fixengine.storage.InMemoryStorageFactory

# Enable switch to primary connection. Default value: true.
cyclicSwitchBackupConnection=true

# Enable auto switch to backup connection. Default value: true.
enableAutoSwitchToBackupConnection=true

# Storage directory could be either absolute path (like /tmp/logs or c:\fixengine\logs)
# or relative path e.g. logs (this one is relative to the application start directory).
storageDirectory=${fixaj.home}/logs

# This parameter specifies cleaning mode for message storage of closed sessions.
# Valid values: None | Backup | Delete
# Default value: None
storageCleanupMode=None

# This parameter specifies back-up directory for message logs
# of closed sessions when storageCleanupMode=backup.
# Valid values: existent directory name (relative or absolute path)
# Default value not defined
# See ${fixaj.home} description in the Configuration section of the
# FIX Antenna Java User and Developer Manual.
storageBackupDir=${fixaj.home}/logs/backup

# Specifies the time zone and affects on the time stamp prefix in the FIX in/out logs.
# The parameter should has the following format GMT[±]HH[:MM] or full name.
# For sample logFilesTimeZone=GMT+02:00
#logFilesTimeZone=UTC

# Incoming log filename template. {0} is replaced with actual SenderCompID,
# {1} with actual TargetCompID.
incomingLogFile={0}-{1}.in

# Outgoing log filename template. {0} is replaced with actual SenderCompID,
# {1} with actual TargetCompID.
outgoingLogFile={0}-{1}.out

# Info filename template. {0} is replaced with actual SenderCompID,
# {1} with actual TargetCompID.
sessionInfoFile={0}-{1}.properties

# Out queue file template. {0} is replaced with actual SenderCompID,
# {1} with actual TargetCompID.
outgoingQueueFile={0}-{1}.outq

# Backup incoming log filename template. {0} is replaced with actual 
# SenderCompID, {1} with actual TargetCompID.
backupIncomingLogFile={0}-{1}-{2}.in

# Backup outgoing log filename template. {0} is replaced with actual 
# SenderCompID, {1} with actual TargetCompID.
backupOutgoingLogFile={0}-{1}-{2}.out

# Specifies the time zone and affects the timestamp prefix in the 
# FIX in/out logs. The parameter has the following format:
# GMT[±]HH[:MM] or full time zone name, such as America/Los_Angeles.
# For sample logFilesTimeZone=UTC
#logFilesTimeZone=UTC

# This parameter specifies whether to reset sequence number at
# time defined in resetSequenceTime.
# Valid values: Yes | No
# Default value: No
performResetSeqNumTime=No

# This parameter specifies GMT time when the FIX Engine initiates the reset
# of sequence numbers.
# Valid values: HH:MM:SS time format
# Default value: 00:00:00
resetSequenceTime=00:00:00

# Time zone di for resetSequenceTime property.
# Default value: UTC
resetSequenceTimeZone=UTC

# Enables SSL transport for all initiator sessions.
# For individual session control set this parameter in session configuration.
#enableSSL=false

# Enable/disable Nagle's algorithm for TCP sockets.
#enableNagle=false

# Sets FIX engine global/per message handler(s), handler is called on each and 
# every incoming message.
# Handler could prevent further message processing.
# Note: handler numbers should be unique and sequential!
# DO NOT UPDATE UNLESS YOU KNOW FOR SURE WHAT YOU ARE DOING!!!
# DO NOT EXPOSE FOLLOWING system. prefixed params to end user,
# since they all have default values and most users never need to adjust those
#system.messagehandler.3=com.epam.custom.RejectMessageHandler
#system.messagehandler.global.0=com.epam.fixengine.session.messagehandler.global.DeliverToCompIdMessageHandler
#system.messagehandler.global.2=com.epam.fixengine.custom.GlobalMessageHandler2

# User supplied handlers.
#user.messagehandler.global.0=com.epam.fixengine.session.messagehandler.global.DeliverToCompIdMessageHandler
#user.messagehandler.global.1=com.epam.fixengine.custom.GlobalMessageHandler2


checkSendingTimeAccuracy=false
# Sending time accuracy 2 minutes (120000 ms).
reasonableDelayInMs=120000
measurementAccuracyInMs=10


# Toggle on/off validation of incoming messages according to base of custom dictionaries.
# Following parameters with the Validation suffix works only if this property set to true.
validation=false

# Toggle on/off validation values of fields with 8, 9, 35 & 10 tags.
wellformenessValidation=true

# Toggle on/off validation if fields are allowed in the message.
allowedFieldsValidation=true

# Toggle on/off validation if all required fields presents in the message.
requiredFieldsValidation=true

# Toggle on/off validation of order in which fields appears in the message.
fieldOrderValidation=true

# Toggle on/off validation of duplicated fields in the message.
duplicateFieldsValidation=true

# Toggle on/off validation of field values according defined data types.
fieldTypeValidation=true

# Toggle on/off validation of repeating group fields.
groupValidation=true

# Conditional validation is very much time consuming - use with care.
conditionalValidation=true

# This parameter specifies encryption config file name.
# Valid values: existent valid config file name (relative or absolute path)
# Default value not defined
# See ${fixaj.home} description.
#encryptionConfig=${fixaj.home}/encryption/encryption.cfg

# encryptionMode
# This parameter specifies the default value of encryptionMode.
# Valid values: None | Des | PgpDesMd5
# Default value: None
encryptionMode=None

And here is a typical fast.properties file:

# Specifies the size of stream's queue for incoming packages which should
# be later decoded and processed.
# default value - 200
# decodingQueueSize=200

# Define the minimum required missed message to start recovery.
# The value should be grate than possible distance of mixing UDP packets.
# Otherwise mixing will lead to premature starting of recovery process.
# default value - 9
# minHoleOffset=9

# Define the size of socket receive buffer size in Kb. Increasing buffer may allow the network implementation to buffer
# multiple packets when packets arrive faster than are being received.
# See details for the setReceiveBufferSize method in the java.net.DatagramSocket documentation.
# default value - 1024
# socketReceiveBufferSize=1024

# Define the size of buffer for incoming increments before processing per instrument.
# messageCorridorQueueSize=1000

# Define the size of queue for storing and ordering increments by RptSeqNum(83) per instrument
# messageIncrementQueueSize=1000

# Define a count of full cycles on Snapshot feed before define that there are no snapshots for instruments and they
# is in actual state.
# If this property set to negative value than it means that need to listen snapshot feed till all snapshots
# for instruments will be found. (Not recommended)
# Default value - 3
# snapshotCyclesToListen=3

# Define maximum size of gap for recovering via TCP. If need to recovery more messages than defined by this property,
# Market recovery via Snapshot should be used.
# Sometimes recovering a large count of messages could affect time for recovering other instruments
#(requests are processing one by one). To prevent this Market recovery could be applied for large gaps.
# Default value - -1 (recovery by TCP any gap)
maxGapForTCP = 500

Typechecking and Error Handling

The adapter uses typecheck messages to help you configure the adapter in your StreamBase application. In particular, the adapter generates typecheck messages for the following reasons:

  • A required property is missing.

  • One or more required fields in an input schema is missing or is of the wrong type or size.

  • One or more required fields in an output schema is missing or is of the wrong type or size.

  • The FAST Channel Definition File field, a required setting, is left blank.

  • The FAST Template File field, a required setting, is left blank.

Suspend, Resume, Shutdown Behavior

When suspended, the adapter disconnects from all UMDF channels. Because of the nature of the incremental update system used by UMDF, staying connected while applications cannot process messages would make staying connected useless.

When resumed, the adapter automatically resubscribes to all instruments that were subscribed to when suspension occurred, thereby allowing the application to rebuild its books for all subscribed instruments and resume operation.

When the application is shut down, the adapter disconnects from all configured and connected UMDF channels.