Application Servers

This section provides an overview of Application Servers and the components related to them.

The application server is the core of PeopleSoft Internet Architecture. It runs business logic and submits SQL to the database server. An application server consists of numerous PeopleSoft server processes, grouped in domains. Each server process within a domain provides unique processing abilities, enabling the application server to respond effectively to a multitude of transaction requests generated throughout the PeopleSoft architecture.

Application servers require database connectivity software installed locally to maintain the SQL connection with the RDBMS. You must install the required connectivity software and associated utilities for your RDBMS on any server on which you intend to run the PeopleSoft Application Server.

After the application server establishes a connection to the database, any device that initiates a transaction request through the application server takes advantage of the application server's direct connection to the database.

PeopleSoft uses Oracle Tuxedo, a middleware framework and transaction monitor, to manage transactions between the application server and the database. PeopleSoft also uses Oracle Jolt, a Java API and class library, to facilitate communication between Tuxedo running on the application server and the PeopleSoft software running on the web server. Tuxedo and Jolt are required elements of the PeopleSoft application server.

Note: Tuxedo doesn’t actually perform processing on the application server; it schedules PeopleSoft server processes to perform the transactions.

A domain is the collection of server processes, supporting processes, and resource managers that enable the database connections required to fulfill application requests. You manage each domain with a separate configuration file, and you configure each application server domain to connect to a single database. A single application server machine can support multiple application server domains running on it. You configure an application server domain using the PSADMIN utility.

There can be a one-to-one or a many-to-one relationship between application server domains and a database. In the simplest case, you configure a single application server domain to connect to a single PeopleSoft database. In a more sophisticated environment, you may configure multiple application server domains, with each domain connecting to the same PeopleSoft database. The opposite is not valid; a single application server domain cannot be used to connect to multiple PeopleSoft databases.

For example, suppose you have installed three application databases. In this case, you must configure at least three application server domains, one for each database. As demand increases, you may need to configure multiple application server domains per database, for redundancy, fail-over, and performance reasons.

You can configure multiple application server domains under a single PeopleSoft configuration home directory, or PS_CFG_HOME. In this context, PS_CFG_HOME refers to the PeopleSoft high-level directory on the application server. PS_CFG_HOME is the directory to which you installed the PeopleSoft application server configuration files creating a domain.

PSADMIN creates a directory beneath PS_CFG_HOME\appserv for each application server domain that you configure. For example, suppose you create three domains: HCMDMO1, HCMDMO2, and HCMDMO3. In this case, PSADMIN creates subdirectories \HCMDMO1, \HCMDMO2, and \HCMDMO3 beneath the PS_CFG_HOME\appserv directory.

When you boot an application server domain, it starts the set of server processes associated with that domain. Numerous server processes run in a domain. Each server process establishes a persistent connection to a PeopleSoft database, and this connection acts as a generic SQL pipeline that the server process uses to send and receive SQL. Each server process uses its own, exclusive, SQL connection to facilitate requests from multiple sources. From the RDBMS perspective, each server process within a domain represents a connected user.

A server process is executable code that receives incoming transaction requests. The server process carries out a request by making calls to a service, such as MgrGetObject. The server process waits for the service to complete, then returns information to the device that initiated the request, such as a browser. While a server process waits for a service to complete, other transaction requests wait in a queue until the current service completes. A service may take a fraction of a second to complete or several seconds, depending on the type and complexity of the service. When the service completes, the server process is then available to process the next request in the corresponding queue.

The number of server processes of each type is configurable and typically varies within a domain, depending on the requirements of your application or the main purpose of the domain. For example, if a domain's primary function is to handle application requests, you might see more of the server processes devoted to that task within that domain, such as PSAPPSRV, PSQCKSRV, and PSQRYSRV. Likewise, if a domain's primary function is to handle Integration Broker SOA requests, you might see more of the server processes devoted to that task in the domain, such as the messaging server processes.

You need to configure only those server processes that your implementation requires per domain. The minimum server processes that a domain requires are PSAPPSRV, PSSAMSRV, and PSWATCHSRV.

Note: PSWATCHSRV is a process that always starts in a domain. It is not an optional server process.

You can configure multiple instances of the same server processes to start when you boot the application server domain. This helps you to handle predicted workloads.

The following tables describes the PeopleSoft server processes. Not all of the server processes will necessarily be a part of every domain as that depends on the configuration options you select.

The required server processes are:

Server Process

Description

PSAPPSRV

This process performs functional requests, such as building and loading components. It also provides the memory and disk-caching feature for PeopleTools objects on the application server. PSAPPSRV is required to be running in any domain.

PSSAMSRV

This SQL application manager process handles the conversational SQL that is mainly associated with Application Designer. This process is required to be running on any domain.

