セキュリティ定義要求メッセージが送信されると、セキュリティのステータスを自動的に送信する Venue 1 があります。しかし、Venue 2 は SecurityStatusRequest メッセージを使用します。
では、Venue 2 のユーザーが Venue 1 のセキュリティ ステータスを要求する問題をどのように解決すればよいでしょうか?
セキュリティ定義要求メッセージが送信されると、セキュリティのステータスを自動的に送信する Venue 1 があります。しかし、Venue 2 は SecurityStatusRequest メッセージを使用します。
では、Venue 2 のユーザーが Venue 1 のセキュリティ ステータスを要求する問題をどのように解決すればよいでしょうか?
この質問は、FIX が実際にどのように機能するかについての誤解を示唆しています。これがそれを解決するための私の最善の試みです。
会場が FIX インターフェイスを提供すると、ルールを設定できます。クライアント アプリがあり、それをある会場のサーバーに接続する場合は、その会場のメッセージ定義と構成に合わせてアプリを調整する必要があります。他の会場の定義や構成は関係ありません。
クライアントを 2 つの異なる会場に接続する場合、それらのインターフェイスに共通性があるとは想定できません。両方とも同じ FIX バージョン (例: 両方とも FIX 4.4) であっても、違いがあります。各会場のドキュメントを熟読し、それに応じてクライアントのさまざまな接続ロジックを実装する必要があります。
したがって、あなたの例では、Venue 2 のユーザーは、ステータスを取得したい場合は SecurityStatusRequest メッセージを送信する必要があり、それを回避する方法はありません。実装方法を決定する必要があります。会場 2 がルールを設定し、会場 1 がどのように処理するかは気にしません。
可能な実装: 証券のリストを受け取ったら、会場 2 にいる場合は、それをループして、それぞれの SSR を送信します。2 つの会場ハンドラーがロジックを共有する場合は、それをif(current_venue==venue2)
-type ブロックに配置します。