Streaming FIX adapter ResendRequest and the Message Replay command
Article ID: KB0074537
Updated On:
| Products | Versions |
|---|---|
| TIBCO Streaming | 10 |
Description
How can we send messages into the TIBCO Streaming EventFlow application which were already received?
Issue/Introduction
Usage guidance
Resolution
Processing messages a second time out of the FIX adapter may be needed for a variety of reasons such as testing, auditing, or recovering from an error. Replaying messages is not expected to be needed for normal business processing.
The FIX message ResendRequest(tag-2) would appear to be ideal for these purposes, but it is an administrative command to be used exclusively to synchronize FIX message stores shortly after Logon, and will confuse the FIX engines if used manually.
The QuickFIX/J engine does not support this command. For alternatives see the "Audit" section below.
The FIX engines use ResendRequest(2) automatically after Logon(A) to synchronize the message stores. It is not expected by either of our FIX engines to be used by the user, so if the messages are already in the store the engine simply ignores the duplicate messages. This is why manual use of ResendRequest(2) isn't producing output. It will only produce output if both of these are true:
a. the message store doesn't have those messages already, and
b. the counter-party doesn't send a Sequence Reset Gap-Fill(4) instead.
1. Logoff from all FIX sessions.
2. Read the message store file with the "CSV File Reader" adapter and parse each line into the fields you need.
The FIX message ResendRequest(tag-2) would appear to be ideal for these purposes, but it is an administrative command to be used exclusively to synchronize FIX message stores shortly after Logon, and will confuse the FIX engines if used manually.
Solution
To satisfy the need to get past messages out of the engine and into the application, the "StreamBase High-Performance FIX" engine supports Command="ReplayMessages" with the desired BeginSeqNo and EndSeqNo. This replays messages between these limits out of the local store and does not initiate communication with the counter-party. This may be used at any time and does not affect the session state.The QuickFIX/J engine does not support this command. For alternatives see the "Audit" section below.
Background
When Logging in you are either starting a session or continuing a session. In all cases, if the counter-party MsgSeqNum is larger than the engine expects the engines automatically handle resends and synchronize the message store. Some of the messages may be skipped by the counter-party with a Gap-Fill(4), at which point the engine assumes it has all the business-level messages available. All messages received that were not previously in the local store are also sent to the application for business processing.The FIX engines use ResendRequest(2) automatically after Logon(A) to synchronize the message stores. It is not expected by either of our FIX engines to be used by the user, so if the messages are already in the store the engine simply ignores the duplicate messages. This is why manual use of ResendRequest(2) isn't producing output. It will only produce output if both of these are true:
a. the message store doesn't have those messages already, and
b. the counter-party doesn't send a Sequence Reset Gap-Fill(4) instead.
Audit
If the messages are in the local store and you need to review them for any reason, the direct approach is to:1. Logoff from all FIX sessions.
2. Read the message store file with the "CSV File Reader" adapter and parse each line into the fields you need.
Feedback
Yes
No
Powered by
