Evento OnTradeTransaction

Los Asesores Expertos y los indicadores pueden recibir notificaciones sobre eventos de trading si su código contiene una función de procesamiento especial OnTradeTransaction.

void OnTradeTransaction(const MqlTradeTransaction &trans,
const MqlTradeRequest &request, const MqlTradeResult &result)

El primer parámetro es la estructura MqlTradeTransaction descrita en la sección anterior. El segundo y tercer parámetro son estructuras MqlTradeRequest y MqlTradeResult, que se han presentado anteriormente en las secciones correspondientes.

La estructura MqlTradeTransaction que describe la transacción de trading se rellena de forma diferente en función del tipo de transacción especificado en el campo type. Por ejemplo, para las transacciones del tipo TRADE_TRANSACTION_REQUEST, todos los demás campos no son importantes, y para obtener información adicional, es necesario analizar el segundo y tercer parámetro de la función (request y result). Por el contrario, para todos los demás tipos de transacciones, los dos últimos parámetros de la función deben ignorarse.

En el caso de TRADE_TRANSACTION_REQUEST, el campo request_id de la variable result contiene un identificador (a través del número de serie), con el que la operación request queda registrada en el terminal. Este número no tiene nada que ver con los tickets de orden y transacción, ni con los identificadores de posición. En cada sesión con el terminal, la numeración empieza por el principio (1). La presencia de un identificador de solicitud permite asociar la acción realizada (llamada a las funciones OrderSend o OrderSendAsync) con el resultado de esta acción pasado a OnTradeTransaction. Veremos ejemplos más adelante.

Para las operaciones de trading relacionadas con órdenes activas (TRADE_TRANSACTION_ORDER_ADD, TRADE_TRANSACTION_ORDER_UPDATE y TRADE_TRANSACTION_ORDER_DELETE) y el historial de órdenes (TRADE_TRANSACTION_HISTORY_ADD, TRADE_TRANSACTION_HISTORY_UPDATE, TRADE_TRANSACTION_HISTORY_DELETE), se rellenan los siguientes campos en la estructura MqlTradeTransaction:

• orden: ticket de la orden
• symbol: nombre del instrumento financiero de la orden
• type: tipo de operación de trading
• order_type: tipo de orden
• orders_state: estado actual de la orden
• time_type: tipo de vencimiento de la orden
• time_expiration: hora de vencimiento de la orden (para órdenes con tipos de vencimiento ORDER_TIME_SPECIFIED y ORDER_TIME_SPECIFIED_DAY)
• price: precio de la orden especificada por el cliente/programa
• price_trigger: precio stop para activar una orden Stop Limit (sólo para ORDER_TYPE_BUY_STOP_LIMIT y ORDER_TYPE_SELL_STOP_LIMIT)
• price_sl: Stop Loss precio de la orden (cumplimentado si se especifica en la orden)
• price_tp: Take Profit precio de la orden (cumplimentado si se especifica en la orden)
• volume: volumen actual de la orden (no ejecutada), el volumen inicial de la orden se puede encontrar en el historial de órdenes
• position: ticket de una posición abierta, modificada o cerrada
• position_by: ticket de posición opuesta (sólo para órdenes que se van a cerrar con posición opuesta)

Para operaciones de trading relacionadas con transacciones (TRADE_TRANSACTION_DEAL_ADD, TRADE_TRANSACTION_DEAL_UPDATE y TRADE_TRANSACTION_DEAL_DELETE), se rellenan los siguientes campos en la estructura MqlTradeTransaction:

• deal: ticket de transacción
• order: ticket de orden en base al cual se realizó la transacción
• symbol: nombre del instrumento financiero de la transacción
• type: tipo de operación de trading
• deal_type: tipo de transacción
• precio: precio de transacción
• price_sl: Stop Loss precio (rellenado si se especifica en la orden en base a la cual se realizó la transacción)
• price_tp: Take Profit precio (rellenado si se especifica en la orden en base a la cual se realizó la transacción)
• volume: volumen de transacción
• position: ticket de una posición abierta, modificada o cerrada
• position_by: ticket de posición opuesta (para cerrar transacciones con posición opuesta)

Para las operaciones de trading relacionadas con cambios de posición (TRADE_TRANSACTION_POSITION), se rellenan los siguientes campos en la estructura MqlTradeTransaction:

