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件ありましたが、アプリケーションまたはクラックからヒットしませんでした
設定がありません。
私は間違った 54 = 0タグが付けられた35 = 8メッセージがFromAppまたはFromAdminに到達しない理由があるため、データ・ディクショナリの制約であるが、これは私にpublic void FromEarlyIntercept(Message msg, SessionID s)インターフェイスを実装するチャンスを与えたと思いますbad 35 = 8レポートがユーザーに報告されるという問題が解決されましたが、という良好なレポートがレポートに2回レポートされるという新たな問題が発生しました。
<field number="54" name="Side" type="CHAR">の列挙に<value enum="0" description="ERROR"/>を追加しましたが、35 = 3のメッセージで35 = 8のメッセージは拒否されません。
ああ、はい、DDの列挙型に0を加えることは、この非常に特定した問題のための最も簡単な修正です。すみません、私はそれを忘れてしまいました。 –
35 = 3は、トランスポート・レベル（別名管理者レベル）が拒否を示しています。メッセージは下位の解析レイヤーで拒否されました。つまり、アプリケーションに渡されていないような形式になっています。
通常、この種類の拒否は、エンジンが正しく解析できない、またはヘッダーフィールドが既知のセッションに解決できないような方法でメッセージが乱されたことを意味します。あなたの特定の状況が35 = jの代わりに35 = 3を引き起こしたのはちょっと驚きです。
FIX仕様をチェックして、列挙型タグの値が不明な場合に何が必要かを確認することができます。エンジンはこの場合スペックに従うとでしょうか？
応答のおかげで、間違ったタグ54 = 0の銀行35 = Dが返され、銀行は35 = 8とタグ150 = 8を使用して、54 = 0の悪意のある要求を拒否し、quickfixは54 = 0であることを銀行に返信する自動35 = 3メッセージを生成します。 ）このタグの '。銀行の35 = 8の報告書（最も重要なメッセージ）に何らかの理由があることを除いて、これはすべて良いです。 – rupweb
私は 'fromAdmin'を通過するべきだと思いましたか？ –
私はそうしましたが、35 = 8はfromappまたはfromadminを経由しません... – rupweb