I use a QuickFix/n initiator. My broker rejects my logon messages, citing wrong order of fields (tags) in the message header. Instead of 34, 49, 52, 56, the order should be 49, 56, 34, 52.
QuickFix/n seems to automatically sort the various fields within the three regions (header, body, trailer) of messages by tag number upon sending the message to the session.
Is there a way to change the order of the fields in a message sent to an acceptor? Is there a way to prevent the sorting behaviour? (Adding groups to the message or changing the data dictionary don't work.)
Or if that is impossible with QuickFix/n, is there a FIX engine which allows changing the order of fields in messages?
This error is normally caused by trying to put a header field into the body of the message. The DataDictionary object provided either by yourself if you are manually adding it to the session or from the session itself (if you are using the config file to tell the session which data dictionary to use) has functions called isHeaderField(int tagNumber) and isTrailerField(int tagNumber) to help you decide if the field should be in the header or the trailer. Different data dictionary files for different counterparties may (I've only seen it once or twice) put header fields into the body part of the message, body fields into the header, or (most commonly) custom tags into the header. This means that it is generally a good idea to use the available functions to check whether a field should be added to the header, body, trailer or a repeating group within the body.
Since this question is about logon messages I am guessing that you are adding fields to that message type so I may need to see the code doing that to help further.
By default quickFix reorders tags in a group by ascending order. If you want to retain the order you need to rebuild the quick fix jar as suggested here.
Related
From what I've read, every Message-ID must be unique, however it is possible to create repeated Message-IDs if we force the header with a fixed value. So I don't understand what the point of them saying that the Message-ID should be unique, but they are very easy to create duplicates. If they can easily be generated by anyone with a little reading and basic programmatic knowledge, why do Message-IDs exist and what are they used for, which I can easily duplicate?
Short answer: For threading in email clients.
The message-id header is defined in RFC 2822:
The "Message-ID:" field contains a single unique message identifier.
The "References:" and "In-Reply-To:" field each contain one or more
unique message identifiers
The message ID is used to show which message is a reply to which other message, for example. That way mail clients can show a tree of emails with their replies even if other things like the Subject don't change. (Counting leading Re:s of the subject line would be a bad way to determine ancestors and children: not every mail client adds them, and some use language specific ones.)
https://datatracker.ietf.org/doc/html/rfc5322#section-3.6.4
in conjunction with the References and In-Reply-To fields, mail clients use Message-ID to organize multiple messages into threads.
https://en.wikipedia.org/wiki/Message-ID
and at least some clients will consider two messages with the same ID to be the same thing and discard one of them.
I am implementing a client to connect to a server which as far as I can tell uses a hybrid of FIX4.2 and FIX4.4.
The server sends group 453 (NoPartyIDs) with fields in a non-standard order when some events occur.
According to the specification document, the first field should be PartyID (448). With certain messages, the first field in the group is PartyIDSource (447) and the message is rejected. PartyIDSource is the second field in the group as per the specification.
I get the following error:
<event> Message 140 Rejected: Group 453's first entry does not start with delimiter 448 (Field=453)
From the documentation and trial and error, I cannot find a way through this issue. Amongst a few guesses, I have tried adding field 447 as the first (non-required) field in the group definition in the data-dictionary. I have also set ValidateFieldsOutOfOrder to N in the config.
Is there something I can do to not reject and process the message?
Relevant documentation:
Groups are a little more nuanced than other parts of the Data Dictionary.
A group is defined within a message, with the group tag. The first child element of the group tag is the group-counter tag, followed by the other fields in the group in the order in which they should appear in the message.
ValidateFieldsOutOfOrder is not relevant here, so you can take that out.
If I understand you correctly, you're saying that
sometimes 447 comes before 448
but at other times 448 comes before 447
If this is true, then unfortunately your counterparty is being really stupid. Per the FIX spec, the order of fields in repeating groups is supposed to be in a consistent order. (And also, the first field of the each group-sequence is always required to be present.) If they're flip-flopping fields, they're violating FIX.
If the order was consistent, you would just edit your DD to change the order, and it sounds like you tried that. But if your counterparty is flip-flopping, then your DD will always be wrong part of the time.
I don't have a good answer for you. QF/n is not designed to handle all the ways that counterparties do FIX wrong (nor should it be).
Your counterparty's implementation is sloppy. Try contacting their support and seeing if they'll fix it?
I'm attempting to implement a FIX protocol in .NET with QuickFIX in order to automatically send out trade orders. Sending orders with the OrderQty tag doesn't raise any issues, however when using the CashOrderQty tag, the host returns the error message "Conditionally Required Field Missing". The message already includes all the specified fields required for CashOrderQty, the error only disappears if I add OrderQty to the message, however the documentation explicitly states only one of the two must be sent in the message.
I would agree with the earlier comments - it seems to be a question to your counter-party, no issue with QuickFix/n as such. It (apparently) correctly delivers the trade order message to the exchange, and the exchange's response back to you, so only the maintainer of the exchange's documentation could explain the reasons for the behavior your see.
Check FIX.xml dictionary on your side, it should match the third party documentation in terms of required and optional fields + supported fields.
Mail user agents usually display threads of Emails by chaining messages together according to the In-Reply-To and References header fields that contain the Message-IDs of other messages. Although a mail usually only replies to one other message, it may be the case that one message answers multiple others. The standard allows multiple entries in both fields. What can I expect when I send an email that References or is In-Reply-To multiple IDs this way?
Is it good practice to do so?
Does it confuse widespread MUAs?
Is there any common ground on how to display such a message in a
threaded view?
The "In-Reply-To:" field will contain the contents of the
"Message-ID:" field of the message to which this one is a reply (the
"parent message"). If there is more than one parent message, then
the "In-Reply-To:" field will contain the contents of all of the
parents' "Message-ID:" fields. If there is no "Message-ID:" field in
any of the parent messages, then the new message will have no "In-
Reply-To:" field.
Technically there COULD be a reason where you would reply to multiple emails and it would be valid to place multiple message ids in the In-Reply-To header. I can’t think of any program that actually supports this. As to MUAs they won’t care the delivery that the MUA cares about is the To, Cc, Bcc headers.
The In-Reply-To header and References header would control how threads are displayed. Not sure if any mail clients would have an issue handling the multiple In-Reply-To headers. 99% of the time there would only be a single message ID in the In-Reply-To header. So it’s feasible mail applications won’t support it. However they would support the additional reference entries. And this shouldn’t pose an issue.
I implement QuickFix client and I parse SecurityDefinition message ('d') with many user-defined fields. The service provider wants me not to validate user-defined fields, as he says that they add new fields from time to time and don't want to make us (clients) dependant of this.
Is there a way to cancel validation of user-defined fields for one specific message only?
Thanks...
Take a look at the Configuring QuickFIX page, in particular the ValidateUserDefinedFields parameter:
ValidateUserDefinedFields: If set to N, user defined fields will not be rejected if they are not defined in the data dictionary, or are present in messages they do not belong to.
This does not turn off validation of one particular message of course. It turns off validation for User Defined Fields in messages where they are not defined in the Data Dictionary. If the SecurityDefinition message is the only one they add fields to without prior notification then setting ValidateUserDefinedFields to N is probably good enough for you because:
In other messages, either you defined User Defined Fields in your Data Dictionary and they are validated, or you haven't and they are not validated. In the latter case because you probably won't use those fields there's no harm.
In SecurityDefinition only the User Defined Fields you put in your Data Dictionary are validated, other UDF's aren't which is what you want.
If there's still a use-case that would prohibit you from using that configuration option, please let me know in the comments section.