Appendix: BEA WebLogic Managed Server Architecture

In the current release, the PIA configuration of BEA WebLogic Server has been expanded to take advantage of WebLogic’s managed server architecture. This appendix provides overviews of web applications in PIA, WebLogic domain types, WebLogic domain directory structure and files, and PIA install and reinstall options, 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 BEA WebLogic

Web Applications in PIA

PIA is packaged as a J2EE Enterprise Archive and is comprised of five J2EE web applications, commonly referred to as webapps. The five webapps are as follows.

In addition to the PeopleSoft webapps, three more webapps are added when you install PIA on a WebLogic server machine. These three webapps are not added as part of the PeopleSoft Enterprise Archive, but instead are defined as individual webapps provided by BEA. These three webapps are as follows.

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. In addition, a multi-server domain can be expanded across multiple machines using the distributed managed server option. Each of these domain configurations has a specific purpose but is fully customizable beyond that purpose.

Single-Server Domain

The single-server domain configuration consists of a single WebLogic server instance, with the WebLogic administration application and all of the web components of PeopleSoft Internet Architecture deployed to use it. This configuration is very similar in design to the WebLogic domain provided in previous PeopleTools releases.

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 BEA WebLogic Server.

In this configuration, the resources used to administer WebLogic Server and your PeopleSoft application are not isolated from one another, therefore leaving the applications vulnerable to possible resource starvation. The low resource requirements of this configuration make it ideal for small scale and non-production usage.

This configuration creates the following server:

Single-Server Webapp Deployment

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

http://server:port/webapp_name/...

The single-server domain configuration deploys webapps as follows:

Single-Server Domain Specific Settings

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

In the console, navigate to Servers, PIA, Configuration, General to configure the PIA server. 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.

Multi-Server Domain

The multi-server domain configuration consists of seven server definitions, a WebLogic cluster, and the web components of PIA split across multiple servers. This configuration takes advantage of WebLogic’s administration server and managed server architecture.

This configuration is intended for production environments.

A production application warrants process and resource pool isolation for greater stability and optionally tighter security controls, which this configuration provides. In this 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 web applications of PIA might be, and usually are, isolated from each other. The PIA applications 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.

This configuration creates the following servers:

The multi-server domain configuration deploys webapps as follows:

Multi-Server Webapp Deployment

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

http://server:port/webapp_name/...

The multi-server domain configuration deploys webapps as follows:

Multi-Server Domain Specific Default Settings

To configure the multi-server domain specific settings, launch the WebLogic Server Console.

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

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

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

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

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

In the console, navigate to Environments, PSEMHUB, Configuration, General to configure the PSEMHUB server. 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.

Distributed Managed Server

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 that's used to extend a WebLogic domain configuration across multiple machines in a heterogeneous network. For example, on one machine you perform a PIA install and create a multi-server domain. On a second machine you again perform a PIA install but select to create a distributed managed server. You stop, start, and administer the distributed managed server on the second machine just as if it was a managed server local to the primary server’s machine.

As with the multi-server domain type, this configuration takes advantage of WebLogic’s managed server architecture.

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.

This configuration is intended for production environments that encompass multiple machines.

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.

Distributed Managed Server Specific Defaults

The server configuration settings for a distributed managed server are maintained via that domain’s administration server and 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.

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.

Single-Server and Multi-Server/Distributed Server Analogy

In a production environment it is highly recommended to use a multi-server or distributed server configuration. The multi-server selection provides an initial WebLogic domain configuration that consists of multiple server definitions: one administration server and multiple managed servers, each with a specific purpose. The distributed server option augments a multi-server configuration by expanding the domain configuration across multiple machines.

An analogy that can describe the differences between the single-server configuration and a multi-server or distributed server configuration uses the example of two common beverage distribution models: a single lemonade stand, and a large chain of coffee shops.

Single-Server Model — The Lemonade Stand

