3

I have a fairly simple quickfix/n setup to the ICE test platform but the engine at this end is rejecting trade capture reports (ae) - stating that field 828 (TrdType) has an incorrect data format for the value.

It looks like the exchange is sending data (an 'S') that quickfix is not expecting. Everything is supposed to be 44.. could this be a version issue or is the exchange just misbehaving?

initiator.config

ValidateFieldsOutOfOrder=N
ValidateFieldsHaveValues=N
ValidateUserDefinedFields=N
DataDictionary=../../spec/FIX44.xml

Subscription code

public TradeCaptureReportRequest ReportRequestSubscribe()
{
    TradeCaptureReportRequest req = new TradeCaptureReportRequest(new TradeRequestID("187345347856"), new TradeRequestType(TradeRequestType.ALL_TRADES));
    req.SubscriptionRequestType = new SubscriptionRequestType(SubscriptionRequestType.SNAPSHOT_PLUS_UPDATES);
    return req;
}

Calling code

if (_initiator.IsLoggedOn)
{
    MessageFactory mFact = new MessageFactory();
    fixApp.sendMessage(mFact.ReportRequestSubscribe());
}

AD and AQ messages

8=FIX.4.49=9435=AD34=249=1006350=testsubid52=20140210-11:40:39.44556=ICE263=1568=187345347856569=010=231

8=FIX.4.49=10035=AQ34=249=ICE52=20140210-11:40:39.60056=1006357=testsubid568=187345347856569=0749=0750=010=042

AE and Reject message

20140210-16:14:03.693 : 8=FIX.4.49=71235=AE49=ICE34=352=20140210-16:14:03.68156=1006357=testsubid571=386487=0856=0828=S150=F17=5325010939=2570=N55=279100548=BRZ SMZ0014_OMCE000000413211121422=8461=OCXXXX202=4.139403=90855287916=20141201917=2014123132=1.031=2.639018=19022=175=2014021060=20140210-16:14:00.5189413=0552=154=137=5325010911=53250109453=11448=scadv-block447=D452=11448=36 South Capital Advisors LLP447=D452=13448=8449447=D452=56448=PVM Oil Associates Ltd-Broker447=D452=1448=10063447=D452=61448=ice_hd447=D452=12448=8449447=D452=35448=8745447=D452=4448=38023447=D452=51448=JP Morgan Securities LLC447=D452=60448=W447=D452=54376=1010000042303dab89ac4149928cb31a46d4c76b0210=060
20140210-16:14:03.855 : 8=FIX.4.49=12535=334=349=1006350=testsubid52=20140210-16:14:03.85356=ICE45=358=Incorrect data format for value371=828372=AE373=610=104

20140210-16:14:03.847 : Could not convert field: Could not convert string to int (S): The first character must be a digit or a minus sign
20140210-16:14:03.853 : Message 3 Rejected: Incorrect data format for value (Field=828)

and the quickfix component raises a real error: 

A first chance exception of type 'QuickFix.FieldConvertError' occurred in QuickFix.dll
A first chance exception of type 'QuickFix.IncorrectDataFormat' occurred in QuickFix.dll
Steve
  • 105
  • 8
  • That reject message looks incomplete. Is that *really* from a real log, or is it from a print statement? Because if it's from a print statement it's probably corrupted. Restore your DD and try again. Your log should have the exact messages that ICE is sending, it should be fairly simple to figure this out. – Grant Birchmeier Feb 10 '14 at 15:31
  • Ahh, my bad. You are completely correct - the messages printed here are from a debug logger. The complete log shows that the exchange is sending an 'S' as the value for 828 which is outside of the allowable values. Many thanks for pointing me at the real logs. – Steve Feb 10 '14 at 16:16
  • The "S" is valid. See my updated answer. – Grant Birchmeier Feb 10 '14 at 16:28

2 Answers2

1

Look at your reject message (which I've added field separators into for readability):

8=FIX.4.4|9=125|35=3|34=4|49=10063|50=testsubid|52=20140210-16:05:44.231|56=ICE|45=4|58=Incorrect data format for value|371=828|372=AE|373=6|10=101

See fields 371 and 372. Those fields tell you that field 828 is wrong in an AE message. Field 45 tells you that the rejected AE message has seq number=4.

From there you should be able to figure out the bad field that is being sent to you.

As to your ICE-specific issue:

Check ICE's latest spec (2.0.34 at time of this answer). "S" is indeed a valid value. You'll need to update your DD with all valid values, or perhaps just change the field to a string (or char) and get rid of the enumeration list altogether. If you delete the enumeration list, QF/n will accept any value of the correct type (e.g. string or char).

Grant Birchmeier
  • 17,809
  • 11
  • 63
  • 98
  • Much appreciated, I was stupid to forego the logs for the less complete custom logging. An 'S' is being sent as the trade type which does not match the FIX specification. – Steve Feb 10 '14 at 16:25
  • Read my answer again, I just updated it. "S" is actually valid, for ICE. – Grant Birchmeier Feb 10 '14 at 16:27
  • Many thanks! Nice to see that the FIX 'specification' is used more as a rough guideline :) – Steve Feb 10 '14 at 16:51
  • Yeah, the default message and field set is at best a suggestion. I've never seen a counterparty that didn't screw with it at least a little. You really have to check each firm's specs; assume nothing. – Grant Birchmeier Feb 10 '14 at 17:05
0

UseDataDictionary - Tells session whether or not to expect a data dictionary. You should always use a DataDictionary if you are using repeating groups.

The website says you should use a data dictonary and you are playing against the rules. The error you are getting currently isn't the area to be concerned about at present.

field 828 (TrdType) has an incorrect data format for the value

Albeit this is the real issue you should be looking into.

DumbCoder
  • 5,696
  • 3
  • 29
  • 40
  • Point taken :) I was just trying to remove the dictionary so I could inspect the AE message and try to work out what (invalid) value was being sent in the 828 field. If I can get at the value then I can add it to the data dictionary. My best bet may be to raise a ticket with the exchange and see which TrdType values they are sending outside of the 0-10 defined in the 4.4 spec. – Steve Feb 10 '14 at 15:05