Когда мы начинаем говорить о том, что же такое ODANT, часто возникают сложности в понимании основных концепций. Вот о том, где такие проблемы появляются, что с ними делать, и как начать думать в терминах ODANT — ниже.
Компонентный подход
Это не о программных компонентах, не о библиотеках. Не о монолитных приложениях и микросервисах. Речь о компонентном подходе к информации. Компонент в ODANT — это класс. Или объект. Или модуль, который по сути тоже является классом. Каждый класс — это уникальная информационная сущность с собственным глобальным идентификатором, по которому к нему можно обращаться. При использовании какого-то ранее созданного класса в своей системе, мы создаем его наследника. Он будет обладать всеми свойствами родителя, но это уже другой класс со своим идентификатором.
Если совсем на пальцах — для создания решения автоматизации нам нужно отнаследовать несколько классов в свою систему и поработать над их связью между собой. Галочку, например, поставить, означающую использование в одном классе сервисов, которые принес с собой другой.
Распределенная архитектура
Это не про кластеры, шардинг или распределенную файловую систему. Технология ODANT не подразумевает использования одной большой БД, которую при масштабировании приходится сохранять виртуально единой, а фактически на более низком уровне разбрасывать по нескольким серверам.
Информация распределена по разным серверам логически. Один набор классов — на одном, другой — на другом. Можно представить это как таблицы одной реляционной БД, распределенные по серверам, но аналогия не совсем верная. Ближе к истине — если подумать о таблицах, все данные для работы с которыми в них уже лежат, и по связям с другими таблицами ходить не надо.
Иерархическая модель
Вся магия в наследовании. Создаем одну БД в головной организации. Наследуем ее в системы филиалов. Сейчас сверху и снизу конфигурация абсолютно одинаковая. Дальше в филиале мы можем модифицировать систему необходимым образом. Вот, например, нужно на месте подключить базу 1С. Для этого настраиваются коннекторы, а затем — сопоставления. То есть, в локальной системе будет, грубо, две таблицы. Одна — глобальная, унаследованная сверху. В ней поля «Адрес», «Телефон» и «ФИО». Другая таблица в терминах существующей ИС, там «Адр.», «Тел.», «Фамилия», «Имя» и «Отчество». Импорт настроен таким образом, что данные во второй таблице автоматически обновляются при изменениях в 1С.
В локальной системе осталось настроить сопоставление полей. В поле «Адрес» первой таблицы будет копироваться информация из «Адр.» второй и так далее. И теперь в головной организации можно запрашивать отчеты из любого филиала или их группы, ведь модель данных в интегрирующей системе едина.
Реактивные вычисления
В предыдущем примере интересный момент был. В одной структуре «ФИО» — одно поле, в другой — три. Проблема решается просто, для получения ФИО пишется XQuery-запрос, выдающий конкатенацию строк с фамилией, именем и отчеством. А исполняется запрос по созданию или изменению данных во второй структуре. Всего в ODANT предусмотрено шесть триггеров, срабатывающих по созданию, изменению или удалению записей; до или после указанного действия. Плюс триггеры, срабатывающие по маске времени.
Агрегация, наследование и гибридный режим
Чрезвычайно важная вещь для понимания того, как вообще работать с данными в ODANT. Допустим, в базе головной организации есть класс «Контрагенты». Обращаясь к этому классу, мы видим все данные в классах «Контрагенты» организаций ниже по иерархии. Это режим агрегации. Второй режим — наследование, здесь это не о структуре, не о наследовании классов, а о наследовании объектов, то есть — данных. Данные в классе «Должностные инструкции», находящиеся в головной организации, будут видны при обращении к классу с таким же идентификатором в дочерних.
Гибридный режим — это объединение агрегации и наследования. Где бы что ни лежало, оно будет видно из любого класса в иерархии с соответствующим названием. Чтобы было интереснее, добавим к этому функционалу локальное переопределение объектов. Есть в одной из организаций в иерархии контрагент «ООО “Рога и копыта”». В гибридном режиме он виден отовсюду. Но тут выясняется, что другая организация уже работает с ним, только записан он в местной ИС как «Рога и копыта, ООО». Переопределим объект таким образом, чтобы в локальной версии в нем название контрагента было «Рога и копыта, ООО». Теперь в этой организации контрагент называется по-старому, но остальные его видят с общим наименованием.
Подытожим
В терминах ODANT, компонентный подход — это использование функционально законченных информационных сущностей. Распределенная архитектура — это не разделение виртуально целой БД по кластерам серверов, а распределение данных по логике их использования. Иерархическая модель — наследование структуры, позволяющей получить одинаковую конфигурацию на всех уровнях (а значит, обращаться к любой системе в общих терминах), затем локально расширяемую для интеграции с местными информационными системами. Принципиальными в понимании основ работы с данными в ODANT являются концепции режимов «агрегация», «наследование», «агрегация + наследование» и реактивных вычислений — пересчета данных в объектах по срабатыванию определенных триггеров.
