cityindex/CIAPI.CS — Issue #102: Missing OCO
Author: mrdavidlaing
Created: 2012-01-09 12:44:08+00:00
State: open

Dear All,

This doesn’t happen on the IFE which makes me believe the API is OK.
Could you double check your tests please David?

Many Thanks,
Pete

From: Peter Dale
Sent: 03 January 2012 11:52
To: David Laing; Jose Muñiz; Chuck Uzoka; Prasanth Sasikumar; Victoria Bello; Sareen Patel
Cc: Belatrix Dev; James Musson; Timothy Snow; 'Sky Sanders'
Subject: RE: Changes to Orders Service?

Hi Prasanth,

Does this get tested during the regression of the ITP (Amending an OCO)?

If not can we please add it and test it, if so..can we establish why it wasn’t caught in the recent PP regression on 1244?

Many Thanks,
Pete.

-----Original Message-----
From: David Laing
Sent: 28 December 2011 12:53
To: Jose Muñiz
Cc: Belatrix Dev; James Musson; Timothy Snow; 'Sky Sanders'
Subject: RE: Changes to Orders Service?

Jose,

Thanks for that update - its a lot clearer what you are talking about now.

Since you can reproduce the problem via the Js test harness, I think its safe to say that the problem isn't in the CIAPI.CS library.

In fact, if the API hasn't changed (I don't think it has), then is possible that the change is in one of the backend order processing services - (Instruction Processor springs to mind).

James or Tim is going to have to help you out there.

Regards
David

-----Original Message-----
From: Jose Muñiz [mailto:jmuniz@belatrixsf.com]
Sent: Wed 12/28/2011 12:11 PM
To: David Laing
Cc: Belatrix Dev; James Musson; Timothy Snow; 'Sky Sanders'
Subject: RE: Changes to Orders Service?

David,

The problem does not seem to be related to changes in the API. If we had to guess, it looks like something in the server itself changed, since some data we could access before is no longer accessible. I provide a sample for the test harness:

var userName = "xx790537";

doPost('/session',{ "UserName": userName, "Password": "password"}, function (data, textCode) {

setRequestHeader("UserName", userName);

setRequestHeader("Session", data.Session);

// Get all orders. One of them is #469636714

// doGet('/order/activestoplimitorders?tradingaccountid=400195958');

// Get order #469636714. It's either a stop or a limit on an active position (#469636713), and has a related OCO order, #469636715.

// doGet('/order/469636714/activestoplimitorder');

// Try to get order #469636715. This worked before, and returned the full order, but now we get null instead.

doGet('/order/469636715/activestoplimitorder');

});

As the comments mention, OCO pairs were fully accessible before, and now we can retrieve only one of the orders, and requests for the other one do not fail, but return null instead of the order DTO. Unfortunately, we are not able to tell when did it change, since we noticed it after we refactored our exception management code and started receiving null reference exceptions.

I hope this helps you pinpoint what we're talking about, since our previous mail was probably not clear enough.

Regards,

José Muñiz
Software Developer

Belatrix Software Factory

jmuniz@belatrixsf.com

Skype: j.m.muniz

www.belatrixsf.com

From: David Laing [mailto:David.Laing@CityIndex.co.uk]
Sent: miércoles, 28 de diciembre de 2011 06:33
To: Peter Dale; Belatrix Dev; James Musson; Timothy Snow; Sky Sanders
Subject: RE: Changes to Orders Service?

Jose,

There were changes to the DTO names in release 13 of the CIAPI.CS library; so its possible that this is where the problems are.

The way to test if the data is missing from the API or the CIAPI.CS library is to check the JSON that is returned from the server when retrieving orders and see if all fields are there or not. (view the CIAPI.CS log output for full details of all the HTTP requests being made).

If you can email me or Sky some relevant log output, and the specific DTO properties which seem to be missing we'll be able to help further.

Regards

David

From: Peter Dale
Sent: 26 December 2011 19:44
To: Belatrix Dev; James Musson; Timothy Snow; David Laing; Sky Sanders
Subject: FW: Changes to Orders Service?

Dear all..as per Jose's email below it seems not all orders are coming back as expected in the pp environment.

James,

Could you please confirm no changes are in preprod that would affect the order gateway?

David/Sky,

Would any changes in the last release have made the behaviour Jose is describing below occur?

Jose,
The page needs to work as originally described, as it once was.

Cheers,
Peter

_____

Hi Pete,

We found that an important behavior of the orders service no longer works as it did and it breaks a few things on our side, so we thought it was important to let you know.

It seems that the orders service no longer allows retrieving orders which are the "other" of an OCO pair as it did before. This means that only a few of the fields of that order are available through the ApiBasicStopLimitOrderDTO object (OrderId, TriggerPrice, Quantity), and thus, the Orders page (the one that allows creating or updating existing entry orders) has no way of retrieving the second order of the OCO pair or its stop & limit, meaning that once an order is saved, you cannot update it properly. Also, as the image shows, the Orders on Position page is no longer useful because of the missing data (the first row is the "missing" order, the one built from an ApiBasicStopLimitOrderDTO object). In addition, the Orders and Positions page is somewhat "deceiving", because the big "plus"
button does not let you to add more than two orders, since the server forbids such thing.

What should we do with this page? Which are the new requirements for this page? How can we minimize the impact of these changes on the Orders page, and possibly other places we haven't found yet?

Regards,

cid:image001.png@01CCC3CB.B4F90DA0

José Muñiz
Software Developer

Belatrix Software Factory

jmuniz@belatrixsf.com

Skype: j.m.muniz

www.belatrixsf.com