New article: Universal Expert Advisor - the Event Model and Trading Strategy Prototype (Part 2)

 

New article Universal Expert Advisor: the Event Model and Trading Strategy Prototype (Part 2) has been published at mql5.com:

This article continues the series of publications on a universal Expert Advisor model. This part describes in detail the original event model based on centralized data processing, and considers the structure of the CStrategy base class of the engine.

The article contains further description of the universal trading engine CStrategy. In the first article Universal Expert Advisor: Trading Modes of Strategies (Part 1), we have discussed in detail trading modes and functions that allow implementing them. We have analyzed a universal Expert Advisor scheme consisting of four methods, two of which open new positions and the other two methods close them. Different combinations of method calls define a particular trading mode. For example, an Expert Advisor can be allowed only to Sell or to Buy, can manage previously opened positions or wait. Using these modes, an Expert Advisor operation can be flexibly set up depending on the trading time or day of the week.

However, the trading modes are not the only thing that an Expert Advisor may need. In the second part we will discuss the event model of the CStrategy trading mode based on the centralized event handling. The proposed event handling scheme differs from the system events in that all the events are gathered in one place. The advantages of such an implementation will be considered later.

Also, this article describes two important classes of the trading engine — CStrategy and CPosition. The first one is the core of the whole EA trading logic, it unites events and modes into a single flexible framework that the custom EA inherits directly. The second class is the basis of universal trading operations. It contains actions applied to an open position (like closing of a position or modification of its Stop Loss or Take Profit). This allows formalizing all trading actions and making them platform-independent.

Access to Events Occurring on Other Instruments, the MarketEvent Structure

When designing a trading system which analyzes multiple symbols, you need to create a mechanism that can track changes in the prices of multiple instruments. However, the standard OnTick function is only called for a new tick of the instrument the Expert Advisor is running on. On the other hand, trading system developers may use the OnBookEvent function that responds to changes in the order book (Depth of Market). Unlike OnTick, OnBookEvent is called for any change in the order book of the instrument, to which you subscribed using the MarketBookAdd function.

Changes in the order book happen very often, that is why monitoring this event is a resource-intensive procedure. As a rule, monitoring changes in the tick stream of the required symbol is enough for Expert Advisors. On the other hand, the event of the order book change also includes the arrival of a new tick. Apart from OnBookEvent, you can set up calls of OnTimer at specified intervals and analyze price changes of multiple symbols in this function.

So in the system functions that react to NewTick, BookEvent and Timer events, you can add a call of some intermediate module (let's call it EventProcessor), which would simultaneously analyze changes in prices of multiple instruments and generate an appropriate event. Each event would have a unified description in the form of a structure and would be sent by the control methods of the strategy. Having received an appropriate event as a structure, the strategy would either react to it or ignore. In this case, the system function which actually initiated the event for the final Expert Advisor would be unknown.

Indeed, if an Expert Advisor receives a notification of a new incoming tick, it does not matter whether the information is received through OnTick, OnTimer or OnBookEvent. The only thing that matters is that there is a new tick for the specified symbol. One event handler can be used for many strategies. For example, if each strategy is represented as a custom class, multiple instances of these classes can be stored in the special list of strategies. In this case, any strategy from the list will be able to receive a new event generated by EventProcessor. The following diagram shows how events are generated and sent:

Fig. 1. Diagram of event generation and sending

Author: Vasiliy Sokolov