Virtual Order Manager zum Verwalten von Ordern innerhalb der positionszentrischen Umgebung von MetaTrader 5

Paul | 8 März, 2016

1. Einleitung

Die vielleicht größte Veränderung beim Übergang von MetaTrader 4 zu MetaTrader 5 ist die Verwaltung offener Handelsaktivitäten als Positionen. Pro Symbol kann zu jedem Zeitpunkt nur eine Position offen sein und die Größe dieser Position passt sich jedes Mal, wenn Order durch den Broker verarbeitet werden, nach oben oder unten an. Dies entspricht der in den USA eingeführten FIFO-Regel NFA 2-43(b) und passt auch zum Handelsmodus vieler anderer Einheiten wie Termingeschäften, Gütern und Differenzkontrakten.

Ein klares Beispiel für diesen Unterschied wäre, wenn zwei EAs, die auf demselben Symbol laufen, Order in unterschiedlichen Richtungen ausgeben.  Das ist eine typische Situation, wenn zwei EAs auf unterschiedlichen Timeframes arbeiten, beispielsweise einer, der eine Scalper-Strategie verfolgt, und ein zweiter, der Trends folgt.  In MetaTrader 4 würde die Liste offener Order offene Kauf- und Verkaufsorder mit einer genutzten Marge gleich Null anzeigen. In MetaTrader 5 wäre überhaupt keine Position offen.

Sieht man sich den Code des EA selbst an, funktionieren Funktionen wie die in MQL4 häufig genutzte OpenOrders() oder ähnliche Varianten nicht wie erwartet, wenn sie nach MQL5 migriert werden.

int OpenOrders()  // MetaTrader 4 code to count total open orders for this EA
{
  int nOpenOrders=0;
  for (int i=OrdersTotal()-1; i>=0; i--)
  {
    OrderSelect(i,SELECT_BY_POS,MODE_TRADES);
    if (OrderMagicNumber()==magic)
      if (OrderType()==OP_BUY || OrderType()==OP_SELL)
        if (OrderSymbol()==Symbol())
          nOpenOrders++;
  }
  return(nOpenOrders);
}

Damit stellt die positionszentrische Umgebung von MetaTrader 5 den Programmierer, der sich an den Orderverarbeitungsansatz von MetaTrader 4 gewöhnt hat, vor ungewohnte Herausforderungen. Was in MetaTrader 4 einfache Funktionen für die Orderverwaltung waren, wird in MetaTrader 5 komplexer, da mehrere Order zu einer Position verschmolzen werden können, beispielsweise durch mehrere EAs, die mit einem Symbol handeln, oder mehrere Order aus einem EA auf einem Symbol.

2. Möglichkeiten der Arbeit mit Positionen in MetaTrader 5  

Es gibt eine Reihe von Möglichkeiten zum Verwalten der positionszentrischen Umgebung in MetaTrader 5, abhängig von der Komplexität der Handelsstrategien.

Zuerst halten wir fest, dass der Umgang von MetaTrader 5 mit Pending Orders ähnlich ist wie in MetaTrader 4, also könnte ein MQL5-Code, der ausschließlich für Pending Orders geschrieben wurde, eine relativ einfache Migration eines MQL4-Codes sein.

2.1 Einfacher EA; ein EA pro Symbol pro Instrument

Die einfachste Herangehensweise ist die Beschränkung des Handels mit einem Instrument auf einen simplen EA pro Symbol.  "Einfacher EA" bedeutet in diesem Fall einen, der nur eine Order auf einmal herausgibt. Das ist eine häufig genutzte Methode, schließt jedoch Strategien wie "Pyramiding" und "Grid Trading" aus.  Einfache EAs können in MQL5 ähnlich geschrieben werden wie in MQL4, möglicherweise mithilfe des unter include\trade\trade.mqh bereitgestellten Bibliothek-Wrappers CTrade.

2.2 Komplexer EA; ein EA pro Symbol pro Instrument

Bei komplexen EAs, beispielsweise solchen, die eine Strategie wie Pyramiding oder Grid Trading verfolgen, die mehr als eine offene Order pro Symbol benötigen können, kann ein relativ einfacher Order-Verfolgungscode, der zum EA hinzugefügt wird, bereits ausreichen, um die Strategie zu verwalten.  Das ist nur möglich, wenn der EA niemals Positionen mit einem anderen EA, der das gleiche Symbol handelt, teilt.

