{{Quickfixn}} custom fields (multi-counter-party)

[James A. Smith]

Let me clarify the case:  There is 1 session to 1 counterparty, however
that counterparty will be sending me messages from many counterparties.
This is the complexity, to parse all counterparty's messages sent to me
by my counterparty.  Does that makes sense?

-----Original Message-----
From: quickfixn-bounces at lists.quickfixn.com
[mailto:quickfixn-bounces at lists.quickfixn.com] On Behalf Of Grant
Birchmeier
Sent: Wednesday, March 06, 2013 12:04 PM
To: Mailing list for QuickFIX/n
Subject: Re: {{Quickfixn}} custom fields (multi-counter-party)

I'm seeing red flags like crazy here, and probably some misused
terminology.

First, a clarification: A session is an instance of a one-to-one
connection.  If an acceptor is handling 5 initiators, then that's 5
sessions.  Sessions are identified by, among other things, the FIX
version and the party IDs.

I assume you're writing an initiator, e.g. a client.  You want to use
one application to connect to multiple venues, and you want to use a
common DataDictionary for all of them.  Is that right?

>From experience, I think that is not a workable plan.

1) It's possible that two venues can have completely incompatible DDs.
 I've seen a venue rearrange FIX fields inside repeating groups for no
good reason, and that would screw your DD up for everyone else.  It's
not likely, but venues can do really insane things.

2) Two venues might use the same custom field tag for different custom
fields.  Say venue-1 defines 8888 as a string, but venue-2 defines it as
an int?

3) Maintainability.  Say a venue makes a DD change.  You need to make
that corresponding change in your DD... but now you need to validate you
change against ALL your venues, not just the one that changed.

4) Are you even thinking about conflicting config file settings yet?
That's a whole other post.

At best, I think you can write an app that takes two parameters: a
config file path and a DD path.  You'll maintain a different config and
a different DD for each venue.  Your app may probably have a lot of
conditional behaviors due to venue differences, though.

I think a much better plan is to just start by writing to one venue.
When that works, try to add a second.  You'll quickly see can be reused
and what can't, and I think you'll come up with a much better plan of
action when you work on venues 3, 4, and beyond.

I appreciate wanting to do a big elegant design at the beginning, but it
sounds like you might not have enough practical QuickFIX experience to
see the pitfalls.  You really need to get your hands dirty for a bit and
do some refactoring later.

-Grant


On Wed, Mar 6, 2013 at 10:36 AM, James A. Smith <jsmith at anstca.com>
wrote:
> I have many counter parties that will have their own custom fields.  I

> want to be able to use 1 session to handle all counter party messages 
> with their respective custom fields.
>
>
>
> I should first define all custom fields in the DD, and then add all 
> possible custom fields to each message type as required=N for each 
> MessageType I am listening for?
>
>
>
> thanks,
>
> James Smith
>
>
>
>
> _______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>



--
Grant Birchmeier
Connamara Systems, LLC
Made-To-Measure Trading Solutions.
Exactly what you need. No more. No less.
http://connamara.com
_______________________________________________
Quickfixn mailing list
Quickfixn at lists.quickfixn.com
http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com