5

Need a quick help. I am a newbie in QuickFixJ. I have a FIX message in a txt file. I need to convert that into FIX50SP2 format. I am enclosing the code snippet.

String fixMsg = "1128=99=25535=X49=CME34=47134052=20100318-03:21:11.36475=20120904268=2279=122=848=336683=607400107=ESU2269=1270=140575271=152273=121014000336=2346=521023=1279=122=848=336683=607401107=ESU2269=1270=140600271=206273=121014000336=2346=681023=210=159";

System.out.println("FixMsg String:"+fixMsg);
Message FIXMessage = new Message();
DataDictionary dd = new DataDictionary("FIX50SP2.xml");
FIXMessage.fromString(fixMsg, dd, false);
System.out.println("FIXMessage Output:" + FIXMessage.toString()); // Print message after parsing
MsgType msgType = new MsgType();
System.out.println(FIXMessage.getField(msgType));

Here is the output:

FixMsg String:1128=99=15835=X49=CME34=47164052=2012090312102051175=20120904268=1279=122=848=336683=607745107=ESU2269=1270=140575271=123273=121020000336=2346=501023=110=205
FIXMessage Output:9=6135=X34=47164049=CME52=2012090312102051175=20120904268=110=117
quickfix.FieldNotFound: Field [35] was not found in message.
    at quickfix.FieldMap.getField(FieldMap.java:216)
    at quickfix.FieldMap.getFieldInternal(FieldMap.java:353)
    at quickfix.FieldMap.getField(FieldMap.java:349)
    at MainApp.main(MainApp.java:52)

I want to extract MsgType field (field 35). Could you please tell me where I am wrong? The thing I have observed is that after parsing to FIX50SP2 format, the convert FIX message is missing many data element (for details see the output)

Thanks

Grant Birchmeier
  • 17,809
  • 11
  • 63
  • 98
Rivu
  • 177
  • 2
  • 12
  • 1
    The answer below seems like the right thing to do, the reason why it didnt work is because the MessageType is held in the header. so you need to do message.getHeader().isSetField(new MsgType()) – robthewolf Aug 07 '13 at 13:30
  • 2
    You know that `fixMsg` is not a valid FIX message, right? There's no BeginString field (should start with "8=FIXT.1.1" for FIX5). And are the field separators in there? Can't tell if they're not there or if it's just a bad paste. – Grant Birchmeier Aug 07 '13 at 14:57
  • Here is another sample FIX message: 1128=99=34835=X49=CME34=47128052=2012090312101416975=20120904268=3279=122=848=1011383=64621107=ESZ2269=0270=139825271=13273=121014000336=2346=31023=1279=122=848=336683=607316107=ESU2269=1270=140550271=10273=121014000336=2346=21023=1279=122=848=336683=607317107=ESU2269=1270=140725271=382273=121014000336=2346=681023=810=203 It STARTS with 1128. Can anyone, parse this string to Valid FIX message. I need to extract Field 268 ie noMDEntries. will be very much helpful if you can provide a sample code. – Rivu Aug 07 '13 at 15:28
  • 2
    That is another **invalid** sample FIX message. It sounds like you don't actually know much about FIX itself. – Grant Birchmeier Aug 07 '13 at 20:16
  • @GrantBirchmeier, Before making such comments please ensure that you are saying it correctly. This Fix message was extracted from CME group. They provide FIX data. For more details related to their FIX data format, google "CME group Fix message technical specification". Another thing, don't make false responses. I really appreciate the effort that everyone has put in. – Rivu Aug 08 '13 at 06:14
  • Maybe I have been overly blunt, but I stand by my point. These are *not* valid FIX messages, and the QF/j engine won't parse them. All FIX messages *must* start with `8=FIX.n.n`. If these are the strings that CME is giving you, then they have altered them somehow. (I think I've actually seen this format before, in a question on the QF mailing list, and the asker got this string from some other interface, not from a FIX connection.) If you'd like me to look at a CME tech spec, please give a URL. You can see the standard FIX message format at [FIXimate](http://fixprotocol.org/FIXimate3.0/). – Grant Birchmeier Aug 08 '13 at 14:09
  • 1
    Furthermore, are you preserving the field separators in your test program? They are unprintable characters (0x00), so I don't know if it's a bad paste or if a misunderstanding. All FIX messages should look something like `8=FIXT.1.1|9=110|35=A|34=1|49=TW|...` where each `|` is actually the NUL field separator character (which every text editor seems to display differently). – Grant Birchmeier Aug 08 '13 at 14:15
  • For those who are dealing with CME group FIX data, please ensure to read their documentation carefully. They are using some custom FIX tags – Rivu Nov 18 '13 at 10:21

