FORTS: OnTradeTransaction() のリターンコード

Sergey Chalyshev 2015.11.26 17:56 #81

Михаил:

あなたは誤解している。

オーダーステータス PLASEDを20秒間送信しなかったのは、サーバーのせいです。

サーバーの開発者のことです。

Andrey Khatimlianskii 2015.11.26 23:31 #82

Михаил:

ターミナルでORDER_STATE_STARTED の注文ステータスが「ハング」する明らかなエラーがあります。

最終的に整理されたのでしょうか？

今回の注文について、取引所では具体的に どのように説明されたのでしょうか。早く配置されたのでしょうか？もしそうなら、サーバーやMT端末にエラーがあり、ステータスが更新されなかったことが明らかです。そして、これを持ってサービスデスクに行くことができます。

MQ Alexander 2015.11.27 08:39 #83

サービスデスクのマイケルとこの問題について話し合った結果。

どうやら、受注システムの仕組みや配置の意味を説明する必要があるようです。

だから

1.リクエストを送信する

buy limit 5.00 SNGR-3.16 at 35501

2.MT5サーバーはこのリクエスト（パラメータ、プレトレードなど）をチェックします。問題がある場合は、リクエストに応じたエラーコードが表示されます。

その後、新しい注文を作成してチケット（#24025010）を渡し、注文に「開始」状態が設定されます。オーダーチケットは、取引所に注文を出す瞬間に、MT5 の注文識別子と取引所の注文をリンクさせるために使用されます。
端末は「開始」状態の新規注文の追加に関するトランザクションを送信し、これはOnTradeTransactionで追跡可能です。

3.次に、取引サーバー（ゲートウェイ経由）が取引所に注文を送信します。リクエストが正常に送信された場合、あなたのリクエストはレスポンスを受け取ります。これは
「リクエストが送信されたこと」を意味します。取引所からどれくらいの時間で返事が来るか事前に分からないため、結果は非同期に実行されることになります。

この時点では、日誌の記録を見ることができます。

2015.11.26 10:48:23.726 Trades  'xxxxxx': buy limit 5.00 SNGR-3.16 at 35501 placed for execution in 7 ms

4.しばらくすると、取引所が注文をシステムに設定し、識別子を付与した後、ゲートウェイとMT5サーバーに通知します。
取引所が注文を設定した場合、MT5の注文に注文識別子が書き込まれ、注文状況が⇒発注と変化します。
何らかの理由で取引所が注文を拒否した場合、その注文は削除されます。

OnTradeTransaction に入ってくるトランザクションを記録するだけで、これらすべてを追跡することができます。

================================================================================

何が起こるか

1.注文依頼をする（ステップ1～3を参照）。

2. 注文がすでにMT5にあり、まだ取引所に存在しない瞬間に、この注文を取り消す注文を出す。
しかし、この注文は初期状態（開始）であり、それに対する注文の有無が定義されていないため、注文の取り下げ拒否（
）を受けてしまいます。

EAのロジックに適切なチェック・修正を加える必要があります。

Z.U.もうひとつは、1秒以内ということです。

2015.11.26 10:48:24.583 Trades  'xxxxxx': failed cancel order #24025010 buy limit 5.00 SNGR-3.16 at 35501.00000 [Invalid request]

(さらに20秒間)注文が行われたはずです。これは対処中で、潜在的な問題の1つが見つかりました。

削除済み 2015.11.27 08:45 #84

MQ Alexander:

解説をありがとうございましたぜひ、ドキュメントに追加してください

Yury Kirillov 2015.11.27 12:54 #85

MQ Alexander:

サービスデスクでマイケルとの問題について議論した結果。

どうやら、受注システムの仕組みや配置の意味を説明する必要があるようです。

だから

1.リクエストを送信する

2.MT5サーバーはこのリクエスト（パラメータ、プレトレードなど）をチェックします。問題がある場合は、リクエストに応じたエラーコードが表示されます。

