0

I was hoping someone can shed some light on how the Quickfixn engine handles outgoing FIX messages... I have an outgoing connection set up, and I'm getting heartbeats. When I generate an outgoing message however, it gets rejected because it says that tag 58 is invalid for this message type... (35=AE) ... Normally, if this was an inbound connection, I could just modify the Data Dictionary and everything would be fine... but seeing as how this is an outgoing connection, plus I have my UseDataDictionary property set to 'N' ... what does the quickfix engine use to validate the outgoing message? Can something be changed to allow the engine to pass the message ? Or is the only resolution not to include this tag in my outgoing message?

Any help on this matter would be greatly appreciated.

Edit-

The message is getting rejected by the quickfix engine. The message that I'm constructing and the respective reject message are:

8=FIX.4.4 9=400 35=AE 34=38 49=XXX 52=20130528-23:11:04.040 56=YYY 31=1.3022 32=1000000.00 39=0 55=EUR/USD 58=ABCD 60=20130528-22:34:52.000 64=20130531 75=20130529 570=N 571=ABCD 5495=0 5971=1302200.00 552=1 54=2 37=ABCD 453=3 448=LP1-DBAB 447=D 452=17 448=XXX 447=D 452=1 448=XXX 447=D 452=19 15=EUR 120=USD 10=082

8=FIX.4.4 9=130 35=3 34=38 49=YYY 52=20130528-23:11:04.283 56=XXX 45=38 58=Tag not defined for this message type 371=58 372=AE 373=2 10=033

I've seen incoming messages get rejected by the quickfix engine because the data dictionary didn't have the correct specs for the message... I thought this might be the same thing but the outgoing connection doesn't seem to use the data dictionary.

Franco Trombetta
  • 207
  • 1
  • 5
  • 14
  • Please explain what you mean when you say "it gets rejected". Is it being rejected by your counterparty? Is it throwing an exception locally? Please paste error messages or exceptions. – Grant Birchmeier May 30 '13 at 00:55
  • Hi, please could you attach the log and add other details? And also the piece of code you use to create the message AE. – stexcec May 30 '13 at 07:23
  • Edited the main post... I can't really include how we construct your message but it basically is just leveraging the QuickFix dlls to create a 4.4 trade capture report message and populating different values. – Franco Trombetta May 30 '13 at 13:05

2 Answers2

1

Your FIX library does not reject a message. The message is sent to the counter-party instead, which then rejects your message as invalid upon receiving and validating it. And the reason for that is because tag 58, if present, must be a part of “NoSides repeating group (tag 552), which in your case it is not, making the message ill-formed. What you have to do is send a "logically" correct message. I recommend you refer to the appropriate FIX protocol specification for a reference on how to construct a correct message.

  • Thanks for the info... I don't think tag 58 is normally present in TradeCaptureReports... I may be wrong. If the message is in fact getting rejected by the Counterparty and not my FIX engine, then they need to modify their data dictionary to include Tag 58 as a valid tag in the TradeCaptureReport message. I'm looking through some references to see any places where tag 58 might appear in a TCR but haven't found any. – Franco Trombetta May 30 '13 at 13:37
  • @FrancoTrombetta: No, it is your message that is invalid. And it is you who should fix it in your code. It doesn't matter if tag 58 is normally present or not, it is an optional field. So if it is, it must be a part of NoSides repeating group, which in your case is not. –  May 30 '13 at 13:40
  • Hm, okay. Thanks. Its just a bit strange because we send this same message to another counterparty and it works fine. I will move it into the no sides repeating group and see how it works out. Thanks for the information. I appreciate you getting back to me. – Franco Trombetta May 30 '13 at 13:43
  • @FrancoTrombetta: It is up to a venue to decide whether to reject a message if it has unexpected fields in it or not. Many don't. I have based my answer on official spec since you don't provide any details about who you actually send a message to. Just look at the spec, tag 58 is inside a repeating group. For example, here — http://btobits.com/fixopaedia/fixdic50/message_Trade_Capture_Report_AE_.html –  May 30 '13 at 13:47
  • I'm using the 4.4 protocol and I see it... Thanks for the info. I'll make the change and see how it works out. Thanks again. – Franco Trombetta May 30 '13 at 13:57
  • All venues are different. In practice, venues usually make customizations to the FIX spec, adding and deleting fields, and in QF you have to adjust your DataDictionary accordingly. You need to supply a venue-specific DD. If you are connecting to two venues in one app, then you need to supply a venue-specific DD for each session. – Grant Birchmeier May 30 '13 at 17:45
  • @GrantBirchmeier: You are right, except that Data Dictionary won't magically move field 58 inside a repeating group. It must be done explicitly. –  May 30 '13 at 17:50
  • @VladLazarenko - I wasn't contradicting you; I was just stating the broader point. – Grant Birchmeier May 30 '13 at 17:55
0

Vlad's answer is correct, but I want to alert you to one other danger in your question.

I have my UseDataDictionary property set to 'N'

I am 90% sure you don't want to do this. Whatever you think you're gaining by using =N is probably based on a misunderstanding of something.

Without a DD, you can't read messages with repeating groups, because the engine won't know what fields go in what group.

In practice, every venue uses repeating groups. Therefore, you'll need to set UseDataDictionary=Y and you need to specify an xml file with DataDictionary=<file>.

The only reason we allow =N in QF/n is to be consistent with QF/C++ and QF/j.

Grant Birchmeier
  • 17,809
  • 11
  • 63
  • 98
  • 1
    Yup, Vlad's answer was correct. I implemented the changes and my issue has been resolved. As far as UseDataDictionary = N - we have different connections to various counter parties and the messages don't usually change and don't come with repeating groups so it hasn't been a problem (This particular config was done prior to me working on it). Thanks though, it's definitely something I'm going to change. – Franco Trombetta May 30 '13 at 20:25