ProRealTime
Zone de développement des applications API, des logiciels et utilitaires développés par les membres du forum
Répondre Page 1 sur 1

IG python : distinguer working order - position en cours

par clodreb » 11 Déc 2017 18:14

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.

Re: IG python : distinguer working order - position en cours

par clodreb » 12 Déc 2017 07:23

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 ?

Re: IG python : distinguer working order - position en cours

par Nomade » 12 Déc 2017 17:45

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.

Re: IG python : distinguer working order - position en cours

par clodreb » 12 Déc 2017 18:21

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

Re: IG python : distinguer working order - position en cours

par Nomade » 12 Déc 2017 21:21

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 :twisted: ) de debugger en reel qu'en demo :roll:

Articles en relation
API IG : problème avec les working order ?
par clodreb » 01 Fév 2016 09:09 (11 Réponses)
Récupérer les cours avec l'API IG Market et Python
par layzard » 24 Juil 2016 11:09 (53 Réponses)
telechargement l3 version 2.2 ou 2.2.1 python only
par musicae » 17 Déc 2015 19:16 (0 Réponses)
Python : IDE && interface graphique
par falex » 08 Aoû 2016 21:08 (3 Réponses)
[PYTHON] Script API IG STREAM + REST
par FemtoTrader » 14 Sep 2015 20:50 (29 Réponses)
[Python] - Gestion des (flux de) données
par GTO » 14 Aoû 2016 14:20 (0 Réponses)
Developper une interface de trading auto en Python pour IG
par Photon » 05 Oct 2018 07:33 (27 Réponses)
API IG par l'exemple, récupération des cours, trades
par maroxe » 28 Jan 2015 13:39 (8 Réponses)
Récupérer les cours des marchés IG sous Excel
par LPhilippe » 22 Aoû 2015 15:25 (9 Réponses)
Cours en temps réel sur le forum avec API iG ?
Fichier(s) joint(s) par jized » 26 Aoû 2015 15:56 (96 Réponses)

ProRealTime