Missing fields in TRADE stream

16 posts / 0 new
Last post
fastiq
Missing fields in TRADE stream

We have noticed that the limitLevel and stopLevel fields in the CONFIRMS and WOU objects received over lightstreamer aren't being populated. Not sure if this has been noticed yet but it would be great if these fields were made available, as at the moment we cannot use the stream to correctly reconstruct order state, and have to revert to a manual REST lookup.

Chris
Re: Missing fields in TRADE stream

Hi fastiq

I've tested this in Demo and it's working ok. I've amended some pending orders, stops and limits etc, and I can the values in CONFIRMS and WOU.

Could you try this in the new Streaming companion to see if it works for you? The companion is available here: https://labs.ig.com/sample-apps/streaming-companion/index.html

Let me know if you still see the problem, and if it's on Prod or Demo.

Chris

fastiq
Thanks Chris, those fields do

Thanks Chris, those fields do seem to be there; but you have left me questioning my sanity as I swear they were missing last week :)

While we're on the topic, could I put in a request for an extra field on the TRADE stream that represents the type of the order? (LIMIT/STOP). It would be the final piece in the puzzle to let us completely construct an order from state delivered over the stream.

APItrader
There are already the fields

There are already the fields "limitLevel," "limitDistance," "stopLevel," and "stopDistance." Can you not piece together the information you want from those?

fastiq
We've also just noticed that

We've also just noticed that the expiry date of an order (the goodTill property from the REST API) does not get delivered as part of the stream. Could we request that this be added?

We would also appreciate it if the type of order (limit/stop) be added to the stream (requestType from the REST API) as this will allow us to classify any new orders that are created purely from the stream rather than having to supplement with a REST lookup.

Chris
Expiry date of an order

Hey Fastiq,

Thanks for the feedback. We're going to look into getting these added.

Cheers,
Chris

APItrader
I agree that it wouldn't hurt

I agree that it wouldn't hurt to have the order type included explicitly, but can you not already determine the order type from the stream data? If "limitLevel" or "limitDistance" is set and non-null it's a limit order, if "stopLevel" or "stopDistance" is set and non-null it's a stop order. Am I missing something?

fastiq
We had looked into this,

We had looked into this, except the "limitLevel" and "limitDistance" (and associated stop fields) are for any attached profit targets/stop losses, not the root order itself. Thanks for the suggestion though!

APItrader
You are absolutely right and

You are absolutely right and I agree that the "order type" is needed in the TRADE packet.

fastiq
Any updates?

Hi Chris,

Any update on the inclusion of these fields? Our current work around is to pull down all working orders over the REST API after receiving an update over the stream just to get the order type and expiry date (of GTD orders) which feels like a bit of a heavy handed solution. This is done as we can't necessarily guarantee that orders are being placed/amended by our application (otherwise we could grab these details at the order creation/modification stage).

Chris
Any updates?

Hi Fastiq,

It's still on our list of things to develop, but work hasn't begun on this yet unfortunately.

Thanks,
Chris

falex
no update from one year.

no update from one year.

The goodtill filed is realy mandatory, I think to have all information in one message.

Chris an update ?

Chris
no update from one year.
Hi, We would like to look into this further. In order to do so please can you let us know what you need the Reconstruct order state and good till filled message for as the team would like to know what value you get at of these fields. Also so that I can give the team as much feedback as possible please can you confirm the following: - Are the order type and goodtill fields required on WOUs, CONFIRMS or both? - Do yiy need to reconstruct orders after a “working order fill” WOU message? - As an alternative to retrieve the list of working order/position - if you keep track of placed orders (e.g. store them in a cache), would that enable you to reconstruct the order when you receive a confirm? I look forward to hearing your feedback as this would be invaluable to help the API offering develop. Thanks Chris
APItrader
> if you keep track of placed

> if you keep track of placed orders (e.g. store them in a cache) would that enable you to reconstruct the order when you receive a confirm?

In my opinion this is not a good idea. The server should always confirm what it has actually done, then the user can verify that it agrees with what they requested (assuming they keep track of it). The user should not have to assume/hope that the server always does what it is asked to do.

falex
Hi Chris,

Hi Chris,

About the WOU message : the good-till and the value is usefull to have ine one message all the information about that ticket.

When I request (REST) for a Working order, the system receive an WOU message. But because therer the missing information about the good-till-date, I can't "print" this information. So I need to process a REST request just after receiving the WOU message.
VEry anoying and boring.

The goal is too be able to create, localy, all the Working order list just by receiving the WOU message (has it is possible with the OPU/CONFIRMS messages).
And that's logical. REST is a non real-time system (HTTP based) so very usefull to send "order" or "action" and the LS stream are really has en event programmatics principle.

WOU and OPU has to be at the same level of information to be able to do the same "job" on each type of message.
Ther is a lot of illogical way that "At market" order and Working order, works.
The WO has a lot of non explicit message error and some usefull error message respond by REST Htttp answer.
The "At market" order, has 99% of the time no message error (HTTP 200). The errors message are stream by OPU or CONFIRMS message.
This is quite strange because the way of working are quit different for something that is so closed, one from each other.
You have too choose wy way or an other but not both direction.

My usage is really a mix of REST and LS message : REST to send the order Stream to update fields (has you do within the puredeal web plateform) and I think that is the way you imagine the public API (it's my feeling).

hI hope this help you to understand our requests.
If needed I can go deeper.

falex
My comment and answers to

My comment and answers to your question

> - Are the order type and goodtill fields required on WOUs, CONFIRMS or both?
falex : for my usage : WOU is mandatory, CONFIRMS will be appreciate.

> - Do yiy need to reconstruct orders after a “working order fill” WOU message?
falex : I don't understand the question ?
What I can say : When an order is fill it is considered as a normal ticket, if I want to track the "source" (ie. WO r "At market") I can use the dealId.

> - As an alternative to retrieve the list of working order/position - if you keep track of placed orders (e.g. store them in a cache), would that enable you to reconstruct the order when you receive a confirm?
falex : Yes could help but in this case, what will be the usage of WOU message ?

My nowadays problem is more to have the good-till information to create my table, and to be able to change this value, only by receiving the WOU message, has I do with OPU message.

Log in or register to post comments