With a lemonade stand you have yourself, one table, one collection of resources and ingredients, and a single recipe. If any of these are ruined, your lemonade stand is out of business. Similarly, in a single-server configuration you have one server process, one machine, one collection of resources and program files, and a single domain configuration file. If any of those is ruined, your web server is out of business. Throughput can also be an issue for both a lemonade stand and a single-server configuration. For example, if the weather is warm and you receive a rush of thirsty customers, your throughput will reach a maximum at either the rate you accept new orders, ring up cashier transactions, or prepare drinks. If you accept orders and ring up transactions in half the time that you prepare drinks, adding a second bartender would double your throughput, but in this configuration you can't do that because it's only you. Likewise, the single-server configuration is constrained to provide server configuration and all web server based portions of PIA on a single process. The multi-server model enables you to overcome these limitations.

Multi-Server Model — The Coffee Shop Chain

Within the same analogy, a large chain of coffee shops has multiple employees, multiple cashier stations, multiple coffee prep stations, and recipes archived and known to multiple employees. Similarly, in a 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 those resources is ruined, work simply shifts to the next instance of that resource. In addition, throughput can be maintained. For example, if the coffee house received a rush of parched customers, additional cashiers and beverage engineers could be added to maintain throughput. Likewise, in the multi-server configuration, an increase in PeopleSoft Portal usage can easily be accommodated by configuring an additional WebLogic server instance to also serve the PeopleSoft Portal application. In this way, the multi-server model supports extendibility and resource independence.

The fundamental benefits of a multi-server configuration are:

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

Domain Topology

A WebLogic domain can be as small and simple as the Single-server configuration or as broad and complex as the Multi-server configuration with distributed managed servers. In no way exhausting the possibilities, following are three sample layouts depicting each domain configuration.

Single server — one machine

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.

Multi-server — one machine

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.

Multi-server with distributed managed servers — multiple machines

In a Multi-server configuration with distributed managed servers, multiple instances of WebLogic server are used, each providing 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. The only differentiating factor from the initial Multi serve configuration is that in this configuration two or more actual machines are used.

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

File and directory layout of PIA on WebLogic does differ from that on prior versions of WebLogic. At a high level, the first difference is that the WebLogic domains are installed within your PS_HOME directory structure, rather than into WebLogic’s directory structure as with prior versions of WebLogic Server.

The default home directories for PIA on different versions of WebLogic are as follows:

This change was performed because managing the WebLogic configuration and PIA configuration similarly to the PeopleSoft application server and PeopleSoft Process Scheduler provided a clearer and more extendable architecture.

File and directory layout of PIA on WebLogic differs from that of prior versions of PIA. The following illustration clarifies the directory structure layout of a PIA install on WebLogic Server.

WebLogic — PeopleSoft directory structure

WebLogic Domain File Listing by Type

Following are listings of all WebLogic domain files installed by the PIA setup, 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 \bin folder under <ps_home>/webserv/<domain>.

The following table lists WebLogic server configuration files. All the life cycle scripts are stored in \config folder under <ps_home>/webserv/<domain>.

The following table lists PeopleSoft J2EE application scripts, which are all used with PeopleSoft 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

Enterprise PeopleTools 8.49 PeopleBook: PeopleSoft 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 PS_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, which are as follows:

• Install additional PeopleSoft site.

  This option is relevant only to the PeopleSoft PORTAL web application, and doesn't modify or revert any other configuration settings. Select this option to install only the necessary files for defining an additional PeopleSoft site onto an existing WebLogic configuration. The new site will be accessed using its name in the URL. A site named “CRM” would be accessed using a URL similar to http://mywebserver_machine/CRM. To reset or recreate an existing PeopleSoft site, simply enter that site’s name as the site to create. On your web server, a PeopleSoft site is comprised of the following directories within the PORTAL web application:

  weblogic_domain\applications\peoplesoft\PORTAL\site\*

  weblogic_domain\applications\peoplesoft\PORTAL\WEB-INF\psftdocs\site\*

  See Enterprise PeopleTools 8.49 PeopleBook: Internet Technology.

• Redeploy PeopleSoft Internet Architecture.

  This selection affects all of the PIA web applications installed to the local WebLogic domain. Select this option to redeploy all of the class files and jar files that comprise web components of PIA. WebLogic Server configuration files, scripts and any existing PeopleSoft (PORTAL) sites are not overwritten, unless you specify an existing PeopleSoft site during this setup.

