Список проголосовавших за комментарий "ignat, вы пробовали? У вас есть позитивный опыт?<br/> Ни мои обращения в саппорт, ни обращения на форуме не приводит к исправлению недостатков данного API. Последнее обращение уже более 20 дней без ответа. Формально никто мне из них ничем не обязан.<br/> По сути за год ни одной описанной мною проблемы, не были решены разработчиками. Исправления ошибок делали либо хуже и откатывались (история с OrderMoveFailed на форуме), либо не имело никакого эффекта. Решение всех проблем были только с моей стороны путем написания очередной обертки/проверяльщика.<br/> Звучит это общение примерно так<br/> Проблема: <strong>иногда</strong> UpdateOrder не приходит при перемещении ордера (вопреки документации). Аттачем все логи.<br/> Ответ: используйте OrderMoveSucceeded.<br/> Все, мы вам совет дали, а вы думайте дальше как хотите. Аргументы, что OrderMoveSucceeded не содержит ни цену заявки, ни нового OrderNo, потенциально ведет к проблеме с идентификацией обычной отмены не имеют значения. Конечно сделать так, чтобы заявленные события всегда приходили тоже не вариант, это же надо что-то делать с библиотекой.<br/> С учетом того, что OrderMoveSucceeded тоже не всегда приходит, то это вообще становится вероятностной оценкой, узнаете ли вы что что-то изменилось или нет.<br/> Вообще этот API пестрит тем, что в документации написано, что должно прийти из событий, а оно может прийти, может не прийти. По настроению.<br/> Порядок прихода событий тоже, как повезет. Т.е. сначала может прийти событие перемещения ордера по акциям, за ним тут же его отмена. Как интерпретировать? Если заявка старая снимается из ТС, то по-логике должна сначала отмена прийти, а потом постановка в новое место. в 98% случаев так, в 2% случаев не так. Отличить отмену по перемещению от легальной отмены из-за этих 2% у вас возможности нет.<br/> Если что-то пошло не так со стороны API (например Symbol Not Found), то сколько потом не запрашивай инструменты, поможет только перезапуск клиента.<br/> Ошибку с пропуском запрашиваемой истории с нового года чинят. Даже новую версию выпустили и отрапортавали об этом. Но ошибка и в новой версии такая же. Запрашиваете историю инструмента дневными барами до сегодняшнего дня, а вам может прийти история только до конца 2014 года, без 2015. <strong>Изредка</strong>, в 1 случае из 30. В зависимости от фазы их ТС дырки в барах есть на всех таймфреймах. И начинаем писать проверки, если история пришла древняя, то перезапросим историю. Упс, перезапрос истории инструмента возвращает ее опять в том же объеме, сколько не запрашивайте. Только перезапуск клиента.<br/> Ок, сервер упал/выключается/глючит (дисконект вам не придет от АПИ, пишите проверяльщик состояния сервера. У меня настроено на отсутствие любых изменений котировок или стакана в течение минуты по всем инструментам — зашибись способ, да?), переключились на резервный. Запросили историю инструмента. Упс… в истории дырки — сервера не синхронизированы. Упс… последнии лимитники застряли в ТС на основном сервере, а на резервном не отображаются, через АПИ не пришли. Потом через 3 часа после переключения на резерв выставились старые лимитники с основного сервера, где они стояли в Pending 3 часа и АПИ, подключенное к резерву, данных о них не получило, с какого перепугу?.. По вечерам разбираю лог и диву даюсь, чего там только могло произойти остается догадываться.<br/> Да блин, там такой ворох проблем, что у меня на 200 строк алгоритма 6000 строк обработчиков разных ситуаций.<br/> Где-то тут на СЛ был замечательный пост про сравнения АПИ, там красиво было про SmartCOM, как оно выглядит в теории и как реально сделать на практике."