Сертификация торговой системы

Ну да. Я понимаю. Я это виду к тому что в основной клиринг когда у инструмента смениться isin_id он так же будет обновлен, т.к. поиск инструмента для обновления идет по CreateSecurityId(secCode, "RTS").
Вот...

isin_id не будет обновлён.
более того - уже говорилось, что isin_id может остаться прежним, а session_id смениться.

Странно. А зачем же он тогда передается в GetSecurity? Он ни как не исп?
Ну значит надо при обновлении присваивать его... И ни какой проблемы...

Кто вам сказал? Я специально звонил. Мне в тех поддержке сказали что и session_id и isin_id меняются.

https://stocksharp.ru/posts/m/14734/

Т.е как я понимаю в данный момент isin_id в методе GetSecurity не используется вообще...
Все понял...

Конечно нет. Это чисто плазовская вещь. Сейчас isin-id маппится на nativeId, что передается в GetSecurity. Но nativeId есть не всех коннекторов (у Квика например нет), и nativeId предполагает константность, а в плазе он меняется. Следовательно или переделывать BaseSecurity или вообще не использовать параметр nativeId и сделать маппинг прямо внутри PlazaTrader. Если появится еще какой-то коннектор, который будет так же менять значения своих идентификаторов в течении торгов, то тогда имеет смысл его занести в BaseTrader. А пока пускай он будет там, где он нужен только сейчас.

Все понятно...
Ну вот как раз _isinIds переделать в SynchronizedDictionary какой нить.. НУ как вы и предлагали собственно...

Еще раз говорю "как мне последний раз сказали в поддержке")) например ShortIsin не меняется, можно его в качестве ключа использовать...

А это поле есть в стаканах, в сделках, заявках? Ключ должен быть не только уникальным и неизменным, но еще и присутствовать везде.

Нет просто вопрос касался инструментов только) Проблема же с ними)

Нет проблем. Есть задачи. Задача - чтобы обновлялись данные по инструменту. Как стаканные, так и ласты. Все данные, вообщем.

Хммм... Нет Михаил просто до этого мы разговаривали об инструментах только... Разве все остальное обновляется с ошибкой?
Я прост не в курсе был...

Все остальное просто перестает обновляться. Это ошибка?

Ну... Да) Ошибка)))
Нет ну в принципе понятно, вы смотрите на плазу так сказать всеобъемлющем взглядом...

мы смотрим на плазу взглядом чтобы работало.
а не "сделать что-то не знаем что, но всё равно чтоб не работало"

Александр это в мой огород камень?
Я вот например понятия не имею что и как у вас там в BaseTrader.
И тем более почему стаканы, заявки и т.д. ставятся в соответствие с инструментом по isin_id.
Просто ссылкой на объект Security это сделать нельзя было?

Не в ваш.
Цель того чтоб это починить - не чтобы закрыть таск. А чтоб действительно работало как нужно.

На биржу вы что передаёте? Security? Везде - в стаканах, сделках, заявках используется isin_id. Именно поэтому и нужен маппинг в PlazaTrader.
Биржа о Stock# и Security знать не знает. Ей важен лишь номер инструмента, что вы передали. Именно по нему идёт сделка на бирже.

Ну да. Это я понимаю.
Ну т.к. у нас в Stock# есть Security - класс общий для всех торговых систем, на него и надо ссылаться. А при отправки запросов бирже использовать те поля этого класса которые нужны биржи.
В случае плазы можно наследоваться от BaseSecurity и расширить этот класс isin_id и еще если тем что нужно.
А можно сделать маппинг и исп в качестве колюча объект Security а в качестве значения тот же isin_id ...
Но в любом случае ссылаться везде на Security.

Это мой взгляд на устройства такой системы. Если вы его считаете неверным, то просто ваше видение расскажите... Это нормальная практика проектирования: сначала обсудить и подумать, а лишь потом кодить...

Мы вроде это обсуждаем и мусолим уже 2 месяца.

У нас есть класс Security, при работе со стаканами и т.д. и т.п. мы на него и ссылаемся.
Что такое BaseSecurity я не знаю, в Security добавлять новое поле смысла нет, т.к. его никто кроме плазы использовать не будет.

Поэтому и предлагается сделать маппинг внутри PlazaTrader.

P.S. Михаил как раз об этом вчера и писал

BaseSecurity - это базовый класс всех инструментов. О нем Михаил упоминал ранее. От него можно наследоваться и создать например PlazaSecurity. Просто маппинг как то не очень похож на решение из ООП...
А если необходимо будет добавить еще какое нибудь поле которого нет в BaseSecurity? Еще одно соответствие лепить?((

Я окончательно запутан...

Базовый класс - Security, другого класса инструментов нет (ну кроме BasketSecurity).

Например, какое поле вам может ещё потребоваться для реализации шлюза Плаза2?
Лепить для каждого шлюза свой инструмент - как раз не самый лучший вариант, ибо надо будет везде приводить, проверять на тип.
А это скорость.

Зачем такое городить, если решение с маппингом - вполне очевидное и быстро работающее?
К тому же реализация занимает малое время.

Так. Давайте в очередной раз попробую объяснить.

Внутри S# мы работаем с понятием Security - оно используется при регистрации заявки (RegisterOrder), оно используется в стакане (MarketDepth).
Везде где вы в S# работаете с инструментом - вы работаете с Security.

Биржа о Security ничего не знает, она знает лишь о isin_id и sess_id. Именно поэтому для того чтобы подавать заявки на биржу, идентифицировать инструменты в заявках, пришедших с биржи, строить стаканы по инструменту, прешедшему с биржи, нам надо взаимно однозначно сопоставлять isin_id и sess_id с Security.

Для этого и должен быть сделан простейший маппинг.

Например поле ShortIsin. Т.к. оно не меняется при смене сессий. Именно по нему можно обновлять инструмент.
Т.е. получаеться у нас есть уже 2 поля которые есть только у плазы isin_id и ShortIsin

ShortIsin используется где-то при подаче заявок и т.д. и т.п.?
Это просто secCode, который мы проставляем в Security.Code

Ещё попытка? :)