Appendix: WebLogic Managed Server Architecture

The PeopleSoft Internet Architecture running on the WebLogic Server takes advantage of WebLogic’s managed server architecture. This appendix provides overview discussion and discusses:

• Administering a WebLogic server life cycle.

• Tuning performance and monitoring resources.

• Changing configuration settings.

• Applying an example single-server configuration.

• Applying an example multi-server configuration.

See Also

Working with Oracle WebLogic

Clustering and High Availability for PeopleSoft on My Oracle Support

PeopleSoft Internet Architecture Servlets and Applications

PIA is packaged as a J2EE Enterprise Archive and is comprised of a collection of J2EE web applications, commonly referred to as webapps or servlets. For the most part, in the context of PeopleSoft, the term 'servlets' is used. The PeopleSoft servlets are:

In addition, these servlets are added when you install PIA on a WebLogic server machine. These elements are not part of the PeopleSoft Enterprise Archive, but instead are defined individually.

WebLogic Domain Types

This section provides an overview of Weblogic domain types and discusses:

• Single-server domain.

• Multi-server domain.

• Distributed managed server.

• Common default settings.

• Single-server and multi-server/distributed server analogy.

• Domain topology.

Understanding WebLogic Domain Types

During PIA setup, you can choose between two different WebLogic domain configurations: a single-server domain and a multi-server domain. A multi-server domain can be expanded across multiple machines using the distributed managed server option. So, a distributed managed server implementation is a variation of the multi-server domain. Each of these domain configurations has a specific purpose but is fully customizable beyond that purpose.

This section discusses:

• single-server domains.

• multi-server domains.

• distributed managed servers.

Single-Server Domains

In a single-server configuration, the WebLogic domain’s administration console and the J2EE components of PIA are all provided on a single instance of WebLogic Server. This configuration is intended for single-user or very small scale, non-critical production environments. It can be used as a starting point for you to familiarize yourself with WebLogic Server.

In a single-server domain, the resources used to administer WebLogic Server and your PeopleSoft application are not isolated from one another, therefore you don't administer each element individually. While each element must complete for the same resources, the low resource requirements of this configuration make it ideal for small scale and non-production usage.

The single-server domain in a PeopleSoft implementation consists of only one server: PIA.

Single-Server Deployment

Some of the servlets deployed in a single-server domain configuration must be accessed using a modified URL:

http://server:port/servlet_name/...

The single-server domain configuration deploys servlets as follows:

Single-Server Domain Specific Settings

To configure the single-server domain specific settings, launch the Administration Console.

In the console, expand the Environment tree and select Servers. Click on the PIA server. Select the Configuration tab, and the General sub-tab. The default web application for the PIA server is PORTAL. The single-server domain specific default settings for the PIA server are as follows:

Note. To configure SSL, you must also define SSL certificates.

See Implementing WebLogic SSL Keys and Certificates.

Example: Single-Server Domain

The following illustrates sample contents of a typical single-server domain:

Multi-Server Domains

The multi-server domain configuration is intended for production environments. This configuration takes advantage of WebLogic’s administration server and managed server architecture. In a multi-server configuration, multiple instances of WebLogic server are used, each contributing a specific function. The WebLogic console is provided on the domain’s administration server, WebLogicAdmin, and the J2EE components of PIA are provided on individual or shared WebLogic managed servers.

A production application warrants process and resource pool isolation for greater stability and optionally tighter security controls, which this configuration provides. In a multi-server configuration, the resources used for WebLogic domain administration and monitoring are isolated from similar resources used to support the PIA application. A server process named WebLogicAdmin performs nothing but WebLogic administration, which includes domain administration and monitoring. Continuing that separation, the individual PIA servlets are (usually) isolated from each other. The PIA servlets are targeted and deployed across a portion of the six remaining server definitions, all of which are classified as managed servers, which are delivered in the multi-server configuration.