4 Answers4

2

Like others mentioned the MsgType is an header field and you get it by using the following

String msgType = null;
if(FIXMessage.getHeader().isSetField(MsgType.FIELD)) {
    msgType = FIXMessage.getHeader().getString(MsgType.FIELD);
}
System.out.println("MsgType is " + msgType);`

The reason you are missing many data element after parsing is, probably your message have some custom tags(like tag 2346), which is not defined in your data dictionary(FIXSP02.xml). hence the parsing of those tags failed and missing in the output.

To fix this, get the data dictionary from the party that is sending you the message and use it to parse the message

Kalatta
  • 466
  • 5
  • 2
  • Hi Kalatta, I can't find any custom tags. I guess you misread it. its tag no 346 whose value is 2. Tag 346 stands for NumberOfOrders. Thanks a lot for your precious time. I appreciate it buddy. Can anyone help me to get the DataElements in the output FIX Message? – Rivu Aug 07 '13 at 16:47
1

I'm not familiar with FIX messages and QuickFixJ, but glancing at the Javadoc, it seems like you should use the identifyType method :

String fixMsg = "1128=99=25535=X49=CME34=47134052=20100318-03:21:11.36475=20120904268=2279=122=848=336683=607400107=ESU2269=1270=140575271=152273=121014000336=2346=521023=1279=122=848=336683=607401107=ESU2269=1270=140600271=206273=121014000336=2346=681023=210=159";
MsgType msgType = Message.identifyType(fixMsg);
Miklos Aubert
  • 4,405
  • 2
  • 24
  • 33
  • thanks for the initial level help.. my ultimate aim to extract Field 268 ie "noMDEntries" from the message and group the repeating DATA Elements. – Rivu Aug 07 '13 at 15:34
0

You may find FixB framework useful as it deals well with non-standard use cases of FIX.

As in your case, to extract only data you are interested in, you need to define a class that will represent this data and to bind it to FIX using annotations. E.g.:

@FixBlock
public class MDEntry {    
    @FixField(tag=269) public int    entryType; // you could define an enum type for it as well
    @FixField(tag=278) public String entryId;
    @FixField(tag=55)  public String symbol;
}
...

FixFieldExtractor fixExtractor = new NativeFixFieldExtractor();
List<MDEntry> mdEntries = fixExtractor.getGroups(fixMsg, List.class, 268, FixMetaScanner.scanClass(MDEntry.class))

In more common cases, FixSerializer interface should be used, but it requires a message with MsgType(35) tag and a class annotated with @FixMessage(type="...") accordingly. E.g.:

@FixMessage(type="X")
public class MarketData {
    @FixGroup(tag=268) public List<MDEntry> entries;
}
...

FixMetaDictionary fixMetaDictionary = FixMetaScanner.scanClassesIn("my.fix.classes.package");
FixSerializer fixSerializer = new NativeFixSerializer("FIX.5.0.SP2", fixMetaDictionary);
MarketData marketData = fixSerializer.deserialize(fixMsg);

I hope you will find it useful.

Vlad
  • 1,723
  • 12
  • 16
0

If you need just a MsgTyp, you're sure the message is correct and you do not need any other field from the message, then I would recommend extracting MsgType from string using regexp.

e.g.: \u000135=(\w+)\u0001

It is MUCH FASTER than parsing (and validating) a string via QuickFix.

Konstantin Pavlov
  • 956
  • 1
  • 10
  • 24