Modèle événementiel, exécution, reprise et Strategy Tester
salut
se sont mes réponses et je peux largement me tromper comme sur la compréhension de tes questions
001
pour cette question c'est assez flou je trouve et en fait il suffit de le voir en pas à pas pour se rendre compte que ce n'est pas évident à trouver une réponse arréter. Le mieux est de faire un check dès l'entrée de l'évènement sur ce que tu as besoin par ne pas exécuter du code qui ne sert à rien
002
ils sont perdus....
003
pas à ma connaissance, c'est un par un ...
004
comme dit le découper et traiter le signal à l'entrée
006
ontick je prendrais
007
en fait je ne sais pas ce qui se passerait si le timer et un tick tombent en meme temps pour moi c'est clair que MT5 n'est pas multitaches
008
il me semble que la doc est clair à ce sujet
009
pareil c'est dans la doc, mais il faut gérer le serveur en face.... et ce n'est pas toujours simple
010
Recommandé .... non. mais tu prends tes risques, tu peux très bien ne pas avoir d'erreur de ton coté en envoyant un ordre au serveur, et celui ci pour plein de raisons possibles, ne pas l'exécuter....
011
non le ticket l'empeche
012
a toi de gérer comme tu peux... le mieux possible
013
ca vaut mieux, mais selon ta stratégie il faut bien être conscient des valeurs qui forment un trade sur le serveur. il se peut que ce ne soit pas complet....
014
le ticket ... c'est un ulong y a de la place
016
le sujet est très vaste.... disons que le testeur est "bien" mais ne peux pas reformer tout le reel
il faut en être conscient et faire avec.
017
C'est là où le bordel commence, perso mocks en couche d'abstraction
018
Si ton code est bien fait avec un bon debug actif, tu n'as pas de souci
Merci pour ton retour, c’est exactement le type d’informations terrain que je cherche.
Mon objectif est de construire une architecture MQL5 assez défensive, donc j’essaie surtout de déterminer ce que MT5 garantit réellement et ce que l’EA doit garantir lui-même.
Sur OnTick / OnTimer, je pars donc sur des handlers courts : contrôle dès l’entrée, traitement minimal, puis délégation vers les composants concernés. Je vais éviter de considérer les événements comme parallèles.
Pour l’exécution, je retiens surtout qu’un envoi accepté côté terminal ne doit jamais être considéré comme une preuve d’exécution réelle côté serveur. Je compte donc dissocier :
intention d'ordre → envoi → résultat de requête → transactions serveur → ordre/deal/position réellement constaté
avec identifiants/corrélations et contrôle via OnTradeTransaction().
Là où j’aimerais ton avis technique, c’est surtout sur les cas limites :
1. Si OnTick() est en cours lorsqu’un événement Timer arrive, est-ce que tu considères fiable de supposer que le Timer sera simplement mis en file, ou prévois-tu toi-même un mécanisme pour détecter qu’un travail périodique n’a pas été effectué ?
2. Pour OnTradeTransaction(), vu qu’une requête peut entraîner plusieurs transactions, quelle méthode utilises-tu pour reconstruire proprement l’état final d’une demande sans considérer trop tôt qu’elle est terminée ?
3. En cas de coupure terminal/réseau juste après OrderSend() mais avant d’avoir récupéré toutes les confirmations, comment évites-tu au redémarrage de renvoyer accidentellement un ordre dont l’état réel côté serveur est encore incertain ?
4. Est-ce que tu reconstruis systématiquement l’état depuis les ordres/positions/deals présents côté serveur après reconnexion, plutôt que de faire confiance uniquement à l’état local mémorisé par l’EA ?
5. Pour les tests, quand tu parles de mocks + couche d’abstraction, est-ce que tu sépares complètement la logique métier des appels MT5 (OrderSend, positions, historique, etc.) afin de pouvoir injecter des réponses serveur simulées : timeout, rejet, exécution partielle, réponse tardive, reconnexion, etc. ?
C’est surtout ces scénarios de panne qui m’intéressent maintenant. Le fonctionnement nominal est assez clair ; je cherche à éviter qu’un événement perdu, une réponse serveur ambiguë ou une reconnexion puisse provoquer un doublon d’ordre ou un état local différent de l’état réel du compte.
Et si tu as le temps, il me manque aussi tes réponses aux 005 et 015.
Merci pour ton aide.
salut
"Sur OnTick / OnTimer, je pars donc sur des handlers courts : contrôle dès l’entrée, traitement minimal, puis délégation vers les composants concernés. Je vais éviter de considérer les événements comme parallèles."
Ca va devenir comme des accès concurrents tes timer à un moment on le meme horaire , je ne le ferais pas.
Je ne sais pas ce que tu veux faire, mais esssaye de voir dans ontick pour mettre un flag pour une opération qui serait à faire en extérieur si pas trop long
"2. Pour OnTradeTransaction(), vu qu’une requête peut entraîner plusieurs transactions, quelle méthode utilises-tu pour reconstruire proprement l’état final d’une demande sans considérer trop tôt qu’elle est terminée ?"
En fait essaye de rajouter une notion d''intention de trade, on pourrait dire que c'est ton code
Tu gardes tout dans une structure, array, ce que je tu veux
Tant que le serveur n'a pas confirmé, tu renvoi l'ordre jusqu'à confirmation et effacement de cette intention dans la structure
" En cas de coupure terminal/réseau juste après OrderSend() mais avant d’avoir récupéré toutes les confirmations, comment évites-tu au redémarrage de renvoyer accidentellement un ordre dont l’état réel côté serveur est encore incertain ?"
il faudrait garder une copie local de tes trade, tout ce que tu veux pour le faire, txt, bdd etc
Si ton total structure est différent du total trades sur serveur c'est que un truc ne va pas, recharger tout depuis la sauvegarde ou le serveur de trades
"Est-ce que tu reconstruis systématiquement l’état depuis les ordres/positions/deals présents côté serveur après reconnexion, plutôt que de faire confiance uniquement à l’état local mémorisé par l’EA ?"
Tu n'as pas vraiment le choix.... tu peux juste te poser des questions si ca ne colle pas entre les deux
seul le serveur à raison
"Pour les tests, quand tu parles de mocks + couche d’abstraction, est-ce que tu sépares complètement la logique métier des appels MT5 (OrderSend, positions, historique, etc.) afin de pouvoir injecter des réponses serveur simulées : timeout, rejet, exécution partielle, réponse tardive, reconnexion, etc. ?"
Ca se peut.... c'est du prototypage et ca peut allez très très vite, bien plus que le testeur, demande beaucoup de travail que je ne suis pas encore arrivé à faire.
"PHX-MQ-005 — WebRequest() étant synchrone, quel est exactement son impact sur le traitement des autres événements de l’EA pendant l’attente de la réponse ?"
je n'ai pas répondu car je n'ai jamais utilisé
"PHX-MQ-015 — Existe-t-il des mécanismes ou pratiques MQL5 recommandés pour assurer l’idempotence d’une logique d’exécution après crash/restart ?"
on vient d'en parler, mais le sujet peut être très vaste selon comment tu le traite
perso, structure local avec des intentions et tout le tralala comme dit
Bonjour,
Merci pour tes deux retours. Ils m’ont permis de fermer une bonne partie des questions, notamment sur la persistance locale des intentions, la réconciliation après redémarrage et l’utilisation de mocks.
Il me reste quelques points techniques précis pour lesquels j’essaie de distinguer ce que MT5 garantit réellement de ce que l’EA doit gérer lui-même.
PHX-MQ-019 — File d’événements
Si OnTick() est déjà en cours et qu’un autre tick arrive avant sa fin, sais-tu si le nouveau tick est systématiquement conservé dans la file, ou s’il peut ne pas être ajouté ?
Même question pour OnTimer() : si un événement Timer est déjà en cours ou déjà présent dans la file, un nouveau Timer peut-il être ignoré ?
PHX-MQ-020 — OnTradeTransaction et intention de trade
Pour ton idée de structure contenant les intentions de trade : quel identifiant utiliserais-tu pour relier de façon fiable une intention locale aux différents événements serveur qui peuvent suivre ?
Je cherche notamment à suivre :
intention locale → requête → ordre → deal(s) → position
sans considérer l’intention terminée trop tôt.
PHX-MQ-021 — Etat UNKNOWN après OrderSend
Je voudrais revenir sur un point de sécurité.
Si OrderSend() a été envoyé puis que la connexion tombe avant que je sache si le serveur l’a accepté, je préférerais ne surtout pas renvoyer immédiatement la même intention.
Est-ce que tu serais d’accord avec cette logique :
état inconnu → aucun nouvel envoi → interrogation/reconstruction serveur → seulement ensuite décision de renvoyer ou non
plutôt que :
pas de confirmation → renvoi automatique ?
Mon objectif est d’éviter absolument un ordre en double.
PHX-MQ-022 — Reconstruction serveur
Après reconnexion, pour reconstruire une intention, quelles données serveur contrôlerais-tu réellement ?
OrdersTotal / positions / historique des ordres / historique des deals / tickets / magic number / commentaire, etc.
Est-ce qu’un simple comptage du nombre de trades te paraît insuffisant pour déterminer qu’une intention précise a été exécutée ?
PHX-MQ-023 — Persistance locale
Dans la structure locale d’intention dont tu parles, quels champs conserverais-tu au minimum pour permettre une réconciliation fiable après crash ?
Par exemple :
IntentID, symbole, sens, volume, heure de création, état avant crash, ticket connu, magic number, dernière confirmation serveur…
PHX-MQ-024 — OrderSend vs OrderSendAsync
Pour une architecture où la priorité absolue est la traçabilité et la prévention des doublons plutôt que la vitesse, choisirais-tu OrderSend() ou OrderSendAsync() ?
Et surtout : pourquoi ?
PHX-MQ-025 — OnTradeTransaction
À quel moment considères-tu personnellement qu’une intention est réellement terminée ?
À la réception du résultat de requête ?
À la création de l’ordre ?
Au deal ?
À l’apparition/modification de la position ?
Ou après vérification de plusieurs de ces éléments ?
PHX-MQ-026 — Crash pendant OnTradeTransaction
Si le terminal ou l’EA plante alors que plusieurs transactions correspondant à une même intention sont encore en cours de traitement, considères-tu qu’au redémarrage il faut abandonner l’ancien état local et reconstruire entièrement la situation depuis le serveur avant toute nouvelle émission ?
PHX-MQ-027 — Mocks
Pour tes mocks/couche d’abstraction, est-ce que tu simulerais également les cas où :
- l’ordre est accepté mais la réponse est perdue ;
- la réponse arrive tardivement ;
- plusieurs transactions correspondent à une requête ;
- exécution partielle ;
- rejet serveur ;
- déconnexion juste après l’envoi ;
- état local différent de l’état serveur ?
Ce sont surtout ces cas que je voudrais tester avant de connecter l’EA à un broker.
PHX-MQ-028 — WebRequest
Comme tu ne l’utilises pas, pas de souci si tu ne peux pas répondre. Mais sais-tu si quelqu’un sur le forum maîtrise suffisamment WebRequest() pour confirmer son comportement vis-à-vis de la file d’événements et des blocages de l’EA ?
Je préfère obtenir une réponse de quelqu’un qui l’utilise réellement plutôt que faire une hypothèse.
Merci encore. Mon objectif est maintenant surtout de sécuriser les cas anormaux et les reprises après panne, le fonctionnement nominal étant beaucoup plus clair.
Merci.
Pour être sûr de bien comprendre :
1. Quand tu dis que le serveur donne un ticket même si le trade sera ensuite rejeté, tu parles exactement du ticket d’ordre ? Et tu l’utiliserais comme identifiant pour rattacher toutes les transactions serveur à mon intention locale ?
2. Quand tu dis « 4 valeurs de tick », tu peux juste me dire lesquelles quand tu auras le temps ?
Pas d’urgence, c’est surtout pour éviter que j’interprète mal ton retou
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation
Bonjour,
Je travaille sur l’architecture d’un Expert Advisor MT5/MQL5 comportant plusieurs modules internes et je souhaite clarifier certains comportements techniques de MT5/MQL5 avant de figer l’architecture.
Je cherche de préférence des réponses factuelles, et lorsque possible des références vers la documentation officielle MQL5.
1 — Modèle événementiel et file d’événements
PHX-MQ-001 — Comment MT5/MQL5 ordonnance-t-il exactement les événements d’un EA (OnTick, OnTimer, OnTradeTransaction, etc.) ?
PHX-MQ-002 — Si le traitement d’un événement est long, que se passe-t-il pour les nouveaux événements arrivant pendant son exécution ?
PHX-MQ-003 — Existe-t-il des situations dans lesquelles certains événements peuvent être regroupés, ignorés ou ne pas être ajoutés plusieurs fois à la file ?
PHX-MQ-004 — Quelles sont les bonnes pratiques pour éviter qu’un traitement interne long bloque ou dégrade la gestion des événements de l’EA ?
2 — Appels réseau et WebRequest
PHX-MQ-005 — WebRequest() étant synchrone, quel est exactement son impact sur le traitement des autres événements de l’EA pendant l’attente de la réponse ?
PHX-MQ-006 — Pour une architecture nécessitant des communications externes, est-il préférable d’isoler les appels réseau dans une logique déclenchée par OnTimer() plutôt que dans OnTick() ?
PHX-MQ-007 — Quelles limitations MT5/MQL5 faut-il prendre en compte pour communiquer avec un service externe sans perturber la boucle principale de l’EA ?
3 — Envoi et suivi des ordres
PHX-MQ-008 — Quelle différence pratique faut-il retenir entre OrderSend() et OrderSendAsync() pour une architecture où l’état d’exécution doit être suivi précisément ?
PHX-MQ-009 — Après l’envoi d’une requête de trading, quelle source doit être considérée comme autoritaire pour connaître l’état réel de son exécution ?
PHX-MQ-010 — OnTradeTransaction() est-il le mécanisme recommandé pour reconstruire précisément le cycle de vie d’un ordre/deal après son envoi ?
PHX-MQ-011 — Existe-t-il des cas où plusieurs événements OnTradeTransaction() peuvent correspondre à une seule intention d’exécution, et comment recommandez-vous de les corréler proprement ?
4 — Crash, redémarrage et réconciliation
PHX-MQ-012 — Après un crash de MT5, de l’EA, du PC ou une perte de connexion, quelle est la méthode recommandée pour reconstruire de façon fiable l’état réel du compte au redémarrage ?
PHX-MQ-013 — Est-il recommandé de considérer l’état du serveur/broker comme source de vérité au redémarrage et de réconcilier l’état interne de l’EA avec les positions, ordres et deals réellement présents ?
PHX-MQ-014 — Quelles informations persistantes recommandez-vous de conserver afin d’éviter qu’un redémarrage provoque l’envoi en double d’une intention déjà exécutée ou encore en cours ?
PHX-MQ-015 — Existe-t-il des mécanismes ou pratiques MQL5 recommandés pour assurer l’idempotence d’une logique d’exécution après crash/restart ?
5 — Strategy Tester et tests d’architecture
PHX-MQ-016 — Quelles différences importantes existent entre le comportement du Strategy Tester et celui d’un terminal MT5 réel concernant événements, timers, transactions de trading et communications externes ?
PHX-MQ-017 — Quelle méthode recommandez-vous pour tester des modules dépendant normalement de services externes lorsque WebRequest() ou le service réel ne peut/ne doit pas être utilisé dans le Strategy Tester ? Utilisez-vous généralement des mocks/stubs ou une couche d’abstraction ?
PHX-MQ-018 — Pour tester les scénarios de panne, reprise, expiration, timeout et ordre des événements, quelles limitations du Strategy Tester faut-il absolument connaître afin de ne pas conclure à tort qu’un comportement observé en test sera identique en production ?
Mon objectif n’est pas de demander une stratégie de trading ni du code complet, mais de comprendre précisément les garanties et limites techniques de la plateforme afin de construire une architecture robuste.
Merci d’avance pour vos retours techniques et, si possible, pour les références vers la documentation officielle MQL5 correspondante.