Imported from previous forum
This is a question with regards to repeating blocks. http://fixwiki.org/fixwiki/NumInGroupDataType describes how FIX handles the scenario where NoXXX=0 and is an optional field. However the article does not mention how FIX handles the scenario where the same occurs but the tags inside the repeating block have been specified. I think it should be rejected with the session reject “Tag not defined for this message type”. The reason being when NoXXX is set to 0, it essentially means there is no repeating block. Thus the field populated inside the repeating block is taken as part of the main message; in essence it would be an invalid tag for the message. Any thoughts on this would be appreciated.
Hello Vindya,
You are correct. See the document in: http://www.fixtradingcommunity.org/pg/file/fplpo/read/30489/fix-sessionlevel-test-cases-and-expected-behaviors
Specifically,
When:
“Receive a message with repeating groups in which the “count” field value for a repeating group is incorrect”
-> then
- Send Reject (session-level) message referencing duplicate field identifier (tag number)
- Increment inbound MsgSeqNum
- Generate an “error” condition in test output
I hope this helps,
Yuval
Yuval, just a minor correction, the text says “incorrect” and not “duplicate” which had confused me. The document is valid but from 2001, i.e. 5 years before we tried to be more specific in the spec with regard to the NoXXX=0 case.
I believe my post from yesterday to respond to Vindja got lost for whatever reason. The rejection is ok but the reason should not be “Tag not defined for this message type”. That only refers to tags not defined in the FIX Repository for this message type in general, not to a specific subset supported by a given interface. The repeating group field should thus also not be seen as part of the root level (you used the term “main message”). It is defined as part of a repeating group and requires the presence of a NoXXX field which serves as a delimiter. If NoXXX=0 then there must be no repeating group fields. When we added text in FIX 5 to be clearer on this case, we only said that NoXXX=0 should not be used, i.e. it is possible but not recommended. A parser does not have to reject the message if the group is optional and no repeating group fields follow the counter field NoXXX=0.
There is an explicit reason for an incorrect counter, i.e.
MsgType(35) = 3 (Reject)
RefTagID(371) =
RefMsgType(372) =
SessionRejectReason(373) = 16 (Incorrect NumInGroup count for repeating group)
Regards,
Hanno.
Hi Yuval/ Hanno,
Thanks a lot for your replies. As mentioned , I will be going ahead with session reject = 16 as it covers the scenario I’m talking about. I.e., having an incorrect counter. Again, thanks a lot for the responses.
Hi Hanno/Yuval,
With regards to the scenarios that session reject = 16 should be used, could you let me know if the belows scenarios can also be rejected with the same? If not, with which session reject should they be rejected?
Scenario 1:Two types of repeating groups are defined in the main message. If the counter field of the first repeating group is NoXXX=0 and a repeating group field of the second repeating group follows the first repeating group counter field, how should this be rejected?
Scenario 2: Two types of repeating groups are defined in the main message. If counter field of first repeating group is NoXXX>0 and the expected no. of sub messages appear in the message but a repeating group field of the second repeating group also appears within the first repeating group, how should this be rejected?
Scenario 3: If the counter field is NoXXX=0 and a repeating group field does not follow the counter field, but appears somewhere else in the message (at root level prior to or after the counter field), how should this be rejected?
Scenario 4: If the counter field is NoXXX>0 and the expected no of repeating group fields appear in the message but an additional repeating group field appears somewhere else in the message (at root level prior to or after the counter field), how should this be rejected?
Kind Regards,
Chavindri
It seems you are trying to look at the entire message when determining the reject reason. In reality a parser is typically walking through field by field and has to take a decision right then and there when he comes across a field that does not belong there.
Scenario 1: NoXXX=0 is followed by a field that does not belong to that repeating group. However, it belongs to another repeating group and must be preceded by the respective counter field ==> 14 = “Tag specified out of required order”
Scenario 2: NoXXX=0 means that none of its repeating group fields should follow. If they do then the counter is wrong ==> 16=”Incorrect NumInGroup count for repeating group”. The parser can stop before hitting the field from the second repeating group.
Scenario 3: NoXXX=0 followed by fields outside of the repeating group is ok. The error will be detected when parsing the repeating group field “somewhere else” in the message ==> 14 = “Tag specified out of required order”
Scenario 4: NoXXX>0 followed by fields inside of the repeating group is ok. One of its fields outside is the same as scenario 3 ==> 14 = “Tag specified out of required order”
Hi Hanno,
Thanks a lot for the prompt reply. However for scenario 2, the NoXXX > 0. As a result I assume reject = 16 is not applicable. Instead, I think reject = 14 should be used here as well?
Correct, sorry for the mistake. That means all scenarios fall under the rejection reason of 14 = “Tag specified out of required order”.
Hi Hanno,
Thanks a lot for your help!
Kind Regards,
Chavindri
Hi Hanno,
Considering the fact that the scenarios I mentioned were with respect to repeating groups, when would session reject = 15 (Repeating group fields out of order) be used? From what I gather, this is how the system should behave following the NoXXX tag (regardless of if NoXXX = 0 or >0):
- If the tag is not supposed to be in the message = It will be rejected with 'Tag not defined for this message type'
- If the tag is not supposed to be in the repeating group = 'Tag specified out of required order'
- If the tag is not in the correct order inside the repeating group = 'Repeating group fields out of order'
Is the above correct?
Not quite, 14 = ‘Tag specified out of required order’ relates to ordering requirements outside of repeating groups, e.g.
- first 3 fields of the standard header
- encoded fields where the related length field must precede the actual field
One more note: a tag that does not belong into a repeating group ends the repeating group as seen from the parser. If the next field then belongs to the repeating group again, it is seen as being placed outside of the repeating group. The parser can only go field by field and not take a holistic view like a human seeing a proper list of repeating group fields containing one field that does not belong in there.
Hi Hanno,
Thanks for your previous reply. Just a question regarding the point you mentioned in the last paragraph.
If the NoXXX field is > 0 and the following field is not part of the repeating group, this means that the repeating group ends right? If this is the case what should tht rejection be? You have stated 14 is used when it concerns ordering requirments outside of repeating groups so would 14 be used here? (the reason being that the parser sees it is a field outside of the repeating group.)
In addition when would rejection 15 (Repeating groups fields out of order) be used? Is it when all the repeating group fields are present yet not in the correct order?
If NoXXX > 0 is followed by a field outside the repeating group then the repeating group ends and has zero instances. Hence, 16=”Incorrect NumInGroup count for repeating group” is appropriate when parsing the fields following NoXXX > 0.
Hi Hanno,
Thanks a lot for your reply. I was wondering if you could let me know the answer to my last quesitons from the previous post. That is, when would session reject 15 (Repeating groups fields out of order) be used? My guess is when a repeating group field is present inside a repeating block but not in the correct order among the other fields of the block.
However I know that the first field after the counter field is required but the fields after the first field can be in any order right? If that's the case, I can't think of a reason why session reject 15 would be used. Any thoughts?
Not sure if you looked at Volume 2 of the spec but there it is clearly stated for the FIX tag=value syntax that "Fields within repeating data groups must be specified in the order that the fields are specified in the message definition within the FIX specification document. ". Your parser should be based on that assumption.
Hi Hanno,
Thank you for the response. In the case mentioned above I think both session reject 14(Tag specified out of required order) or 15(Repeating group fields out of order) may be used. Hence may I ask as to what the difference is between session reject 14 and 15? Perhaps a guideline on how each session reject would be used (similar to your post on 26th March) if possible?
14 is more generic than 15 which talks about repeating groups. FIX does not explicitly define it anywhere but it is advisable to distinguish ordering conflicts outside versus inside repeating groups by using 14 (outside) versus 15 (inside). A clarification / update of the spec for tag=value is a good idea. This makes sense in the context of changes to tag=value syntax which are currently not planned. A syntax change such as an explicit ending delimiter for repeating groups would have a major impact on existing implementations and there has been little appetite in the community for any syntax changes.
That makes sense. Again, thanks a lot for your responses regarding this. Really appreciate it.