その後、新しい注文を作成してチケット（#24025010）を渡し、注文に「開始」状態が設定されます。オーダーチケットは、取引所に注文を出す瞬間に、MT5 の注文識別子と取引所の注文をリンクさせるために使用されます。
端末は「開始」状態の新規注文の追加に関するトランザクションを送信し、これはOnTradeTransactionで追跡可能です。

3.次に、取引サーバー（ゲートウェイ経由）が取引所に注文を送信します。リクエストが正常に送信された場合、あなたのリクエストはレスポンスを受け取ります。これは
「リクエストが送信されたこと」を意味します。取引所からどれくらいの時間で返事が来るか事前に分からないため、結果は非同期に実行されることになります。

この時点では、日誌の記録を見ることができます。

4.しばらくすると、取引所が注文をシステムに設定し、識別子を付与した後、ゲートウェイとMT5サーバーに通知します。
取引所が注文を設定した場合、MT5の注文に注文識別子が書き込まれ、注文状況が⇒発注と変化します。
何らかの理由で取引所が注文を拒否した場合、その注文は削除されます。

OnTradeTransaction に入ってくるトランザクションを記録するだけで、これらすべてを追跡することができます。

================================================================================

何が起こるか

1.注文依頼をする（ステップ1～3を参照）。

そして、すでにMT5に注文が入っていて、取引所に注文がない瞬間に、この注文を取り消す注文を出すのです。
しかし、この注文は初期状態（開始）であり、それに対する注文の有無が定義されていないため、注文の取り下げ拒否（
）を受けてしまいます。

EAのロジックに適切なチェック・修正を加える必要があります。

Z.U.もうひとつは、1秒以内に

(さらに20秒間)注文があるはずだ、対処している、潜在的な問題の一つを見つけた-それを解決しよう。

注文を「開始した」という状態が、どの時点で「配置した」という状態に変わるのか、まだ分かっていない。これは、説明のポイント3に従って起こるのですか、ポイント4に従って起こるのですか、それともポイント3と4の両方が起こるのですか？

Andrey Khatimlianskii 2015.11.27 15:49 #86

Yury Kirillov:
どの時点で注文の「開始」状態が「配置」状態に変わるかは不明です。これは、説明のポイント3に従って起こるのですか、ポイント4に従って起こるのですか、それともポイント3と4の両方が起こるのですか？

MQアレキサンダー：

4.
取引所が注文を設定した場合、注文識別子が MT5 の注文に書き込まれ、注文の状態が開始 => 配置に変わります。

Andrey Khatimlianskii 2015.11.27 15:51 #87

MQ Alexander:

3.その後、取引サーバー（ゲートウェイ経由）が取引所にリクエストを送信し、リクエストが正常に送信された場合、リクエストに応答する、ということです。

"リクエストが送信された "ということは、その作業結果は非同期に実行されることになります。なぜなら、交換の応答が何時なのか事前に分からないからです。

したがって、この時点では、ログエントリにあるように

2015.11.26 10:48:23.726 Trades  'xxxxxx': buy limit 5.00 SNGR-3.16 at 35501 placed for execution in 7 ms

4.しばらくすると、取引所が注文をシステムに設定し、識別子を付与した後、ゲートウェイとMT5サーバーに通知します。
取引所が注文を設定した場合、MT5での注文に識別子が書き込まれ、注文状況が ⇒発注と変化します。

ログにはすでに注文が行われたと書かれていますが、実際にはまだ注文の状態は変化していません。

注文が実際に取引所に受理されていないため、「paced」ではなく「sent」のように書くべきかもしれませんね。

Mikhail Filimonov 2015.11.27 17:45 #88

次のようなことが判明しました。

注文に対して何らかのアクションを実行する前（または後）。

その都度、状態を「確認」する必要があります（違ったら訂正してください）。

