Exploring Content Management - The Request Lifecycle
I wanted to write a few blogs that cover the fundamentals of how Content Management works from a bit of a deeper view, with the main goal just being increasing the general knowledge of how Content Management works. I find the more knowledge people have around how a solution works the better they can understand and troubleshoot any specific issue, or performance concern.
This first post focuses on the journey of an HTTP request within the system.
Content Management HTTP requests
Most interactions with a Content Management system originate as standard browser requests: logging in, navigating pages, uploading files, and so on. These requests first hit a web server, like IIS or Tomcat, which acts as the gateway to the Content Management system.
The web server's job is to run a specific component that bridges the gap between the web and the Content Management system. This component can be a Servlet, an ISAPI filter, or a CGI.
- Servlet (Java): Deployed within Tomcat, the Servlet is a Java application whose configuration details for communicating with Content Management are stored in Tomcat's configuration files.
- ISAPI Filter (IIS): The ISAPI filter (llisapi.dll) runs within IIS, constantly active but creating a new thread for each incoming request.
- CGI: CGI (cs.exe) is an older technology. It starts up, reads from the opentext.ini file, and shuts down for every single request – a less efficient approach.
Threading inside of Content Management
The Content Management system utilizes a variety of threads, each with specific responsibilities. The diagram below illustrates a subset of the threads spawned by LLServer, excluding components like Sockserv, Agents, and Distributed Agent Workers for clarity.
Web Server Socket
When the web server handles a request (using one of the methods described earlier), it creates a socket and passes it to LLServer. This socket remains attached and waiting until a receiver thread becomes available to process the request.
Receiver Threads
Receiver threads listen on port 2099 (by default), awaiting incoming requests. They deserialize these requests and queue them for the next available worker thread in the Worker Pool. It's important to note that the relationship between receivers and workers is not one-to-one. For example, Receiver 1 might pass work to Worker Thread 5.
Worker Threads
Worker threads are likely the most familiar threads to many. These threads are responsible for processing the actual request. As they generate output, they send it back down the socket to the web server. Closing the socket and completing the request.
The Request inside of the worker thread
Now let's take a deeper look inside of the Worker Thread. Each request can leverage a number of systems inside of Content Management.
The Dispatcher
The worker thread accepts the inbound request and calls the main oScript dispatch script (WEBDSP:RequestHandlerSubsystem.DispatchLLServer). This script performs crucial security checks, such as validating allowed IP addresses for CGI hosts, and then calls WEBDSP:RequestHandlerSubsystem.Dispatch. This second dispatch function parses the request parameters and determines the correct oScript to execute.
Request Handler
Request handlers are oScript objects responsible for authentication, processing the request, and generating the output. You can often identify them by ?func=
LLNode (Business Logic)
LLNodes are oScript objects that embody the business logic. Each LLNode (or SubType)controls the implementation of specific actions. (i.e. Copy) They communicate with the core Content Management engine using DAPI, CAPI, UAPI, and WAPI calls, and also provide Node Callbacks for the engine.
WebNode (Presentation)
WebNodes handle user interface actions like browsing. Like LLNodes, they are uniquely assigned to each subtype. They are typically invoked via ?func=ll.X request handlers. The objaction parameter specifies the action, and objid identifies the target object.
CSNode (API Layer)
The newest layer, CSNode, acts as an API wrapper around LLNode. Used by core, optional, and custom modules, it provides a more consistent and programmatic interface, while the core business logic remains within LLNode.
The REST interface for Content Management is a major consumer of the CSNode layer.
WebLingo (Dynamic Pages)
Similar to PHP, WebLingo blends code (oScript) with HTML to create dynamic pages. WebLingo files (typically .html) can include other WebLingo files, promoting reusable components.
Callbacks (Engine Communication)
Callbacks function as a way for the Engine of Content Management to call into oScript functions. DAPI and WAPI operations commonly use callbacks. LLNodes usually implement DAPI callbacks as scripts prefixed with "CB," although there are exceptions.
Hopefully, this breakdown has shed some light on how requests are processed within a Content Management system.
Back to post listing