A multi-server domain in a PeopleSoft implementation creates the following servers:

Multi-Server Servlet Deployment

Some of the servlets deployed in a multi-server domain configuration must be accessed using a modified URL:

http://server:port/servlet_name/...

The multi-server domain configuration deploys servlets as follows:

Multi-Server Domain Specific Default Settings

To configure the multi-server domain specific settings, launch the Administration Console. In the Domain Structure tree, expand Environment, select Servers and click on the appropriate servlet, server, or application. Then select the Configuration tab, and the General sub-tab.

The domain specific default settings for the WebLogicAdmin server are as follows:

The domain specific default settings for the PIA server are as follows:

The domain specific default settings for the PIA1 server are as follows:

The domain specific default settings for the PIA2 server are as follows:

The domain specific default settings for the PSOL server are as follows:

The default web application for the PSEMHUB server is PSEMHUB. The domain specific default settings for the PSEMHUB server are as follows:

In the console, navigate to Environments, RPS, Configuration, General to configure the RPS server. The default web application for the RPS server is HttpProxyServlet. The domain specific default settings for the RPS server are as follows:

Note. To configure SSL, you must also define SSL certificates.

See Implementing WebLogic SSL Keys and Certificates.

Example: Multi-Server Domain

The following illustrates the elements running within a typical multi-server domain:

Distributed Managed Servers

The distributed managed server configuration, although listed alongside the single-server and multi-server domain types, is not a true domain type. It's an optional extension for an existing multi-server configuration. As with the multi-server domain type, this configuration takes advantage of WebLogic’s managed server architecture. The distributed managed server configuration is intended for production environments encompassing multiple machines.

A distributed managed server configuration enables you to spread a logical WebLogic domain configuration physically across multiple machines in a heterogeneous network. One server machine might act as the domain administration server, while the other server machines act as distributed managed servers, running various manages servers, such as PIA1, PIA2, and so on. Typically, you would also take advantage of the WebLogic Node Manager, which enables a system administrator to control the managed servers remotely.

See your WebLogic Node Manager documentation.

In a distributed, multi-server configuration you can have multiple machines, multiple collections of resources and program files, multiple web server processes, and a replicated domain configuration file. In this model, if any of system resources or server instances becomes unavailable, work shifts to the next instance of that resource. In the multi-server configuration, an increase in PeopleSoft Portal usage, for example, can be accommodated by configuring an additional WebLogic server instance or machine to also serve the PeopleSoft Portal application. Using distributed manages servers provides flexibility in shaping your hardware allocation to meet your system demands.

Benefits of the Distributed Managed Server

A distributed managed server configuration provides the same benefits as a multi-server configuration with the added benefit of hardware isolation. This option requires a multi-server installation to be performed to some other location, which will contain the configuration for this distributed managed server.

The fundamental benefits of a multi-server configuration include:

• Dedicated service providers: Web servers can be dedicated to providing PeopleSoft Portal and are insolated from other portions of PIA such as PeopleSoft Integration Gateway or PeopleBooks.

• Redundant service providers: Multiple web servers can be used to serve different aspects of PIA, providing load balancing and failover support.

• Distributed resources: Multiple web server machines can be used, each capable of serving different or redundant aspects of PIA.

• Centralized and replicated configuration: Master domain configuration is centralized and distributed server information is replicated locally.

The server configuration settings for a distributed managed server are maintained by that domain’s administration server are stored locally on that administration server. Configuration settings are replicated to a managed server during its startup, but are only maintained as a read-only backup copy for that individual managed server in the event that the administration server isn't available the next time this particular managed server needs to be started.

Note. Only one managed server can be run per distributed managed server domain directory. If you intend to run multiple distributed managed servers on a single machine, perform the PIA install and create unique distributed managed server domain directories, one for each distributed managed server that you intend to run on that machine.

Example: Distributed Managed Server

The following illustrates the multiple servers, their roles, and the various elements running on the multiple server machines within a sample distributed managed server configuration:

