Im using quickfix to connect to fix engine and receive data. But the market data that comes in are being rejected by my app, stating that the tag appears twice.
20160624-12:44:36.770 : 8=FIX.4.49=21835=W34=2649=CfhDemoPrices52=20160624-12:44:37.79356=PrimoDEMOFIX55=GBPUSD262=PrimoApp13268=2269=0270=1.37203271=1500000290=164=20160628278=30/34-920771269=1270=1.37228271=1500000290=1278=30/34-92077610=038
20160624-12:44:36.798 : 8=FIX.4.49=12635=334=2749=PrimoDEMOFIX52=20160624-12:44:36.79456=CfhDemoPrices45=2658=Tag appears more than once371=278372=W373=1310=139
After lot of analysis, we found that the tag 278(MDEntryID) is not included in NoMDEntries in fix44. I want to include the field in that group in my quickfix and rebuild it. Any idea how to do that? Or please let me know your suggestions to solve this problem.
You've modified your DD incorrectly, because you don't know how repeating groups work.
This is the standard FIX44 DD for your message. I've added some comments to indicate tag numbers.
<message name="MarketDataSnapshotFullRefresh" msgtype="W" msgcat="app">
<field name="MDReqID" required="N" />
<component name="Instrument" required="Y" />
<group name="NoUnderlyings" required="N">
<component name="UnderlyingInstrument" required="N" />
</group>
<group name="NoLegs" required="N">
<component name="InstrumentLeg" required="N" />
</group>
<field name="FinancialStatus" required="N" />
<field name="CorporateAction" required="N" />
<field name="NetChgPrevDay" required="N" />
<group name="NoMDEntries" required="Y"> <!-- 268 -->
<field name="MDEntryType" required="Y" /> <!-- 269 -->
<field name="MDEntryPx" required="N" /> <!-- 270 -->
<field name="Currency" required="N" />
<field name="MDEntrySize" required="N" /> <!-- 271 -->
<field name="MDEntryDate" required="N" />
... and so on ...
Fields inside of repeating groups must be in the prescribed order. When QF processes a group, if it encounters an unexpected field then it assumes the group is over.
Your DD does not match the order that your sender is sending, so your engine is malfunctioning.
Your sender is sending fields in this order:
268-> (group 1) 269 270 271 290 64 278
(group 2) 269 270 271 290 278
(The above is directly from your rejected message.)
Your DD, however, is expecting 269 278 271 270. As soon as it hits 278, it ends the group and weird things start happening.
Revert your DD back to the default, then add 64/SettlDate and 278/MDEntryID to the end of the NoMDEntries component. Given the evidence you've provided, it's clear that your counterparty has added those fields to the end of the group.
Surely these are not the only modifications that your counterparty has made to the DD. GET THEIR DOCUMENTATION AND READ IT. Then modify your DD accordingly.