2.3 Mehr als ein EA beliebiger Art pro Symbol pro Instrument

Dies stellt die komplexesten Anforderungen an Handel und Code und ist der Grund für die Entwicklung der Virtual-Order-Manager-Bibliothek (VOM).  Diese Bibliothek ist darauf ausgelegt, die Entwicklung eines robusten EA-Codes, der zu keinen Konflikten mit anderen EAs führt, wesentlich zu erleichtern.

Im Rest dieses Beitrags wird die Virtual-Order-Manager-Bibliothek im Detail beschrieben.

3. Architekturziele, Vorteile und Nachteile des Virtual Order Manager 

Der VOM hat vier wichtige Architekturziele:

1. Klarheit: Das Verhalten von EAs, die korrekt mithilfe der VOM-Handelsfunktionen geschrieben wurden, ist von anderen EA-Aktivitäten isoliert.
2. Robustheit: eleganter Umgang mit ungewöhnlichen Ereignissen wie Fehlern, Unterbrechungen der Kommunikation zwischen Client und Server und unvollständiger Ausführung von Ordern.
3. Benutzerfreundlichkeit: Bereitstellung gut dokumentierter und einfacher Handelsfunktionen.
4. Möglichkeit der Nutzung im Strategietester

Diese Ziele werden wie folgt umgesetzt:

• Nutzung virtueller offener Order, Pending Orders, Stoplosses und Takeprofits.  "Virtuell" bedeutet in diesem Zusammenhang, dass ihr Status im Client Terminal unabhängig von Positionen auf dem Server erhalten bleibt.  Für diese Order werden im Terminal ähnlich wie für Positionen horizontale Linien gezeichnet.
• Ein schützender serverbasierter Stopp in einer gewissen Entfernung von den virtuellen Stopps für den Schutz vor Katastrophen nach Ausfällen des Computers oder der Internetverbindung.

Mit der VOM-Herangehensweise kann ein MQL5-EA-Programmierer:

• EAs auf "orderzentrische" Weise schreiben, d. h. ähnlich wie in MetaTrader 4.
• Umsetzen, was in der MetaTrader-Community von vielen als "Risikohandel" bezeichnet wird oder, genauer ausgedrückt, gleichzeitige Handelsaktivitäten in umgekehrter Richtung gegen ein einzelnes Symbol. 
• Weitere fortgeschrittene Handelsstrategien wie Grid-Trading-, Pyramiding- und Geldverwaltungsansätze relativ einfach schreiben.
• Stopps und Pending Orders dichter als das Mindest-Stoppniveau einrichten.

Es sollte auch erwähnt werden, dass ein Nebeneffekt der VOM-Herangehensweise ist, dass die virtuellen Stoploss, Takeprofit und Pending Order von Natur aus "unsichtbar" sind, d. h. nicht auf dem Broker-Server gesehen werden können.  Manche betrachten das Verstecken von Stoploss als notwendig, um zu verhindern, dass der Broker Stopps jagt.

Der VOM hat auch Nachteile.  Die Höhe des Risikokapitals wird aufgrund der Möglichkeit, sich während eines Ausfalls des PCs oder der Internetverbindung auf weiter entfernte Server-Schutzstopps verlassen zu können, erhöht.  Auch kann die Abweichung in Momenten hoher Volatilität, beispielsweise Nachrichtenereignissen, beim Erreichen eines virtuellen Pending Order, Stoploss oder Takeprofit viel höher sein als beim jeweiligen Server-Äquivalent.  Die Auswirkungen dieser Nachteile können minimiert werden, wenn VOM-EAs über einen hochzuverlässigen virtuellen Desktop mit kurzer Ping-Zeit zum Broker-Server gehandelt werden.

4. Der VOM in der Praxis – ein einfacher EA

Bevor wir fortfahren, ist es wichtig zu wissen, wie ein VOM-EA geschrieben werden kann.  Wir schreiben einen einfachen MA-Überquerungs-EA und beginnen mit dem Vorlage-EA aus dem Standardpaket.  Wir nutzen den fraktalen gleitenden Mittelwert (Fractal Moving Average), der sinnlose Handelsvorgänge bei Seitwärtsmärkten – ein klassisches Problem bei MA-Überquerungsstrategien – reduzieren kann. Es muss betont werden, dass dieser EA als einfaches Beispiel dient und nicht für die Verwendung im realen Handel empfohlen wird. Der Backtest ist zwar profitabel, aber die geringe Menge an Handelsvorgängen bedeutet, dass das Ergebnis nicht von statistischer Bedeutung ist.

