IG python : distinguer working order - position en cours

Bonjour à toutes et tous,

je suis en train d'essayer de bidouiller le code de l'Api IG en python et j'ai une petite question :
lorqu'on fait un check des positions ouvertes, on a :
- les positions réellement en cours
- les working order qui sont actifs.

Y-a-t-il un champs qui permet de distinguer les working order des positions réellement ouvertes ?


Merci d'avance.

merci pour le rappel du tableau -.

En relisant le code que j'ai bidouillé il y a un peu de temps, je crois que j'ai mal posé ma question.

Effectivement, quand tu fais le "get" , c'est en fonction de l'url que tu choisis que tu obtiens un résultat différent.
Mon problème se situe plus au niveau de la gestion des update de positions quand un message OPU arrive.

ex :
1) quand un working order est encodé "en live", je reçois ceci :

{u'status': u'OPEN', u'guaranteedStop': False, u'direction': u'SELL', u'level': 5600, u'timestamp': u'2017-12-12T06:01:11.000', u'dealReference': u'WMCQ7SGXKGB5BLJ', u'dealStatus': u'ACCEPTED', u'expiry': u'-', u'dealId': u'DIAAAABMSAEDJA7', u'timeInForce': u'GOOD_TILL_DATE', u'currency': u'EUR', u'goodTillDate': u'2017-12-12T21:01:00', u'limitDistance': 50, u'orderType': u'LIMIT', u'epic': u'IX.D.CAC.IMF.IP', u'stopDistance': None, u'channel': u'AndroidApp',u'size': 2.8}


2) quand un ordre direct est exécuté "en live", je reçois ceci :

{u'guaranteedStop': False, u'trailingStopDistance': 0, u'direction': u'SELL', u'epic': u'IX.D.CAC.IMF.IP', u'level': 5404.4, u'timestamp': u'2017-12-12T06:09:54.000', u'dealIdOrigin': u'DIAAAABMSAWZAAU', u'dealReference': u'F959N55P944L4S3', u'dealStatus': u'ACCEPTED', u'expiry': u'-', u'currency': u'EUR', u'stopLevel': 5414.4, u'status': u'OPEN', u'channel': u'PublicRestOTC', u'trailingStep': 0, u'limitLevel': 5394.4, u'dealId': u'DIAAAABMSAWZAAU', u'size': 2.8}


Sur base de ces données, y a-t-il un moyen de distinguer les 2 types d'origine de l'ordre ou est-ce qu'il faut gérer les working-order dans un tableau et faire un "get" à chaque fois qu'un update se produit ?

Si c'est la 2ème solution, ça risque d'alourdir les performances , non ?

Dans le cas des WO (cas 1) le champ 'orderType' indique le type d'ordre, ici LIMIT, dans le cas d'un ordre OTC ('ordre direct' cas 2), le champ n'existe pas. Ca te permet de trier les OPU correspondant a des working order des autres.

Quand un WO est declenche et devient un ordre OTC tu recois un OPU dont le champ 'channel' est 'OSAutoStopFill'.

Attention car il y a des differences entre la demo et le reel:

-en reel je ne recoit que des WOU c'est plus facile a gerer (mais je n'utilise que mon appli et ig)
-en demo... c'est fonction de l'humeur des serveurs ... recemment les OPU contiennent l'info orderType quand il s'agit de WO, il y a quelque temps le champ orderType n'etait pas rempli. Dans ce cas, si tu veux gerer les WO de diverses origines (WEB, android, ton appli,...) il faut demander la liste des WO et OTC pour faire la part des choses sachant que ca risque de te servir que pour la demo

Dans mon cas je gere une liste des ordres envoyes et des reponses (OPU, WOU, CONFIRM) en attentes ou pas. Si un message OPU ou CONFIRM arrive dont la reference n'est pas dans ma liste je le traite comme un OTC par default avant de verifier si c'est un WO.

Merci beaucoup Nomade pour ces remarques concernant les champs "orderType" et concernant le champs "channel='OSAutoStopFill'" .

je n'avais pas remarqué cette différence.

j'avais bien remarqué que dans le cas d'un OTC, le champs 'dealIdOrigin' est rempli mais pas dans le cas d'un WO.
Mais je n'ai pas encore pu analyser la valeur de ce champ quand le WO devient un OTC...j'étais en train d'attendre d'avoir un cas

En théorie, mon but est de laisser mon robot faire des WO et de gérer d'autres prises de WO par la suite en fonction de l'activation, attente ou réussite des WO précédents.
Donc, en theorie, je dois uniquement faire comme toi : gérer les (OPU, WOU, CONFIRM).

Mais comme je sais que je ne pourrais peut-être pas résister à la tentation de prendre un trade manuel si celui-ci est trop beau , j'aime autant prendre en compte ce cas de figure directement dans ma programmation .

merci pour ces indications

Je n'ai pas bien compris l'usage des multiples champs de dealID et dealReference, mais c'est peut etre du fait de mon utilisation des API:

-mon appli envoie (en automatique ou manuel) des OTC et WO et, en temps normal, je les gere depuis mon app
-en cas de probleme j'ai toujours l'appli WEB ig pour fermer une pos ou supprimer des WO, mais dans ce cas il y a eu probleme au niveau de mon app et je prefere la relancer pour repartir au propre.

J'utilise essentiellement le dealReference. Quand tu envoies un ordre a ig tu peux definir le dealReference. Ce dealReference est associe a l'ordre durant toute sa vie, et dans le cas des WO, se transmet, lors du declenchement, a l'OTC genere, ce qui te permet de reconnaitre les messages concernant ce nouvel ordre (en plus du channel OSAutoStopFill).

Le fait de definir ton format dealRefrence te permet aussi de trier les messages en fonction de l'origine de l'ordre (si ce n'est pas ton format l'ordre ne vient pas de ton appli).

En fonction de la finalite de ton appli, ca peut vite devenir une usine a gaz de gerer des OTC et WO de toutes les origines possibles. D'autant plus que la demo et le reel ne fonctionnent pas tout a fait pareil. C'est parfois fastidieux de regler les problemes surtout concernant les WO.

Le reel est plus "rigoureux" et stable. La demo n'a pas tout a fait le meme fonctionnement mais surtout est plus aleatoire dans ces procedures.
Par ex, en reel pour les WO, je recois systematiquement, et comme prevu par la doc, un WOU. En demo ca depend des fois oui des fois non, mais je recois des OPU ou CONFIRM qui peuvent eventuellement contenir un champ orderType, en ce moment oui mais ca n'a pas toujours ete le cas (j'ai pose une question sur IGlabs il y a quelques mois...j'attend la reponse).

En conclusion mon app fonctionne tres bien en reel, mais a des bugs en demo et il est plus "facile" (mais ca coute plus cher ) de debugger en reel qu'en demo :roll: