WOU + OPU clarification

7 posts / 0 new
Last post
BAMBOOLDN
WOU + OPU clarification

When I use the REST API /workingorders/otc to create a Working Order, it gets created successfully, but then the STREAMING API is apparently sending me both a WOU (with status OPEN) AND a OPU (with status OPEN). Is this an expected behavior?

Ideally I'd like to only get a WOU when I open my Working Order, and only get an OPU when the Working Order triggers the position.

EDIT: Actually I do not get WOU at all. Everything is an OPU even opening a working order.

vimus
Yes, you get both the WOU and

Yes, you get both the WOU and OPU into the OPU. However, the JSON schema is different.

My understanding is that, historically, there were some changes with the WOU coming either through WOU or OPU. I think you can find some discussion here also.

This is not ideal...

BAMBOOLDN
Actually no I only get an OPU

Actually no I only get an OPU. I think this is a bug from IG. I opened a ticket and they told me this is currently being investigated.

vimus
Interesting... Could you post

Interesting... Could you post here some details:
- JSON sent,
- JSON received through LS
- bid & ask at that time.

I am curious if we are refering to the same thing.

Thanks

BAMBOOLDN
So basically, I am

So basically, I am subscribing to both WOU and OPU with the NodeJS Lightstreamer library.

Then,
When I use the Web platform to open a working order, and I receive an OPU.
When I use the Web platform to open a position, I also receive an OPU.

This is an exemple of JSON I receive when opening a working order:
{"dealReference":"xxxxxxxxxxxx","dealId":"yyyyyyyyyyy","direction":"SELL","epic":"IX.D.DAX.IFMM.IP","status":"OPEN","dealStatus":"ACCEPTED","level":12310,"size":1,"timestamp":"2018-04-06T12:46:50.000","channel":"WTP","expiry":"-","currency":"EUR","stopDistance":8,"limitDistance":10,"guaranteedStop":false,"orderType":"LIMIT","timeInForce":"GOOD_TILL_CANCELLED","goodTillDate":null}

This is an exemple of JSON I receive when opening a position:
{"dealReference":"xxxxxxxxxxxx","dealId":"yyyyyyyyyyy","direction":"SELL","epic":"IX.D.DAX.IFMM.IP","status":"OPEN","dealStatus":"ACCEPTED","level":12265.5,"size":1,"timestamp":"2018-04-06T12:50:32.000","channel":"WTP","dealIdOrigin":"yyyyyyyyyyy","expiry":"-","stopLevel":12305.5,"limitLevel":12205.5,"guaranteedStop":false}

All of them are considered as OPU.

One thing that I could do is say that if dealIdOrigin is not present in the JSON, then it's a WOU, otherwise it's an OPU, but that would really be a very dirty hack.

vimus
Oh, I see what you are saying

Oh, I see what you are saying.

Basically (as I am using the text mode), the LS client will receive the following message:

1,1|CONFIRMS|OPU|WOU

So the JSON payload from WOU is coming through the OPU channel.

You are right in testing the JSON , but need to consider the fields that are specific to WOU, such as order type , etc. Have a look at the LightStreamer reference page.
More generally, even with mature APIs , you need to test whatever you are receiving as payload against expected JSON schemas. Then process the JSON. At a minimum this will save you some hours identifying why your app is breaking when for example WOU is coming through OPU :))
Any decent JSON parser will make this very easy.

Hope this helps.

BAMBOOLDN
Yes, this is what I am doing.

Yes, this is what I am doing. I am checking for orderType in the JSON payload to figure out if it's a WOU or an OPU.

But still this is not the expected behaviour and WOU should come through the WOU channel. Hopefully this will get fixed at some point :)

Log in or register to post comments