Блог компании Os_Engine | AServer #10. Механизм запроса ордеров при перезагрузке и при частичной потере связи с биржей. Коннекторы к OsEngine #83

Бывают случаи, когда стандартные средства прослушивания статусов ордеров перестают работать… Случается это очень редко, но при этом последствия таких проблем значимы.

На данный случай в OsEngine существует отдельный механизм запроса ордеров. Запрашиваются они либо после переподключения коннектора, либо если API просто не присылает никакого ответа на выставленный ордер.

Называется этот механизм AServerOrderHub, ну или по-русски — хранилище ордеров под коннектором.

1. Нужные нам классы в проекте.

2. AServerOrdersHub. Регионы.

1. Constructor, Settings – настройки и конструктор.
2. Set orders – регион для приёма ордеров извне внутрь класса.
3. Main Thread – регион, в котором работает поток, обслуживающий класс.
4. Query orders after reconnect – регион для логики вызова события запроса ордера после переподключения коннектора.
5. Orders Hub – менеджмент ордеров. Сохранение и загрузка из файловой системы.
6. Query order status – регион для логики вызова событий запросов статусов ордеров.
7. Log – логирование.

3. AServerOrdersHub. Поток, обслуживающий класс.

0. В бесконечном цикле, раз в секунду бежим в три основных метода. Все они ниже будут описаны.
1. Если у коннектора есть разрешение на запрос статусов после реконнекта, идём проверять, нужно ли.
2. Если у коннектора есть разрешение на проверку потерянных статусов ордеров, идём сохранять активные ордера и разбирать очереди.
3. Если у коннектора есть разрешение на проверку потерянных статусов ордеров, идём проверять статусы активных ордеров.

4. AServerOrdersHub. Запрос ордеров после переподключения коннектора.

Через 15 секунд после включения коннектора вызывается событие GetAllActivOrdersOnReconnectEvent. Один раз после переподключения.

5. AServerOrdersHub. Хранение ордеров.

1. Массив с активными ордерами, за которыми мы следим.
2. Менеджмент ордеров. Их приём и распределение по массивам. Проверка статусов.
3. Сохранение и Загрузка массива ордеров в файловую систему.

6. AServerOrdersHub. Запрос статусов потерянных ордеров.

1. Метод, вызываемый из основного потока класса.
2. Методы разные для Market и Limit ордеров. Т.к. по ним надо запрашивать статусы в разных ситуациях.
3. События для запроса статуса ордера и отправки на верх события о том, что ордер потерялся окончательно.

При каких случаях вызывается статус Limit ордера:

1. Если в течении 5ти секунд не пришло никакого оповещения о статусе ордера, который отправил в API Os Engine.
2. Если никакого оповещения не приходит, вызываем: через 5ть сек. Через 5ть сек. Через 10 сек. Через 15 сек. Через 20 сек. После этого высылаем ERROR в экстренный лог. О том, что ордер полностью потерян.
3. Раз в пять минут запрашиваем статус лимитки. Просто по времени.

При каких случаях вызывается статус Market ордера:

1. Если в течении 5ти секунд не пришло никакого оповещения о статусе ордера.
2. Если никакого оповещения не приходит. Вызываем: через 5ть сек. Через 5ть сек. Через 10 сек. Через 15 сек. Через 20 сек. После этого высылаем ERROR в экстренный лог. О том, что ордер полностью потерян.

7. AServerOrdersHub. Активация в разрешениях коннектора.

На примере класса разрешения для ALOR:

1. CanQueryOrdersAfterReconnect – если True, хранилище ордеров будет запрашивать у реализации сервера через 15 секунд активные ордера.
2. CanQueryOrderStatus – если True, хранилище ордеров будет запрашивать статусы потерянных ордеров.

8. Создание хранилища в AServer.

1. Создание объекта AServerOrdersHub происходит в seter свойства ServerRealization.
2. Собственно, создание объекта хранилища ордеров и подписка на событие этого объекта.

9. Отдельный регион хранилища в AServer.

1. Обработка события: запрос всех активных ордеров после переподключения.
2. Обработка события: ордер потерялся окончательно. Произошло пять попыток запросить ордер. По нему нет ответа. Пора идти в журнал и править позиции руками.
3. Обработка события: по ордеру нет ответа. Нужно запросить статус у ордера.

10. IServerRealization. Конечный метод запроса активных ордеров после реконнекта.

1. Обязательный к перегрузке метод, в котором нужно делать запрос всех активных ордеров с биржи.
2. Обязательный к перегрузке метод, в котором нужно узнать статус ордера.

11. ALOR. Пример. Конечный метод запроса активных ордеров после реконнекта.

1. Если ордер не активный – не пропускаем. Надо высылать наверх только ордера со статусами Active / Patrial / Pending.
2. Высылаем наверх. Стандартно.

12. ALOR. Пример. Конечный метод запроса статуса потерянного ордера.

1. Сначала мы находим ордер, который у нас запрашивало хранилище.
2. Если вдруг ордер со статусом Done или Patrial, то нужно загрузить ещё по этому ордеру MyTrades. Обязательно! Иначе автотест Order_10 не пройдёт!

Удачных алгоритмов

Пост из серии «Коннекторы к OsEngine».

Серия о том, как стать настоящим программистом и изменить свою профессию.

Оглавление и смыслы здесь: https://smart-lab.ru/company/os_engine/blog/959953.php

Что почитать по алготрейдингу?

1) Сборник статей по парному арбитражу: https://smart-lab.ru/company/os_engine/blog/948250.php

2) Сборник статей по валютному арбитражу: https://smart-lab.ru/company/os_engine/blog/965051.php

3) Сборник статей по индексному арбитражу: https://smart-lab.ru/company/os_engine/blog/997533.php

4) Сборник статей про индикаторы и роботы к ним: https://smart-lab.ru/company/os_engine/blog/966919.php

OsEngine: https://github.com/AlexWan/OsEngine
FAQ: https://o-s-a.net/os-engine-faq
Поддержка OsEngine: https://t.me/osengine_official_support

https://smart-lab.ru/company/os_engine/blog/972745.php