• Re-create WebLogic domain and redeploy PeopleSoft Internet Architecture.

  This option affects WebLogic Server configuration and all of the PIA web applications installed to the local WebLogic domain. Select this option to completely remove an existing WebLogic domain and create the newly specified PeopleSoft site.

  Warning! The entire WebLogic and PIA configuration in the specified WebLogic domain is deleted when you select this option.

• Deploy additional PeopleSoft application extensions.

  This option is solely for use with PeopleSoft applications. PeopleSoft application extensions are provided with certain PeopleSoft applications, and this option enables you to deploy those extensions. Consult the installation documentation for your PeopleSoft application to see if this option is appropriate. PeopleTools does not use application extensions.

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 BEA WebLogic

Stopping BEA 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 its administration console. To shut down a WebLogic server in the WebLogic Server 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.

See http://edocs.bea.com/wls/docs92/intro/console.html#wp1122447

In the navigation tree on the left, expand your domain, click Envrironment, 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:

Following are some important managed server considerations for scripts:

• For all platforms:

  When starting a WebLogic managed server it will attempt to connect to its administration server. A managed server’s administration server is specified either as a command line parameter when starting the managed server, or using the three administration server environment variables in setEnv, specifically ADMINSERVER_PROTOCOL, ADMINSERVER_PORT, and ADMINSERVER_HOSTNAME. The first time a managed server starts, it must connect to its administration server. If on subsequent startups the administration server is not available, the managed server starts up in Managed Server Independence (MSI) mode by using its locally replicated msi-config.xml. A managed server running in MSI mode can't be administered from a console, so this situation should only be encountered when it is imperative that the managed server be started even though the administration server is not running. Once the administration server is back online, running managed servers that were not previously known by the administration server to be running may be rediscovered using WebLogic’s command line utility java weblogic.Admin DISCOVERMANAGEDSERVER, or you can just restart the managed server.

  To use WebLogic’s java command line utility classes run setEnv to set up your environment, then run java weblogic.Admin for usage.

• For Windows only:

  When running a WebLogic managed server as a Windows service, the managed server’s administration server must be running. When installing a managed server as a Windows service, the managed server service can be configured to be dependent on its local administration server. To configure a managed server service to be dependent on its local admin server service use the –depends option of installNTservice.cmd when defining the Windows service for the managed server. In addition, when the administration server is also a Windows service, you must define it using the following command:

  installNTservice.cmd –delay interval

  Where intervalis a period in milliseconds, for example 6000. This allows the administration server sufficient time to start before the managed server starts.

WebLogic Server Console

A WebLogic server can also be shut down from its administration console. The procedure for mutli-server environments is the same for 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.

See http://e-docs.bea.com/wls/docs92/server_start/nodemgr.html

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 BEA_HOME\weblogic92\server\bin\, not your PeopleSoft created WebLogic domain directory.

Note. BEA_HOME\weblogic92\common\nodemanager\NodeManagerLogs\ is the default logs directory for WebLogic Node Manager.

Note. All other configuration files are located in WL_HOME\common\nodemanager.

See http://e-docs.bea.com/wls/docs92/server_start/nodemgr.html#wp1100601

To start a local WebLogic Managed server from the WebLogic Node Manager:

1. Start the WebLogic domain’s WebLogic administration server.

2. Start the Node Manager of that domain’s local BEA_HOME.

   If you're attempting to start a distributed managed server, you must start the Node manager on that distributed machine, otherwise the administration server, Node Manager and managed server are all on one machine.

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

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

   1. Click Environment.

   2. Click Servers in the right hand window.

5. Select the check box for the managed server that you would like to shutdown, and click on shutdown button.

A WebLogic Managed server started from the WebLogic Node Manager doesn't use Java options defined in setEnv, such as Java heap size. If you opt to use the WebLogic Node Manager, you should confirm or adjust the Java options in the WebLogic console of the administration server.

To adjust the Java options:

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

2. Click Environment, Servers.

3. Select the managed server that you would like to modify.

