The application server is an automated application of database transactions. To develop applications in different purposes, the programming of new program code is not needed. The application server checks automatically the consistency and the integrity of the attributes of the input. Types can be configured with the regular expressions or by a reusable external module. These check the form of the attribute value. The model of the dependencies of the attributes is the relational model of the relational database management software. The model is configured by adding dependencies of the individual attributes. The model is used to check the consistency of the transaction attributes before the transaction. Configurable text strings are used to print messages in the output files to help the user to fill in the data in correct format.

The benefit to the end user is a ready made application server software with software maintenance. The software provides a fast development time without the uncertainty of the development of new software for the purpose. The quality of the application software improves with less cost and the software can be distributed to all of the application server users. It is possible to integrate multiple databases into an information system since the schema may consist of attributes in multiple databases. The attribute dependencies can be given new meanings based on the needs of the information system and the dependencies of the attributes may be more informative than the ones in the relational database schema. The application is able to use international character codes and texts.

Program interfaces and possible architecture component interconnections are listed in the image "Possible interconnections". An HTTPS -server may be used in front of the application server to serve the not changing content.

During each request, program execution divides into three processes. The processes are isolated from each other and run in their own reserved memory. This adds security in the program. The database connection is separated from the consistency and the integrity check in its own memory. After each request, the processes exit emptying everything the previous request had left.

RVP understands both HTTP POST and GET queries. The capability to use query part of the URL may have to be configured in the "UseQuery" parameter in the run/etc/rvp.conf. The query key-value -pair has to end in & character in the end of the query. It is recommended to use method POST because the content can be in internationalized encoding and the length of the message content may be longer. Web browsers have different maximum length values for the URL ranging usually from 2048 to 4000. Best MIME type to use is application/x-www-form-urlencoded in both GET and POST queries. In HTML FORM:s, this is the enctype parameter. enctype sets the HTTP Content-Type -header when POST is used. text/plain may be used if the values do not have linefeed in them and it is not anymore recommended. If the urlencoding is needed using GET, the "URLEncodedValues" setting should be set in the configuration. Character sets are chosen using accept-charset.

Available encodings are one-byte encodings, two- and four byte encodings and all of the Unicode encodings UCS-2 and UCS-4 and the transfer formats: UTF-8, UTF-16LE, UTF-16BE, UTF-32LE and UTF32BE. These have to be set in the encoding settings and the setting is used in every transaction. Every external interface may have different encoding. All of the input has to be in the same encoding. One byte encodings include 7-bit US-ASCII and all of the one byte encodings, at least ISO-8859-1 and ISO-8859-15, the Scandinavian one byte character set. Recommended default is UTF-8. Unicode character sets contain all of the characters in the world.

The application server forms an attribute schema based on individual attribute declarations in each startup. The schema is similar to the relational database management systems schema in table format. The difference is the attributes are declared individually. The relational database schema can be used in adding the software attributes. The primary-key attributes are the determinants or the multivalued determinants. More determinants are found in the same tables. The attribute declarations are otherwice similar to the declarations in the SQL. The convenient error messages are attached in every integrity type of an attribute to help the user to type the attribute values in correct format.

In some extent it is possible to use the same already configred run/etc/attributes.conf -attribute schema or attribute catalog in multiple applications. In using multiple databases, the attribute names still have to identify the attributes.

Relational integrity is defined with the following four rules. Different sources add other rules, these are used here. In a transaction to a relational database, the attributes modified are allways the ones in the relational table or a relation where the attributes are. These transactions are called atomic. The RVP software checks the following four different types.

The configuration files are JSON files started with an object sign ('{' - curly brace). The usual location where the files are found is the directory run/etc/. Unlike in JSON depending on the interpretation, the special control characters are allowed, for example the ones below Unicode value 0x001F. All application reserved special characters have to be bypassed, for example the backslash '\'. This is important to know with regular expressions.

The attribute definitions in the previous section lists the most important declarations of the attribute declaration file. run/etc/attributes.conf is a JSON file. Attribute names are added as a list. Every attribute is an object containing the prementioned relational integrity parameters with the following objects: "Type" and "Error".

Application reserved special characters are the characters used to delimit names and values and the bypass character. The texts in the configuration files are usually in the encoding of the output. The most used is the HTML. The special characters of these have to be bypassed in the texts. For example in the regular expression of the email -type in the previous example, all of the bypass characters have been bypassed with another bypass character.

Since in most cases the editing of the files has to be done by hand, the normal line feed characters may be used instead of using only the JSON special characters. In checking the syntax of the file, ./run/bin/rctrl may be used to remove these special characters before checking the syntax of the file.