PSWATCHSRV

Monitors the domain and detects any orphaned application server processes.

Other server processes that you can elect to configure based on your system requirements, include:

Server Process

Description

PSQCKSRV

Handles quick, read-only SQL requests. This is an optional process designed to improve performance by reducing the workload of PSAPPSRV.

PSQRYSRV

Handles any query run by PeopleSoft Query. This is an optional process designed to improve performance by reducing the workload of PSAPPSRV.

PSMSGDSP, PSMSGHND, PSPUBDSP, PSPUBHND, PSSUBDSP, PSSUBHND

Used for "Publish-Subscribe" processing for Integration Broker and the PeopleSoft service oriented architecture (SOA).

PSANALYTICSRV

Performs processing and requests required for Analytic Calculation Engine.

PSRENSRV

Enables real-time event notification (REN) used in various PeopleTools technology, such as MultiChannel Framework and report distribution.

PSUQSRV, PSMCFLOG

Used within the MultiChannel Framework to manage queues and transaction logs.

PSPPMSRV

Handles the processing of all the data recorded by the Performance Monitor.

PSDBGSRV

When debugging PeopleCode, this server process maintains an independent connection to the database to avoid conflict.

When a PeopleSoft application sends a request to the application server, it sends a service name and a set of parameters, such as MgrGetObject and its parameters. Tuxedo then queues the transaction request to a specific server process that is designed to handle certain services.

When a server process boots, it advertises to the system the predefined services it handles.

Note: When discussing PeopleSoft architecture mechanics and system features, the term service is used in various contexts. The following statement may help to clarify this term within the context of an application server domain: An application server domain calls server processes, such as PSAPPSRV, which in turn invoke services, such as MgrGetObject, which run against the database. The services called by domain server processes are not to be confused with the services and service operations associated with the service oriented architecture (SOA) provided by Integration Broker.

Listeners, handlers, and queues provide the basis of a domain's functionality. They receive requests, route requests, store requests, monitor requests, and return request responses.

Image: Listeners route application requests to handlers where they are placed in queues monitored by server processes that submit requests to the database

The following diagram illustrates how listeners, handlers, and queues interact with incoming requests and server processes:

Listeners route application requests to handlers where they are placed in queues monitored by server processes that submit requests to the database

Note: For simplicity, the diagram does not depict every server process that runs on the application server.

The following table describes each component depicted in the previous diagram:

Item

Description

Browser

Enables internet and intranet access to all PeopleSoft applications, including many PeopleTools system administration interfaces.

Development Environment

A Microsoft Windows workstation used for specific application development and system administration tasks. For example, an application developer accesses Application Designer in the development environment to modify a page or record definition. Likewise, a system administrator would access PeopleSoft Data Mover in the development environment to import a data file. Using the development environment you can connect directly to the database (a two-tier connection) or through the application server (a three-tier connection).

Note: Using the PeopleTools development environment in Microsoft Windows, you can connect directly to the database, or through an application server.

Note: No end user applications are deployed to the C++/Windows platform. All end user applications are deployed through the browser.

Workstation listener (WSL)

The workstation listener monitors Tuxedo ports for initial connection requests sent from the PeopleTools development environment (as in Application Designer). After the workstation listener accepts a connection from a workstation, it directs the request to a workstation handler. From that point, the workstation interacts only with the workstation handler to which it is assigned.

Workstation handler (WSH)

The workstation handler processes the requests it receives from the workstation listener. A unique port number identifies a workstation handler. The port numbers for the workstation handler are selected (internally by Tuxedo) from a specified range of numbers. You can configure multiple workstation handlers to start automatically if demand increases and other handlers become overloaded.

Jolt server listener (JSL)

The Jolt server listener applies only to browser requests. The Jolt server listener monitors the Jolt port for connection requests sent from the browser through the web server. After the Jolt server listener accepts a connection, it directs the request to a Jolt server handler. From that point, the browser interacts with the Jolt server handler. This is analogous to the relationship between the workstation server listener and workstation server handler.

Jolt server handler (JSH)

The Jolt server handler applies only to browser requests. The Jolt server handler processes the requests it receives from the Java server listener. The port numbers for the Jolt server handler are selected internally by Tuxedo in sequential order.

Request queues

Each type of server process has a service request queue that it shares with other server processes of the same type. For example, PSAPPSRV processes use the queue, APPQ, and PSQCKSRV processes use the queue, QCKQ. The workstation handler and Jolt server handler insert requests into the appropriate queue, and then the individual server processes complete each request in the order that it arrives.

Server processes

The server processes act as the core of the application server domain. They maintain the SQL connection and make sure that each transaction request gets processed on the database and that the results are returned to the appropriate origin.