RE: [Quickfix-developers] Re: [Quickfix-users] how to send response to a client

[Brian E. <azz...@ya...>]

James -

We have two groups of users connecting to our applications. 

The first set are clients who are new to FIX. Their biggest issues tend
to be the session management parts and just getting their minds wrapped
around the whole FIX process. For these users, a couple of additional
field values isn't an issue - development is new and the values have no
intrinsic "meaning" to them anyway. They generally write to the FIX
documents that we provide.

The second set are clients that have pre-existing FIX implementations.
Many clients like to use FIX as a "standard" way to communicate to
several different ISV or FCM systems - a way to mitigate risk and
vendor lock-in. These users will sometimes grumble about yet another
instance of non-standard behavior, but pretty much EVERY ISV/FCM has to
deviate from the standard in some way. The addition of a few new field
values is actually pretty easy compared with different FIX versions
(4.2 and 4.3 being the most popular, but a few 4.0 and 4.4 versions are
out in the wild) and non-standard session management. 

Aside from the additional field values, we've only made a few other
extensions to the protocol: 

1. The addition of tag 789 (NextExpectedMsgSeqNum) on logout messages
(a 4.4 field backported to our 4.3 application). Nearly every customer
loves this addition.

2. Co-opting the SecurityExchange tag (207) to use as an exchange
specifier (e.g., which exchange is this order for?). The only other
choice was to mess around with the Symbol tag, and we thought this
implementation was cleaner.

3. Adding some additional exchange-specific OrdTypes - there are some
pretty funky order types out there and FIX doesn't have values for all
of them.

4. We also drop the ClOrdId on some of the ExecutionReports (due to
limitations within our own legacy app), but this is not unusual
behavior out in the real world.

We do a number of things to mitigate our changes to the specification.
First, we use a very small subset of available FIX fields on orders and
execution reports (typically for us, any order can be submitted using
only 12 tags). Second, we provide additional QuickFIX documentation and
a custom FIX43.XML file to encourage QuickFIX usage - it's vastly
simpler to use than coding all the session management stuff yourself.
(I know - I've written FIX engines into four different exchanges.)
There a couple of things I'd change about QuickFIX [which I've posted
about in the past], but it's vastly superior to anything else out
there.

I think pretty much everyone in the industry uses quotes when they
speak of the FIX "standard". It's a nice starting point, but no one in
the futures industry makes any attempt to stick closely to every
detail. In many cases, it's been impossible (until 4.4, many futures
industry-specific data simply did not have tags). In others, it's
inertia or hubris (the CME is notorious for its "improvements" to the
FIX specification - while simultaneously sticking to the 4.2 release
that doesn't support futures). I think the situation is getting better
now that the exchanges are much more active in the specification - but
even that is a mixed bag, as they continue to push the spec to handle
exchange needs while ignoring the needs of ISVs and FCMs.

Of course, wait until you see the "implicit tagging" specification
that's being worked on - the QuickFIX team will have PLENTY of work in
the future! >;-)

- Brian Erst
Thynk Software, Inc.

--- "James C. Downs" <jc...@co...> wrote:

> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> Brian,
> This is a great example of how all the differences in business
> requirements
> from implementation to implementation cannot be completely covered by
> a
> standard protocol. This is also a good real world example for those
> who are
> new to FIX struggling with the map between the protocol and business
> needs
> and how that gap is bridged. 
> 
> Would you mind commenting on the general reaction of a new
> counterparty to
> your system when they are presented with custom field values (at the
> application level)? Is it an education process as to the value the
> custom
> values bring to the implementation?
> 
> Thanks,
> Jim
> 
> -----Original Message-----
> From: Brian Erst [mailto:azz...@ya...] 
> Sent: Friday, June 03, 2005 9:39 AM
> To: James C. Downs; azz...@ya...; 'rohan joel pais';
> qui...@li...;
> qui...@li...
> Subject: RE: [Quickfix-developers] Re: [Quickfix-users] how to send
> response
> to a client
> 
> James -
> 
> The problem occurs when you have a fairly sophisticated order
> management
> system that acts as more than just a proxy pass-through to an
> exchange.
> Here's an example of an issue that (so far) has best been resolved
> through
> additional OrdStatus values.
> 
> The system I work on has connections to 12 different futures
> exchanges.
> We attempt to deliver a consistent interface for all these exchanges,
> even
> when any particular underlying exchange may not support the superset
> of
> functionality across the many exchanges. For instance, not all of the
> exchange systems support stop orders (even though the use of such
> orders is
> widespread throughout the industry). For those exchanges that do not
> support
> stop orders, we have created a process that simulates stop order
> processing
> within our order management system.
> Essentially, we hold the orders, listen to the price feed and submit
> the
> orders once the trigger price has been touched.
> 
> For these orders, they may NEVER reach the exchange system (price is
> not
> matched). We need a consistent way of telling our users when orders
> have
> been accepted into our system for management, when (if) they have
> been
> diverted to our internal stop processing ssytem, when the orders get
> elected
> into the market and when the order actually reaches the market.
> 
> The simplest way to handle this (by far) was to add a few additional
> OrdStatus/ExecType values. We define "NEW" as being accepted by OUR
> application and add three new values ('l' for locally working stops,
> 'e' for
> stop order election and 'x' for at the exchange).
> 
> In this way, our clients know where an order is at all times. Just as
> importantly, our helpdesk knows where that order is as well. If the
> client
> experiences a communications failure and needs to work their orders,
> they
> should still have some idea as to what their current market risk is
> while
> talking with our helpdesk to manage their open orders.
> 
> - Brian Erst
> Thynk Software, Inc.
> 
> --- "James C. Downs" <jc...@co...> wrote:
> 
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
> > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> > 
> > Brian,
> > I'm curious why in your case the OrdStatus = "NEW" was not
> sufficient 
> > to indicate that the order was accepted by the exchange and in the 
> > market? What exchange/venue was most problematic for you in this 
> > regard?
> > 
> > Thanks,
> > Jim
> > 
> > -----Original Message-----
> > From: qui...@li...
> > [mailto:qui...@li...] On Behalf
> Of 
> > Brian Erst
> > Sent: Friday, June 03, 2005 7:45 AM
> > To: rohan joel pais; qui...@li...;
> > qui...@li...
> > Subject: [Quickfix-developers] Re: [Quickfix-users] how to send 
> > response to a client
> > 
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX FAQ:
> > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> > 
> > I have a very similar application and I eventually decided that the
> 
> > "better"
> > way was to add additional ExecType/OrdStatus values and use those
> to 
> > differentiate between "my application has received the order"
> > and "the exchange has received the order".
> > 
> > In my particular case, I use Pending New (OrdStatus='0') to
> indicate 
> > that my app received and databased the order. I created a new 
> > OrdStatus ('x'
> > for at
> > the eXchange) to indicate that the order had been received by the 
> > exchange.
> > 
> > FIX hasn't fully come to terms with third-party order management 
> > systems acting as a bridge between clients and exchanges. Hopefully
> 
> > they will start looking at that (if they haven't already) as most
> of 
> > the ISVs out there are now adding some sort of FIX interface to
> their 
> > order management systems.
> > 
> > - Brian Erst
> > Thynk Software, Inc.
> > 
> > --- rohan joel pais <roh...@re...> wrote:
> > 
> > >   
> > > Hi all,
> > >        I need some help in developing a new project. It is like
> > this
> > > -  My application will act like a passer, which recieves fix
> > messages
> > > from the client and then converts it into another format and
> sends
> > it
> > > to the exchange.
> > > But my problem here is i want to tell the client that i have
> > recieved
> > > his order, without sending him the execution report. so i am
> asking
> > 
> > > whether i can build my own response message and send it to the
> > client.
> > > 
> > > with regards
> > > rohan pais
> > > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using
> Yahoo!
> > Search APIs Find out how you can build Yahoo! directly into your
> own 
> > Applications - visit
> > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Yahoo.
> > Introducing Yahoo! Search Developer Network - Create apps using
> Yahoo!
> 
=== message truncated ===