Transaction object is the connection to the database or other module producing the output of the transaction. The parameter to the module may be a "SQL-Statement" or a "Parameter". The difference between these two is in replacing the empty value. In the SQL, empty values are replaced with a text NULL. In these texts, the input parameters are marked with a dollar sign $. The RVP replaces these variable names with the attribute values.

"Module" parameter chooses the needed module file installed in run/lib -directory and configured in the run/etc/rvp.conf -file. "Modifies" setting is important. If it is set to false, the referential integrity is not checked. in the SQL SELECT statements, the referential integrity is not necessary. It is easier to read from the database than it is to write.

Other optional parameters are the "Repeat" and "Returns". If "Repeat" is set to true, the application will repeat the transaction to every attribute set it finds from the input. Care should be taken to not to use this function in anything where it may cause too many rows or unintended data. "Returns" attribute declares an error attribute name the developer may use to deliver the database module error message to the user interface.

The previous example would select the user email to be set in the session database as an authentication function.

The Modifies attribute value false switches the referential integrity check to off. The SELECT-statements do not necessarily need the referential integrity check. The developer should take care to SELECT only those attributes needed for the transaction using the session database attributes and the input attributes.

The transaction can be repeated if the setting "Repeat" is set to value true. CBI will repeat as many times it finds the next names of the transaction from the input stream and the DB will repeat the transaction as many times the attributes are found.

The attributes are grouped in every repeat. Allways the next same named attribute is get from the inputs. If "Modifies" is set to true, unique input values are used. In this case allways the first occurrence of the attribute is used. Inside a repeat loop, the attributes are grouped and inside the group number and the repetition, the attributes are unique.

Every SELECT -statement has to be in its own "SQL-Statement" -block. INSERT and UPDATE -statements may be in the same "SQL-Statement". It is as well possible to use an own or multiple "Transaction" -blocks. In this case all of the database and the connection information has to be written again and each block has its own "On Success" -block for a COMMIT -statement. It is possible to use as many databases with as many database connections as is necessary.

If these characters are needed in the "SQL-Statement" text, these can be bypassed with a double bypass character: `\\' . Since the "Parameter" text is not in SQL syntax, single bypass is needed `\' .

Each "SQL-statement" and "Parameter" -block starts an own attribute group. Inside the group, only one similar attribute name is found. This is the same as in the Grouping search in the reporting options. Inside the group the behaviour is similar as in the Unique search ordering.

The attribute prefix sets the attribute as not found after the search and sets the same attribute as reusable in the next searches. The attributes are searched as if they were Unique across all of the "SQL-Statement" and "Parameter" -blocks in the URL.

Session attributes are set with "SetsRoles" and used with "ReqRoles". To use the session attributes in an SQL-Statement, a & -sign is used. Session attributes are used as unique attributes, they may occur only once and when they are used, the attribute value is always the same value.

Simple configuration can be made using Apache httpd modules mod_proxy and mod_proxy_http, a simple configuration using only one RVP -server in Apache httpd.conf.

The requests to URL /live are sent to the RVP in address my.domain.com.

Similar functionality is get with different load balancing features using Apache httpd modules mod_proxy, mod_proxy_http and mod_proxy_balancer. An example of using multiple RVP-servers with different balancer modules, here, the "byrequests" is used.

Directive Proxypass tells the path of the URL from where the requests are send to the RVP in port 8443. In the example this is /live. Timeout has to be set to a bigger value than the biggest timeout in the rvp.conf . The default value in Apache 2.4 is 60 seconds (as of 13:th May 2017).

The attributes reported are searched from the database module output. Allways the next same named attributes are searched and printed. If the attribuet or the next one is not anymore found, the attribute is not found. There are possibilities to change the search order: UNIQUE sets the attribute as unique. With this setting the same attribute is used again and again. The first occurrence of the attribute is used, either from the last group or from all of the attributes. Every REPEAT loop changes the group of the attributes in a loop. In a loop, the same attributes are used again and again as with UNIQUE. These attributes are inside a group and the group is changed with every loop. Every loop increases the group number and new attributes are searched and used within a group.

Options in attribute tag.

It is possible to put inner <%TAG:s inside the options texts in the <%TAG. The text is replaced with the <%TAG value from the database module output.

Inside the content of the options texts the special characters have to be bypassed to deliver them to the next tag. In the above example, if the inner tags had options texts, the quotes of the texts should be bypassed. If a syntax error is encountered, the RVP usually prints the system error page with an ascii arrow pointing to the location where the error occurred.

Depending on the database module, the attribute value may contain a tabulated stream of delimiter separated values. The <%TAG is capable of parsing this text if separators are single characters delimiting values in an output stream.

The order of the separators are as follows: <file <group <record <unit> > > >, the unit is on top of the others and the first separator is the file separator.

