Re: [Quickfix-developers] Removing unsupported fields in toApp()

[Nick R. <nic...@gm...>]

thanks for the very quick reply.

I also just noticed that I had defined a message for reject 35=3 and not
35=j in my data dictionary.
I was about to change that, but as you point out, QF won't  'force' the
issue with regard to outbound message

thanks
again

nick.



On 29/01/07, Oren Miller <or...@qu...> wrote:
>
> Hi Nick,
>
> The method you are looking for is removeField( int field ).  It is
> not defined in the Message class but is in the base FieldMap class,
> which is probably why you didn't see it.
>
> Currently, data dictionaries are only used to validate incoming
> messages.  Any outgoing messages are sent without regard for the data
> dictionary.  The reason is that the QuickFIX developer has control
> over what they send out (as opposed to what they receive) and if they
> choose to send a message it is assumed they know what they are
> doing.  This also saves some overhead in validating messages that the
> counter-party is really responsible to validate (as you witnessed).
>
> This of course seems to be a case of the counter-party not liking a
> message generated by the engine itself.  This happens on occasion and
> sometimes results in a configuration setting to handle communicating
> with these weird situations if there is no obvious workaround.  It
> seems that using the removeField method should work for you though.
>
> Also, note that as a validator, there is no case where the data
> dictionary will see a field missing and remove the field from the
> message by itself.  As a validator, it decides whether a message is
> ok or not.  It will never try to modify the message to force it to be
> ok,
>
> You could of course grab the data dictionary and validate outgoing
> messages in the toApp method yourself if you like.  As you noted
> however the best you could do is throw a DoNotSend if the message
> fails validation.  If you do throw a DoNotSend on a message with a
> PossDup flag, by the way, the engine will replace the message with a
> gap fill.  It is not a problem to do this.
>
> --oren
>
> On Jan 29, 2007, at 12:35 AM, Nick Richardson wrote:
>
> > Hi all,
> >
> > I've recently been evaluating QF as a possible replacement for an
> > in house FIX engine.
> > We connect to quite a few Brokers globally and as you can imagine
> > they all run different FIX engine and each have their own
> > interpretation of FIX.
> >
> > Apologies if this is a really naive question
> >
> > One broker we connect to supports Business Message Reject (35=J),
> > however they do not support all the fields, tag 380 (Business
> > Reject Reason)
> > tag 380 is a mandatory filed, so you would expect them to support
> > it, or at the very least ignore, however this is not the case.
> >
> > Is there a way I can not send a tag on a session message ?
> > I've tried to find a message.unset(filed) type method that I can
> > use in the toApp() callback, but haven't found anything.
> >
> > I could throw a 'DoNotSend' here and then create my own
> > BusinessRejectMessage without the tag they can't handle... BUT what
> > would happen if the business reject was being send as part of a
> > resend request (eg possDup flag is set) ? From the doco it seems
> > that the QF session will sequence-reset because of the possdup flag
> > being set and the fact that I threw the DoNotSend.
> >
> > Would that be the case ? If so, then catching in toApp(), throwing
> > the exception and creating my own BusinessReject message would not
> > be possible, IMHO.
> >
> > One other thing i did do, which I thought may have helped, was to
> > make sure that the business reject message was defined in the
> > DataDictionary for this particular session, and that the tag 380
> > was NOT in the message, I didn;t just make it optional, I actually
> > removed it totally.
> >
> >     <message name="Reject" msgtype="3" msgcat="admin">
> >       <field name="RefSeqNum" required="Y"/>
> >       <field name="RefTagID" required="N"/>
> >       <field name="RefMsgType" required="N"/>
> >       <field name="SessionRejectReason" required="N"/>
> >       <field name="Text" required="N"/>
> >     </message>
> >
> >
> > Which raises another question. If I create a DataDictionary for a
> > particular session, why does QF ignore some of it ?  I know that my
> > newOrderSingle definition in the DataDictionary works and is being
> > used by QF,  as for this particular session tags 48 and 22 are
> > optional and I wasn't catching the 'Conditionally Required Field'
> > when I tried to get the fields, so its definitely reading the
> > business messages, but not the Reject message,  which is an admin
> > message.
> >
> >
> > I hope that all makes sense,  I guess there are two questions here,
> > 1. Can i delete a field from session message in toApp() callback
> > before it is sent ?
> > 2, why does QF not use my reject message as defined in the data
> > dictionary ?
> >
> > Any help truly appreciated
> >
> > regards
> > Nick
>
>


-- 
Nick Richardson