we are using Data dictionary in initiator and acceptor both side is Same, also the message send from initiator to acceptor and vice versa is same,
message when we send message from initiator to acceptor it is received by acceptor and processed.but when the same message is sent from acceptor to initiator,
the initiator sends reject (35=3) to acceptor.
Can anyone assit on this issue
Please refer below logs
8=FIXT.1.1|9=192|35=3|34=3|49=XXXX|52=20200826-11:10:55.716|56=XXX|45=3|58=Tag appears more than once, field=448|371=448|372=CCR|373=13|1408=01.005.00|1603=XXXX|1604=XXXX|10=181|
Looks like a non-standard message you are sending. “CCR” is not valid for RefMsgType(372), i.e. user defined message types need to start with “U”. Can you also post the message that has been rejected? Then I can tell you on which side the software is behaving correctly
There does not seem to be any obvious error, i.e. the initiator software seems to have an issue and should not reject the message. The error message seems to be misleading, maybe 448 is identified in RefTagID(371) because it sometimes uses the “#” sign. But that is just a guess, i.e. you will have to investigate your software to find the real issue.
The only other issue I see is your UDF 11092 which references XML code but the rest seems to be just a string of field values without delimiters. There is no length field preceding 11092 that would allow the parser to know exactly when the field value ends. Standard FIX fields like SecurityXML(1185) have a length field (SecurityXMLLen(1184)) to mitigast parsing issues.
I noted two things in terms of FIX compliance:
MsgType(35) value “CCR” is invalid, should be “UCCR”
Usage of tags 10,000 - 19,999 is only valid for internal communication (not sure if initiator and acceptor are inside your company, then it is ok)
Like @hanno.klein says, this sort of technical question is best directed at your FIX engine development community.
The style of the message you’re getting looks very much like those generated by QuickFIX. I’d suggest contacting the community list for QuickFIX, QuickFIX/J , QuickFIX/N or Quickfix/Go as appropriate.
You will definitely need to use both a Transport and App dictionary to parse messages with repeating groups - given your message has custom fields you may also need to tweak the dictionary.
Providing 11092 doesn’t contain the SOH delimeter character the engine can probably handle the content without length indication as text (FIX standard type: String, rather than FIX standard type: data or XMLData). (It’s not well-formed XML obviously but that’s a side issue).
The most likely issue is the presence of a non-standard tag in the 8th repeating group. This will probably cause the parser to think that that the series of groups has ended and then be ‘surprised’ by the presence of 448=OTC. You can fix this most easily by adding 11059 to the definition of the group in the dictionary.
Obviously as there are 9 groups you might expect it to handle this better and include the tag but alas I think it does not right now.
