API REST / STREAM

Pour l'instant et une semaine de test sur les serveurs demo pour l'instant, je n'ai jamais été déconnecté de mon iphone.

Je n'ai pas testé une seule fois la connexion web, va falloir que j'y passe ...

Je crois que Benoist a aussi remonté un souci de déconnexion.

Je vais pousser un message chez ig pour avoir un statu plus clair.

Par défaut tu es nécessairement déconnecté de l'interface Web au bout d'un certain nombre d'heures d'inactivité, c'est dans les préférences du compte. De son côté PRT arrête le streaming si tu es inactif (il affiche une petite fenêtre "Bougez la souris") mais il ne te déconnecte pas ! Ce que j'ai vu, c'est que si tu te déconnectes proprement côté code, cela n'affecte en rien PRT, alors que cela déco l'interface Web.

Il n'y a pas de souci de déconnexion en soi je pense : l'API est relié à un compte, donc si via API on envoie le message "Je me déconnecte" il déconnecte...le compte donc toutes les applications associées au compte 'Web, API n°1, API n°2, etc.). C'est "logique". Ce qui l'est moins c'est que PRT ne le soit pas ...déconnecté.

Effectivement j'ai déjà eu le cas où j'avais fermé mon navigateur mais pas prt et celui-ci continué de fonctionné (en tout cas pour la partie graphique, je n'ai jamais testé le passage d'ordre dans ces conditions.

TRuc auquelle il faut vraiment faire gaffe :

Avec une request /markets/epic eexcuté par le companion j'obtien Currencies ... code ...

Alors que si je regarde ce qui sort réellement de cette requête dans le programme : code = name ...

c'est au moins la 3ème fois que j'observe des décalages entre la sortie du companion et la réalité ...

Je viens de relire la page https://labs.ig.com/trading-basics

Finallement tout est expliqué sur la partie "Succession d'état", de manière un peu succincte mais c'est suffisant pour comprendre le qui-fait-quoi du fonctionnement des API.

Donc quand on lance une demande de création d'ordre :
API REST / position ... l'ACK est revnoyé sur on a un dealReference
API STRAM TRADE:CONFIRMS ... confirmation de l'ouverture par l'association dealReference/dealID eet status OPEN.

Donc j'en reviens à une question que je me suis posé au début :
A quoi sert API STREAM TRADE:OPU ???

---

Je vais tenter une auto-réponse :
CONFIRMS est la confirmation de l'action.
Chaque action (ouverture, fermeture, modification du ticket (changement SL/TP, fermeture partielle) a un dealID qui lui est unique. Dans le message il y a un affectedDeals avec les DealID des ticket concerné. Donc Confirms c'est la confirmation de la'action et ça indique quel sont les dealID (donc les tickets à l'ouverture) concerné.

OPU c'est presque pareil sauf que ça donne pour chaque dealID l'action qui vient de lui e^tre affecté. Il n'y a pas de référence au dealID d'action.

Donc le message le plus complet c'est confirms
Si on veut juste le résultat sur les tickets sans voir toute la mécanique, OPU suffit.

WOU c'est pour les ordre-limités tant qu'ils ne sont pas servi.

A quoi sert API STREAM TRADE:OPU ???

OPU sont les notifications sur les positions ouvertes.
Un trailing stop qui remonte, un stop loss ou un TP exécuté, c'est là que tu recevras la notification.

SAlut les dev,

Depuis un moment je me demandais comment on pouvait utiliser le DELETE /position/otc pour fermer plusieurs ticket en une seule requête :
https://labs.ig.com/node/233

Testé et approuvé.

NB : Si j'avais du attendre la réponse de Chris, je pense que j'y serai encore

A vos IDE

Bien joué falex !
T'as des gains significatifs en terme de rapidité ?
T'as essayé d'envoyer une liste de deal id dans la requête ? Peut être que c'est comme les epics....

Liste de dealId : ça ne marche pas.

C'est vraiment un copié/collé du fonctionnement de l'interface web : Positions agrégées et clique sur le ticket et tu fermes tout ou partie.

Oui ça va encore plus vite (enfin visuellement sur l'interface web) donc je suppose qu'au niveau du système ça doit être pris ainsi.

J'ai souvent utiliser cette technique sur le web/iPhone et c'est beaucoup plus rapide que de fermer ticket par ticket.

Merci falex !

OK merci

Yop !

Je suis en train de développer une appli de reporting (que je peux publier si ça intéresse) et j'ai l'impression qu'il y'a un problème avec la requête sur les transactions. ig ne me renvoie que 20 trades alors que j'ai en passé plus (31 exactement) ce qui correspond à la première page du rapport disponible via la profit factor. Du coup ça fausse tous mes calculs.
Est-ce que vous avez le même problème ? Où est-ce que je m'y prend mal ?


---
Edit: je viens de tester avec la L3 et même problème

Re-edit: en fait je testais en démo, je viens de tester en réel et ça à lair d'être cohérent, j'ai tous mes trades ouf !
A mon avis ils sont en train de bricoler l'API chez ig

oui ça intéresse grave

Merci swing !

Je code en python sous linux donc je vais peut être avoir du mal à tester ton exemple.

De toute façon je pense que le prob viens d'IG, la requête ne me renvoie bien que 20 trades seulement en démo et tous les trades en réel.

J'essaie de publier d'ici la fin de la semaine, mais ne vous emballez pas hein, ça reste basique :musique:

Il me reste a coder le maxdd et un widget pour renseigner le capital initial.

Un p'tit teaser:

Spoiler:

teaser.png (115.97 Kio) Vu 701 fois

"your are the Best falex, I'm in love with me" :-p

On est jamais aussi bien servi que par soi même :musique:

Salut,
J'ai l'impression qu'il n'y a pas de limite sur la taille de l'history, ou alors assez grande, même en mode démo.
Obtenue avec : GET /history/activity/{lastPeriod}
C'est un peu plus compliqué à décortiquer mais il y a un gros avantage : l'heure des ouvertures et clotures de positions. Bien pratique pour les analyses a posteriori.

Swing> j'ai retesté avec un prog de dev pour tester les requêtes et celle sur les transactions renvoie bien uniquement 20 trades en démo. Et le bon nombre de trades en réel. Je pense vraiment que ça vient d'ig, je vais voir avec eux.

jized> en effet j'utilise la requête sur les activités pour de l'analyse journalière car effectivement la date/heure est une info bien utile. La requête sur les transactions je l'utilise pour de l'analyse sur plus long termes (semaine/mois/trimestre), l'avantage c'est que ça te renvoie directement le programmation neuro-linguistique en monnaie du compte, pas besoin de le calculer en local (avec le taux de changes et tout et tout)

beni_des_dieux> il y a 2 mystères pour moi chez ig :
- pourquoi ne pas avoir l'heure des transactions ?
- pourquoi ne pas avoir le programmation neuro-linguistique dans l'historique puisque le Taux de change est variable ?

Avec un pseudo pareil tu dois t'y connaître en mystères

Ah ah ! il faut que je change mon pseudo, il est trop prétentieux. Et puis ça date de DoD/Red Orchestra donc ça commence à dater

Je ne sais pas non plus pourquoi il n'ajoute pas l'heure dans les transactions.
Pour ce qui est de l'historique d'activités ça regroupe tout (ouverture fermeture de pos, changement de stop/limite), c'est peut être pour ça qu'il ne mettent pas le programmation neuro-linguistique...Enfin au pire ils mettent un champ vide (genre "-" ou "N/A" ou "coucouçava") pour ce type d'activités.

@Jized
- Je m'étais posé la même question en testant leur API : je pense que la granularité est à la seconde car leur politique d'exécution est d'avoir 99,x% des trades exécutés en moins de 0,1s. Donc il y a < 1% des trades qui sont exécutés en plus de 0,1s. C'est cette marge d'erreur qui les oblige à ne pas donner les millisecondes; Sans parler du fait qu'après il faudrait prendre en compte la durée pour que l'ordre depuis chez nous arrive chez eux, puis que notre ordre soit redirigé vers la meilleure "place boursière" pour son exécution.
- programmation neuro-linguistique dans l'historique : pour les mêmes raisons qu'au-dessus (et même en pire) -> c'est la donnée la plus volatile de toute (elle est résultante de l'agrégat de toutes les positions avec les Taux de change appliqués) et ils ne pourraient pas assurer qu'au moment exact de la transaction X la valorisation du compte est au niveau indiqué. Ils répondraient : "prenez le stream et vérifez de votre côté"