Метаданные, код MODAIB-2

[akumidv]

Модуль, при запуске должен инициализировать в ядре специальный класс агентов.
Этот класс должне быть обычным классом приложения. Возможно его в приложении надо создавать - но его структура жестко привязывается к модулу.

Назначение - агента можно создавать в регистри, или вызовом специальной утилиты (но в регистри сразу будет работать модель безопасности, а это важно)

Структура данных класса агента:

• [id] id агента (автоматический)
• [code] код (агента)
• [version] версия агента
• [name] наименование агента
• [description] описание агента
• вид агента:
  • import - импортирует сигналы из внешней системы
  • export - экспортируе сигналы во внешнюю систему
  • gibrid - гибридный он и выдает сигналы и получает их для внешней системы
  • internal - внутренний.
• [type] тип агента (пока по идее достаточно только подключаемого js) - тип агента по идее какой-то расширяемы справочник регистрируемых типов - которые можно подключать отдельно (возможно нужна реинициализация модуля)
  • js
  • python (пока можно не делать, по идее можно в js запихать, но может можно как-то вызывать)
  • tensorflow (по идее можно веншюю модуль запуска, иначе надо библиотеку ставить,
  • веб-сервис
• [path] путь к исполняемому файлу с кодом агента (пока основное) - или скорее папке с агентом. Т.к. по идее агенты это отдельные проекты, которые могут содержать зависимости библиотек, устанавливаемых как npm install . Вероятней всего это имя приложения агнета??? из таска MODAIB-5
• [run] запустить/остановить (логическое поле или БП на логическое поле потом повесим)
• [runResult] результат запуска (обновляется при каждом запуске)
• [dateCreate] дата создания
• [dateRun] дата последнего запуска (не передачи сигналов к нему, а именно инициализации запуска когда обнаружено значение запустить)
• [runResult] текст последнего результатов запуска (логи с ошибкой например при инициализации)
• [signalParamWaitFinish]требуется ли дожидаться окончания выполнения агента (безсигнальные агенты по идее могут ничего не выдавать) -но в любом случае он должен сообщить, что закончил. Иначе его надо вырубать по таймауту
• [signalParamWaitResult]требуется ли дожидаться появления сгиналов для выполенения для передачи следующего
• [signalParamQueue] формировать ли очередь входных сигналов, если требуется ожидания выполнения следующего экземпляра агента.
• [input] сигналы входные
  • нужно ли в описании агента или мы их автоматически регистрируем при инициализации- из примера это поле "callback":"OnQuote".
  • нужно ли кроме сигнала ещё какие-то значения парамеров указывать для сигнала - например ниже из пример поле "secCode":"SBER" - т.е. только на акцию сбербанка агент заточен. Можем ли мы регистрировать одного и того же агента на одни и те же сигналы, но разные параметры. Или пока параметры лучше отложить.
• [output] сигналы выходные
• [memoryType] агент с памятью/без памяти и параметры сохранения
• [none] нет сохраняемой памяти
• [stop] сохранять память при остановке системы
• сохранять или нет периодически память и значение периода в секнудах(микросекундах) для сохранения (не сохранять, по 1 раз в секнуду (т.е. когда больше секунды прошло)
• [count] сохранять или нет по счетчику передачи сиганлов (в т.ч. по каждому сигналу - т.е. 0 не сохранятт, 1 по каждому, по 2 через один и т.д.)
• [memoryTypeValue] значение для типа памяти - время или счетчик
• [memoryValue] поле хранения памяти (json объект), если сохраняем память при остановке системы или по периоду => ПОСТАВИЛ ТИП Custom type - Но по идее нужен JSON ⚠️
• [runInit] нужна инициализация или нет при старте - не понятно нужно или нет, по идее контрактом агента должна быть эта функция, но он просто её может сразу возвращать.
• нужен ли деплой или нет (например если агент содержит свои классы для хранения обработанных сигналов - их храним в нейспейсе агента - т.е. агент это простейшее специализированное приложение/метаданные иона?) - не стал ставить атрибут - по идее если агент это приложение - мы его инициализировали.

Вопрос только в том как регистрировать сигналы - по идее их можно тоже в объекте указывать. Справочник сигналов, их добавлять входные и как называть выходной сигнал

Ещё вопрос по сигналам - по идее часть сигналов - это объекты класса. Т.е. при получении мы их должны сохранить в системе. А часть это просто информация для других агентов и сохранения не требует.

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

И тогда эти классы можно поключать к агенту - как входные и выходные сигналы. Сигналы с данными - будут иметь структуру класса - это удобно.

Что делать с информационными сигналами пока не знаю. По идее это тоже класс - чтобы структура его была понятна. Вопрос ещё в том, что сигнал - это будет весь JSON объект - т.е объект класса со всей структурой связанных с ним объектов.

Пример тика (тик значение, объект) по сигналу по трейдингу (в трейдинге тик - это факт изменения сигнала - он может быть периодическим - т.е. тупо раз в секнуду или минуту мы подаем, или апериодическим - т.е. по факту изменения) - по идее это тоже свойство сигнала. Для периодического ещё период надо указывать, если в период не поступило - передавать ошибку отсуствия сигнала агентам.

{"datetime":1591880033,
"secCode":"SBER",
"value":
{"bid_count":"10.000000",
"offer_count":"10.000000",
"bid":[
{"price":"206.33","quantity":"633"},
{"price":"206.34","quantity":"2982"},
{"price":"206.35","quantity":"809"},
{"price":"206.36","quantity":"134"},
{"price":"206.37","quantity":"259"},
{"price":"206.38","quantity":"110"},
{"price":"206.39","quantity":"184"},
{"price":"206.41","quantity":"504"},
{"price":"206.42","quantity":"56"},
{"price":"206.43","quantity":"740"}],
"offer":[{"price":"206.50","quantity":"248"},
{"price":"206.51","quantity":"7"},
{"price":"206.52","quantity":"102"},
{"price":"206.53","quantity":"214"},
{"price":"206.54","quantity":"1944"},
{"price":"206.55","quantity":"283"},
{"price":"206.56","quantity":"150"},
{"price":"206.57","quantity":"343"},
{"price":"206.58","quantity":"733"},
{"price":"206.59","quantity":"706"}]},
"classCode":"TQBR",
"callback":"OnQuote",
"stockMarket":"MOEX"
}

"callback":"OnQuote" - это по сути имя сигнала - в данном случае это таблица данных по инструменту secCode - можно стандартизировать имя сигналов в json, можно делать отдельные сервисы для приема разных сигналов и для трансформации их в нужный на вход в шину. Т.е. нужен ещё какая то структура сигнала. Поля bid и offer по идее могут быть либо коллекциями, либо полем с типом object - мы такой обсуждали, но не ввели в ion. Возможно (и скорее всего) такое поле нужно, когда нет смысла хранить связанные объекты отдельно от основного

Возможная стурктура класса регистрации сигнала:

• [code] код сигнала
• [ver] версия структуры сигнала(?)
• коллекция имен параметров сигнала и их типы(?) насколько нужно?
• [source] источник сигнала
  • внешний,
  • другой агент
• [type] тип сигнала
  • периодический - поле параметра периода в секундах
  • апериодический
• [save] сигнал отражается в данных или нет - логический
• [saveClassName] если сигнал отражается - коллекция куда сохраняются данные
• надо ли проставлять метку времени получения сигнала - по идее в самом сигнале может быть служебное поле __busRegistrationDate или что-то такое и его можно и так создавать.

Где сигналы описаны? это какой-то класс? он в агенте лежит или отдельно? по идее версия сигналов может быть по модели semver - и тогда у агентов, можно указывать допустимые версии сигналов по модели как версии пакетов в npm - мажорная совместимость и т.п.