Modules/WebUser

The module provides the user with a mechanism to create WWW-pages, and can process other WWW-requests in internal OpenSCADA language, usually JavaLikeCalc, without involving low level programming. As a page processor, the module allows you to use standard DAQ-Templates. Using DAQ-Templates allows you to create WWW-page libraries and call them in this module multiple times as their implementations, as well as provide the data context of the template with their connection to the data of the subsystem "Data Acquisition".

Except of the module's belonging to OpenSCADA it also belongs and is the module of the Protocol.HTTP transport protocol module. Actually, the module WebUser call is made from Protocol.HTTP and through the enhanced communication mechanism — by the exported function HTTP() of the module.

Addressing of the pages begins with the second element of the URI. It is connected with the fact that the first element of the URI is used to identify the user WWW-interface module. For example, URL http://localhost.localdomain:10002/WebUser/UserPage can be deciphered as a call of the user page "UserPage" of this module on the host "localhost.localdomain" on port 10002. In the case of absence of the second element of URI and instruction to display an index of the user pages in the configuration, the index of the pages is generated (Fig.1).

Fig.1. Index of the user pages.

The main tab of the module configuration (Fig.2) contains the state of the module, provides the ability to select the default page and allows you to make the user pages list.

Fig.2. Main tab of the module configuration.

WWW-pages

The module provides the ability to create multiple implementations of WWW-pages in the object "User WWW-page" (Fig.3).

Fig.3. Main configuration tab of a user page.

The main tab contains the basic settings of the WWW-page:

• Section "State" — contains properties that characterize the state of the page: Status, "Enabled", the name of the database containing the configuration (with tracking the availability of the data in different storages and providing the sequentially removing duplicates) and date of the last modification.
• Identifier, name and description of the page.
• The state "Enabled", in which the page must be translated at boot.
• Language of the direct procedure or DAQ-Template associated with the page.

All requests to the user pages are sent to the direct procedure of the processing of the requests of the user page, or to the DAQ-Template procedure, which is represented on the "Program" tab of the user page object (Fig.4). In the case of the DAQ-Template, the template configuration tab is also provided (Fig.5).

Fig.4. The tab "Procedure" of an user WWW-page object.

Tab of the procedure for processing the requests to the user's page contains:

• Table of data context for the procedure. Preferably, it makes sense only when working on a template and where you can control this processing, including the possibility of intruding through the data values changing.
• The text of the direct procedure of the page, missed in the mode of work on the template.
• Links to the data of the "Data Acquisition" subsystem, which are visible and available for determination in the mode of work on the template and in the state "Enabled" of the page object.

For the direct processing procedure, and the required or optional ones to create in the template, the following exchange attributes with the HTTP-protocol are predetermined:

• Result (rez) <String> — processing result, by defaults — "200 OK"; in the DAQ-Template mode you must write thither directly, not by the operator "return"; to prevent sending a HTTP-wrapped response, put an empty string here, that is, send the response directly via SYS.Transport["Modul"]["in_Transp"].writeTo();
• HTTP request (HTTPreq) <String> — the HTTP request method like to GET, POST, ...;
• URL (url) <String> — URI of the request;
• WWW-page (page) <String> — content of the Get/Post page for the request and respond as well;
• Sender (sender) <String> — request sender;
• User (user) <String> — authenticated user;
• HTTP variables (HTTPvars) <Object> — HTTP variables; changed and appended variables (besides "Date", "Server", "Accept-Ranges" and "Content-Length") will be placed to the response package;
• URL's parameters (URLprms) <Object> — URL parameters;
• Content items (cnts) <Object::Array<XMLNodeObj>> — content items for POST;
• This object (this) <Object> — pointer to this page's object;
• Protocol's object (prt) <Object> — pointer to the input part object of the HTTP protocol;
• Transport's object (tr) <Object> — pointer to the input transport to the input part object of the HTTP protocol;
• Scheduling the next service call (schedCall) <Integer> — write here the time value in seconds for scheduling the procedure context execution in a service call; the service calls are performed in the periodicity 10 seconds usually, so you can schedule the calls not often than at 10 seconds.

The overall scenario of the user's page request:

• External network station generates an HTTP request with the following form of URI "/WebUser/{UserPage}" which falls on the OpenSCADA transport with the value of the configuration field "Protocol" equal to "HTTP".
• Transport sends the request to the module of the transport protocol "Protocol.HTTP".
• The transport protocol module, in accordance with the first element of the URI, sends the request to this module.
• This module selects the object of the user's page which is specified in the second element of the URI.
• Initialization of the HTTP-protocol variables for the page procedure is made:
  • HTTPreq — is set to value of the HTTP-Method (like to "GET", "POST"), depending on the request type;
  • url — address of the requested resource (URI);
  • page — the input single content and the sending page for the method "POST";
  • sender — address of sender of the request;
  • user — identifier of the authenticated user, if the authentication has occurred;
  • HTTPvars — parsed list of variables of the HTTP-protocol in the form of object's properties;
  • URLprms — parsed list of the URL parameters in the form of object's properties;
  • cnts — parsed content's items for POST, in the Array <XMLNodeObj>, with the elements content in the text and properties, in the XMLNodeObj attributes.
• Calling the procedure for execution, which, having processed the request, forms the page content in the "page" and the request result in the "rez".
• At the end, the answer is formed with the return code of the HTTP from "rez" and with the content from the "page", and also with changed and appended variables of the HTTP-protocol from "HTTPvars". For empty "rez" the answer is not generated!