Общее описание таблиц 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 | Фильтры |
Company | Компания (аккаунт) |
Department | Департаменты |
LiquidMongoUpdate | Одноразовые задачи, и признак их применения (аналог liquibase но для MongoDB) |
MainMenu | Меню слева |
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 | Сгруппированная по идентификатору инстанции БО очередь на исполнение процессов |
KafkaIdDto__triggerForKafkaBois | Признак исполнения инстанции БО |
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.