quickFix - sending XML message for Fix 4.4 failing validation - quickfix

while sending a FIX 4.4 xml message msgType as n - the message fails validation (yes, we perform validation while sending fix message out) - with error.
quickfix.FieldException: Invalid MsgType, field=-1
at quickfix.DataDictionary.checkMsgType(DataDictionary.java:699)
at quickfix.DataDictionary.validate(DataDictionary.java:647)
at quickfix.DataDictionary.validate(DataDictionary.java:624)
Searched everywhere but not able to get much help.

that was the issue. Making following ammendments to the dictionary solved the issue.
<message name="XML_non_FIX" msgtype="n" msgcat="app">
<field name="XmlDataLen" required="N"/>
<field name="XmlData" required="N"/>
</message>

It looks like the standard data dictionaries for FIX 4.4 in QuickFIX don't contain message type n (msgtype="n"), you will have to add the message type yourself. Incidentally I have never seen XMLnonFIX messages before so had to look it up first!

Related

How to allow and parse FIX message with QuickFIX if Field 55 appears multiple times in FIX incoming message?

This particular broker does not provide a DataDictionary so I have to create my own based on their documentation.
This is how they send a particular message:
FIX.4.4|9=709|35=y|34=53|49=DUMMYBROKER|56=<client_ID>|52=20210211-
12:12:37.358847|55=AUD/CAD|55=AUD/CHF|55=AUD/JPY|55=AUD/NZD|55=AUD/USD|55=
CAD/CHF|55=CAD/JPY|55=CHF/JPY|55=EUR/AUD|55=EUR/CAD|55=EUR/CHF| ...
etc
How can I allow QuickFix a field to appear multiple times?
Once I recieve the message what is the best way to read it? I am using QuickFIX/n.
This would probably provide me the last symbol only:
var symbolstring = message.GetString(Tags.Symbol);
This is how the SecurityList is defined in the DataDictionary:
<message name="SecurityList" msgtype="y" msgcat="app">
<group name="NoMDEntries" required="Y">
<field name="Symbol" required="N"/>
</group>
</message>
I have tried changing "Y"/"N" in all variations, but it still cannot absorb the message properly.
This message is invalid FIX, and is simply not parseable by QuickFIX/n (or any QF engine).
A repeating group must start with a counter field which tells the receiver how many instances of that group will follow. Their message doesn't have that counter field.

How to use FIXT11 function in quickFix/n package

I have a question of using FIXT1.1 xml.
Indeed, I have successfully established the connection by using the transport dictionary (FIXT11.xml) and app dictionary (FIX50SP2.xml) ; However, I would like to do the following action manually:
Resend Request
SequenceReset
I found these two messages available in the transport dictionary:
<fix type='FIXT' major='1' minor='1' servicepack='0'>
...
<message msgcat='admin' msgtype='2' name='ResendRequest'>
<field name='BeginSeqNo' required='Y'/>
<field name='EndSeqNo' required='Y'/>
</message>
<message msgcat='admin' msgtype='4' name='SequenceReset'>
<field name='GapFillFlag' required='N'/>
<field name='NewSeqNo' required='Y'/>
</message>
but I cannot create this message class manually as I used to in FIX44. I've looked through the names spaces in QuickFix.dll but there is no such object know as QuickFix.FIXT11 in the quickfix/n package
Create message directly using QuickFix/n FIX44 object
QuickFix.FIXT11 missing in quickfix/n package
Do you have any recommendation what should I do?

Unable to receive message from WEB-SPHERE MQ queue by using Citrus Frame work xml test cases

