This section discusses:
Listeners, handlers, and queues.
PeopleSoft server processes.
The application server is the core of PeopleSoft Pure Internet Architecture; it runs business logic and issues SQL to the database server. An application server consists of numerous PeopleSoft services and server processes. Just as different elements make up the physical environment in which an application server operates, such as database servers and web servers, a variety of elements operate on the application server, enabling it to respond effectively to a multitude of transaction requests and handle transaction processing, system scaling, browser requests, and so on.
An application server maintains the SQL connection to the database for browser requests and the PeopleTools development environment in Microsoft Windows.
You should have a general knowledge of how an application server operates before you attempt to configure and tune it.
An application server domain is the collection of server processes, supporting processes, and resource managers that enable connections to the database. 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 located in the PS_HOME\appserv directory on the application server.
A one-to-one or a many-to-one relationship can exist 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 can configure multiple application server domains, with each domain connecting to the same PeopleSoft database. The opposite is not true; a single application server domain cannot be used to connect to multiple PeopleSoft databases.
For example, suppose that you have installed three databases, HRDMO1, HRDMO2, and HRDMO3, and you want to enable browser requests to each database. 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, not the file server. PS_CFG_HOME is the directory in which you installed the PeopleSoft application server configuration files when using the Server Transfer program.
PSADMIN creates a directory beneath PS_CFG_HOME\appserv for each application server domain that you configure. Using the previous HRDMO example, suppose that you decided to name the application server domains the same name as the database to which they connect. In this case, PSADMIN creates subdirectories \HRDMO1, \HRDMO2, and \HRDMO3 beneath the PS_CFG_HOME\appserv directory on the application server.
Starting an application server domain starts the set of server processes associated with that domain, such as PSAPPSRV, PSQCKSRV, and PSSAMSRV. 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 the same SQL connection to facilitate requests from multiple sources. From the RDBMS perspective, each server process within a domain represents a connected user.
For simplicity, the diagram does not depict every server process that runs on the application server. For example, the optimization server process, PSOPTENG, is not pictured, and integration server processes were also omitted.
Note: When PeopleSoft architecture mechanics is discussed, the term service is overused. The following statement may help to clarify this term: An application server domain calls server processes, such as PSAPPSRV, which in turn invoke services, such as MgrGetObject, on the database.
The following table describes each component depicted in the previous diagram:
Workstation listener (WSL)
The workstation listener monitors Oracle Tuxedo ports for initial connection requests sent from the PeopleTools development environment. After the workstation listener accepts a connection from a workstation, it directs the request to a workstation handler. From that point, the Microsoft Windows workstation interacts with the workstation handler to which it is assigned.
Workstation handler (WSH)
The workstation handler processes the requests that 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 Oracle Tuxedo) from a specified range of numbers. You can configure multiple workstation handlers to take care of demand increases; new processes are created as other processes become overloaded.
Oracle Jolt server listener (JSL)
The Oracle Jolt server listener applies only to browser requests. The Oracle Jolt server listener monitors the Oracle Jolt port for connection requests sent from the browser through the web server. After the Oracle Jolt server listener accepts a connection, it directs the request to an Oracle Jolt server handler. From that point, the browser interacts with the Oracle Jolt server handler. This is analogous to the relationship between the workstation server listener and workstation server handler.
Oracle Jolt server handler (JSH)
The Oracle Jolt server handler applies only to browser requests. The Oracle Jolt server handler processes the requests that it receives from the Oracle Java server listener. The port numbers for the Oracle Jolt server handler are selected internally by Oracle Tuxedo in sequential order.
Each type of server process has a service request queue that it shares with other servers of the same type (as in PSAPPSRV on APPQ and PSQCKSRV on QCKQ). The workstation handler and Oracle Jolt server handler insert requests into the appropriate queue, and then the individual server processes complete each request in the order that it appears.
The server processes act as the heart 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.
Multiple server processes run in an application server domain. 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.
Server processes invoke services to perform application logic and issue SQL to the RDBMS. Each application server process, such as PSAPPSRV, PSQCKSRV, PSQRYSRV, PSSAMSRV, or PSOPTENG, establishes and maintains its own connection to the database.
The server process waits for the service to finish, then returns information to the device that initiated the request, such as a browser. While a server process waits for a service to finish, other transaction requests wait in a queue until the current service finishes. A service may take a fraction of a second to finish or several seconds, depending on the type and complexity of the service. When the service finishes, the server process is then available to process the next request in the corresponding queue.
You need to configure only those server processes that your implementation requires per domain. The minimum server processes that a domain requires are PSAPPSRV and PSSAMSRV.
You can configure multiple instances of the same server processes to start when you start the application server domain. This helps you handle predicted workloads. Furthermore, Oracle Tuxedo can dynamically generate incremental server processes to handle increasing numbers of transaction requests. The capability to configure multiple server processes and generate incremental server processes contributes to the application server's scalability.
The following list describes the possible server processes included in an application server domain. Depending on the configuration options that you choose, not all of the server processes will necessarily be a part of every domain.
This process performs functional requests, such as building and loading components (which were known as panel groups in previous releases). 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.
This process performs quick, read-only SQL requests. This is an optional process designed to improve performance by reducing the workload of PSAPPSRV.
This process is designed to handle any query run by PeopleSoft Query. This is an optional process designed to improve performance by reducing the workload of PSAPPSRV.
This SQL application manager process handles the conversational SQL that is mainly associated with PeopleSoft Application Designer. This process is required to be running on any domain.
This optimization engine process provides optimization services in PeopleSoft Optimization Framework. You need to configure this process in a server domain only if you want to use the optimization plug-in delivered with PeopleSoft applications.
The following set of server processes is used for application messaging. (Your messaging domain must also contain PSAPPSRV and PSSAMSRV, the required server processes.)
Note: You can examine servers by using the ps -ef command in UNIX or Task Manager in Microsoft Windows. The PeopleSoft configuration utility, PSADMIN, also offers a monitoring utility.
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. Oracle Tuxedo then queues the transaction request to a specific server process that is designed to handle certain services.
When a server process starts, it advertises to the system the predefined services it handles. You can see the association between the many services and server processes by reviewing the PSAPPSRV.UBB file.
PeopleSoft software uses Oracle Tuxedo, a middleware framework and transaction monitor, to manage database transactions. PeopleSoft software also uses Oracle Jolt, a Java API and class library, as the layer that facilitates communication between the PeopleSoft servlets on the web server and the application server. Both Oracle Tuxedo and Jolt are required.
Although we document the Oracle components with respect to their function within the context of a PeopleSoft environment, we do not duplicate the documentation provided by Oracle. You should become familiar with the Oracle documentation that we ship along with our products. The Oracle documentation provides an extensive error catalog that serves as an invaluable source of information when you are troubleshooting.
Note: Oracle Tuxedo doesn’t actually perform processing on the application server; it schedules PeopleSoft server processes to perform the transactions.
See PeopleSoft 9.2 Application Installation for your database platform.
Application servers require database connectivity software to be installed locally to maintain the SQL connection with the RDBMS. You must install the required connectivity software and associated utilities for your RDBMS.
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 and therefore requires no connectivity software.