Der EA liegt unter experts\Virtual Order Manager\VOM EAs ab.

//+------------------------------------------------------------------+
//|                                           FraMA Cross EA VOM.mq5 |
//+------------------------------------------------------------------+
#property copyright "Paul Hampton-Smith"
#property link      "http://paulsfxrandomwalk.blogspot.com"
#property version   "1.00"

// this is the only include required.  It points to the parent folder
#include "..\VirtualOrderManager.mqh"

input double   Lots=0.1;
input int      Fast_MA_Period=2;
input int      Slow_MA_Period=58;
/* 
Because the broker is 3/5 digit, stoplosses and takeprofits should be x10.  
It seems likely that all brokers offering MetaTrader 5 will be 3/5 digit brokers, 
but if this turns out to be incorrect it will not be a major task to add 
digit size detection. */
input int      Stop_Loss=5000;
input int      Take_Profit=0;
/*
We can also change the level of logging.  LOG_VERBOSE is the most prolific 
log level.  Once an EA has been fully debugged the level can be reduced to 
LOG_MAJOR.  Log files are written under the files\EAlogs folder and are 
automatically deleted after 30 days.  */
input ENUM_LOG_LEVEL Log_Level=LOG_VERBOSE;

// The following global variables will store the handles and values for the MAs 
double g_FastFrAMA[];
double g_SlowFrAMA[];
int g_hFastFrAMA;
int g_hSlowFrAMA;
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
   LogFile.LogLevel(Log_Level);

// Need to include this line in all EAs using CVirtualOrderManager  
   VOM.Initialise();
   Comment(VOM.m_OpenOrders.SummaryList());

   g_hFastFrAMA = iFrAMA(_Symbol,_Period,Fast_MA_Period,0,PRICE_CLOSE);
   g_hSlowFrAMA = iFrAMA(_Symbol,_Period,Slow_MA_Period,0,PRICE_CLOSE);
   ArraySetAsSeries(g_FastFrAMA,true);
   ArraySetAsSeries(g_SlowFrAMA,true);

   return(0);
  }
//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
  {
// Need to include this line in all EAs using CVirtualOrderManager  
   VOM.OnTick();
   Comment(VOM.m_OpenOrders.SummaryList());

// We now obtain copies of the most recent two FrAMA values in the 
// g_FastFrAMA and  g_SlowFrAMA arrays.  
   if(CopyBuffer(g_hFastFrAMA,0,Shift,2,g_FastFrAMA)!=2) || 
      CopyBuffer(g_hSlowFrAMA,0,Shift,2,g_SlowFrAMA)!=2)
     {
      Print("Not enough history loaded");
      return;
     }

// And now we detect a cross of the fast FrAMA over the slow FrAMA,
// close any opposite orders and Buy a single new one
   if(g_FastFrAMA[0]>g_SlowFrAMA[0] && g_FastFrAMA[1]<=g_SlowFrAMA[1])
     {
      VOM.CloseAllOrders(_Symbol,VIRTUAL_ORDER_TYPE_SELL);
      if(VOM.OpenedOrdersInSameBar()<1 && VOM.OpenOrders()==0)
        {
         VOM.Buy(_Symbol,Lots,Stop_Loss,Take_Profit);
        }
     }

// Opposite for Sell
   if(g_FastFrAMA[0]<g_SlowFrAMA[0] && g_FastFrAMA[1]>=g_SlowFrAMA[1])
     {
      VOM.CloseAllOrders(_Symbol,VIRTUAL_ORDER_TYPE_BUY);
      if(VOM.OpenedOrdersInSameBar()<1 && VOM.OpenOrders()==0)
        {
         VOM.Sell(_Symbol,Lots,Stop_Loss,Take_Profit);
        }
     }
  }
//+------------------------------------------------------------------+

Dank des Strategietesters kann er nun durch Backtesting geprüft werden, siehe Abbildung 1:

Abbildung 1. Backtest des EA FrAMA Cross

Der Protokollabschnitt ist in Abbildung 2 zu sehen:

Abbildung 2. Journaleintrag des Strategietests

 

5. VOM-Struktur

Abbildung 4 zeigt, wie mehrere VOM-EAs konfiguriert werden:

Abbildung 3. Mehrere VOM-EAs

Abbildung 4 zeigt die Hauptkomponenten aus der Betrachtung des VOM von innen heraus:

