Main application

Application infrastructure

The architecture of the main Creatio application is presented in Figure 1.

Fig. 1. The architecture of the main Creatio application

You can enhance the performance of large-scale Creatio projects through horizontal scaling. When using horizontal scaling, the architecture of the main Creatio application (Fig. 2) includes the following components.

• Load balancers.
  The load balancer may be either hardware or software. To work in fault-tolerant mode, use the HTTP/HTTPS traffic balancer that supports the WebSocket protocol. Learn more about setting up the HAProxy load balancer in the “Set up a web-farm for Creatio application server” block of articles.
• Web farm (multiple application servers).
• A Redis or Redis Sentinel caching server / a Redis cluster (multiple Redis caching servers). Learn more about the Redis Sentinel mechanism in the “Set up Redis Sentinel” article.
• A database server or a database cluster (multiple database servers).
• Version control system server (optional). Learn more about setting up a version control system server in the “Set up version control for a development environment” article.

Fig. 2. The architecture of the main Creatio application when using a web-farm, a Redis cluster, and a database cluster

You can enable additional features by setting up components and services in the main Creatio application.

Application server

The application server performs the main computing work of the system.

The application on the .NET Framework platform runs under Internet Information Services (IIS). Windows OS, starting from Windows 7, is required for the operation of Creatio application servers on the .NET Framework platform. The .NET Framework Creatio application server consists of the application loader (WebAppLoader) and the Creatio configuration part (WebApp).

The purpose of the application loader is executing the service functions of Creatio and then redirecting users to the main Creatio application.

The application loader accounts for the following:

• User authorization.
• License verification and user authentication.
• Running the scheduler, which enables the execution of background tasks based on a schedule.

On the file system level, the loader is located in the root folder of the application.

After the application loader processes the authentication query, the users can work with the configuration part. The configuration part is an application that implements a specific configuration in Creatio and accounts for the business logic. On the file system level, the configuration part is located in the Terrasoft.WebApp folder.

The application on the .NET Core platform runs under Kestrel. OS X, the last official version, is required for the operation of Creatio application servers on the .NET Core platform. The Creatio application on .NET Core is monolithic and handles the function of both the application loader and the configuration part, You can learn more about Creatio products of the .NET Core platform in the “Creatio on the .NET Core platform” article.

The database server

The database stores the following data:

• User data.
• Data required for Creatio operation.
• Configuration settings that define the functions of the product.

You can use the following database management systems (DBMS):

• MS SQL Server 2012 SP3 or higher.
• Oracle DBMS 11g Release 2 and 12c (when deploying on-site).
• PostgreSQL 11. PostgreSQL setup files are available for download at postgresql.org.

The setup options for Creatio products are available in Table 1.

Table 1. The setup options for Creatio products

Creatio products	DBMS
	MS SQL	Oracle	PostgreSQL	PostgreSQL (.NET Core)
Marketing	+		+	+
Sales Enterprise	+		+	+
Sales Commerce	+		+
Sales Team	+		+
Service Enterprise	+		+	+
Customer Center	+		+
Studio	+		+	+
Lending	+		+
Bank Customer Journey	+		+
Bank Sales	+		+
Sales Enterprise & Marketing & Service Enterprise	+	+	+	+
Sales Enterprise & Marketing & Customer Center	+		+
Sales Commerce & Marketing & Customer Center	+		+
Sales Team & Marketing	+		+
Sales Team & Marketing & Customer Center	+		+	+
Bank Sales & Bank Customer Journey & Lending & Marketing	+	+	+	+

Redis caching server

The Redis caching server is responsible for the following tasks:

• Storage of user and application data (user profile, session data, etc.).
• Storage of cached data
• Data communication between web farms.

For these tasks, data repository technology is implemented in Creatio’s architecture. The object model of classes, being a unified API for access from application to data, located in an external repository forms the base of this technology. Creatio uses Redis as the external repository.

Creatio repositories focus on the execution of service functions or arrangements of data handling but they also can be used in configuration business logic for solving user tasks.

The data model of Redis is based on "key-object" pairs. Redis supports access only with a unique key and can be successfully used for the storage of serialized objects. Data, placed into the repository, is stored as binary serialized objects in Creatio.

Redis supports the following data storage strategies:

• In-memory only.
  Redis is used simply as a caching layer making a copy of the persistent database available in-memory. No data storage.
• RDB persistence (default).
  A snapshot is saved to disk at specified intervals (normally once in 1-15 minutes) based on the time the previous copy has been created and the number of changed keys.
• AOF persistence.
  Redis logs each write operation synchronously to an append-only log file.
• Replication.
  You can assign each Redis server with a master server. All changes in the master Redis instances will be reproduced in the replica instances on the slave servers.

The data storage method is determined by configuring the Redis server. At present, Creatio supports RDB persistence but no Redis replication.

More information about the Redis caching server is available in the Redis documentation.

Creatio supports two types of repositories, i.e. data and cache repositories. Learn more about data repositories and caching in the “Repositories. Types and recommendations on use” article. The object model is covered in the “Repositories. Types and recommendations on use” article.

A data repository is designed for data warehousing of rarely modified long-term data. A cache repository stores operation data.

Individual logical levels of data placement for each repository type are described in Tables 2 and 3.

Table 2. Data repository levels

Level	Details
Request	The query level. The data of this level is available only in the course of current query processing. Corresponds to Terrasoft.Core.Store.DataLevel.Request enumeration value.
Session	The session level. The data of this level is available only in the session of the current user. Corresponds to Terrasoft.Core.Store.DataLevel.Session enumeration value.
Application	The application level. The data is available for the entire application. Corresponds to Terrasoft.Core.Store.DataLevel.Application enumeration value.

