Chapter 4. Product Scheme

The "Incoplax" platform has its own Continuous Integration (hereafter CI) build process. The result is a distribution. It is a program directory packaged either in a docker container or in a zip archive with a deployment script.

On each of the cluster servers, a docker container is created that contains all the required modules and assemblies. The contents of the container are identical on all servers in the cluster. The container is under the supervision of an operating system daemon. Inside the container, a kernel node runs, which provides orchestration and supervision of microservices according to the configuration. The termination of any process is handled by a higher-level supervisor, all the way down to the operating system daemons.

If the configuration changes, the composition of microservices on a particular server and/or their parameters may change. The application is performed by a kernel node. Platform upgrades can be performed automatically within existing containers by swapping modules and assemblies and then restarting the container. In special cases, a server-side update can be applied by creating a new container.

Each container stores the latest up-to-date configuration on disk and is loaded from it. The microservices of the system are already then connected to external storages and loaded from them. The current configuration can also be updated after the responsible microservices have been loaded from the database.

Products, distributions and build process

Each version of the product comes in the form of a distribution. It is a separate docker image and update archive, resulting from the build during the CI process of the platform stack «Incoplax». The CI process of the platform involves unit and system testing of the platform and its underlying applications.

The finished product distribution contains a program catalog containing libraries of included applications, including the "Incoplax" platform itself, environment files (assets), and runtime environments. The program catalog is filled sequentially with the results of building all supplied applications.

product_assets

Other assets or environments (such as JREs) can be added to a docker image created from a docker image with a suitable platform version.

In special cases, the build process can be customized with a different composition of applications and asserts.

Domains, product layer and subject areas

All data in the platform belongs to domains. The functionality of domains may vary significantly. A product layer can be installed in each domain of the communication domain. With the product layer, the communication platform is "fertilized" and gets the information part. The product layer is delivered together with the distribution, or separately. Versioning of the product layer is performed independently of the platform.

The product layer makes the platform an information and communication platform.

In the information part of the platform, a basic data model is created: * Classes * Controls * Editors * User Roles * Web applications * Server microservices * Scenarios * Packages

A class is a typed data structure under which a collection is automatically created, REST-API, allocated in repositories, and wrappers are generated for the JS/TS. A package is a set of entities of various types, including specific related classes, applications, roles, microservices. All these entities in a package represent a specific subject area and solve a specific information and communication task. For example, a callcenter package is an information and communication bundle that provides in a specific domain functionality for mass typed call processing, related reporting and services.

The package extends the functionality of the domain. New roles are created for users, and the web applications of the subject domain become available to the owners of specific roles. For example, in a call center, these are Call Center Operator, Supervisor, Call Center Administrator and their corresponding applications APM, Reports, Settings, etc. To service complex processes, client and server microservices are used. Server services are activated together with the package with binding to a specific domain, connect to the API of the platform, interact with each other by creating and modifying certain entities.

One of the essential principles of the product layer is real-time change tracking. Each application or microservice can subscribe to changes to certain collections or specific entities to be notified instantly.

Packages are created, exported/imported, activated/deactivated in the base application of the product layer (Builder). The creation of packages takes place in low-code form.

  • Personalization
  • Increase font size
  • Decrease font size