{{Quickfixn}} Missing tags, tag order; symbol tag 55 (mis?)listed as required?
olamide olatunji
krazibit312 at gmail.com
Thu Dec 26 19:26:22 PST 2013
Hi Manuel,
Find my answers to your questions below
1. It is greatly advised to check and follow closely the specification
provided by your counter party, as the might have customized a few things
to sooth their MO.
2. Tag order is rarely important, the fix engine sorts this out as long as
there are correctly defined in the dictionary.
3.The best way to check for existence of a field is to use the
msg.IsSetField(Field) method, and its recommended to do this for all fields
marked as optional by your counter party, because if you try to get a field
in a message that is not set by your counter party your FIX engine would
rejects the message citing the reason as Unconditionally Require Field
Missing.
Best Regards
Ola
On Fri, Dec 27, 2013 at 5:04 AM, Manuel Lopez <lopez.post at gmail.com> wrote:
> This is a minor point, but led to a few more general questions:
> In customizing the fix4.4 definition file, I noticed that tag 55
> (Symbol) shows as required for the "instrument" category, when it's
> optional according to the fix 4.4 spec I have and our counterparty.
> I'll add custom fields of course, but
> 1) is it advised to check the xml definition closely for "required"
> being correct and
> 2) for having all the fields in the same order as the counterparty
> sends out (or expects)? (I could for example worry only about those
> issues that come up in testing, if I can assume that tag order is
> rarely important, or only for repeating groups etc.)
> 3) What is the best way to check for the existence of a tag value
> before saving it to a database? for example, if I have (where msg is a
> quickfixn ExecReport type):
> TransactTime_fx60 = msg.TransactTime.getValue();
> Can I just test for a null value?
> (--I'm doing this in the OnMessage MessageCracker handler, assuming
> that's the best place, rather than say overriding the store or log.)
>
> Thanks (--and thanks for the great work in 1.5--SSL is just in time for
> me.).
> _______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20131227/151b51b9/attachment-0002.htm>
More information about the Quickfixn
mailing list