The RP Server platform is designed exclusively for creating applications that work with databases running on Microsoft SQL Server. Basically, this refers to the tasks of enterprise automation, but is not reduced only to them. It is a fairly powerful, self-contained environment that has a built-in programming language and allows you to create not just screen forms, but logically complete program modules and large applications consisting of many modules.
Architecturally, the platform consists of three main parts: the development environment, the execution environment and the repository
The development environment (RP Designer) is designed to create applications. It can be compared with Visual Studio. An application created by a programmer in the development environment is placed in the repository.
The repository (RP Repository) is a database running Microsoft SQL Server. The same database, in addition to the application, can also contain the target data scheme with which the application itself works. Those. We receive in the same database both user data and the application that processes them.
The RP Runtime is designed for the execution of applications stored in the repository. In fact, this is what is usually called a fat client, because the system is client-server. Three-tier architecture can be implemented through terminal access.
Development
The development environment allows you to create several types of objects: lists, dialogs, menus, procedures, etc. From these objects, an application is built.
To control objects, the embedded language (x-language) is used, which is an interpreted language.
Each object has its own set of event handlers. Many of them have a default implementation, so in typical cases their implementation is not required. For example, to create a list with all list-specific properties (sorting, searching, filtering, uploading to a file, etc.), it is enough just to write a SQL query. If you want to implement some additional property, you need to write the appropriate handler.
Installation
Since the application code is stored in the database tables, the installation is reduced to creating the required data structure in the target database and transferring the contents of the tables with the code.
')
Customization
Refining the application for a specific client can be done in two ways.
The first method (additional code segments) allows you to add handlers of existing objects of the serial version with your own code fragments, which the system will embed in the code of the processor before it, after it or instead of it, at the execution stage.
The second method (replacement of objects) allows you to completely replace a serial version object with your own object, or create your own object from scratch. In particular, you can replace the menu object by adding your own items to it, to which you attach a whole set of your own objects.
In both cases, both additional segments and replacement objects can be associated with database users (or roles). Those. You can create several different versions of the same object, each of which will be executed only for a specific user (or role).
All such objects are stored separately from the objects of the serial version, so updating the serial version does not affect them. Instead, a change protocol is generated, according to which the accompanying programmer can determine what he needs to test or refine. If the changes in the serial version did not affect the developments of the accompanying programmer, then he doesn’t need to do anything, because the system will automatically pick up its objects.
It is possible to distribute such practices by unloading into the export file and loading into the target database.