Understanding PeopleSoft Pure Internet Architecture

This chapter discusses:

PeopleSoft Pure Internet Architecture fundamentals.
Database server.
Application servers.
Batch server environment.
Web server.
Web browser.
Configuration and deployment options.

PeopleSoft Pure Internet Architecture Fundamentals

Your PeopleSoft application runs on PeopleSoft Pure Internet Architecture, which requires a variety of software and hardware elements:

A relational database management system (RDBMS) server.
An application server.
A batch server.
A web server.
A web browser.

It's important to understand the role of each element before you can decide which configuration will work best for your implementation of PeopleSoft Pure Internet Architecture. The following diagram illustrates, at a high level, the physical relationship between PeopleSoft Pure Internet Architecture elements:

High-level PeopleSoft Pure Internet Architecture relationships

Configuring PeopleSoft Pure Internet Architecture is not just about enabling internet application deployment through a browser. PeopleSoft Pure Internet Architecture enables you to take advantage of all PeopleSoft intranet and internet solutions, as well as PeopleSoft integration technologies such as PeopleSoft Integration Broker.

See the PeopleSoft platforms database on the PeopleSoft Customer Connection website.

Database Server

The database server houses a database engine and your PeopleSoft application database, which includes all the application's object definitions, system tables, application tables, and data. The database server must be running one of the PeopleSoft-supported RDBMS and operating system combinations.

A single database server can have multiple application servers connecting to it. The database server simultaneously handles the application server connections, development environment connections, and batch programs running against it.

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

The PeopleSoft database is the repository for all information managed by your PeopleSoft application. Both application data and PeopleSoft metadata are stored and maintained in the database. PeopleSoft Application Designer enables you to define and maintain this metadata, which the system uses to drive the runtime architecture. The application server runs business logic based on the metadata.

Use PeopleSoft Application Designer to define, configure, and modify PeopleSoft applications. You can create dozens of different types of application objects, such as fields, records, pages, and messages. When an application developer saves an application object, PeopleSoft Application Designer saves this definition to the metadata repository in the PeopleSoft database.

At runtime, the application server fetches the most recent application object definitions from the metadata repository, compiles and caches the application object into memory, and runs the business rules based on the definitions.

Application Servers

This section discusses:

Application servers.
Domains.
Listeners, handlers, and queues.
PeopleSoft server processes.
Services.
BEA products.
Database connectivity.

Application Servers

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.

Domains

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.

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 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 home directory, or PS_HOME. In this context, PS_HOME refers to the PeopleSoft high-level directory on the application server, not the file server. PS_HOME is the directory to which you installed the PeopleSoft application server files when using the Server Transfer program.

PSADMIN creates a directory beneath PS_HOME\appserv for each application server domain that you configure. Using the previous HRDMO example, suppose 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_HOME\appserv directory on the application server.

When you boot an application server domain, it 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 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.

Listeners, Handlers, and Queues

Listeners, handlers, and queues provide the basis of the application server functionality. Understanding the role of each element is essential when you configure and tune your application server. For instance, although it is important to know how to configure multiple Java server handlers, it is equally important to know why and when to perform this task.

The following diagram illustrates application server processes:

Application server components and server processes

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 left out.

Note. When discussing PeopleSoft architecture mechanics, the term service becomes 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:

Item	Description
Workstation listener (WSL)	The workstation listener monitors BEA 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 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 BEA 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.
BEA Jolt server listener (JSL)	The BEA Jolt server listener applies only to browser requests. The BEA Jolt server listener monitors the BEA Jolt port for connection requests sent from the browser through the web server. After the BEA Jolt server listener accepts a connection, it directs the request to a BEA Jolt server handler. From that point, the browser interacts with the BEA Jolt server handler. This is analogous to the relationship between the workstation server listener and workstation server handler.
BEA Jolt server handler (JSH)	The BEA Jolt server handler applies only to browser requests. The BEA Jolt server handler processes the requests it receives from the BEA Java server listener. The port numbers for the BEA Jolt server handler are selected internally by BEA Tuxedo in sequential order.
Request queues	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, PSQCKSRV on QCKQ). The workstation handler and BEA Jolt server handler insert requests into the appropriate queue, and then the individual server processes complete each request in the order that it appears.
Server processes	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.

PeopleSoft Server Processes

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 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.

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 boot the application server domain. This helps you to handle predicted workloads. Furthermore, BEA Tuxedo can dynamically spawn incremental server processes to handle increasing numbers of transaction requests. The capability to configure multiple server processes and spawn 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.

The basic PeopleSoft server processes are:

PSAPPSRV

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.
PSQCKSRV

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

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.
PSSAMSRV

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.
PSOPTENG

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.)

PSMSGDSP
PSMSGHND
PSPUBDSP
PSPUBHND
PSSUBDSP
PSSUBHND

Note. You can examine servers by using the ps -ef command in UNIX or Task Manager in Microsoft Windows NT. The PeopleSoft configuration utility, PSADMIN, also offers a monitoring utility.