I am trying to receive messages from web-sphere mq queue by using citrus framework by defining actions in XML-test-cases. as shown below.
<receive endpoint="jms:Queue_Name?timeout=1000">
<selector>
<element name="correlationId" value="303132333435363738393130313131323133313431353136"
</selecotr>
<message>
</message>
</receive>
I tried mentioning correlation id with hexadecimal value and ASCII value but I am unable to get the message I am getting ACTION TIME OUT EXCEPTION. I cross checked correlation id that existed in WEB-SPHERE MQ with mentioned correlation id in xml. but without selector tag I am able to get the message that was inserted first in the queue based on time.
You have to give correlation ID value like this it will work for you
<receive endpoint="jms:Queue_Name?timeout=1000">
<selector>
<element name="correlationId" value="ID:${varible consisting og hexa value}"
</selecotr>
<message>
</message>
</receive>

How to get MAM message ID of sent messages?

I am using eJabberd server (MAM enabled) with client library Strophe.js. Client app is storing fixed amount of the messages in local storage.
All the messages, that I receive from the server include elements <archived/> and <stanza-id/>, which provide server-side generated IDs:
<message
xmlns="jabber:client" to="aaa#example.net/8667085700924567016834" from="aaa#example.net">
<result
xmlns="urn:xmpp:mam:2" id="1520510373346685">
<forwarded
xmlns="urn:xmpp:forward:0">
<message
xmlns="jabber:client" xml:lang="en" to="bbb#example.net" from="aaa#example.net/60965696931000870402419" type="chat">
<archived
xmlns="urn:xmpp:mam:tmp" by="aaa#example.net" id="1520510373346685"/>
<stanza-id
xmlns="urn:xmpp:sid:0" by="aaa#example.net" id="1520510373346685"/>
<body>asdf</body>
</message>
<delay
xmlns="urn:xmpp:delay" from="example.net" stamp="2018-03-08T11:59:33.346685Z"/>
</forwarded>
</result>
</message>
I use these IDs to get fixed amount of messages on each MAM call (using RSM paging - before/after/max attributes). For example:
params = {
"before": "1520510373346685",
"max": 10,
onMessage: <some handler>,
onComplete: <some handler>,
}
this.connection.mam.query(Strophe.getBareJidFromJid(this.myJid), params);
This gets me 10 messages before the message with stanza-id 1520510373346685.
However, the messages I send inherently do not have this ID, until I send them and retrieve from MAM.
I did not find any examples on getting the currently sent message ID from the server, and the Strophe does not provide any callbacks after the message was sent from the client and received by the server.
So, the question - is there any way to get the server-generated message ID (stanza-id/archived) for the currently sent message?
Maybe my own approach is wrong - should I generate my own IDs and add it to each message from the client?
There is currently no mechanism specified besides querying the archive. One prominent idea within the XMPP community to solve this in the future is to reflect the send carbon back to the original sender, which would include a stanza-id element with the ID assigned by the archive.

quickfixn executionreport 35=8 in message log but didn't hit fromapp or crack

So we send a FIX deal message without a side, and the bank rejects with a 35=8 execution report with 150=8 reject, and text FIX Tag 54 (Side) has invalid value (0). Reason (should be either 1 or 2) and then a 35=3 reject message with Value is incorrect (out of range) for this tag. The 35=3 message is cracked but the 35=8 message never gets to fromapp.
Am I missing a setting?
35=3 indicates a transport-level (aka admin-level) reject. The message was rejected at a lower parsing layer, which means that it's so malformed that it wasn't even passed up to your application.
Usually this kind of reject means that the message was messed up in a way such that the engine can't even parse it correctly, or that the header fields can't resolve to a known session. I'm a little surprised that your particular situation triggered a 35=3 instead of a 35=j.
I suppose you could check the FIX spec to see what it mandates when an enum-type tag has an unknown value. Maybe the engine is following spec in this case?
I guess the reason why the 35=8 message with the incorrect 54=0 tag doesn't get to FromApp or FromAdmin is because of a data dictionary constraint, but this gave me a chance to implement the public void FromEarlyIntercept(Message msg, SessionID s) interface, and that has solved the problem that a bad 35=8 report is now reported back to the user... but introduced a new problem that a good report is now reported twice.
So I added <value enum="0" description="ERROR"/> to the enumeration for <field number="54" name="Side" type="CHAR"> and now the 35=8 message is not rejected by a 35=3 message.