Table 3. Cache levels

Level	Details
Session	The session level. The data of this level is available only in the session of the current user. Corresponds to Terrasoft.Core.Store.DataLevel.Session enumeration value.
Workspace	The level of the workspace. The data of this level is available for all users of the same workplace. Corresponds to the Terrasoft.Core.Store.CacheLevel enumeration value.
Application	The application level. The data of this level is available for all application users regardless of their workspace. Corresponds to the Terrasoft.Core.Store.CacheLevel enumeration value.

Such partitioning of repositories is implemented for logical separation of data units in the repository and convenience of further use in the source code. The partitioning accounts for:

• Isolation of data between workspaces and user sessions
• Conditional classification of data
• Control of the data life cycle

All repository and cache data can be located physically on an abstract data storage server. The data in the Request level repository are an exception and are stored in the memory directly.

Creatio uses Redis as the repository server. In common cases, it may be a user repository, accessed through unified interfaces. It is necessary to take into account the fact that repository access operations are resource-intensive since they are associated with serialization/deserialization of data and network communication.

The data repository and cache represent the following possibilities for data handling:

• Access to data by key for reading/recoding.
• Deletion of data from the repository by key.

The key difference between a data repository and the cache is the approach to the lifetime of the contained objects.

Data will be stored in the storage until deleted explicitly. The lifetime of such objects is limited by the query execution time (for the data in a Request level repository) or session existence time (for the data in a Session level repository).

Cached data have an aging period that limits the time a specific cached element remains valid. All items are cleared from the cache regardless of their aging period in the following circumstances:

• Upon the session end (data in the cache and repository of the Session level).
• Upon explicit deletion of the workspace (data in the cache of the Workspace level).

The items of the Application level cache are stored for the entire period of existence of the application and can be deleted only by clearing the external repository.

Data can be cleared from the cache at any time. This may result in situations when a program tries to access the cached data that have already been cleared from the cache by the time the attempt is made. In this case, the calling code should only receive data from the persistent repository and place them in the cache.

Version control system server (SVN)

A version control system server is an optional application component. Use a version control system server when developing custom configurations in parallel with the normal operation of the application. Version control is, however, required for multi-user development.

The version control server accounts for the following functions:

• Transferring changes between applications during the development.
  Changes are transferred via packages stored as sets of folders and files on the file system level. Learn more about working with packages in the Development tools. Packages” block of articles.
• Storing the configuration status as packages of a specific version.
  The version control system stores all configuration elements developed in the packages.

The version control system stores the entire change history in the configuration. Learn more about setting up a version control system in the “Create repository in SVN server” article. Learn more about working with a version control server in the “Version control system. Built-in IDE” block of articles. Different version control systems are covered in the “Version control systems” block of articles.

Deployment options

There are two Creatio deployment options:

• On-site.
• Cloud (deploying the Creatio application on cloud).

On-site deployment

In On-site deployment, all expenditures associated with handling the servers (installation, configuration, maintenance, administration) are charged to the customer.

On-site deployment provides the following advantages:

• Fast and convenient development process.
• Independent development environments. Since development is made in a separate application, other applications cannot be affected.
• Using the version control system for saving and transferring changes.
• The ability to use an IDE and set up continuous integration processes.

The disadvantage of on-site deployment is that the customer bears the cost of supporting the infrastructure (update, administration, maintenance costs).

To deploy the Creatio application on-site, the server-side and the client-side must meet certain technical requirements. More information about the system requirements for client PCs is available in the “Client-side system requirements” article. More information about the system requirements for Creatio application servers is available in the “Server-side system requirements” article.

To calculate the parameters of the servers needed to deploy the application and additional components, use the system requirements calculator.

A step-by-step guide for deploying Creatio on-site and setting up the application on Windows platforms is available in the “Deploy Creatio .NET Framework application on Windows” block of articles. A step-by-step guide for deploying Creatio on-site and setting up the application on Linux platforms is available in the “Deploy Creatio .NET Core application on Linux” block of articles.

The following on-site deployment options are available for Creatio applications:

• Without fault-tolerance (Fig. 3).
• With fault-tolerance (Fig. 4).

Fig. 3. Creatio on-site deployment without fault-tolerance

You can use a version control server to set up a fault-tolerant Creatio development environment. However, such complex fault-tolerant systems are normally used in testing and production environments.

Fig. 4. Creatio on-site deployment with fault-tolerance

Cloud deployment

In the cloud mode, the application is deployed on cloud data center servers (Amazon, Azure) managed by Creatio. All application server part is stored in the data centers and administrated by Creatio employees. All issues related to administration, speed, or scalability are handled by Creatio. The customers only use the client part of the application.

Cloud deployment provides the following advantages:

• Timely updates.
• Maximal performance.
• Compliance with industry standards on data availability and security.

Learn more about the limitations of the on-cloud deployment of a Creatio application in the “Deploying the Creatio cloud application” article.

To deploy Creatio on-cloud, go to the trial request page. During the 14-days trial period, you can become familiar with the main features of the application. After the trial period is over, the demo version of the application can be moved to the main Creatio platform.

See Also

• Deploying the Creatio on-site application
• Deploying the Creatio cloud application
• On-site deployment
• Components and services
• Developing solutions in Creatio

Video tutorial

• Creatio architecture basics
• Setting up a development environment