• symbol: nombre del instrumento financiero de la posición
• type: tipo de operación de trading
• deal_type: tipo de posición (DEAL_TYPE_BUY o DEAL_TYPE_SELL)
• price: precio medio ponderado de apertura de la posición
• price_sl: precio Stop Loss
• price_tp: precio Take Profit
• volume: volumen de posiciones en lotes
• position: ticket de posición

No toda la información disponible sobre órdenes, transacciones y posiciones (por ejemplo, un comentario) se transmite en la descripción de una operación de trading. Para obtener más información, utilice las funciones correspondientes: OrderGet, HistoryOrderGet, HistoryDealGet y PositionGet.

Una solicitud de trading enviada desde el terminal manualmente o a través de las funciones de trading OrderSend/OrderSendAsync puede generar varias transacciones de trading consecutivas en el servidor de trading. Al mismo tiempo, el orden en que las notificaciones sobre estas operaciones llegan al terminal no está garantizado, por lo que no puede construir su algoritmo de trading esperando unas operaciones después de otras.

Los eventos de trading se procesan de forma asíncrona, es decir, con retraso (en el tiempo) respecto al momento de generación. Cada evento de trading se envía a la cola del programa MQL, y el programa los recoge secuencialmente en el orden de la cola.

Cuando un Asesor Experto está procesando transacciones de trading dentro del procesador OnTradeTransaction, el terminal continúa aceptando transacciones de trading entrantes. Por lo tanto, el estado de la cuenta de trading puede cambiar mientras OnTradeTransaction está en funcionamiento. En el futuro, el programa será notificado de todos estos eventos en el orden en que aparezcan.

La longitud de la cola de transacciones es de 1024 elementos. Si OnTradeTransaction procesa la siguiente transacción durante demasiado tiempo, las transacciones antiguas de la cola pueden ser desbancadas por las más recientes.

Debido al funcionamiento paralelo multihilo del terminal con objetos de trading, en el momento en que se llama al manejador OnTradeTransaction, todas las entidades mencionadas en él, incluyendo órdenes, transacciones y posiciones, pueden estar ya en un estado diferente al especificado en las propiedades de la transacción. Para obtener su estado actual, debe seleccionarlos en el entorno actual o en el historial y solicitar sus propiedades utilizando las funciones MQL5 adecuadas.

Comencemos con un ejemplo sencillo de Asesor Experto TradeTransactions.mq5, que registra todos los eventos de trading de OnTradeTransaction. Su único parámetro DetailedLog permite utilizar opcionalmente las clases OrderMonitor, DealMonitor, PositionMonitor para mostrar todas las propiedades. Por defecto, el Asesor Experto muestra sólo el contenido de los campos rellenados de las estructuras MqlTradeTransaction, MqlTradeRequest y MqlTradeResult, que llegan al manejador en forma de parámetros; al mismo tiempo, request y result se procesan sólo para las transacciones TRADE_TRANSACTION_REQUEST.

Vamos a ejecutarlo en el gráfico EURUSD y a realizar varias acciones manualmente, y las entradas correspondientes aparecerán en el registro (por la pureza del experimento, se supone que nadie ni nada más realiza operaciones en la cuenta de trading; en concreto, que no hay otros Asesores Expertos en ejecución).

Vamos a abrir una posición larga con un lote mínimo.

Venderemos el doble del lote mínimo.

Vamos a realizar la operación de cierre del contador.

Seguimos teniendo una posición corta del lote mínimo. Vamos a cerrarla.

Si lo desea, puede activar la opción DetailedLog para registrar todas las propiedades de los objetos de trading en el momento de procesar el evento. En un registro detallado se pueden observar discrepancias entre el estado de los objetos almacenados en la estructura de la transacción (en el momento de su inicio) y el estado actual. Por ejemplo, al añadir una orden para cerrar una posición (opuesta o normal), se especifica un ticket en la transacción, según el cual el objeto monitor ya no podrá leer nada, puesto que la posición se ha borrado. Como resultado, veremos líneas como ésta en el registro:

Vamos a reiniciar el Asesor Experto TradeTransaction.mq5 para restablecer los eventos registrados para la próxima prueba. Esta vez utilizaremos la configuración por defecto (sin detalles).