Common Default Settings

Single-server and multi-server domain configurations have many settings in common.

Domain Defaults

Many of these common settings can be configured in the WebLogic Server Console, but some are configured in other environments. Default values are listed when available.

Script and Environment Defaults

Modify these settings by editing a setEnv script or applying command line parameter overrides to WebLogic control scripts.

The following settings specify the names and structure of various directories on the web server machine.

Note. You configure Java VM options including JVM memory size using the JAVA_OPTIONS_OSplatform parameter, during PIA setup.

The following are miscellaneous settings.

The following are debugging output settings.

The following are HTTP forward proxy support settings.

WebLogic Domain Directory Structure and Files

This section discusses:

• WebLogic domain directory structure.

• WebLogic domain file listing by type.

• J2EE application files.

WebLogic Domain Directory Structure

In a PeopleSoft implementation, the WebLogic domains are installed into your PS_HOME directory. The major components of the directory structure layout of a PIA install on WebLogic Server are:

WebLogic Domain File Listing by Type

This section lists the WebLogic domain files installed by the PeopleSoft installation, organized by file type. Where necessary, each table includes columns that indicate whether a given file is used in a single-server, multi-server, or distributed server configuration.

This listing does not include Java classes or PIA configuration files. On UNIX an equivalent Bourne shell script is provided where a Windows script is listed.

The following table lists WebLogic server administration scripts. All the life cycle scripts are stored in PIA_HOME\webserv\domain\bin.

The following table lists WebLogic server configuration files stored in PIA_HOME\webserv\domain\config.

The following table lists PeopleSoft J2EE application scripts, which are all used with Integration Broker, and can be used with every WebLogic server configuration.

The following table lists miscellaneous files, which can be used with every WebLogic server configuration.

See Also

PeopleTools 8.51 PeopleBook: Integration Broker

J2EE Application Files

In addition to WebLogic domain configuration files, application descriptors are installed with the PeopleSoft J2EE enterprise application. The following table lists these descriptor files. The path shown for each file is relative to PIA_HOME\webserv\WebLogic_domain\applications\.

PIA Install and Reinstall Options

The PeopleSoft Internet Architecture (PIA) installer enables you to create a new WebLogic server domain or update a valid existing WebLogic domain. A valid domain is a domain built by the PIA installer in the PS_HOME directory that you specify.

Depending on which option you select, you're prompted for additional information relevant to that selection. When creating a new domain, you're prompted to select from three configuration types: Single-server, multi-server and distributed managed server. If you select to update an existing domain, you're prompted to indicate which domain you would like to update and what type of update you would like to perform. These options are described in detail in your PeopleTools installation documentation.

See Also

PeopleTools 8.51 Installation for your platform:"Setting Up the PeopleSoft Pure Internet Architecture in GUI Mode"

Administering a WebLogic Server Life Cycle

This section provides an overview of the WebLogic server life cycle and discusses how to:

• Start and stop single-server processes.

• Start and stop multi-server processes.

• Start and stop a distributed managed server.

See Also

Starting WebLogic

Stopping WebLogic

Understanding the WebLogic Server Life Cycle

You control a WebLogic server’s life cycle primarily using a collection of scripts provided in that server’s WebLogic domain directory. Each instance of a WebLogic server runs in an isolated Java Runtime Environment (JRE), regardless of whether you're testing with a single-server configuration or implementing a multi-server configuration for production. All scripts must be launched from the WebLogic domain directory; and provide usage syntax if run with –help.

Starting and Stopping Single-Server Processes

In a single-server configuration, there's only one server to administer: PIA. You can control the life cycle of the PIA server using scripts or in the WebLogic console.

Scripts

For all platforms:

Note. When you shut down the server, a warning is displayed since the shutdown command uses a non-SSL http connection to connect to the WebLogic Server. This shutdown command can be changed to use the SSL connection by editing the stopPIA.sh script. To use the SSL connection the shutdown command will be the following.

