quickfixn executionreport 35 = 8消息日誌，但沒有擊中fromapp或裂紋

所以我們沒有側發送FIX成交信息，以及銀行與150 = 8拒絕35 = 8執行報告拒絕和文本FIX Tag 54 (Side) has invalid value (0). Reason (should be either 1 or 2)然後與Value is incorrect (out of range) for this tag一起發送35 = 3拒絕消息。 35 = 3消息被破解，但35 = 8消息永遠不會到達fromapp。quickfixn executionreport 35 = 8消息日誌，但沒有擊中fromapp或裂紋

我失去了一個環境？

來源

2017-10-05 rupweb

我認爲應該通過'fromAdmin'？ –

我也是這樣，但是35 = 8沒有通過fromapp或fromadmin ... – rupweb

我猜測爲什麼與不正確 54 = 0標籤35 = 8消息沒有得到FromApp或FromAdmin的原因是因爲數據字典的約束，但是這給了我一個機會來實現public void FromEarlyIntercept(Message msg, SessionID s)接口，並且已經解決了現在將報告返回給用戶的問題...但是引入了新問題，即現在報告了兩次報告。

所以我加了<value enum="0" description="ERROR"/>枚舉<field number="54" name="Side" type="CHAR">現在35 = 8消息不被35 = 3消息拒絕。

來源

2017-10-06 10:32:39 rupweb

哦，是的，給DD的enum加0是解決這個非常具體問題的最簡單的方法。對不起，我忘了提示。 –

35 = 3表示傳輸級別（又名管理員級別）拒絕。該消息在較低的解析層被拒絕，這意味着它的格式不正確甚至不會傳遞給您的應用程序。

一般這種拒絕意味着該消息被在某種程度上弄亂使得發動機甚至不能正確地解析它，或者說，報頭字段無法解析爲一個已知的會話。我有點驚訝你的特定情況觸發了35 = 3而不是35 = j。

我想你可以檢查FIX規格，看看它的任務時枚舉型標籤具有未知值。也許發動機是繼在這種情況下，規範呢？

來源

2017-10-05 20:44:12

感謝您的回覆，我們向銀行發送了一個35 = D的錯誤標籤54 = 0，所以銀行以35 = 8並且標記150 = 8以拒絕具有54 = 0的不良交易請求，quickfix向其產生自動35 = 3消息以發送回銀行，以告訴他們54 = 0是「值不正確（超出範圍）爲這個標籤'。所有這些都很好，除了某些原因外，銀行的35 = 8報告（最重要的信息）沒有被破解。 – rupweb

quickfixn executionreport 35 = 8消息日誌，但沒有擊中fromapp或裂紋

回答

相關問題