Capital Markets Adapters 10.15 | Apama Capital Markets Adapters Documentation 10.15 | BM+F Bovespa UMDF Adapter | Transport properties configuration | Additional transport properties
 
Additional transport properties
The following additional transport configuration properties are available:
*Additional configuration file. BM&F Bovespa UMDF provides the option of switching to a backup feed in case of primary feed failure. You can enable this functionality in the adapter by providing an additional configuration file with the connection details for the backup feed. For example:
<property name="ConfigFile" value="config_backup_feed.xml" />
Note:
The adapter can handle multiple instances of ConfigFile property name.
*EnableFixLogging. If enabled, all the decoded fix messages will be logged to the folder mentioned by FIXLogFolder transport property. If FIXLogFolder is not specified, the messages are logged to UMDF_FIX_LOG. For example:
<property name="EnableFixLogging" value="true" />
Note:
It is not recommended to enable FIX logging in production environments as it increases the latency considerably.
*FIXLogFolder. Only useful when EnableFIXLogging transport property is set to true. Fix messages logs are stored in the folder mentioned this parameter. For example:
<property name="FIXLogFolder" value="UMDF_FIX_LOG" />
*ConvertNativeStrings. If true, any STRING-type fields in FAST decoded messages should be converted from the native character encoding to UTF8. If false, all strings are assumed to be UTF-8. This value defaults to false. For example:
<property name="ConvertNativeStrings" value="true" />
*NativeEncoding. If non-empty, this is the name of the native encoding to use for conversions to/from UTF-8. This parameter overrides the system encoding. For example:
<property name="NativeEncoding" value="ISO8859-1" />
*MulticastInterface. IP address (as a dotted quad, for example, "1.2.3.4") of the network interface on the machine running the adapter that should be used to subscribe to UDP multicast traffic. If not specified, all interfaces will be used. For example:
<property name="MulticastInterface" value="1.2.3.4" />
You can also configure MulticastInterface for each of the active-passive feeds (primary and secondary). For Example:

<property name="MulticastInterface.A" value="a.b.c.d"/>
<property name="MulticastInterface.B" value="w.x.y.z"/>
*LogMessages. FIX message that should be logged when they are received from UMDF. The message contents will be logged at INFO level. The following message types are supported:
*Heartbeat
*SequenceReset
*News
*SecurityStatus
*MarketDataFullRefresh
*MarketDataIncrementalRefresh
*SecurityDefinition
*TCPReplayMessages (used to log the TCPReplay Session FIX messages at INFO)
*Unknown ( any unrecognized message type)
For example:
<property name="LogMessages" value="Unknown" />
*LogDebug. A comma separated list of extra debug logging categories that should be enabled. The additional logging produced by an enabled category will be logged at the INFO level unless otherwise stated. Currently the following categories are supported:
*UpstreamEvents. Enable logging of all events sent to the adapter by the correlator ("upstream" events). These will include subscription and unsubscription requests, commands to enable and disable the feed of security definitions, and heartbeat events.
*SockReader. Enable detailed logging on all socket reader. This should be disabled by default for performance reasons.
*EventConstruction. Detailed logging of the transformation of an incoming FIX message into an Apama event.
*ChannelMessageRate. Log the number of raw FIX/FAST update messages, received on each channel, every 60 seconds.
*Recovery. Enable detailed logging in regions related to recovery procedure (initial or recovery after Gap). This should be disabled by default for performance reasons.
*ThreadStates. Logs information about the start and stop of threads.
For example:
<property name="LogDebug" value="ChannelMessageRate" />
Note:
LogMessages and LogDebug can produce extreme amounts of output and should be used with caution in a production environment.
*TcpFeedRecoveryLimit. By this parameter, you can set the limit for the number of messages that can be recovered using TCP Replay. The default is set to 2000. For example:

For PUMA 2.0
<!-- Max value supported for UMDF 2.0 -->
<property name="TcpFeedRecoveryLimit" value="10000" />
*GapMaxRetryAttempts. Number of messages to wait on the incremental feed before identifying a gap on the feed (defaults to 3 messages).
<property name="GapMaxRetryAttempts" value="3"/>
*GapRetryDurationMilliseconds. Time to wait before reporting a gap on the incremental feed (defaults to 25 milliseconds).
<property name="GapRetryDurationMilliseconds" value="25"/>
*TCPReplayRetryMilliseconds. Time to wait before retrying to recover a message using the TCP Replay feed (defaults to 140 milliseconds).
<property name="TCPReplayRetryMilliseconds" value="140"/>