Общее описание таблиц MongoDB
MyBPM создаёт в MongoDB несколько баз данных:
mybpm - содержит коллекции, в которых хранится структурная информация. Данных для бизнеса тут нет, за некоторыми исключениями.
mybpm_boi - здесь хранятся инстанции бизнес-объектов (последние значения полей и мета-информация). В этой БД есть коллекции, которые начинаются на
boi_а дальше идёт идентификатор бизнес-объекта, который находиться в коллекцииmybpm.Bo.mybpm_aux - тут хранятся всякие временные данные.
mybpm_chat - здесь хранятся сообщения чатов.
mybpm_event - тут находиться история изменений инстанций бизнес-объектов подготовленная для отображении на клиенте.
mybpm_process - здесь находятся данные о состоянии бизнес-процессов. Какие шаги пройдены, а какие ещё нет.
mybpm_sessions - здесь хранятся сессии пользователей, и ключи защиты сессий.
mybpm_files - здесь хранятся файлы системы.
Коллекции в базе данных mybpm
| Коллекция | Описание |
|---|---|
| Bo | Хранит структуру бизнес-объектов. Так же здесь храниться структура полей БО |
| BoGroup | Группы бизнес-объектов |
| BoiInMigrationRef | Связи инстанций БО с внешними идентификаторами БО при входящей миграции из PostgreSQL |
| BoProcess | Структура процессов (квадратики и стрелочки между ними) |
| BoProcessVersions | Версии структур процессов по каждому БО процесса |
| BracketFilter | Фильтры для меню слева |
| BracketPersonFilter | Фильтры |
| CompanyDto | Компания (аккаунт) |
| Department | Департаменты |
| LiquidMongoUpdateDto | Одноразовые задачи, и признак их применения (аналог liquibase но для MongoDB) |
| MainMenuDto | Меню слева |
| Person | Пользователи в систему. Через них происходит аутентификация и авторизация |
| PersonGroupLink | Связи многие-ко-многим между пользователями и рабочими группами |
| PersonSearch | Информация о поиске пользователей |
| ReportGroup | Группы отчётов |
| ScriptModule | Модули скриптов (их структура - блоки и выражения связанные между собой) |
| SignatureNcaValidation | Подписи |
| SystemSettings | Системные настройки |
| Token | Токены пользователей для АПИ (API_TOKEN) |
| TouchedBoi | Инстанции БО, которые подверглись воздействию |
Коллекции в базе данных mybpm_aux
| Коллекция | Описание |
|---|---|
| AdminInvitation | Подтверждение email для администраторов |
| BoiDraft | Черновик изменения инстанций БО при ручном редактировании |
| BoImportError | Ошибки импорта данные через xlsx |
| BoImportInstance | Про-импортированные, но ещё не применённые, инстанции БО |
| Certificate | Сертификаты для подписей |
| EmailVerifyInvitation | Подтверждения email для обычных пользователей |
| GoProcess | Очередь на исполнение (Go) процесса |
| GoProcessError | Ошибки исполнения процессов |
| GoProcessGrouped | Сгруппированная по идентификатору инстанции БО очередь на исполнение процессов |
| LockTask | Коллекция для осуществления блокировки задач |
| MobileVerify | Сообщения для различных подтверждений пользователя через смс или почту по сгенерированному коду |
| PersonInvitation | Регистрационное приглашение пользователя |
| PersonPassword | Список паролей пользователя |
| ReportCoViewStruct | Структура вьюшки для ЦО. Её нужно отслеживать чтобы можно было менять без ошибок со стороны PostgreSQL - он позволяет добавлять поля в конец, но удалять и менять местами поля вьюшки нельзя. |
| ScriptModuleJar_1 | Место где хранятся откомпилированные модули, которые являются jar-файлами |
| UndoLog | Ссылочная информация о журнала действий пользователя для Ctrl+Z |
| UndoLogPage | Журнал запоминания действий пользователя при редактировании скриптов разбитый по страницам |
| UserNotificationRow | Оповещение пользователям |
Коллекции в базе данных mybpm_boi
В этой БД лежат коллекции, которые начинаются на boi_. Дальше идёт идентификатор БО.
В этих коллекциях лежат данные по инстанциям БО - это основная база данных, где хранятся данные инстанций БО.
Коллекции в базе данных mybpm_process
Здесь хранятся данные по исполнению процессов. А именно шаги исполнения. Какой процесс на каком месте исполняется.
В этой БД лежат коллекции, которые начинаются на bo_process_. Дальше идёт идентификатор из таблицы mybpm.BoProcess.
Коллекции в базе данных mybpm_files
Здесь используется механизм хранения файлов, которые подготовили разработчики MongoDB. Называется она GridFS. Про неё можно прочитать здесь: https://www.mongodb.com/docs/manual/core/gridfs/
Коллекции в базе данных mybpm_sessions
Здесь хранится информация о сессиях работы пользователей в системы.
В коллекции cryptoKeys хранятся ключи шифрования идентификаторов сессии, которые нужны для того, чтобы нельзя было подсунуть инородный идентификатор сессии. Эту коллекцию можно зачистить, и тогда пользователи все вылетят из текущего сеанса работы. Система автоматически создаст новые ключи шифрования. Пользователям нужно будет ещё раз пройти процесс входа в систему.
В таблице sessionStorage хранится информация по сеансам работы пользователе. Эту таблицу можно удалить, и тогда пользователям придётся опять пройти процесс входа в систему.
Коллекции в базе данных mybpm_chat
| Коллекция | Описание |
|---|---|
| ChatMessagePage | Сообщения чата в соответствующей комнате, разбитые по страницам, для возможности точечного доступа |
| ChatRoom | Комнаты чатов. Обычно чаты парные (два собеседника в одном чате). Но есть возможность использовать многопользовательские чаты |
Коллекции в базе данных mybpm_event
BoiEventKafkaIdDto - данная коллекция содержит те идентификаторы сообщений из кафки, которые были обработаны. Это нужно, чтобы
одно
изменение не было учтено дважды. Кафка не гарантирует одиночную обработку сообщений - иногда она может быть обработана дважды.
boi_current_(boiId) - данные коллекции начинаются на boi_current_ и заканчиваются идентификатором БО.
В этой коллекции скапливаются старые и новые значения полей. Это нужно чтобы достоверно сгенерировать событие изменения поля со старым\
и новым значением.
event_(boiId) - данные коллекции начинаются на event_ и заканчиваются идентификатором БО. В этой коллекции
хранятся изменения по инстанции БО. Они разбиты на страницы, чтобы можно было их загружать на клиента в режиме доступа по одному
идентификатору. В коллекции boi_current_... храниться идентификатор первой страницы. А в первой странице, кроме списка
изменений, храниться ещё идентификатор следующей страницы. И так можно загружать историю изменений вниз сколько нужно.
Отображение коллекций в Dto-классы
В системе для каждой коллекции существует Dto-класс, через который происходит работа с этой коллекцией. Общая логика ассоциации коллекции с Dto-классом осуществляется так:
Берётся имя коллекции, например Person. Дальше к ней добавляется окончание Dto и получаем PersonDto и это значит, что существует класс PersonDto, через который происходит работа с коллекцией из Java. В этом классе описаны все поля и их предназначения.
Ассоциация эта происходит в классе MongoAccess.