Ahora vamos a intentar realizar acciones de trading programáticamente en el nuevo Asesor Experto OrderSendTransaction1.mq5, y al mismo tiempo describir nuestro manejador OnTradeTransaction en él (igual que en el ejemplo anterior).

Este Asesor Experto le permite seleccionar el volumen y la dirección de la operación: si lo deja a cero, se utiliza por defecto el lote mínimo del símbolo actual. También en los parámetros hay una distancia a los niveles de protección en puntos. Se entra en el mercado con los parámetros especificados, hay una pausa de 5 segundos entre el ajuste de Stop Loss y Take Profit, y a continuación se cierra la posición, de manera que el usuario pueda intervenir (por ejemplo, editar Stop Loss manualmente), aunque esto no es necesario, puesto que ya nos hemos asegurado de que las operaciones manuales sean interceptadas por el programa.

La estrategia se lanza una vez, para lo cual se utiliza un temporizador de 1 segundo, que se desactiva en su propio manejador.

Todas las acciones se realizan a través de una estructura MqlTradeRequestSync ya familiar con características avanzadas (MqlTradeSync.mqh): inicialización implícita de campos con valores correctos, métodos buy/sell para órdenes de mercado, adjust para niveles de protección y close para cerrar la posición.

Paso 1:

Paso 2:

Paso 3:

Las esperas intermedias no sólo permiten tener tiempo para considerar el proceso, sino que también demuestran un aspecto importante de la programación MQL5, que es el monohilo. Mientras nuestro Asesor Experto de trading se encuentra dentro de OnTimer, los eventos de trading generados por el terminal se acumulan en su cola y serán reenviados al manejador interno de OnTradeTransaction en un estilo diferido, sólo después de la salida de OnTimer.

Al mismo tiempo, el Asesor Experto de TradeTransactions que se ejecuta en paralelo no está ocupado con ningún cálculo y recibirá los eventos de trading lo más rápido posible.

El resultado de la ejecución de dos Asesores Expertos se presenta en el siguiente registro con temporización (por brevedad, OrderSendTransaction1 se etiqueta como OS1, y Trade Transactions como TTs).

La numeración de los eventos en los programas es la misma (siempre que se inicien limpiamente, según lo recomendado). Observe que el mismo evento se imprime primero desde TTs inmediatamente después de que se ejecute la solicitud, y la segunda vez sólo al final de la prueba, donde, de hecho, todos los eventos se emiten desde la cola a OS1.

Si eliminamos los retrasos artificiales, el script, por supuesto, se ejecutará más rápido, pero aún así el manejador OnTradeTransaction recibirá notificaciones (múltiples veces) después de los tres pasos, no después de cada solicitud respectiva. ¿Hasta qué punto esto es crítico?

Ahora los ejemplos utilizan nuestra modificación de la estructura MqlTradeRequestSync, utilizando a propósito la opción sincrónica OrderSend, que también implementa un método universal completed que comprueba si la solicitud se ha completado con éxito. Con este control, podemos establecer niveles de protección para una posición, ya que sabemos cómo esperar a que aparezca su ticket. En el marco de este concepto síncrono (adoptado por comodidad), no necesitamos analizar los resultados de las consultas en OnTradeTransaction, pero esto no siempre es así.

Cuando un Asesor Experto necesita enviar muchas solicitudes a la vez, como en el caso del ejemplo con el establecimiento de una cuadrícula de órdenes PendingOrderGrid2.mq5 abordado en la sección sobre propiedades de posiciones, esperar a que cada posición u orden esté «lista» puede reducir el rendimiento global del Asesor Experto. En tales casos se recomienda utilizar la función OrderSendAsync. Pero si tiene éxito, sólo rellena el campo request_id en MqlTradeResult, con el que luego hay que hacer un seguimiento de la aparición de órdenes, transacciones y posiciones en OnTradeTransaction.

Uno de los trucos más obvios pero no especialmente elegantes para implementar este esquema es almacenar los identificadores de las solicitudes o estructuras enteras de las solicitudes que se envían en un array, en el contexto global. Estos identificadores pueden buscarse seguidamente en las transacciones entrantes en OnTradeTransaction, los tickets pueden encontrarse en el parámetro MqlTradeResult y pueden adoptarse además otras medidas. Como resultado, la lógica de trading se separa en diferentes funciones. Por ejemplo, en el contexto del último Asesor Experto OrderSendTransaction1.mq5, esta "diversificación" radica en el hecho de que después de enviar la primera orden, los fragmentos de código deben ser transferidos a OnTradeTransaction y comprobados para lo siguiente:

