Search code examples
quickfixfix-protocolquickfixjcamel-quickfix

Is it correct to use TargetSubID as a flag for test data in FIX protocol?

We are currently working on a FIX connection, whereby data that should only be validated can be marked. It has been decided to mark this data with a specific TargetSubID. But that implies a new session.

Let's say we send the messages to the session FIX.4.4:S->T. If we then get a message that should only be validated with TargetSubID V, this implies the session FIX.4.4:S->T/V. If this Session is not configured, we get the error 

Unknown session: FIX.4.4:S->T/V

and if we explicitly configure this session next to the other, there is the error

quickfix.Session – [FIX/Session] Disconnecting: Encountered END_OF_STREAM

what, as bhageera says, is that you log in with the same credentials.

(...) the counterparty I was connecting to allows only 1 connection per user/password (i.e. session with those credentials) at a time.

I'm not a FIX expert, but I'm wondering if the TargetSubID is not just being misused here. If not, I would like to know how to do that. We develop the FIX client with camel-quickfix.

Solution

  • It depends a lot on what you system is like and what you want to achieve in the end.

    Usually the dimensions to assess are:

    • maximising the flexibility
    • minimising the amount of additional logic required to support the testing
    • minimising the risk of bad things happening on accidental connection from a test to a prod environment (may happen, despite what you might think).

    Speaking for myself, I would not use tags potentially involved in the sesson/routing behavior for testing unless all I need is routing features and my system reliably behaves the way I expect (probably not your case).

    Instead I would consider one of these:

    • pick something from a user defined range (5000-9999)
    • use one of symbology tags (say Symbol(55)) corrupted in some reversible way (say "TEST_VOD.L" in the tag 55 instead of "VOD.L")

    A tag from a custom range would give a lot of flexibility, a corrupted symbology tag would make sure a test order would bounce if sent to prod by accident.

    For either solution you may potentially need a tag-based routing and transformation layer. Both are done in couple of hours in generic form if you are using something Java-based (I'd look towards javax.scripting / Nashorn).