For Windows only:

WebLogic Console

A WebLogic server can also be shut down from the Administration Console. Sign in to the console at http://webserver:port/console and perform either of the following.

Note. Before you perform any action in the WebLogic console, you have to click the Lock and Edit button and then the Activate Changes button after the changes are done.

In the navigation tree on the left, expand your domain, click Environment, Servers. Click PIA and select the Control tab. Select the check box for the server that you would like to shutdown, and click Shutdown. You have these options:

Starting and Stopping Multi-Server Processes

In a Multi-server configuration, as the title implies there are multiple servers to administer. Controlling the life cycle of these servers can be done via scripts, the WebLogic console and the WebLogic Node Manager.

Scripts

For all platforms:

For Windows only:

Consider the following when using scripts with managed servers:

WebLogic Server Console

A WebLogic server can also be shut down from its administration console in the same way as single server environments.

WebLogic Node Manager

The WebLogic Node Manager provides the ability to start a WebLogic managed server from the WebLogic Server Console. In addition, the console provides a way to automatically restart a failed server. As with all WebLogic servers, the WebLogic Node Manager runs isolated in its own JRE, and on Windows it can also run as a Windows service. The WebLogic Node Manager binds to a unique IP address and port at startup and accepts lifecycle commands from a WebLogic administration server.

Multiple WebLogic domains running on a singe machine can have its managed servers administered by a shared WebLogic Node Manager, as long as each WebLogic domain uses the same version of WebLogic.

The following table lists the WebLogic Node Manager files that are provided with WebLogic server, not the PIA install. These files are located in WLS_HOME\wlserver 10.3\server\bin\, not your WebLogic domain directory created within the PeopleSoft directory structure.

WLS_HOME\wlserver 10.3\common\nodemanager\NodeManagerLogs\ is the default logs directory for WebLogic Node Manager.

Additional configuration files are located in ...\common\nodemanager.

To configure Node Manager:

1. Start the Admin Server.

2. Signon to the Administration Console.

3. Select Environment, Machine.

   Create one local machine (as in MachineLocal) for all of the managed servers running in the local server and one remote machine (as in MachineRemoteX) for each of the managed servers running in remote servers.

4. Configure machines.

   Click each of the machines created. Under the Configuration tab, select the Node Manger tab.

   Choose Plain from the Type drop down list.

   For Listen Address, enter the IP address of the server on which Node Manager is running.

   Enter the Node Manger port number into the Listen Port text box. The default port number is 5556. This can be changed by updating the NodeManager.properties file.

5. Add managed servers.

   Under the Servers tab, add the managed servers into the machine. For example, you may have two managed servers running locally, with PIA1 and RPS assigned to MachineLocal.

6. Start the Node Manager.

   Start the Node Manger from your local WebLogic install directory (BEA Home for the WebLogic Sever on which your PeopleSoft domain is referring to). Node Manager can be started by startNodeManager.cmd/.sh script under BEA_Home\wlserver_10.3\server\bin directory.

   After the Node Manger has been started for the first time, a file called nodemanager.properties appears under the BEA_Home\wlserver_10.3\common\nodemanager directory.

7. Modify the nodemanager.properties file.

   Stop the Node Manger and open the nodemanager.properties file in a text editor, and make the following changes and save the file.

   SecureListener=false

   ListenAddress= the IP of the box where the Node Manager is running

   Note. In the same file you can see the default port number is set as ListenPort=5556. Changing the port setting here and restarting the Node Manager will set the Node Manager to be listening on the newly configured port number. The port setting here must match with the one set in the machine configuration.

8. Restart the Node Manager.

9. Once the Node Manger is up and running, it should be reachable from the machine configured to listen to the local Node Manager (as in, MachineLcoal). This can be confirmed by the Node Manager Status tab under the Monitoring tab.

