Details
-
Type:
Other
-
Status:
Closed
-
Priority:
Default
-
Resolution: Fixed
-
Affects Version/s: 1.4.0
-
Fix Version/s: None
-
Component/s: Documentation
-
Labels:None
Description
The documentation for ValidateFieldsOutOfOrder reads:
"If set to N, fields that are out of order (i.e. body fields in the header, or header fields in the body) will not be rejected. Useful for connecting to systems which do not properly order fields."
Search of the source code reveals that it has to do with mis-ordered repeating group fields. It does nothing about header fields in the body or vice versa. (Verified by experiment.)
"If set to N, fields that are out of order (i.e. body fields in the header, or header fields in the body) will not be rejected. Useful for connecting to systems which do not properly order fields."
Search of the source code reveals that it has to do with mis-ordered repeating group fields. It does nothing about header fields in the body or vice versa. (Verified by experiment.)
On further investigation, it seems in an earlier version we were able tolerate header tags in the body. See also QFJ-477.
Also found that the behaviour around duplicate fields has changed, probably at about the same time. There is currently no way to relax it. (Believe it or not, we have seen problem gateways in production that produce dups.)
The attached patch makes ValidateFieldsOutOfOrder allow header tags in the body.
In addition, it add a new setting "ValidateDuplicateFields". Default is true.
Finally, I noticed that the DataDictionary.copyFrom method does not copy the AllowUnknownMsgFields setting. Now it does.
There may still be some holes out there. For example, suppose you turn off validation of user defined fields, and someone throws a repeating group at you that isn't in your data dictionary. I suspect this will show as a duplicate field. (Unless you use the new setting.)