enum ENUM_ORD_REAL_STATE
{
  ORD_NOT_SPECIFIED         = 0, //Состояние ордера не определено
  ORD_NONE_CANCELED         = 1, //Ордера нет, отменён пользователем
  ORD_NONE_PARTIAL_CANCELED = 2, //Ордера нет, исполнился частично (не был залит вторым объёмом)
  ORD_NONE_PARTIAL          = 3, //Ордера нет, исполнился частично
  ORD_NONE_EXPIRED          = 4, //Ордера нет, удалён по сроку
  ORD_NONE_FILLED           = 5, //Ордера нет, исполнился полностью
  ORD_NONE_REJECTED         = 6, //Ордера нет, отклонён брокером(биржей)
  ORD_BUSY                  = 7, //Ордер находится в переходном состоянии
  ORD_EXIST                 = 8, //Ордер выставлен на биржу, возможны действия над ним
  ORD_EXIST_PARTIAL         = 9  //Ордер выставлен на биржу, частично исполнился, возможны действия над ним
};
//
ENUM_ORD_REAL_STATE CheckOrderState( const ulong ticket )
{
  if ( ticket > 0 )
  {
    if ( HistoryOrderSelect( ticket ) ) //Только не существующий ордер может находится в истории
    {
      ENUM_ORDER_STATE ord_state = ENUM_ORDER_STATE( HistoryOrderGetInteger( ticket, ORDER_STATE ) );
      double init_volume = HistoryOrderGetDouble( ticket, ORDER_VOLUME_INITIAL );
      double cur_volume = HistoryOrderGetDouble( ticket, ORDER_VOLUME_CURRENT );
//---      
      switch( ord_state )
      {
                                                           
        case ORDER_STATE_CANCELED:       if ( init_volume == init_volume )
                                         {
                                           return( ORD_NONE_CANCELED );
                                         }
                                         else
                                         {
                                           return( ORD_NONE_PARTIAL_CANCELED );
                                         }  
                                         break;
                                         
        case ORDER_STATE_PARTIAL:        return( ORD_NONE_PARTIAL );
                                         break;
                                         
        case ORDER_STATE_EXPIRED:        return( ORD_NONE_EXPIRED );
                                         break;
                                                                              
        case ORDER_STATE_FILLED:         return( ORD_NONE_FILLED );
                                         break;
                                         
        case ORDER_STATE_REJECTED:       return( ORD_NONE_REJECTED );
                                         break;   
 
       
      }
    }
    else
    if ( OrderSelect( ticket ) ) 
    {
      ENUM_ORDER_STATE ord_state = ENUM_ORDER_STATE( OrderGetInteger( ORDER_STATE ) );
//---      
      switch( ord_state )
      {
        case ORDER_STATE_STARTED:
        case ORDER_STATE_REQUEST_ADD:
        case ORDER_STATE_REQUEST_MODIFY:
        case ORDER_STATE_REQUEST_CANCEL: return( ORD_BUSY );
                                         break; 
 
        case ORDER_STATE_PARTIAL:        return( ORD_EXIST_PARTIAL );
                                         break;
                                          
        case ORDER_STATE_PLACED:         return( ORD_EXIST );
                                         break;
      }
    }
  }
  return( ORD_NOT_SPECIFIED );
}

Sergey Chalyshev 2015.11.27 18:53 #89

Михаил:

次のようなことが判明しました。

注文に対して何らかのアクションを実行する前（または後）。

その都度、状態を「確認」する必要があります（見落としがあれば訂正してください）。

間違っている。

HistoryOrderSelect( ticket ) に注目すると、HistoryOrderGetInteger(),HistoryOrderGetDouble() を適用する必要があります。

Mikhail Filimonov 2015.11.27 19:07 #90

Sergey Chalyshev:

不正確です。

HistoryOrderSelect( ticket ) を見ると、HistoryOrderGetInteger(),HistoryOrderGetDouble() を適用する必要があることがわかります。

そうですね、誤植です :)

ありがとうございます、修正しました...

FORTS: OnTradeTransaction() のリターンコード - ページ 9