• tipo de transacción en MqlTradeTransaction (transaction type);
• tipo de solicitud en MqlTradeRequest (request action);
• id de solicitud en MqlTradeResult (result.request_id);

Todo ello debe completarse con una lógica aplicada específica (por ejemplo, la comprobación de la existencia de una posición), que proporciona la ramificación por estados de la estrategia de trading. Un poco más adelante haremos una modificación similar del Asesor Experto OrderSendTransaction bajo un número diferente para mostrar visualmente la cantidad de código fuente adicional. Y luego ofreceremos una forma de organizar el programa de forma más lineal, pero sin abandonar los eventos transaccionales.

Por ahora señalamos únicamente que el desarrollador debe elegir si construye un algoritmo en torno a OnTradeTransaction o sin él. En muchos casos, cuando no es necesario el envío masivo de órdenes, es posible permanecer en el paradigma de programación síncrona. Sin embargo, OnTradeTransaction es la forma más práctica de controlar la activación de órdenes pendientes y niveles de protección, así como otros eventos generados por el servidor. Tras una pequeña preparación presentaremos dos ejemplos relevantes: la modificación final del Asesor Experto de cuadrícula y la implementación de la popular configuración de dos órdenes OCO (One Cancels Other) (véase la sección On Trade).

Una alternativa a la aplicación de OnTradeTransaction consiste en el análisis periódico del entorno de trading, es decir, en recordar el número de órdenes y posiciones y buscar cambios entre ellas. Este enfoque es adecuado para estrategias basadas en calendarios o que permiten ciertos retrasos.

Insistimos una vez más en que el uso de OnTradeTransaction no significa que el programa deba pasar necesariamente de OrderSend a OrderSendAsync: Puede utilizar cualquiera de las dos variedades o ambas. Recordemos que la función OrderSend tampoco es del todo síncrona, ya que devuelve, en el mejor de los casos, el ticket de la orden y la transacción, pero no la posición. Pronto podremos medir el tiempo de ejecución de un lote de órdenes dentro de la misma estrategia de cuadrícula utilizando ambas variantes de la función: OrderSend y OrderSendAsync.

Para unificar el desarrollo de programas síncronos y asíncronos sería genial admitir OrderSendAsync en nuestra estructura MqlTradeRequestSync (a pesar de su nombre), lo cual puede hacerse con sólo un par de correcciones. En primer lugar, debe sustituir todas las llamadas OrderSend existentes por su propio método orderSend, y en él cambiar la llamada a OrderSend o OrderSendAsync en función de una bandera.

Estableciendo la variable pública AsyncEnabled en true o false, puede cambiar de un modo a otro; por ejemplo, en el fragmento de código en el que se envían las órdenes en masa.

En segundo lugar, aquellos métodos de la estructura que devuelvan un ticket (por ejemplo, para entrar en el mercado) deberán devolver el campo request_id en lugar de order. Por ejemplo, dentro de los métodos _pending y _market teníamos el siguiente operador:

Ahora se sustituye por:

Por supuesto, cuando el modo asíncrono está activado, ya no podemos utilizar el método completed para esperar a que los resultados de la consulta estén listos inmediatamente después de su envío. Pero este método es, básicamente, opcional: puede abandonarlo incluso cuando trabaje a través de OrderSend.

Así pues, teniendo en cuenta la nueva modificación del archivo MqlTradeSync.mqh, vamos a crear OrderSendTransaction2.mq5.

Este Asesor Experto enviará la solicitud inicial como antes desde OnTimer, mientras establece niveles de protección y cierra una posición en OnTradeTransaction paso a paso. Aunque esta vez no tendremos un retraso artificial entre las etapas, la secuencia de estados en sí es estándar para muchos Asesores Expertos: se abrió una posición, se modificó, se cerró (si se cumplen ciertas condiciones de mercado, que aquí se dejan entre bastidores).

Dos variables globales le permitirán realizar un seguimiento del estado: RequestID con el id de la última solicitud enviada (cuyo resultado esperamos) y Position Ticket con un ticket de posición abierta. Cuando allí la posición no ha aparecido todavía, o ya no existe, la entrada es igual a 0.

