Метод для получения информации по номеру заявки

[NikitaMelnikov]

Новый метод /orders/?orderId={ORDER}, в котором можно получить статус заявки

[finico]

Более подходящий для REST будет /orders/{orderId} (или /orders/:orderId, кто к какой записи привык)

[v-crys]

Это работает? На шарпе написал следующий код, валится с ошибками:

public async Task<Models.Order> OrderIdAsync(string id)
        {
            var idParam = HttpUtility.UrlEncode(id);
            var path = $"{Endpoints.Orders}?orderId={idParam}";
            var response = await Connection.SendGetRequestAsync<Models.Order>(path).ConfigureAwait(false);
            return response?.Payload;
        }

В чем может быть дело, что я не так понимаю?

[NikitaMelnikov]

@v-crys задача еще не сделана

[mlshvdv]

@NikitaMelnikov есть ли примерные сроки?

[NikitaMelnikov]

Пока что нет

[Jokero]

Я крайне удивлен, что такого базового метода нет

[tolk-vm]

Тем временем, уже больше года тикету 😐

[kitMP]

Стоит ли удивляться, если другие базовые вещи (выдача дневных свечей через rest) до сих пор не починили? Тоже уже скоро год исполнится..

[tolk-vm]

Я думаю, это всё "когда-то" будет в версии OpenAPI v2. Практически все тикеты заканчиваются тем, что "в v2 учтём". А когда будет v2, и будет ли, уже больше года можно только гадать (

[aiptasia]

@NikitaMelnikov , есть ли смысл ждать данный метод в OpenAPI v1 ?

[AlexanderVolkovTCS]

@s-golikov Добрый день, в v1 - нет.

[aiptasia]

@AlexanderVolkovTCS , спасибо. Появилась ли информация о примерных сроках выхода APIv2? Без возможности проверки статуса ордера написать хоть сколько-нибудь работающего бота не представляется возможным.

[polkila]

@AlexanderVolkovTCS , спасибо. Появилась ли информация о примерных сроках выхода APIv2? Без возможности проверки статуса ордера написать хоть сколько-нибудь работающего бота не представляется возможным.

Рассказываю о своём супер-способе) После создания заявок известен orderId для каждой заявки. Значит:

1. Собираю список заявок, которые ещё не исполнились;
2. Также собираю список FIGI от этих заявок;
3. Нахожу datetime_min (дата-время самой ранней неисполнившейся заявки минус 1 минута);
4. Нахожу datetime_max (дата-время самой поздней неисполнившейся заявки плюс 1 минута);
5. Если есть неисполнившиеся заявки, то формирую запрос к "/operations"; а) Если в списке FIGI только одна уникальная штука, значит, указываю его при обращении к "/operations". б) Также указываю datetime_min и datetime_max. Так минимизируется объём ответа от API.
6. Получаю список и нахожу соответствие между orderId и operation.id;
7. Проставляю статусы заявкам в своём списке.

Эта проверка запускается примерно каждые 30 сек.

Часто бывает так, что лимитная заявка исполняется сразу. Поэтому опрашиваю "/operations" через 10 секунд после создания заявки с указанием конкретного FIGI и datetime_min—datetime_max. Работает)

[AlexanderVolkovTCS]

@s-golikov Работаем, но к сожалению сроки не называем

@polkila для большого количества выставленных торговых поручений алгоритм оптимальный!

[aiptasia]

@polkila , спасибо за подробное описание! В этом алгоритме для меня слабым местом является необходимость обращения к endpoint'у /operations. Судя по тому, как работают терминал и мобильное приложение, в инфраструктуре TCS активно используются очереди, ну и как следствие имеем eventual consistency. Видимо именно очереди там являются узким местом, и в данном случае после выполнения заявки нет гарантированного временного интервала, в течение которого исполненная заявка отразится в операциях.

На данный момент я полагаюсь только на endpoint /orders, у меня одна горутина раз в секунду опрашивает этот endpoint, другая выставляет лимитную заявку и ждет, когда она исчезнет из списка активных ордеров. В таком случае моя проблема заключается в том, что я не могу снять заявку вручную - программа будет считать, что заявка исполнилась, и не могу написать нормальный алгоритм отмены заявки, т.к. опять же, нет гарантии, что заявка будет именно отменена, а не исполнена. И даже если я добавлю к этому параллельное отслеживание marketdata, все равно гарантий корректного определения статуса нет.

Использовать большие таймауты тоже нет возможности, т.к. я прорабатываю скорее скальперские стратегии, нежели свинг.

[polkila]

@polkila , спасибо за подробное описание! В этом алгоритме для меня слабым местом является необходимость обращения к endpoint'у /operations. Судя по тому, как работают терминал и мобильное приложение, в инфраструктуре TCS активно используются очереди, ну и как следствие имеем eventual consistency. Видимо именно очереди там являются узким местом, и в данном случае после выполнения заявки нет гарантированного временного интервала, в течение которого исполненная заявка отразится в операциях.

На данный момент я полагаюсь только на endpoint /orders, у меня одна горутина раз в секунду опрашивает этот endpoint, другая выставляет лимитную заявку и ждет, когда она исчезнет из списка активных ордеров. В таком случае моя проблема заключается в том, что я не могу снять заявку вручную - программа будет считать, что заявка исполнилась, и не могу написать нормальный алгоритм отмены заявки, т.к. опять же, нет гарантии, что заявка будет именно отменена, а не исполнена. И даже если я добавлю к этому параллельное отслеживание marketdata, все равно гарантий корректного определения статуса нет.

Использовать большие таймауты тоже нет возможности, т.к. я прорабатываю скорее скальперские стратегии, нежели свинг.

Согласен со всем перечисленным. Ну, ждём! Пока что свинг)