To add text before, after and between group of attributes, paired tag <%GROUP> <%/GROUP> and <%GROUP $attribute> <%/GROUP> can be used. The first pair without the attribute definition repeats as many times attributes are found. This is attributegroup. The second can be used to repeat as many times as the domain attribute value changes in the group. This is domaingroup. In domaingroup the repetition stops when the domaingroup attribute value changes. In selecting from two relational tables, the domainattribute in both tables creates repetition. The domainattribute value has to be ordered. The change of domain is recognized from the changed domain attribute value.

It is possible to report JSON-files and other tree structures from the relational database tables using the domain attribute. In the example the transactions.conf -file is printed using attribute tags and group tags. The attributegroup may be used before the domaingroup to endlessly report as many times there are attributes.

Options in group tag.

The database module output may contain control characters with a special meaning. A bypass character \ in the database module output causes the software to bypass the control character functionality and to remove the bypass character. A bypass character in the database module output is printed with two bypass characters.

In the following is an example rvp.conf loading modules, a PostgreSQL database module postgres, module email sending emails with SASL, a module file reading output from a file and a typemodule builtintypes. Module name chart prints tabulated text from the PostgreSQL module with the chart functions. The function names are changed with "FunctionPrefix" and the given module name can be any.

Included in the RVP distribution, some ready made modules are available. For example the following modules to use database connection to PostgreSQL 9.6 database, SASL authenticated smtp emails module and a module printing just an output file. Configuration example to add these modules in rvp.conf was in the previous section.

Module file.so prints the files declared in the transaction in an attribute. The file is output to the attribute value. The attribute name is postfixed with an order number. For example the following files in the example would be printed in attributes FILE1, FILE2 and FILE3.

cIf the file is needed to be output as itself, a file containing only the <%TAG -text can be used in outputting. Be aware that the empty white space characters are going to be in the output. In these cases the MIME-type in the HTTP headers set in the "Content-type" -header is the same the application is using. This can be changed with the "MIME-Type" setting of the URL. A comma separated file for example can be printed with the <%TAG as in the example.

Email is usually sent with SASL authentication. This module connects to the SMTP server, authenticates and prints a standard MIME-type format of an email to the SMTP server. Note that the header attributes start from the first character of the line.

A module tag.so forms a file using the RVP output format. The module reads a first parameter file and writes attribute data in it to record the result in the second parameter file. In this example, a configuration file. The file format of the first parameter is the same as in the "Reporting Options" section.

The database modules are external programs to be used by the RVP. The RVP finds the implemented functions from the library file using the symbols of the functions. Other functions can be declared as static for example to not to mix them with the symbols used. For example nm -tool can be used to check if the needed symbol is available. To export the symbols, a compiler flag -export-symbols or similar is needed. Some operating systems allow additionally initialization functions to be used in source files. These functions are called at the time when the library is loaded. In the example modules these init functions are not used.

The function interfaces to be implemented are declared in an include file cb_db_module.h.

The database module name is used as a prefix in searching the functions from the library file. If attribute "FunctionPrefix" is used, this prefix is used instead.

Connecting to the database usually results an object in reserved memory. This object can be carried in structure db_conn_param in pointer *dbconn. The pointer to the memory is copied to structure transaction_params pointer *dbconn. Allways make sure the pointers are either NULL or carry allocated memory. Other options are explained in the include files and in other external sources. Usually every text is encoded in four byte UCS-4 representation. The module program should allow some other parameters to be NULL as well. For example the *param and *queryparam parameters are set to NULL if DirectInput was used.

The "SQL-Statement" is a text in the chosen encoding in the parameters *sqlst and *utfsql. All of the variables in the configured text are replaced with the attribute values. Precedence is from the POST attributes, after from the GET attributes. The "Encoding" is configured in DBModules in rvp.conf. Everything needed is to execute the text with the database client software functions with the correct encoding parameters. The RVP replaces empty or missing values inside ' -characters with a text NULL by removing the surrounding ' characters. If the database client software does not use standard SQL syntax, the module should convert the SQL-text to the syntax the database client software uses.

The optional auto configuration function <module name>_autoconf can be used to configure the transaction parameters otherwice set in the transactions.conf. The reading and writing operations are fundamentally different from each other. When writing, the writing occurs when the attributes are checked. The output buffer is used to queue the output before the result is known. In reading the buffer is not used and even larger files can be output without buffering. For example the module file.so can set the modifies into false automatically. Start of the SQL-statements can be read to find uncommented UPDATE or INSERT texts from the SQL-syntax to configure the transaction automatically.

To open files, the directory path in use can be copied from the attribute dirpath in structure transaction_params.

The type modules are similar to the database modules. The functionality is simple. The function is called by the attribute name or by the name given in "InbuiltName". The function should return value 0 on success and other values if an error occurred.