RP Server for the developer

    The RP Server platform is designed exclusively for creating applications that work with databases running Microsoft SQL Server. Basically, this refers to the tasks of enterprise automation, but not limited to them. This 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: development environment, runtime environment and 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 a development environment is placed in the repository.
    Repository (RP Repository) is a database running Microsoft SQL Server. In addition to the application, the same database may also contain the target data scheme with which the application itself works. Those. we get in one database both user data and the application that processes them.
    The runtime environment (RP Runtime) is designed to run applications stored in the repository. In fact, this is what is commonly called a thick client, because the client-server system. Three-tier architecture can be implemented through terminal access.

    Development

    The development environment allows you to create objects of several types: lists, dialogs, menus, procedures, etc. The application is built from these objects.
    To control objects, a built-in 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 the properties typical for lists (sorting, searching, filtering, uploading to a file, etc.), it is enough to simply write an 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

    Application development for a specific client can be carried out in two ways.
    The first method (additional code segments) allows you to supplement the handlers of existing objects of the serial version with your own code fragments, which the system will embed in the handler code in front of it, after it or instead of it.
    The second method (replacing objects) allows you to completely replace the 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 serial version objects, 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 modify. If the changes in the serial version did not affect the developments of the accompanying programmer, then he does not need to do anything, because the system will automatically pick up its objects.
    Such developments can be distributed by uploading to an export file and uploading to the target database.

    Also popular now: