Предопределенные коллекции доменов

Обзор

Различные микросервисы для своих нужд создают коллекции в динамической модели данных. В работе с ними мало отличий - разрешены CRUD операции в соответствии с ролевыми настройками доступа, подписки на изменения. Разрешены также добавления полей и использование с продуктового слоя и из внешних систем. Разрешено добавлять элементы в перечислимые типы данных. Однако при удалении или модификации предустановленных полей автоматически производится восстановление метаданных сущности в исходное состояние.

Предустановленные коллекции разделены на группы.

Коллекции коммуникационного слоя платформы

Список коллекций коммуникационного слоя платформы:

  • email (только в рабочем домене)

    • email/Profiles - профили настроек для email-аккаунтов.

    • email/Accounts - email-аккаунты.

    • email/Folders - IMAP каталоги. Заполняются автоматически при первом подключении, требуют включения.

    • email/Messages - email-сообщения.

  • im (только в рабочем домене)

    • im/Accounts - аккаунты мессенджеров.

    • im/RemoteParties - абоненты мессенджеров. Заполняются автоматически при поступлении сообщений.

    • im/Messages - сообщения мессенджеров.

  • system (только в мастер домене)

  • telephony (только в рабочем домене)

  • ws (только в мастер домене)

    • ws/ExternalRoutedHosts - маршрутизируемые по особым правилам внешние имена сервера (мастер-сайта).

  • oauth (только в мастер домене)

  • meet (только в рабочем домене)

    • meet/Feedbacks - Обратная связь участника по проведенной конференции.

    • meet/Messages - Сообщения в рамках конференции.

    • meet/Records - Записи конференции.

    • meet/Rooms - Комнаты конференций.

    • meet/RoomSessions - Сессии конференций.

    • meet/Users - Пользователи конференций.

    • meet/UserSessions - Сессии пользователей конференций.

Размещение в хранилищах

Классы коммуникационного слоя платформы способны динамически типизироваться. Например, классы исторических данных могут размещаться в подключенном к домену хранилище clickhouse при наличии соответствующих хранилищ, а при его отсутствии в реляционной БД postgres.

Используются следующие предустановленные коды хранилищ для данных:

  • 'model_ch' - в случае наличия хранилищ типов clickhouse и kafka одновременно будет использован приоритетно для размещения исторических данных.

  • 'model_pg' - в случае наличия хранилища типа postgres будет использован для размещения категорий и исторических данных (в случае отсутствия хранилища clickhouse).

  • 'auto' - хранилище для категорий и исторических данных по умолчанию, расположено рядом с доменной БД в postgres.

Используются следующие предустановленные коды хранилищ для файлов:

  • 'email_files' - файловое хранилище типа s3, fs, nfs. Используется для размещения файлов, связанных с сообщениями email. Используется приоритетно.

  • 'im_files' - файловое хранилище типа s3, fs, nfs. Используется для размещения файлов, связанных с сообщениями мессенджеров. Используется приоритетно.

  • 'vmail_files' - файловое хранилище типа s3, fs, nfs. Используется для размещения файлов, связанных с голосовыми сообщениями. Используется приоритетно.

  • 'model_files' - в случае наличия хранилища типов s3, fs, nfs. Используется для размещения файлов, связанных с сущностями, если для сущности не обнаружено более приоритетного хранилища.

  • 'auto' - хранилище файлов по умолчанию, если не обнаружено более приоритетных хранилищ с указанными выше кодами. Размещается локально экземплярами микросервисов fs.

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

Коллекции продуктового слоя платформы

Коллекции продуктового определяются установленными пакетами.

Список доступных коллекций можно посмотреть, обратившись к API (преимущественно под учетной записью администратора домена) и указав URL с завершающим слешом, например: '/rest/v1/model/platform/'. Веб-сервер вернет список путей следующего уровня, а также коллекции, расположенные непосредственно на указанном уровне.

При установке продуктового слоя в домен сразу доступны следующие системные пакеты:

  • base

  • builder

  • platform

  • root

  • scenario

  • tools

и

  • callcenter

  • email

  • etl

  • helpdesk

  • im

  • meet

  • tester

  • wfm

Некоторые классы продуктового слоя декорируют классы платформы, так, при установке продуктового слоя и/или пакетов продуктового слоя в классе коммуникационного слоя могут появиться новые поля, новые элементы в перечислимых типах. Изменять существующие поля и параметры таких классов не следует, поскольку платформа восстановит метаданные класса, обнаружив значимые изменения.

  • Персонализация
  • Увеличить шрифт
  • Уменьшить шрифт