Создание робота (подскажите)

ignat, мне кажется это из разряда вредных советов. Простое API только по документации. Если бы все работало четко, как в документации, то да, не сильно сложно. Говорю, как человек, который уже год ловит баги в Смарткоме. Каждую неделю что-нибудь интересное вылезает.

Eduard, так напишите в саппорт айти — поправят. На мой личный взгляд — они стараются очень быстро исправлять баги. Либо сюда напишите, мне любопытно, у меня смартком работает очень стабильно.

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

Eduard, у меня UpdateOrder приходит всегда. Когда-то давно он терялся, но тогда же и починили. Да, иногда статусы ордера приходят вразнобой — сначала оупен, потом отмена — для мува, но каким-то образом я это решил в коде. Как — сейчас сам не помню и сразу не могу понять в коде, но данная проблема меня не беспокоит и решается несложно. Внутренние события смарткома не использую, обрабатываю только UpdateOrder.
Символы инструментов я проверяю при старте и иногда действительно они не приходят (редко), тогда робот останавливается и мне приходится его запустить еще раз.
Событие дисконнект приходит всегда, если сервер выключается.
Ордера иногда застревают в пендингах (очень редко) — вижу их в терминале и снимаю руками или звоню в саппорт, чтобы точно знать, что они сняты.
А с историей не работал, поэтому говорить не буду.

ignat, да вы фартовый :) А мне поддержка пишет, что UpdateOrder является необязательным к получению от API SmartCOM, что я вижу с завидной регулярностью. Вижу, что лог клиента пишет, мол перемещение завершено, но в логе событий чисто. Сообщения на эту тему висят в двух последних страницах форума поддержки.
Аналогично события UpdateOrder для отмены ордеров (в случае CancelOrder) не является обязательным (офф.ответ поддержки). Ума не приложу, как вы не обрабатываете эти события.
У меня был робот, который совершал по 300-400 сделок на инструменте, вот там вообще веселуха была, когда 2% событий не ловились смарткомом.
Про Pending это хорошо сказано, если есть возможность смотреть в терминал весь день. Тут наверное мне робот был бы уже не нужен. А вот если нужно робота без присмотра оставлять, тогда сложно становится.
Кстати останавливать робота не обязательно по символам. Ловим исключения по событиям:
ListenTicks(Symbol);
ListenQuotes(Symbol);
ListenBidAsks(Symbol);

и достаточно создать новый класс StServerClass(). Старый не нужен. Это перезапускает локальный сервер и можно заново подписываться на события и регистрировать обработчики. Как раз к этому моменту еще иструменты могут быть неинициализированы, поэтому и проблем в этой части мало. GetSymbols (офф.решение от поддержки) только замедлит запуск/перезапуск.

Eduard, я не знаю, фарт ли это )
В сессию бывает до 3000 заявок, большинство — мувы. Если бы терялись, я бы с этим точно столкнулся, но у меня нет потерь ни от потерянных апдейтордер, ни от неправильного порядка прихода статусов.
И заморачиваться с классами не хочется, у меня один класс в роботе, один поток и проще ткнуть кнопку старт еще раз, когда символ робот не получил.
Кстати, вот как раз создать новый объект StServerClass() смартком не даст — что-то там с доменами приложения. То есть невозможно обнулить объект и пересоздать, надо закрывать приложение и открывать опять. Во всяком случае, раньше было так, с тех пор не менял этот кусок кода.

ignat, smart-lab.ru/blog/199423.php
вот то сообщение. Со временем я понял, насколько оно правдиво :)
Постоянно приходится писать обертки.