4. Select the first level Star Server tab

5. Update the Arguments field.

6. Click Save.

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 at the WebLogic 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 Console to Monitor PeopleSoft Sessions

Managing JVM Heap Size

One main resource to monitor and tune with regards to WebLogic Server is the JVM memory 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 two primary sources for monitoring the amount of memory that is in use within a JVM are the WebLogic console and the WebLogic logs.

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

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. 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 first level Monitoring tab.

5. Select the second level Performance tab.

For more information on these statistics on this page, click on “More info” link provided on this page. Also this page provides two buttons: Garbage Collect and Dump thread Stacks. The Garbage Collect button calls the JVM’s System.gc() method to perform garbage collection. The JVM implementation then decides whether or not the request actually triggers garbage collection. Dump thread Stacks prints the thread stack for all the active threads for the WLS process.

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 two 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 OS where the WebLogic server is running.

• JAVA_OPTIONS_WIN32="-server -Xms256m -Xmx256m -XX:MaxPermSize=128m”

• JAVA_OPTIONS_AIX="-Xms128m -Xmx256m"

• JAVA_OPTIONS_HPUX="-server -Xms256m -Xmx256m -XX:MaxPermSize=128m"

• JAVA_OPTIONS_LINUX="-jrockit -Xms256m -Xmx256m"

• JAVA_OPTIONS_SOLARIS="-server -Xms256m -Xmx256m -XX:MaxPermSize=128m

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 first level Configuration tab.

5. Select the second level Server Start tab.

6. Update the Arguments field.

7. 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 WebLogic Server Console.

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

   1. Click Deployments.

   2. Click PeopleSoft.

3. Select the Monitoring tab.

See Also

Configuring Web Profiles

Using WebLogic Console to Monitor PeopleSoft Sessions

WebLogic console can display a list of established HTTP sessions for that instance ofWebLogic Server. Session Monitoring is automatically enabled in WebLogic Server 9.2.

Note. The following describes how to monitor the single server configuration of PIA. When in production, a multi server configuration would be used to perform these steps to the server instance that you intend to monitor, such as PIA1 or PIA2, or both.

To monitor PeopleSoft sessions:

1. Start the PIA server.

   Start the PIA server either via startPIA.cmd(.sh) or if installed as a Windows service, " NET START peoplesoft-PIA".

2. Log on to PeopleSoft.

   Log on to your PeopleSoft application. If possible, log on from a couple different workstations using different PeopleSoft IDs. For the purpose of this test, do not log off.

3. Log on to the WebLogic Server Administrative Console.

   In a new browser, access the WebLogic Server console at http://WebLogicHost:port/console, and specify the WebLogic administrative ID you specified during the PIA installation. The default ID and password are system/password, respectively.

4. Monitor established HTTP sessions for the PORTAL web application.

5. In the left side menu, use the following navigation to view the list of established HTTP sessions for the PORTAL web application:

   1. Click Deployments. You will see the list of deployments, in the right hand window.

   2. Click on PeopleSoft applications.

   3. Click on the Ccontrol tab.

   4. Select PORTAL application module where the context root of the module is ‘/’.

   5. Click the Monitoring tab.

   6. Click the Sessions tab.

Also you can customize the list of fields that you want to monitor by using the Customize this table option.

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 the setEnv script, config.xml, and the web.xml and weblogic.xml for each webapp.

• SetEnv contains statically and dynamically defined environment variables. It's called from all of the WebLogic administration scripts to assist in building the Java command line. You modify this file using a text editor.

• Config.xml contains server runtime settings, such as the HTTP port. You modify this file using the WebLogic Server Console.

• Web.xml and weblogic.xml, which are located in the WEB-INF directory of each webapp, are web application descriptors and contain settings relevant to their application.

Changing the WebLogicAdmin Server’s Listen Ports

In the multi-server configuration, several parameters are set based on the environment detected and on 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 via 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.

Note. 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 an application is targeted and deployed to, sign on to the WebLogic Server 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. Traverse the following in the navigation tree on the left:

   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 webapp to this server.

10. Click Apply.

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

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