TECHNICAL STRUCTURETARIFSsupport@erp-platforma.com Sign up Sign in EN

TECHNOLOGIES


After creating an account and logging into the system, you see a friendly interface. You can create leads, tasks, projects. Usually in cloud CRM you can only use this, but in the "ERP-Platform" you can edit_s12 the interface and data structure, create new modules, make your own unique changes in standard modules and adjust the system to the logic of your business processes? And all this in the cloud !

Here we will tell you how the ERP-Platform is technically arranged, why it can be individually and unlimitedly configured. How is it that "ERP-Platform" can grow together with clients, turning into an ERP system for the client?

Databases

When registering, each company receives an individual container in which its databases will live. Each company operates and stores data in its own individual database.

There are 4 databases inside the client container:

This division was made for technical and pragmatic reasons:

Configuration base (main base)

This is the main customer database.
It stores individual configuration and data. All other bases are auxiliary. For example, it is not worth storing logs in this database. one field can be overwritten many times, and with each overwrite a copy of this field will be stored, which will bloat the database and complicate its backup. As a result, the backup is fast, takes up little space, and there is no water in it, but only the necessary data.

Backup of this database can be configured from the interface and is regulated by the client himself. It can also be backed up to an external ftp server of the client, i.e. you can store the backup on your side. To do this, you just need to specify the IP of your ftp server in the interface.

Filebase

This database implements its own file system. There is a directory structure, access rights. Files are stored inside the database as a binary data sequence. When the user clicks on the file icon in the browser, the system reads the binary sequence and generates a file for the user.

Made so for the following reasons:
  • For security reasons, all methods of hacking by downloading fake files are eliminated;
  • It is more convenient to backup and decentralize the structure. The database can be stored on any server without a direct link to the web server.
  • The client can store backups of the file base on his ftp (as well as with the main one);
  • The structure of the file system can be controlled normally from the built-in configurator;
  • Filesystem elements can be embedded in shared blocks with other configuration elements;

Database of logs.

This database stores detailed logs of any activity. Who, when, where, what and for what changed. Here you can lift any actions on any table, see what data was before the change.

Logging data is written at the event level in the main database, not at the user interface level. Therefore, all changes along the chain of triggers and automatic actions are also recorded.

