WebApps that run within browsers are usually based on HTTP(S) protocols. These protocols consist of messages being sent from the client to the browser, then to the server, and the server sends back a response. There is no continuous connection between the client and the server.
There are two main types of HTTP requests.
POST requests: the request and the response contain content such as calls to web services, AJAX calls or to upload files
When an application is accessed and used in the browser, each action that takes place causes requests to be sent to the server. The whole of those requests forms a “session.” Every session is assigned a session ID or key by the server within the first request and is stored in a cookie. The cookie is sent by the browser with each request to a specific domain, so that the server can identify which session the request belongs to.
The WebApp Server runs on the server with the Microsoft Internet Information Server (IIS), and is responsible for mapping requests to the right application. For each application, the WebApp Server has a pool of DataFlex-written processes that are available to handle the requests.
A request comes in through IIS. IIS forwards it to the server that passes it to an available DataFlex process to be handled. The response that is generated is then relayed back through the WebApp Server to the client via IIS.
The request handling in DataFlex is accomplished with the cWebService or cWebHttpHandler class.
The WebApp Server has a pool of processes available for each application. HTTP requests that come in are spread throughout the available processes to distribute the load. This means that multiple requests from a single session may be handled by different processes. Because the same process may be handling requests from different sessions, and sessions may have requests being sent to different processes, data cannot be stored in memory and assume it to be there with the next call that comes in.
WebApp Framework request handling steps:
Error handing is started
Errors are stored in a que, and at the end of the request they are sent back to the client in the response
Session is validated
Web property initialization is started
Re-finds records currently in use by open views
Server actions are performed
Example: on-click on a button
DDO Synchronization again to store changes to records on the screen
Recording of changes to web properties
Changes in client web properties are added to the response, and changes in server properties are stored in the database
Finish error recording
Errors to the response
The synchronization that is done is per view. This means that not all views within the application are always in synch. This is an optimization because a request usually only involves a single view. The view that is currently open is in sync and is invoking views as well. For drill-down applications, the invoking view is the view that sends the navigate forward into the current view. For model dialogs, the invoking view is the view that has opened the dialog.
DDOs and client web properties are only in sync and available for views that in sync. IsViewInSync (cWebApp) is a message that can be used to query whether a view is in sync or not.