El modo asíncrono está activado en el manejador OnInit.

La función OnTimer es ahora mucho más corta.

Una vez completada con éxito la solicitud, sólo obtenemos request_id y lo almacenamos en la variable RequestID. La impresión de estado contiene ahora un signo de interrogación, como «¿OK Open?», porque aún no se conoce el resultado real.

OnTradeTransaction se complicó considerablemente debido a la verificación de los resultados y la ejecución de las órdenes de trading posteriores según las condiciones. Vamos a verlo poco a poco.

En este caso, toda la lógica de trading se ha trasladado a la rama de operaciones de tipo TRADE_TRANSACTION_REQUEST. Por supuesto, el desarrollador puede utilizar otros tipos si lo desea, pero utilizamos este porque contiene información en forma de una estructura MqlTradeResult familiar, es decir, este tipo representa una finalización retrasada de una llamada asíncrona OrderSendAsync.

Sólo deberían interesarnos las solicitudes con el ID que esperamos. Así que la siguiente sentencia será if anidada. En su bloque, describimos el objeto MqlTradeRequestSync con antelación, ya que será necesario enviar solicitudes de trading periódicas de acuerdo con el plan.

Sólo tenemos dos tipos de solicitud en funcionamiento, así que añadimos para ellos una if anidada más.

Hay que tener en cuenta que TRADE_ACTION_DEAL se utiliza tanto para abrir como para cerrar una posición, por lo que se requiere un if más, en el que distinguiremos entre estos dos estados dependiendo del valor de la variable PositionTicket.

En la estrategia de trading analizada no hay incrementos de posición (para la compensación) ni posiciones múltiples (para la cobertura), por lo que esta parte es sencilla desde el punto de vista lógico. Los Asesores Expertos reales requerirán estimaciones mucho más diferentes de los estados intermedios.

En el caso de una notificación de apertura de posición, el bloque de código tiene el siguiente aspecto:

Para simplificar, hemos omitido aquí la comprobación de errores y recotizaciones. Puede ver un ejemplo de su manejo en el código fuente adjunto. Recordemos que todas estas comprobaciones ya se han implementado en los métodos de la estructura MqlTradeRequestSync, pero sólo funcionan en modo síncrono, por lo que tenemos que repetirlas explícitamente.

El siguiente fragmento de código para establecer los niveles de protección no ha cambiado mucho.

La única diferencia aquí es: rellenamos la variable RequestID con el ID de la nueva solicitud TRADE_ACTION_SLTP.

Recibir una notificación sobre una transacción con un PositionTicket distinto de cero implica que la posición se ha cerrado.

En caso de borrado con éxito, la posición no puede seleccionarse utilizando PositionSelectByTicket, por lo que reiniciamos RequestID y PositionTicket. A continuación, el Asesor Experto vuelve a su estado inicial y está listo para realizar el siguiente ciclo de compra/venta-modificación-cierre.

Nos queda considerar el envío de una solicitud de cierre de la posición. En nuestra estrategia simplificada al mínimo, esto ocurre inmediatamente después de modificar con éxito los niveles de protección.

Esa es toda la función OnTradeTransaction. El Asesor Experto está listo.

Vamos a ejecutar OrderSendTransaction2.mq5 con la configuración por defecto. He aquí un registro de ejemplo:

La lógica de trading está funcionando como se esperaba, y los eventos de transacción llegan estrictamente después de que se envíe cada orden siguiente. Si ahora ejecutamos nuestro nuevo Asesor Experto y el interceptor de transacciones TradeTransactions.mq5 en paralelo, los mensajes de registro de dos Asesores Expertos aparecerán de forma sincronizada.

Sin embargo, pasar de la primera versión OrderSendTransaction1.mq5 directa a una segunda versión OrderSendTransaction2.mq5 asíncrona requería un código bastante más sofisticado. La pregunta que se plantea es: ¿es posible combinar de algún modo los principios de descripción secuencial de la lógica de trading (transparencia del código) y procesamiento paralelo (velocidad)?

En teoría, esto es posible, pero requerirá en algún momento dedicar tiempo a trabajar en la creación de algún tipo de mecanismo auxiliar.