The client (client's administrator) can also manage the log recording on his own. You can configure the data retention period, disable or enable the recording of this data individually in the tables.

By default, the log database is not backed up. this data is not critical and even its loss will not affect the work as a whole. They are of an auxiliary nature so that you can understand mysterious situations.
But at the request of the client, we can make backups of this database.

Database.

Our system allows the client to perform flexible integration with any of their external systems, directly from the cloud. The client himself can come up with interaction formats. Those. create your own API format.

Our technologies allow transferring data to the outside world directly from within the main event database. For example, you can create a trigger that, if the data in the table changes, will transfer the data in YOUR format to YOUR IP address on the Internet. Those. data transfer is not tied directly to the interface, but can work both with some user actions and with the occurrence of some events, including all changes along the chain of triggers and pending tasks.

These data can be quite voluminous, because similar to logs, multiple records can be made for one field when changing. Their storage in the main database is impractical, therefore, using a similar technology with logs, when an event occurs, the data is relayed to the service database, and from there it goes to the outside world. For some time, the data lives here, in case of problem analysis, and then it is cleared, only the packet headers remain, since they do not take up much space and after the fact you can understand that such and such a packet was transmitted with such and such a status.

This database is not backed up, because there is only service data.

Configuration

Now let's look at how the Configuration (main) database works and how the individual web interface is built.
The base is divided into 2 large sections:
  1. Data is the working data of the company
  2. Configuration is the structure of the database and interface and the structure of their interaction
The configuration, in turn, is divided into 2 large sections:
  1. Interface configuration.
  2. Database configuration.




The interface configuration is interpreted . Those. when the user opens the page, it refers to its configuration and builds itself on the fly, arranges the elements in the right places on the web page.

Why Interpreted? The point is in the access rights and the withdrawal of elements depending on external conditions.

  • Access rights have a very deep setting, down to individual elements of a web page. They can be given on the menu, on page blocks, on elements, inherited by nested elements, and be of different types (for reading, edit_s12ing, adding, deleting). Depending on this, the web page can be displayed differently for different users.

  • The display of elements can also depend on external conditions, for example, depending on the status of the document (lead, task, ...), some elements of the web page can be hidden, and some, on the contrary, are shown.

  • Convenient conversion to mobile version. Depending on the screen or browser type, instead of displaying a 2D structure, you can automatically collapse all cells into a column. Moreover, in the configuration you can specify unimportant elements that can be ignored for the mobile version.
    Here's an example of a fully automatic conversion when opened from a mobile browser:


  • You can make automatic mirroring of the page structure when choosing an RTL language (for example, Arabic or Hebrew)
Configuring the interface is visual and fairly straightforward. Our system implements 3D configuration of the interface.

What is it? For example, in Bitrix you can add only new fields in the lists - this is 1D configuration. You can simply add a new field, but you cannot position it to the left, right, second or third row, in the corner, etc.

2D - when you can place interface elements anywhere on the page. 2D configuration is simple and elegant. The entire interface is divided into cells as in Excel. Just like in Excel, you can combine cells with each other, and rows and columns. This way you can build any page structure. After that, you can add interface elements to the cells. These may not necessarily be text fields. You can add buttons, lists, images, tables, etc. Cells can be styled i.e. paint in the desired colors, customize the borders of the fields, position and font, etc. You can set fixed sizes of columns and rows. In general, the interface is very flexible.

3D - 2D edit_s12or is not always enough if the page has to have complex logic of work. For example, when, depending on the status of the task, you need to hide or show certain blocks of the page. Or display different edit_s12ing elements in the same cell, depending on certain data.
To implement such complex interactions, a third dimension is introduced, by analogy with layers. Depending on the events, it can show the desired cell layer. Those. in each cell, you can create many layers with your own elements and set the logic according to which this or that layer will be displayed.
For rows or columns, you can also set the logic of hiding or showing, depending on external conditions.
Cloud 3D configuration of the page allows you to implement any logic of the user interface.



Data sources are also created in the interface configurator, which are the link between the interface and the database. They know with what data this or that page element will work, where to write the information entered by the user, where to get it from when forming the page.



Database configuration (DB), unlike the interface, is compiled .

This was done for the following reasons:
  • Separate the edit_s12able level (where the user can configure the database) and the working level. If the user has done something wrong, the database compiler will not allow the crooked code to compile and start working.

  • Modern databases, very perfect tool. Procedures and triggers are very fast. The time for processing data and obtaining a result is minimal.

  • Any data processing logic can be conveniently implemented in a procedure. Our system fully supports the PL \ SQL concept and allows you to write arbitrary processing.

  • A trigger is a special type of procedure that is triggered when an event occurs (for example, writing a row to a table). Triggers can also use the full power of the PL / SQL approach.

  • Procedures can be run on a schedule or bind to user commands from the interface.
A visual edit_s12or for procedures and triggers has been made for users. The procedure is internally structured in blocks. You can create blocks of queries, additions, changes, deletions, loops, strings, etc. All sorts of math and string processing functions have been implemented. And even API structures for transferring data to the outside while the procedure is running.

Queries can be of any complexity, including joining multiple tables, case, etc.

Inside some procedures, you can start others.

The division of levels into user (configuration) and working levels allows us to do quite unique things in our system, for example:
  • Data type image , where you can get an image right in a sql query. It is very comfortable.
    For example: displaying a table of this type in the interface with one query does not make it there:


  • Take a snapshot of the structure.
    For example: you did something wrong, you can roll back to the previous stable state without any problems.

  • Standard implementation of blockchain technologies.
    If you need to make not just a table, but to keep, for example, a security log, then you can read the checksum of the line normally. To do this, in the table you just need to click the desired checkbox and the system will automatically calculate the checksums at the database level.
    You can read both a simple checksum and a checksum, taking into account the checksum of the previous record, to ensure the integrity of the data in the entire table.
    The sql query is similar, you can use a regular function to organize the checksum check. And depending on the result, program the consequences

  • Programming automation.
    You can create sets of standard procedures for the table with one button. You can create variables based on tables, automatically fill in sql query fields, etc. automation functions.
Those. at the level of configuring the structure, you can turn and turn the database configuration as you like. As you have finished, everything is compiled and becomes a working part of your database.

All configuration is naturally done in the cloud, right in the browser.

Interface and Database Friendship



When a page is formed, in addition to the arrangement of elements in space, it must also display data in the right places, fill in the elements or decide to display certain blocks. Those. knowing the input parameters, it must get the data necessary for output from the database. And sometimes it is not easy to get raw data, but to output it taking into account some processing, arithmetic operations, etc.

At the same time, it is necessary that everything works quickly, nothing superfluous is performed.

The link between the interface and the database is a structure called the Data Source. It's pretty simple. It must indicate:
  1. The procedure that the page will call and the situation in which this should happen.
  2. What should be fed into the procedure, for example, from which elements of the interface forms the data will be submitted to it.
  3. How to distribute the result of the procedure. Those. in which cell, element, table you need to output the result issued by the procedure.

With such a structure, you can configure whatever logic of the module's operation you want. You can change and create any interfaces, create any data storage and processing structures.

If you want to purchase a local version, client databases can be easily transferred to the client's server with all the data and the structure developed in the cloud.

Multilingual support

The system includes multilingual support. Any element of the system can be translated into any language.

For this, the client can independently register a new language in the settings, and it will be available in the configurator. Any element can have a designation in the given language.

Also for the convenience of development, the system makes an automatic primary translation of new elements into registered languages. It works like this:
  1. If the translation fields are not filled in when creating a new element, the system automatically makes a request with the base name to Yandex-translator for the required languages.
  2. The query result is entered into the appropriate fields.
  3. A technical translation may not always be correct, the user can manually correct the translation at any time. But even technical translation greatly simplifies development.
Thanks to this approach, the system can be automatically translated into a new language completely, within a couple of minutes. A script is launched that will go through all existing language elements and, from the specified base language, make a request for technical translation, save the new value. It is also possible to automatically “pre-translate” untranslated elements in an existing language.

Basic configuration

We provide our client not with a “bare” platform where he can develop something, but an account with an already existing “basic” configuration. Those. the system configurator has already developed Tasks, Projects, Applications, Contractors, Leads, Deals, Proposals, Schedules, Warehouse, Documents, etc.
For more details on basic functionality, see OPPORTUNITIES .

Modules of standard configuration will suit most clients, or require some minimal changes for the client's specific needs. Changes can be made at any time in the configurator.

If a client has some unique business processes and needs to develop some individual module - no problem. Any custom modules can be developed using the system configurator. The client can do this independently, or order revisions.

For self-development configuration you need:
  1. Experience with procedural SQL (PL \ SQL).
    To set the logic for storing and transforming data.

  2. Basic knowledge of web page design (if you have experience in HTML layout, then everything is fine).
    To understand the basics of interface configuration.
There are a lot of such specialists, and it is not a problem to find. In fact, any specialist with experience with a database can handle it without problems.

Report Configurator

A powerful report configurator is built into our system.
A detailed article about our report configurator on habr https://habr.com/post/331884/ (ru).

System performance

The system is fast due to the correct architecture of the kernel.

System performance is greatly affected by the way the application works with the database. All edit_s12ed systems try to use the programming language built into the interface (it can be one of its own, or one of the standard popular languages), and only data is stored in the database. As a result, they get the following scheme of work:
  1. A program executed in the interface forms sql queries to the database, there can be many of them.
  2. The database server executes them and returns the result to the application.
  3. The application processes this data according to the specified algorithms.
  4. Then it can write the result to the database (another data transfer) or output the result to the interface.
As a result, a lot of data is sent back and forth on request, and the interface, working as an interpreter, does not process the data very quickly. As a result, huge performance losses. Problems with event management and automatic actions.

We have made a more modern scheme of work, with minimization of losses. The result is absolutely the same as in the scheme above, but the speed of work is much higher.

All data processing takes place at the base level, in fast compiled tools. The interface only gives commands and outputs the result.

The required procedure is called from the interface, parameters are passed to it. Further, the procedure inside the database makes all requests, all data processing, all modifications and data records, and sends the already assembled result of work to the interface. As a result, there is no useless transfer of data back and forth, and data processing is performed by a technically perfect, fast tool, which are modern databases.

As a justification for the use of standard popular programming languages, it is often stated that there are many such specialists and they are quite easy to find. But there are also a lot of specialists professionally working with databases, and finding a programmer familiar with procedural SQL is also not difficult.


Welcome to our system!

We invite you to register and test all the above features.
Or see how the configuration works without registration.

We are waiting for your questions, wishes and suggestions from 10:00 to 18:00 (Moscow time) from Monday to Friday
by writing by email: support@erp-platforma.com





FREE VERSION VIEW WITHOUT REGISTRATION


«ERP-PLATFORM» LLC © 2021