Services

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. BEA 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. You can see the association between the many services and server processes by reviewing the PSAPPSRV.UBB file.

BEA Products

PeopleSoft uses BEA Tuxedo, a middleware framework and transaction monitor, to manage database transactions. PeopleSoft also uses BEA 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 BEA Tuxedo and Jolt are required.

Although we document the BEA components with respect to their function within the context of a PeopleSoft environment, we do not duplicate the documentation provided by BEA. You should become familiar with the BEA documentation that we ship along with our products. The BEA documentation provides an extensive error catalog that serves as an invaluable source of information when troubleshooting.

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

See the Enterprise PeopleTools 8.49 installation guide for your database platform.

Database Connectivity

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.

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.

Batch Server Environment

This section provides discusses:

Batch server environment.
Batch server support.
PeopleSoft Process Scheduler and the application server.

Batch Server Environment

The batch server environment is where you have PeopleSoft Process Scheduler installed and configured, and it is the location where many of your batch programs, such as Application Engine programs, run. In most situations, this is also where you have COBOL and SQR executables installed.

In a multiserver environment, you can decide where your sites' batch server environment resides. In PeopleSoft, you can install the batch server on a separate server, or it can run on either the application server or the database server.

Batch Server Support

You can install PeopleSoft Process Scheduler on any supported application server, database server, or batch server, but it's important that you choose a location that’s supported in the PeopleSoft environment. There at least two options for each database environment.

If you install PeopleSoft Process Scheduler on a machine that is a supported database machine, but not a supported application server machine, you can still configure and administer PeopleSoft Process Scheduler using PSADMIN, the PeopleTools server administration utility. However, you won't be able to access application server options from PSADMIN.

PeopleSoft Process Scheduler and the Application Server

PeopleSoft uses PSADMIN to configure and administer both the application server and PeopleSoft Process Scheduler server. The PeopleSoft Process Scheduler setup procedure in PSADMIN provides a menu-driven interface to configure PeopleSoft Process Scheduler parameters and administer the Process Scheduler server agent.

Even though the application server and PeopleSoft Process Scheduler have PSADMIN as a common interface and share the directories under PS_HOME on the application server, they are separate entities. For instance, you boot, configure, and shut down the application server and the PeopleSoft Process Scheduler server separately.

The application server uses BEA Tuxedo to schedule transaction requests and send transaction results, and it issues SQL requests to the database server using the persistent connections of a collection of PeopleSoft application server processes.

In contrast, PeopleSoft Process Scheduler is a separate facility that's designed to poll the PeopleSoft database table, PSPRCSRQST, for inserted requests and initiate Application Engine, COBOL, SQR, and other batch processes.

Web Server

A Java-enabled web server is required to support browser transaction requests and PeopleSoft application messaging technology. You install on the web server a collection of PeopleSoft Java servlets designed to handle a wide range of PeopleSoft transactions.

This section discusses:

Server software elements.
PeopleSoft servlets.
BEA Jolt.

Server Software Elements

During the PeopleSoft installation, a variety of PeopleSoft Java servlets are installed on the web server, so, you must have a supported servlet engine installed.

The following software runs on the PeopleSoft Pure Internet Architecture web server:

Web services.

Web services software manages the web server, such as WebLogic or WebSphere.
Servlet engine.

The servlet engine is the environment in which servlets run. This component is tied to the web services software, but in some cases you install it separately.
Java servlets.

Java is a platform-independent programming language used widely for web-based programs. Servlets are Java programs that run on the web server. The Java executables are required for the servlet engine to operate.

PeopleSoft Servlets

The following PeopleSoft servlets reside on the web server:

Portal servlet.

The portal servlet handles all of the requests and formatting for the users accessing PeopleSoft through PeopleSoft portal technologies. It manages search, content management, and homepage personalization.
Integration gateway servlet.

This servlet transmits publish/subscribe messages between message nodes. The gateway handles PeopleSoft-to-PeopleSoft messages, PeopleSoft-to-third party messages, and third party-to-PeopleSoft messages.
Report repository servlet.

This servlet enables users to easily access and distribute the output of batch reports, such as Crystal and SQR, run through PeopleSoft Process Scheduler over the internet. This servlet retrieves the report output in the report repository and serves it to the browser.

BEA Jolt

The PeopleSoft servlets on the web server transmit requests and data through a connection to BEA Jolt, which runs on the application server. BEA Jolt extends BEA Tuxedo capabilities to the communication layer between the web-based environment and the C++ environments. You configure the servlets to direct requests from the web server to a predefined BEA Jolt port on the application server.

BEA Jolt must coexist with Tuxedo on the same application server machine. BEA Jolt can’t function without Tuxedo. The following diagram shows the relationship between PeopleSoft Pure Internet Architecture components:

BEA Jolt in relation to other components

Web browsers don't connect directly to the application server. Instead, they send HTTP requests to the portal servlet running on the web server. The web server translates the HTTP request into a BEA Jolt request that is sent to a specified Jolt port. Then the application server itself, leveraging BEA Tuxedo, runs the appropriate SQL against the database.

Web Browser

