[QFJ-620] Problem validating Fix 4.4. TradeCaptureReport 35='AE' Created: 19/Jul/11 Updated: 14/Oct/16 Resolved: 14/Oct/16 |
|
Status: | Closed |
Project: | QuickFIX/J |
Component/s: | Message Generation |
Affects Version/s: | 1.5.0 |
Fix Version/s: | None |
Type: | Bug | Priority: | Default |
Reporter: | Alwyn Donnell | Assignee: | Unassigned |
Resolution: | Cannot Reproduce | Votes: | 0 |
Labels: | None | ||
Environment: |
linux - RHEL 5.0 |
Issue Links: |
|
Description |
Trying to construct TradeCaptureReport using QuickFixJ 1.5.0 There seems to be a problem validating the fields for the TrdCapRptSideGrp repeating group . In my message I have defined the following fields for that particular repeating group i.e. only those that are mandatory: When I attempt to send it I get the following reject message : I know it is a mandatory field , but I tried removing it and tried sending it again to get the following error : 8=FIX.4.4<SOH>9=123<SOH>35=3<SOH>34=56<SOH>49=BLP<SOH>52=20110718-11:19:22.707<SOH>56=CMF<SOH>45=56<SOH>58=Tag not defined for this message type<SOH>371=54<SOH>372=AE<SOH>373=2<SOH>10=201 I also know that tag 54 is mandatory for this message, but I removed it anyway and of course got this error which makes sense : It looks like there is a problem around the validation of this repeating group. Tags 54 and 37 are manadatory for this message type, so should'nt be reporting |
Comments |
Comment by Michael Daloia [ 25/May/12 ] |
I too am having the same issue. I send a TradeCaptureReport message (35=AE) to my simulator built with quickfix 1.13.3 Here is the TCR message being sent: The msg is being rejected by my quickfix simulator My FIX xml file for TradeCaptureReport is below. It has OrderID defined in the NoSides repeating group. It's as if the NoSides repeating groups isn't being handled properly by quickfix: <message name='TradeCaptureReport' msgcat='app' msgtype='AE'> Here are my quickfix settings: UseDataDictionary=Y |
Comment by Christoph John [ 14/Oct/16 ] |
Had a similar case like this today. The bottom line was that there was an unknown/user-defined field at the end of the NoSides repeating group that caused the error. So the data dictionary just needed that adaption. Will close this issue unless there is a complete test which proves otherwise. |