紹介
FIX APIはセッションベースの通信を使用します。セッションは、通信を開始する当事者であるイニシエーター（クライアント）と、イニシエーターからの接続要求を受け取る当事者であるアクセプター（サーバー）との間の通信として定義されます。
サーバーはログオンメッセージを使用してクライアントのリクエストを検証します。
FIXセッションプロトコル
各セッションは、クライアントとcTraderエンティティの間で双方向のメッセージを維持します。セッションには複数の物理的な接続が含まれることがあります。セッションはシーケンス番号を使用して維持されます。
単一のセッション内の新しいメッセージはすべて1（1）から始まる一意のシーケンス番号を受け取ります。両当事者は、秩序ある通信を維持するためにシーケンス番号に依存しています。欠落したメッセージは、両当事者の合意に基づいて再送信されます。
典型的なセッションフロー：
- クライアントがLOGONメッセージでセッションを開始
- サーバーとのアプリケーションメッセージの交換
- LOGOUTメッセージで終了
cTrader FIXプロトコルメッセージカテゴリー
FIXプロトコルで定義されているように、cTrader FIXサーバーは2つの異なるデータレベルを使用しています：システムとアプリケーション。
これは必要なワークフローをサポートするために必要な最小限のメッセージセットであり、ビジネスニーズやFIX標準の進化に伴い時間とともに変更されることがあります。
システム（管理）メッセージ
- ハートビート（クライアント ↔ cTrader） – 2つの当事者間の通信リンクを確認するために使用されます
- テストリクエスト（クライアント ↔ cTrader） – 通信リンクの健全性をテストするために使用されます
- ログオン（クライアント → cTrader） – クライアント認証メッセージ
- ログアウト（クライアント → cTrader） – セッションの正常終了
- 再送信リクエスト（クライアント ↔ cTrader） – 特定のアプリケーションメッセージを再送信するリクエスト
- 拒否（クライアント ↔ cTrader） – セッションレベルの検証失敗
- シーケンスリセット（クライアント ↔ cTrader） – 通信の問題が発生した場合、欠落したメッセージを回復するか、シーケンスをリセットして欠落したメッセージを無視する
アプリケーションメッセージ
- マーケットデータリクエスト（クライアント → cTrader） – 一般的なマーケットデータのリクエスト
- マーケットデータ増分リフレッシュ（クライアント ← cTrader） – マーケットデータリクエストメッセージへの応答
- 新規注文シングル（クライアント → cTrader） – ブローカーに対する注文を電子的に送信するために使用されます
- 実行報告（クライアント ← cTrader） – 確認、充填、および非依頼の変更など、注文ステータス情報をFIXクライアントに送信するために使用されます
- ビジネスメッセージ拒否（クライアント ← cTrader） – 非セッションの理由でFIXクライアントのリクエストを拒否するために使用されます
FIXメッセージ構造
このセクションでは、FIX APIメッセージの構成方法について説明します。このセクションでは、FIXメッセージ形式についても説明し、FIXタグと値のペアの概念を理解するのに役立ちます。
各メッセージは3つの部分を含む必要があります：
- ヘッダー：各管理メッセージまたはアプリケーションメッセージの前には標準ヘッダーが付いています。ヘッダーはメッセージタイプ、FIXバージョン、メッセージの長さ、宛先、シーケンス番号、起源、および時間を識別します。
- 本文：メッセージ本文の内容は、ヘッダーで定義されたメッセージタイプによって指定されます。
- フッター：各メッセージ（管理メッセージまたはアプリケーションメッセージ）の最後には標準フッターがあります。フッターはメッセージを区切るために使用され、CheckSum <10>値の3桁の文字表現を含みます。
FIXメッセージ形式
FIXメッセージはフィールドの集合です。各フィールドは{tag}={Value}形式のタグ-値ペアとしてフォーマットされます。例えば、54=2は注文タイプが売りであることを意味します。
タグ
- FIXは事前定義されたタグを使用します
- 各タグは特定のフィールドを表します
- 各タグには事前に定義された番号が割り当てられます
- cTrader FIX仕様書はフィールドと対応するタグ番号のリストを提供します
値
- 値はタグに割り当てられた値を表します
- 値は次のデータタイプのいずれかにのみすることができます：整数、浮動小数点、文字、時間、日付、データ、文字列
cTrader FIX API内のすべてのメッセージは”8=FIX.x.y”で始まり、ここでx.yはFIXプロトコルのバージョンです。すべてのメッセージの最後には”10=xyz”フィールドがあり、xyzはメッセージ内のすべてのバイナリ値の合計を表すチェックサムです。
チェックサムは、受信者がメッセージの一部が欠落しているかどうかを知ることができるようにすることで、送信の問題、特にパケットロスを識別するのに役立ちます。
Symbol(55)タグがcTrader/cServerへのFIXメッセージで使用される場合、そのFIXシンボルIDを指定する必要があります。その値はブローカーごとに異なる場合があります。そのブローカーのcTraderアプリケーションのシンボル情報ウィンドウからFIXシンボルIDフィールドを見つけることができます。
メッセージ例
8=FIX.4.4|9=126|35=A|34=1|49=theBroker.12345|57=TRADE|50=any_string|52=20170117-08:03:04|56=CSERVER|98=0|108=30|553=12345|554=passw0rd!|10=131|
| タグ # | タグ名 | 値 | 説明 |
|---|---|---|---|
| 8 | BeginString | 4.4 | FIXバージョン |
| 9 | BodyLength | 102 | メッセージ本文の長さは102文字 |
| 35 | MsgType | A | メッセージタイプはログオン |
| 34 | MsgSeqNum | 1 | メッセージシーケンス番号は1 |
| 49 | SenderCompI | D | broker.1047 トレーディングパーティのIDで、”broker”はcTraderによって提供される一意のBrokerUIDであり、”1047″はトレーディングアカウントの数値識別子です |
| 57 | TargetSubID | TRADE | 追加のセッション識別子。可能な値は：”QUOTE”,”TRADE”。 |
| 50 | SenderSubID | QUOTE | 特定のメッセージ送信者を識別するために使用される値。 |
| 52 | SendingTime | 20131129- 15:40:10.276 | メッセージ送信時間は2013年11月29日（YYYYMMDD）15:40:10.276 |
| 56 | TargetCompID | CSERVER | メッセージターゲットはCSERVER。cTrader FIX API内での唯一の有効な値です。 |
| 98 | EncryptMethod | 0 | 現在、有効な値は”0″（ゼロ）= NONE_OTHER（暗号化は使用されていません） |
| 108 | HeartBtInt | 30 | ハートビート間隔（秒）。値は’config.properties’ファイル（クライアント側）で’SERVER.POLLING.INTERVAL’として設定されます。30秒がデフォルトの間隔値です。HeartBtIntが0に設定されている場合、ハートビートメッセージは必要ありません。 |
| 553 | Username | 1047 | 数値ユーザーID |
| 554 | Password | MyPassword1 | ユーザーパスワード |
| 10 | Checksum | 000 | チェックサムの計算方法は次の通りです：メッセージのすべてのバイトをチェックサムフィールド自体を含まずに合計し、それを256で割った余りを3桁の数字に変換して”0″を付ける。 |