The web browser is the primary means by which users and administrators access PeopleSoft applications and administrative tools.

You must make sure that a supported browser is installed on each workstation. You do not need to install other software on the workstation running the browser, such as applets or connectivity software. The system sends pure HTML to the browser.

A web browser uses the HTTP protocol. The browser sends a request to the web server, which forwards the request to the application server. A servlet installed on the web server facilities all browser connections.

The browser does not download any applets to complete a transaction. The application server sends only the following to the browser:

HTML
JavaScript
Cookies

Because the browser processes only this basic internet content, the client workstation is not burdened with unnecessary processing responsibility.

PeopleSoft Pure Internet Architecture leverages web browser cookies to store a unique access token for each user when the user is initially authenticated. When the user connects to another PeopleSoft system, the token in the browser cookie is used to reauthenticate the user and bypass the sign-in process. The browser cookie is an in-memory cookie and is never written to disk. The cookie is also encrypted to prevent snooping and check-summed to prevent tampering.

Note. With PeopleSoft Pure Internet Architecture, there is no traditional client software installation. Most processing occurs at the server level. PeopleSoft still supports the PeopleTools development environment in Microsoft Windows, which is intended for application developers and system administrators who need access to PeopleTools. These users require workstations running Microsoft Windows.

Web Browser Cookies Setting

To use PeopleSoft Pure Internet Architecture, the Internet option to allow session cookies must be enabled.

To enable session cookies:

From your browser menu, select Tools, Internet Options, Security, Custom Level.
Scroll down to the Cookies – Allow per-session cookies (not stored) option.
Select Enable.
Click OK to save the setting.
Click OK again, to close the dialog window.

Note. The Internet option to allow cookies that are stored on your computer is optional.

Configuration and Deployment Options

This section discusses:

Configuration options.
Deployment options.

Configuration Options

You can configure your environment to support either a physical or a logical application server configuration. In some cases, the PeopleSoft standard installation procedure recommends one or the other depending on the combination of database and operating system at your site.

Generally, your application server should be on the same physical machine as the database server. This produces a logical separation between the application server and database server. If the application server and database server don't reside on the same machine, then the application server and the database server should be connected to the same high-performance backbone network. This ensures optimum performance.

Logical Application Server Configuration

A logical application server environment means that one or more servers share the same physical machine. The servers are logically, but not physically, separate.

The following diagram depicts a logical configuration with two server machines—one for the web server, and the other for the application and database servers:

Logical application server configuration

The solid line surrounding the application server and the database server represents one physical machine. In this case, a logical application server configuration is possible only when both the database server and the application server are supported on a particular operating system. This shows that certain PeopleSoft Pure Internet Architecture elements can share the same machine.

Although this diagram depicts the application server and the database server sharing the same machine, the web server could also reside on the same machine with both the application server and the database server. The only requirement is that each component be supported by the underlying operating system. If all servers are located on the same machine, however, you should consider security issues. If you're deploying PeopleSoft applications to the internet, you will most likely want your web server outside of your network firewall and not on the same machine as the database server.

Note. For development, testing, or training purposes, you might want to have all PeopleSoft Pure Internet Architecture elements on the same Microsoft Windows NT or UNIX machine.

Physical Application Server Configuration

A physical application server configuration means that each component resides on a separate machine. The following diagram depicts a physical application server configuration:

Physical application server configuration

Deployment Options

There are a variety of user deployment options.

PeopleTools Base Portal

You can use the PeopleTools base portal to deploy PeopleSoft applications to a browser. The portal enables you to integrate PeopleSoft content with content from other data sources. The PeopleSoft portal can stand on its own, or you can integrate it with any enterprise portal that you may already be using.

PeopleSoft portal technology consists of the portal servlet and an application server. These two components work together to provide common portal processing, such as page assembly, search ability, content management, navigation, and homepage personalization. You can combine content from a wide variety of data sources and deliver the result to users in a unified, simple-to-use interface.

Development Environment

Although the majority of users connect using browsers, application developers and system administrators, who require access to PeopleTools, must use Microsoft Windows workstations. PeopleSoft Application Designer and various other PeopleTools applications are not accessible through a browser.

With the PeopleTools development environment in Microsoft Windows, you can connect directly to the database (two-tier), or you can connect through an application server (three-tier).

Integration Technologies

Although PeopleSoft integration solutions don't deploy a user interface, they do enable you to share information with third-party systems and other PeopleSoft databases. To take advantage of these integration solutions, you must configure PeopleSoft Pure Internet Architecture. PeopleSoft provides the following integration technologies:

PeopleSoft Integration Broker.

This middleware technology facilitates synchronous and asynchronous messaging among internal systems and with trading partners, while managing message structure, message format, and transport disparities.
PeopleSoft Component Interfaces.

This object-oriented, request/reply, component architecture enables third-party applications to synchronously invoke PeopleSoft business logic.
PeopleSoft Business Interlinks.

This plug-in framework enables PeopleSoft applications to easily invoke third-party application programming interfaces over the internet.

Introducing Component Interfaces