Abbildung 4. Interne VOM-Struktur

 Erklärung der Elemente von Abbildung 4:

• Configuration – der VOM nutzt CConfig zum Speichern aller wichtigen Konfigurationseinträge an einem Ort im globalen Objekt Config. Um den Zugriff einfacher zu gestalten, sind die Variablen des Objekts public und es gibt keine Funktionen zum Abrufen/Festlegen.
• Global variables – das sind Variablen, auf die in MQL5 Funktionen wie GlobalVariableGet() zugreifen. Der VOM nutzt die globalen Variablen, um:
• Die Ticketnummer der letzten virtuellen Order mithilfe von CGlobalVariable zu erfassen und zu erhöhen;
• Eine Liste aller virtuellen Stoplosses zu pflegen, damit die Serverstopps für den Katastrophenschutz erhalten bleiben können.
• Open trades and history files – das sind permanente Dateien auf der Festplatte, die durch CVirtualOrderArrays gespeichert werden, um sicherzustellen, dass der Orderstatus beim Neustart wiederhergestellt werden kann.  Ein Paar dieser Dateien wird für jeden EA, der den VOM nutzt, unter Files\VOM erstellt und abgelegt.  Die Klasse CVirtualOrder beginnt ihren Lebenszyklus im Array VOM.m_OpenOrders und wird an das Array VOM.m_OrderHistory übertragen, wenn die Order geschlossen oder gelöscht wird.
• Activity and debug log – die meisten Codes jeder beliebigen Komplexität benötigen die Fähigkeit, Aktivitäten zu protokollieren. Diese Funktion ist in der Klasse CLog gekapselt. Damit können Protokolle auf vier verschiedenen Detail- und Wichtigkeitsebenen erfasst werden. Die Klasse beinhaltet außerdem eine automatische Bereinigung alter Protokolldateien, um Speicherplatz zu sparen.

Expert Advisors, die VOM nutzen, interagieren mit der Bibliothek, wie in Abbildung 5 dargestellt:

 Abbildung 5. Interaktion des EA mit der VOM-Bibliothek

6. Näheres zum Katastrophenschutz-Stoploss

Virtuelle Stopps waren in EAs in MetaTrader 4 ziemlich weit verbreitet.  Wenn ein Stoploss-Niveau nur auf dem Client-Ende erhalten wird, ist das Austrittsniveau für einen Handelsvorgang für den Broker unsichtbar. Diese Strategie wird oft in dem Glauben genutzt, dass einige Broker Stopps jagen.  Für sich allein erhöhen virtuelle Stopps das Handelsrisiko deutlich, da Broker und Client immer miteinander kommunizieren müssen, damit der Stopp ausgelöst werden kann. 

Der VOM kontrolliert dieses Risiko, indem er einen serverbasierten Stopp mit einem konfigurierbaren Abstand zum engsten virtuellen Stopp erhält.  Dies wird als Katastrophenschutz-Stoploss (disaster protection stoploss, DPSL) bezeichnet, weil er normalerweise nur ausgelöst wird, wenn die Verbindung zwischen Broker und Client für eine bestimmte Zeit unterbrochen wird, beispielsweise bei einem Ausfall der Internetverbindung oder des PCs.  Da virtuelle Order geöffnet und geschlossen und auf dem Server in eine Position umgewandelt werden, kann die Erhaltung des DPSL auf dem korrekten Niveau ein wenig komplex sein, wie es durch die folgende Sequenz illustriert wird.

Aktion der virtuellen Order	Eröffnungs- preis	Virtueller SL	Position auf Server	Stoploss auf Server	Kommentar
0.1 lots BUY #1	2,00000	1,99000	0.1 lots BUY	1,98500	DPSL ist 50 Pips unter virtuellem SL #1
0.1 lots BUY #2	2,00000	1,99500	0.2 lots BUY	1,99000	Virtuelle Order #2 hat einen engeren SL, deshalb wird DPSL auf 50 Pips unter dem virtuellen SL #2 verengt
Close #2			0.1 lots BUY	1,98500	Zurück zu loserem DPSL
0.1 lots SELL #3	2,00000	2,00500	keine	keine	Virtuelle Order #1 und #3 heben sich auf dem Server gegenseitig auf
Close #1			0.1 lots SELL	2,01000	Virtuelle Order #3 bleibt offen, DPSL ist nun 50 Pips über dem virtuellen SL #3