10. In the remote box hosting the managed server, follow the previous steps to configure the Node Manager.

11. From the bin directory under your PS_Domain, run setEnv.cmd/sh to set up the environment.

12. Start WLST using the command java weblogic.WLST.

13. Connect the remote server to the Admin Server running on the local box.

    Following is the syntax of the connect command:

    connect('username','password','t3://Local Machine's IP:port on which the admin
    server is running on Local machine')
    

14. Enroll the remote domain and Node Manger into the Admin Server running on the local box.

    The command is nmEnroll with the following syntax:

    nmEnroll('full path to the distributed PeopleSoft Domain ','BEA_Home\wlserver_10.3\common\nodemanager')

    For example:

    nmEnroll('D:\PT850-809R2\webserv\Dis4103Installed603','D:\Wls103Installed603
    \wlserver_10.3\common\nodemanager') 

15. Once the domain and Node Manager have been enrolled, check the Admin Console to confirm that the Node Manger can be reached from the server that was configured to listen to the remote Node Manager.

    Once a Node Manager is reached from a "machine," the Admin Console will be able to start and stop the managed server assigned to that "machine."

    The Servers tab shows the list of servers. The Control tab grants the control of those servers to the Admin Console.

Starting and Stopping a Distributed Managed Server

In a multi-server configuration, a distributed managed server is simply a managed server that isn't started from the same physical location as its domain’s administration server. You can control the life cycle of these servers using scripts, the WebLogic Server Console and the WebLogic Node Manager.

See Starting and Stopping Multi-Server Processes.

Tuning Performance and Monitoring Resources

Monitoring the performance of a WebLogic instance is primarily performed in the Administration Console. This section discusses how to:

• Manage JVM heap size and execute thread usage.

• Monitor HTTP session count for PeopleSoft portal.

See Also

Using WebLogic Server Administration Console to Monitor PeopleSoft Sessions

Managing JVM Heap Size

This section discusses how to:

• Monitor JVM heap.

• Change JVM heap size.

Monitoring JVM Heap

The JVM heap size is the amount of memory that a particular JRE (Java Runtime Environment) gives to the JVM (Java Virtual Machine) that it creates. The java.exe command on Windows, java on UNIX and beasvc.exe when running WebLogic as a Windows service is the JRE, and the JVM exists within the JRE’s memory space. The primary sources for monitoring the amount of memory that is in use within a JVM are the Administration Console and the WebLogic logs.

To monitor the amount of the JVM heap size available and in use:

1. Sign on to the Administration Console by entering the following URL in a browser:

   http://webserver:9999/console

   Where webserver is the hostname of the WebLogic server.

2. Traverse the following in the navigation tree on the left:

   1. Expand your WebLogic domain (for example, peoplesoft).

   2. Expand Servers.

3. Click the server you intend to monitor (for example, PIA).

4. Select the Monitoring tab, and the Performance sub-tab.

Changing the JVM Heap Size

If you need to adjust any of the Java options, most commonly the JVM heap size, you must manually edit that WebLogic domain’s local setEnv script. The parameters, -Xms and -Xmx, control the JVM memory minimum and maximum heap size respectively.

Following are examples of the JVM heap size as specified in setEnv using the JAVA_OPTIONS_OSplatform environment variable. You only need to set the variables that correspond to the operating system where the WebLogic server is running.

See Adjusting the JVM Heap Size.

Note. If you do adjust any of the Java options, most commonly the JVM heap size, you must restart WebLogic for these changes to take effect.

If you're running WebLogic Server as a Windows service you must rerun the installNTservice script to propagate this change into the Windows registry.

The WebLogic Node Manager does not use the Java options set in setEnv, but instead uses Java options set from the WebLogic console.

To modify the Java options for a WebLogic instance started via the WebLogic Node Manager:

1. Sign on to the WebLogic Server Console by entering the following URL in a browser:

   http://webserver:9999/console

   Where webserver is the hostname of the WebLogic server.

2. Expand your WebLogic domain (for example, peoplesoft) and click Environment, then Servers.

3. Select the managed server you intend to modify.

4. Select the Configuration tab, and the Server Start sub-tab.

5. Update the Arguments field.

6. Click Save.

See Also

Adjusting the JVM Heap Size

Monitoring HTTP Session Count for PeopleSoft Portal

In addition to memory and thread usage, it's also possible to monitor the number of established HTTP sessions used in conjunction with the PeopleSoft PORTAL application. This number, although not necessarily directly related to current performance, is an indicator of the following performance factors:

• JVM memory used to store HTTP session data.

• Current number of logged on clients.

• Peak number of logged on clients.

• Idle time of logged on clients.

To monitor the total number of HTTP sessions:

1. Sign on to the Administration Console.

2. In the Domain Structure section, click Deployments and select the check box next to peoplesoft.

3. Select the Monitoring tab.

Changing Configuration Settings

This section provides an overview of the WebLogic server configuration files, and discusses how to:

• Change the WebLogicAdmin server’s listen ports.

• Change application and server deployment targets.

Understanding the WebLogic Server Configuration Files

WebLogic server configuration settings are stored in a collection of files, primarily these include: script, config.xml, and the web.xml and weblogic.xml for each webapp.

Changing the WebLogicAdmin Server’s Listen Ports

In the multi-server configuration, several parameters are set based on the environment detected and delivered defaults. One such parameter is the HTTP port of the WebLogicAdmin server. By default the WebLogicAdmin server’s HTTP listen port is 9999.

To change this value:

1. Start the WebLogicAdmin server using the startWebLogicAdmin script.

2. Sign on to the WebLogic Server Console by entering the following URL in a browser:

   http://webserver:9999/console

   Where webserver is the hostname of the WebLogic server.

3. Navigate to Servers, WebLogicAdmin, Configuration, General.

4. Modify the value of the Listen Port field.

5. Click Apply.

6. Restart the WebLogic server.

If you can't initially start the server due to a port conflict, you can manually edit the value of the ListenPort parameter in that domain’s config.xml file. Creating a backup of config.xml is recommended before manually changing this file.

After changing the ListenPort value in your domain’s config.xml, either directly or using the console, you must also update your setEnv script. Update the ADMINSERVER_PORT environment variable to reflect the new HTTP port. This setting is used by the stopWebLogic and startManagedWebLogic scripts as the default administration server HTTP port.

Changing Application and Server Deployment Targets

With WebLogic, J2EE applications are targeted to any combination of WebLogic servers and WebLogic clusters. A WebLogic cluster is a logical grouping of servers, generally all providing the same application, though that's not a requirement. To change the servers or clusters that to which an application is targeted and deployed, sign on to the Administration Console and update the application's target assignments. You can view and modify application and server target assignments on the Deployments, Applications tabs, and on the Targets tab for each server.

Following is an example of how to change the target assignments of the PeopleSoft Integration Gateway (PSIGW) web application so it’s the only application targeted to the PIA server, and is the sole application on that instance.

To change the target assignments of the PeopleSoft Integration Gateway web application:

1. Sign on to the WebLogic Server Console.

2. In the Domain Structure section:

   1. Expand peoplesoft.

   2. Expand Deployments.

   3. Expand Applications.

   4. Expand peoplesoft.

3. Select PSIGW.

4. Select the Targets tab.

5. In the Clusters section, clear the peoplesoftCluster check box.

6. Click Apply.

7. In the navigation tree, select PORTAL.

8. Select the Targets tab.

9. In the Independent Servers grid, clear the check box for targeting the PORTAL to this server.

10. Click Apply.

11. Repeat steps 7 to 10 for the PSEMHUB, PSINTERLINKS and PSOL.

To deploy an application to a cluster, target the server to the cluster and target the application to the cluster.