Predefined domain collections

Overview

Various microservices create collections in a dynamic data model for their needs. There are few differences in their operation - CRUD operations are allowed according to role-based access settings, subscriptions to changes. Field additions and uses from the product layer and from external systems are also allowed. Adding elements to enumerated data types is allowed. However, when preset fields are deleted or modified, the entity metadata is automatically restored to its original state.

Preset collections are categorized into groups.

Collections of the platform communication layer

A list of collections of the platform’s communication layer:

Placement in storage facilities

The classes of the platform’s communication layer are capable of being dynamically typed. For example, classes of historical data can be hosted in a domain-joined clickhouse storage if the appropriate storage is available, and if it is not available in a relational database postgres.

The following predefined storage codes for data are used]:

  • 'model_ch' - in case of availability of storage types clickhouse and kafka at the same time will be used in priority for placing historical data.

  • 'model_pg' - in case of availability of postgres type storage will be used to place categories and historical data (in case of absence of storage clickhouse).

  • 'auto' - default repository for categories and historical data, located next to the domain database in the postgres.

The following predefined storage codes for files are used:

  • 'email_files' - s3, fs, nfs file storage. Used to host files related to email messages. Prioritized.

  • 'im_files' - s3, fs, nfs file storage. Used to host files related to messenger messages. Prioritized.

  • 'vmail_files' - s3, fs, nfs file storage. Used to host files related to voice messages. Prioritized use.

  • 'model_files' - in case there is storage of type s3, fs, nfs. Used to host files associated with entities if no higher priority storage is found for the entity.

  • 'auto' - the default file repository if no higher-priority repositories with the above codes are found. Hosted locally by microservices instances fs.

By default, all data is placed in auto storage. By creating storages with appropriate types and names, you can achieve data placement in external storages or on other disk partitions. The previous data, if any, will remain in the same location and will need to be migrated externally to merge it.

Collections of the platform’s product layer

The collections of the grocery are defined by the installed packages.

The list of available collections can be viewed by accessing the API (mostly under a domain administrator account) and specifying a URL with a closing slash, e.g.: '/rest/v1/model/platform/'. The web server will return a list of next-level paths, as well as collections located directly at the specified level.

The following system packages are immediately available when you install the product layer in the domain:

  • base

  • builder

  • platform

  • root

  • scenario

  • tools

и

  • callcenter

  • email

  • etl

  • helpdesk

  • im

  • meet

  • tester

  • wfm

Some product layer classes decorate platform classes, so, when installing a product layer and/or product layer packages, new fields, new elements in enumerated types may appear in the communication layer class. Existing fields and parameters of such classes should not be changed, as the platform will restore the class metadata upon detecting meaningful changes.

  • Personalization
  • Increase font size
  • Decrease font size