Virtual Order Manager zum Verwalten von Ordern innerhalb der positionszentrischen Umgebung von MetaTrader 5
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:
- Klarheit: Das Verhalten von EAs, die korrekt mithilfe der VOM-Handelsfunktionen geschrieben wurden, ist von anderen EA-Aktivitäten isoliert.
- Robustheit: eleganter Umgang mit ungewöhnlichen Ereignissen wie Fehlern, Unterbrechungen der Kommunikation zwischen Client und Server und unvollständiger Ausführung von Ordern.
- Benutzerfreundlichkeit: Bereitstellung gut dokumentierter und einfacher Handelsfunktionen.
- 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 |
7. Testen des Virtual Order Manager
Ein Projekt dieser Größe braucht viel Zeit, um ordentlich getestet zu werden. Deshalb habe ich den EA VirtualOrderManagerTester.mq5 geschrieben, um die Erstellung, Anpassung, Löschung und Schließung von virtuellen Ordern mit Befehlsbuttons auf dem Diagramm zu ermöglichen.
Abbildung 6 zeigt eine virtuelle buy-Order bei 0.1 Posten im M5-Fenster und eine virtuelle buy-Order bei weiteren 0.1 Posten im H4-Fenster gegen EURUSD (siehe Kommentarzeilen). Der Serverstatus zeigt korrekt eine Position bei 0.2 gekauften Posten. Da die entstehende Position lang ist, kann der Katastrophenschutz-Stoploss unter dem engeren Pip-Stopp bei 20.0 gefunden werden.
Abbildung 6. Zwei EAs einigen sich auf eine Richtung
Abbildung 7 zeigt zwei Test-EAs mit entgegengesetzten virtuellen Ordern und ohne offene Position beim Broker:
Abbildung 7. Zwei EAs mit entgegengesetzten virtuellen Ordern und ohne offene Position beim Broker
8. Eine sehr einfache Darstellung aller durch den VOM geöffneten Order
Der VOM-EA kann nur seine eigenen Order sehen, deshalb habe ich einen sehr einfachen EA geschrieben, der alle offenen Order von allen VOMs sammelt. Die Darstellung ist sehr einfach und wenn es die Zeit erlaubt, kann sicherlich eine viel bessere Version geschrieben werden, vielleicht mit Befehlsbuttons für Änderungs-, Löschungs- oder Schließungsaktionen nach Bedarf für jede Order. Der EA ist im Standardpaket als VOM_OrderDisplay.mq5 enthalten.
9. Fazit
Zum Verfassungszeitpunkt dieses Beitrags befindet sich der VOM-Code genauso wie MetaTrader 5 selbst in der Betaphase und es wird sich mit der Zeit herausstellen, ob das VOM-Konzept beliebt wird oder nur als interessante Möglichkeit der MQL5-Programmierung betrachtet wird.
Blicken wir zurück auf die Architekturziele aus Abschnitt 3 und sehen uns an, was wir erreicht haben:
- Klarheit: Das Verhalten von EAs, die korrekt mithilfe der VOM-Handelsfunktionen geschrieben wurden, ist von anderen EA-Aktivitäten isoliert.
- Ergebnis – ja, die VOM-Herangehensweise hat dieses Ziel erreicht.
- Robustheit: eleganter Umgang mit ungewöhnlichen Ereignissen wie Fehlern, Unterbrechungen der Kommunikation zwischen Client und Server und unvollständiger Ausführung von Ordern.
- Ergebnis – eine gewisse Robustheit ist zu erkennen, doch anhand von realen Handelssituationen können möglicherweise Verbesserungsbedarfe erkannt werden.
- Benutzerfreundlichkeit: Bereitstellung gut dokumentierter und einfacher Handelsfunktionen.
- Ergebnis – wie Sie im Standard-Dateipaket sehen werden, ist eine .chm-Hilfsdatei beigefügt.
- Möglichkeit der Nutzung im Strategietester
- Ergebnis – erste Tests im kürzlich veröffentlichten Strategietester deuten darauf hin, dass die Backtest-Ergebnisse des VOM korrekt sind, obwohl der VOM den Test erheblich verlangsamt. Vermutlich muss noch etwas getan werden, um den Datendurchsatz zu erhöhen.
Eine Reihe von zukünftigen Verbesserungen wäre wünschenswert:
- Wie bei jeder komplexen Softwareentwicklung ist es wahrscheinlich, dass einige Bugs im Code verbleiben.
- Mit jeder neuen Beta-Veröffentlichung von MetaTrader 5 muss der VOM möglicherweise angepasst werden, um seine Kompatibilität zu erhalten.
- Funktionen VomGetLastError() und VomErrorDescription().
- Möglichkeit, die Konfiguration aus einer Datei auszulesen.
- Trailing von Stopps verschiedener Typen.
10. Dateien im gezippten Standardpaket
Das VOM-Paket besteht aus einer Reihe von .mqh-Dateien, die im Ordner Experts\Virtual Order Manager installiert werden sollten:
- ChartObjectsTradeLines.mqh – CEntryPriceLine, CStopLossLine, CTakeProfitLine
- StringUtilities.mqh – globale enum-Deskriptoren wie ErrorDescription()
- Log.mqh – CLog
- GlobalVirtualStopList.mqh – CGlobalVirtualStopList
- SimpleChartObject.mqh – CButton, CLabel and CEdit
- VirtualOrder.mqh – CVirtualOrder
- GlobalVariable.mqh – CGlobalVariable
- VirtualOrderArray.mqh – CVirtualOrderArray
- VirtualOrderManager.mqh – CVirtualOrderManager
- VirtualOrderManagerConfig.mqh – CConfig
- VirtualOrderManagerEnums.mqh – diverse für den VOM definierte enums
- VOM_manual.mqh – diese Seite des Handbuchs
- VOM_doc.chm***
Unter Experts\Virtual Order Manager\VOM EAs sind ebenso fünf EA-Dateien im mq5-Format enthalten:
- VOM_template_EA.mq5 – kopieren Sie diese Datei, um Ihre eigenen EAs zu erstellen, um speichern Sie sie in Experts\Virtual Order Manager\VOM EAs
- VirtualOrderManagerTester.mq5
- Support_Resistance_EA_VOM.mq5
- FrAMA_Cross_EA_VOM.mq5
- VOM_OrderDisplay.mq5
***Beachten Sie, dass die Datei VOM_doc.chm möglicherweise entsperrt werden muss:
Übersetzt aus dem Englischen von MetaQuotes Ltd.
Originalartikel: https://www.mql5.com/en/articles/88
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.