Contents
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.
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.
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.
- 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.
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_XXX
, where XXX is an integer. If it does, the FAST template is examined for a FAST field with tag XXX. 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.
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.
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 typeLength
, which announces the number of repeating groups in the sequence in a manner similar to FIX fields of typeNumInGroup
-
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 ofNoMDEntriesGroup
)
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.
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.
The adapter has five output ports, listed here in the order in which they appear on the adapter:
-
Events
-
Instrument Definitions
-
Snapshots
-
Incremental Refreshes
-
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.
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:
|
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. |
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.
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.
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.
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.
The Adapter defines two input ports:
-
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.
-
The Subscription port is used to subscribe to and unsubscribe from some (or all) the instruments available on a given channel.
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 valueListInstruments
.
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 leftnull
, 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 valueDisconnect
. -
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 valueDisconnect
.
-
-
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 itsInfoText
field of eitherConnected
orDisconnected
.Requires the following fields to be filled:
-
Command
: Set to the valueConnectionStatus
. -
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.
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 valueSubscribe
. -
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 valueUnsubscribe
. -
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 valueSubscribe
All. -
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 valueUnsubscribe
All. -
ChannelID
: Set to the ID of the channel from which to unsubscribe for all instruments.
-
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.
Add an instance of the adapter to a new StreamBase EventFlow application as follows:
-
In StreamBase Studio, create a project, including an empty StreamBase EventFlow application file to host the adapter.
-
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
. -
Select the adapter's icon on the canvas, and select the Adapter Properties tab.
-
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. -
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. -
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.
-
Connect Input and Output Streams to the adapters' input and output ports.
-
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. -
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.
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.
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>
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.
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's 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 here: http://docs.oracle.com/javase/6/docs/api/java/net/DatagramSocket.html#setReceiveBufferSize%28int%29 # 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
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.
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.