This chapter provides an overview of BEA WebLogic and discusses how to:
Access the BEA WebLogic server console.
Start BEA WebLogic.
Stop BEA WebLogic.
Use WebLogic server console to monitor PeopleSoft sessions.
Set up a reverse proxy server (RPS).
Set up HTTP session timeout.
Enable or disable HTTP keep alive.
Change a WebLogic user's password.
Implement WebLogic SSL keys and certificates.
Adjust the Java Virtual Machine (JVM) heap size.
Determine the service pack level.
Enable or disable the HTTP access log.
This section discusses the PeopleSoft domain and the WebLogic session cookie name format
PeopleSoft Internet Architecture installation on BEA WebLogic Server provides three primary server configuration options. Those options and their intended purpose are:
Single server.
This domain configuration contains one server named PIA, and the entire PeopleSoft enterprise application is deployed to it. This configuration is intended for single user or very small scale, non-production environments.
Multi server.
This domain configuration contains seven unique server definitions and a WebLogic cluster, and the PeopleSoft enterprise application is split across multiple servers. This configuration is intended for the production environment.
Distributed managed server.
This option is an extension of the “Multi server” selection and installs the necessary files to boot a managed server. This option requires a “Multi server” installation to be performed to some other location that contains the configuration for this managed server.
See Also
BEA WebLogic Managed Server Architecture
When a user signs in to a PeopleSoft Pure Internet Architecture application, the portal servlet generates a cookie containing the user’s HTTP session ID, and sends it to the user’s browser to maintain the state of the session. The name of the cookie is fixed for all users accessing that portal.
On a WebLogic portal, the session cookie’s name is generated at install time based on the portal hostname and port number, which uniquely identify the portal within your PeopleSoft system. This name is stored in the portal’s weblogic.xml file.
However, the cookie name must not start with a number, and it must not contain any periods. If your users are experiencing problems signing in to PeopleSoft applications at different URLs from the same browser session, make sure that the session cookie names at those sites are valid.
To ensure valid WebLogic session cookie names:
Shut down your WebLogic server.
Open the weblogic.xml file for your web server in a text editor.
You can find it in PS_HOME\webserv\domain_name\applications\peoplesoft\PORTAL\WEB-INF.
Check the value of the session parameter called CookieName.
Ensure that the content of the param-value element doesn’t start with a number or contain any periods. For example, the following session cookie name is invalid:
<session-param> <param-name>CookieName</param-name> <param-value>57.28.208.21-80-WebLogicSession</param-value> </session-param>
You can replace the periods with dashes (-). Following is a valid version of the session cookie name:
<session-param> <param-name>CookieName</param-name> <param-value>c57-28-208-21-80-WebLogicSession</param-value> </session-param>
Save and close the file.
Restart your WebLogic server.
The BEA WebLogic Server console is the main utility that is used to administer and monitor the BEA WebLogic Server processes. The BEA WebLogic server console provides an interface to monitor and tune aspects of a PeopleSoft application from a web server perspective.
Access the console by pointing your browser to http://weblogic_servername:weblogic port:/console. Before the console opens, you will be prompted for the WebLogic system ID and password that you specified during the PIA install. The default ID is system and the default password is password..
This section discusses how to:
Start BEA WebLogic on Microsoft Windows.
Start BEA WebLogic on UNIX.
See Also
Administering a WebLogic Server Life Cycle
To run BEA WebLogic Server on Microsoft Windows, you can use a Windows service or a foreground process.
Using the Command Prompt
Running BEA WebLogic as a foreground process is beneficial if you need to monitor WebLogic in real time. To run WebLogic as a foreground process, enter the following at the command prompt in the WebLogic <domain>\bin directory that the PeopleSoft install created for you (as in PS_HOME\webserv\<domain>\bin).
Single server:
startPIA.cmd
Multi server:
To start the WebLogic domain admin server run startWebLogicAdmin.cmd
To start a managed server, such as PIA, run startManagedWebLogic.cmd PIA
Using the Windows Service
Two benefits of running BEA WebLogic as a Windows service are:
BEA WebLogic can automatically start when the Windows server boots.
You can start and stop the service from a remote Windows machine.
To install the service, open the command prompt, and enter the appropriate command from your WebLogic <domain>\bin directory:
Single server:
installNTservicePIA.cmd
Multi server:
InstallNTservice.cmd weblogic_server_instance_name
For example:
installNTservice.cmd PIA
To start BEA WebLogic as a Windows service, use either of these methods:
Start the service named WebLogicdomain-servername (for example, peoplesoft-PIA) by using the Services utility in the Windows Control Panel.
Start the service from a command prompt by entering the following command:
NET START peoplesoft-PIA
Note. If WebLogic fails to start as a service, try starting it as a foreground process.
To uninstall the service, enter the following command:
UninstallNTservicePIA.cmd
To start PeopleSoft on UNIX execute the appropriate script in the WebLogic domain directory that the PIA install created, as in PS_HOME/webserv/peoplesoft/bin).
Single server:
startPIA.sh
Multi server:
To start the WebLogic domain admin server run startWebLogicAdmin.sh
To start a managed server such as PIA, run startManagedWebLogic.sh PIA
When you run the above scripts, the server runs as background process.
For both Windows and UNIX, you can stop the PeopleSoft server from the BEA WebLogic Server console (http://weblogichost:port/console).
To stop the PeopleSoft server:
In the left pane of the console, expand Environment, and select Servers.
Click the Lock & Edit button before you perform any action in the console.
In the Servers table, click the name of the server that you want to shut down.
Select Control, Start/Stop.
In the Server Status table, select the server that you want to shut down.
From the Shutdown menu, select one of the following options:
When work completes: This command initiates a graceful shutdown, which gives WebLogic Server subsystems time to complete application processing currently in progress.
Force shutdown now: This command initiates a forced shutdown, in which the server instructs subsystems to immediately drop current requests.
Click Yes to confirm and shut down the server.
If you shut down the Administration Server, the Administration Console is no longer active.
You can also stop the server through the command line by running:
Configuration |
Windows |
UNIX |
Single server |
stopPIA.cmd |
stopPIA.sh |
Multi server (WebLogic Admin server) |
stopWebLogic.cmd |
stopWebLogic.sh |
Multi server (Managed WebLogic server) |
stopWebLogic.cmd <ManagedServerName> |
StopWebLogic.sh <ManagedServer Name> |
If WebLogic is running as a Windows service you can also stop the service in Windows Control Panel.
See Also
Administering a WebLogic Server Life Cycle
TheWebLogic Server console can display a list of established HTTP sessions for that instance of the WebLogic Server. Session Monitoring is automatically enabled for WebLogic. These instructions describe how monitor the single server configuration of PIA. When in production, note that 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.
Start the PIA server.
Start the PIA server either using startPIA.cmd(.sh) or, if installed as a Windows service, NET START peoplesoft-PIA.
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.
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.
Monitor established HTTP sessions for the PORTAL web application.
On the left, use the following navigation to view the list of established HTTP sessions for the PORTAL web application:
Click Deployments, and view the deployment list in the right hand window.
Click PeopleSoft.
Select the Control tab.
Select the PORTAL application module, where the context root of the module is '/'.
Select the Monitoring tab.
Select the Sessions tab.
Note. You can customize the list of fields that you want to monitor using the Customize this table link.
Note. An established HTTP session remains on the web server until the client logs out of PeopleSoft or until the user's HTTP session times out. Simply closing the browser does not log out a PeopleSoft user. As a result, when a user closes the browser without logging out of the PeopleSoft session, the corresponding HTTP session remains on the web server until it times out. HTTP session timeouts are controlled by the site's PeopleSoft web profile.
See Also
Tuning Performance and Monitoring Resources
PeopleSoft applications support the use of reverse proxy servers (RPS) with BEA WebLogic. An RPS supplies the URL to which the browsers connect, but another web server handles the actual transaction processing.
This section discusses how to:
Configure Microsoft Internet Information Server (IIS) as an RPS.
Configure BEA WebLogic as an RPS.
Configure Sun iPlanet as an RPS.
Use the iPlanet plug-in.
Configure Apache HTTP as an RPS.
This section describes how to proxy content to a single server configuration of PIA. When in production, a multi server configuration would be used to perform these steps to proxy content to your managed server instance of PIA, PIA1, PIA2, and so on..
Microsoft Internet Information Server (IIS) can be configured as a reverse proxy server (RPS) to one or more WebLogic Server instances. Multiple instances can be independent instances or grouped into a cluster. When you use a reverse proxy, any URL that would be used to access your PeopleSoft application (even URLs that are stored in the database) would point to the reverse proxy, and not to the WebLogic Server.
These instructions are based on a logical separation of BEA WebLogic Server and Microsoft IIS, where both web servers are installed on the same machine. If your configuration has BEA WebLogic Server and Microsoft IIS on separate machines, you must perform three additional steps. Those steps are:
From the BEA WebLogic server, WL_HOME\server\plugin\win\32\iisproxy.dll or WL_HOME\server\plugin\win\64\iisproxy.dll (based on your to c:\inetpub on your Microsoft IIS server.
From the BEA WebLogic server, copy WL_HOME\server\plugin\win\32\iisforward.dll or WL_HOME\server\plugin\win\64\iisforward.dll (based on the platform’s architecture) to c:\inetpub on your Microsoft IIS server.
In the following procedure, change any reference from WL_HOME\server\plugin\win\32\ or WL_HOME\server\plugin\win\64\ (based on the platform’s architecture) to c:\inetpub.
To set up a Microsoft IIS RPS:
Install the PeopleSoft Internet Architecture.
Run the multiplatform PeopleSoft Internet Architecture install from %PS_HOME%\setup\PsMpPIAInstall\setup.exe.
Access the Microsoft IIS configuration.
On a Microsoft Windows server, select Start, Programs, Administrative Tools, Internet Services Manager.
Note. Windows workstation and Windows 2000 Professional are not supported.
Open the Default Web Site properties
Expand your list of available servers, right click the Default Web Site and select Properties.
Add an ISAPI filter.
Select the ISAPI Filters tab, and click Add to define a new filter.
Enter IISFORWARD for the filter name.
Enter WL_HOME\server\plugin\win\32\iisforward.dll or WL_HOME\server\plugin\win\64\iisproxy.dll for the executable.
Define a new application extension mapping.
Select the Home Directory tab then click Configuration.
Click Add on the App Mapping tab to define a new application mapping.
Enter WL_HOME\server\plugin\win\32\iisproxy.dll or WL_HOME\server\plugin\win\64\iisproxy.dll for the executable.
Enter .wlforward for the extension.
For Verbs, enter All Verbs (or at a minimum, GET and POST).
Create the IIS-Plugin configuration file.
Create WL_HOME\server\plugin\win\32\ or WL_HOME\server\plugin\win\64\iisproxy.ini, containing the following lines and setting the values appropriately.
# #For a list of available parameters see #http://edocs.bea.com/wls/docs81/plugins/index.html # WebLogicHost=<hostname or IP of weblogic server to forward requests to> WebLogicPort=<HTTP port of weblogic server to forward requests to> DebugConfigInfo=OFF Debug=OFF # #To proxy all IIS directed requests to WebLogic set "WlForwardPath=/" #To selectively proxy only PeopleSoft requests to WebLogic set "WlForwardPath="to #the list of PeopleSoft sites to proxy. #e.g. To proxy requests for only 'ps' and 'crm' set WlForwardPath to the following; #WlForwardPath=*/ps/*,*/crm/* WlForwardPath=/ # #If you have specified an AuthTokenDomain during your PIA installation, #you must set the cookieName for your reverse proxy. #CookieName=<CookieName as specified on weblogic in PORTAL webapps's weblogic.xml>
Restart Microsoft IIS.
Restart the two Windows services, IIS Admin Service and World Wide Web Publishing Service by using the Services utility in the Control Panel or by issuing the following three commands at a command prompt:
NET STOP IISADMIN /Y NET START IISADMIN NET START W3SVC
Start the BEA WebLogic server.
Start the PeopleSoft Internet Architecture server either by invoking startPIA.cmd (.sh) or if installed as a Windows service, “NET START peoplesoft–PIA”.
Test your configuration by accessing the Microsoft IIS server by using the URL for your site.
For example, http://IIS_server:port/ps/signon.html.
Note. To connect to Microsoft IIS by using HTTPS, you must install digital certificates on the Microsoft IIS server.
See Also
“BEA documentation for IIS-plugin, ” http://e-docs.bea.com/wls/docs92/plugins/isapi.html
“BEA documentation for IISPROXY.INI parameters, ” http://e-docs.bea.com/wls/docs92/plugins/plugin_params.html#wp1143055
This section discusses how to configure a BEA WebLogic server as a reverse proxy server (RPS).
Creating the RPS
To create an RPS, select Multi Server Domain as the configuration to install during PIA setup. As a result, a server named “RPS” is automatically defined in addition to the main PIA server, and is configured to be a reverse proxy server to other managed servers. By default, the following settings are applied to the RPS:
Setting |
Value |
Name |
RPS |
HTTP Listen Port |
8080 |
HTTPS Listen Port |
8443 |
Default web application |
HttpProxyServlet |
Address of back-end WebLogic content server |
The hostname of the machine from which the PIA setup was run, with the HTTP listen port specified during the PIA setup. |
The default address specified for the back-end WebLogic content server assumes that it's the same machine as the one on which you're configuring the RPS, using the HttpProxyServlet application. There's no need to change this setting unless the content server is a different machine, or you enable load balancing with multiple content servers. If it's a different machine, you must change this setting to specify the correct content server. If you enable load balancing, you'll need to specify additional content servers.
In addition to the HttpProxyServlet application, the PIA setup also defines an HttpClusterServlet application in your WebLogic configuration, which by default isn't active. The primary difference between the two applications is that for a given HTTP request, HttpProxyServlet can proxy content only from a single back-end content server, whereas HttpClusterServlet can proxy content from multiple back-end content servers, all of which serve the same content. This enables the RPS to load-balance the requests across a cluster of WebLogic servers.
You can configure the RPS for load balancing by changing the default web application from HttpProxyServlet to HttpClusterServlet, which becomes active as a result.
To change the default web application:
Start the WebLogic server.
Sign in to the WebLogic administration console.
Navigate to Deployments, Web Application Modules, HttpProxyServlet.
Select the Targets tab.
Click the Lock & Edit button before you make any changes, clear the RPS Server check box, then click Apply, and then after making changes click Activate Changes.
Navigate to Deployments, Web Application Modules, HttpClusterServlet.
Select the Targets tab.
Select the RPS Server check box, then click Apply.
Sign out of the WebLogic administration console.
Specifying Back-End WebLogic Content Servers
You need to specify back-end WebLogic content servers only for the currently designated default web application (HttpProxyServlet or HttpClusterServlet).
To do this, you edit the appropriate web.xml configuration file directly.
To edit the configuration file directly:
For the HttpProxyServlet application —
You need to change this setting only if the back-end WebLogic content server is on a different machine than the one where you're configuring the RPS. Edit the web.xml configuration file in PS_HOME\webserv\weblogic_domain\applications\HttpProxyServlet\WEB-INF.
Modify the param-value elements for the WebLogicHost parameter and the WebLogicPort parameter to specify the hostname and HTTP listen port, respectively, of the back-end content server.
For the HttpClusterServlet application —
Edit the web.xml configuration file in PS_HOME\webserv\weblogic_domain\applications\HttpClusterServlet\WEB-INF.
Modify the param-value element for the WebLogicCluster parameter to specify multiple back-end content servers separated by “|” symbols, using the following format:
host1:http_port:https_port|host2:http_port:https_port
Starting the RPS
To start the RPS, open a command prompt, change to PS_HOME\webserv\weblogic_domain, and launch the following commands:
startWebLogicAdmin
startManagedWebLogic RPS
Note. You can also run the RPS as a service on Windows.
See Also
“BEA documentation for WebLogic Proxy, ” http://e-docs.bea.com/wls/docs92/plugins/http_proxy.html#wp115201
“BEA documentation for proxy parameters, ” http://e-docs.bea.com/wls/docs92/plugins/plugin_params.html
This section describes how to proxy content to a single server configuration of PIA. When in production, a multi server configuration would be used to perform these steps to proxy content to your managed server instance of PIA or PIA1.
Note. The Netscape Enterprise Server is also referred to as iPlanet. For simplicity, in these instructions, it will be referred to as iPlanet.
The iPlanet web server can be installed and configured as a reverse proxy to WebLogic Server. BEA has certified different version of iPlanet web server version on different operating systems. Oracle | PeopleSoft extends that certification list to its customers.
See http://e-docs.bea.com/platform/suppconfigs/configs92/92_over/add-ons.html#1084356
See http://e-docs.bea.com/wls/docs92/plugins/nsapi.html
To configure iPlanet as an RPS:
Download iPlanet Web Server, Enterprise Edition.
Download and install a BEA certified platform/version of iPlanet Web Server from Sun.
See http://www.sun.com/software/products/web_srvr/home_web_srvr.html
Install WebLogic iPlanet plug-in by copying the appropriate BEA plug-in files to your iPlanet installation.
Note. If you are going to run iPlanet on the same machine as WebLogic, it is recommended to skip this step.
The plug-in files are located in the WL_HOME/server/plugin/OperatingSystem/Architecture directory of your WebLogic Server distribution. WL_HOME represents the top level installation directory for your WebLogic platform. The server directory contains installation files for WebLogic Server. The OperatingSystem directory corresponds to the operating system, such as UNIX or Windows. For example, on 32-bit Microsoft Windows machines, copy the plugin files using WebLogic_home\weblogic92\server\plugin\32\ to iPlanet_dir\plugins.
iPlanet_dir refers to the location where iPlanet is installed. For iPlanet 4.x on Windows, the default is c:\netscape\server4\. For iPlanet 6.x on Windows, the default is C:\iPlanet\servers\
iPlanet_platform refers to the OS platform on which BEA has certified iPlanet.
Define the NSAPI Module
Be sure to backup your obj.conf before you begin this step. This step covers modifying the iPlanet configuration file, obj.cont, (magnus.conf for iPlanet (6.x) so as to reference the BEA provided NSAPI module.
Following are examples using configuration files on a Windows machine named crm.peoplesoft.com.
For iPlanet 4.x:
Edit the configuration file C:\Netscape\Server4\https-crm.peoplesoft.com\config\obj.conf for your iPlanet instance.
Add the following lines to the top of the obj.conf file, preceding any comments. This instructs iPlanet to load the native library as an NSAPI module. For iPlanet and drive, substitute the actual location, including the drive letter of the NSAPI module you copied in at previous steps:
Init fn="load-modules" funcs="wl-proxy,wl-init"\ shlib=drive:/iPlanet/plugins/proxy36.dll Init fn="wl-init"
If you skipped Step 1 because iPlanet and WebLogic will be running on the same machine, update your configuration file similar to the following:
Init fn="load-modules" funcs="wl_proxy,wl_init"\ shlib="drive:/WebLogic_home/weblogic92/server/plugin/<platformArchitecture >/proxy36.dll" Init fn="wl_init"
For iPlanet 6.x:
Edit the configuration file C:\iPlanet\server\https-crm.peoplesoft.com\config\magnus.conf for your iPlanet instance.
Add the following lines to the bottom of the magnus.conf file. This instructs iPlanet to load the native library as an NSAPI module. For iPlanet and drive, substitute the actual location, including the drive letter of the NSAPI module you copied in at previous steps:
Init fn="load-modules" funcs="wl-proxy,wl-init"\ shlib=drive:/iPlanet/plugins/proxy36.dll Init fn="wl-init"
If you skipped Step 1 because iPlanet and WebLogic are running on the same machine, update your configuration file similar to the following:
Init fn="load-modules" funcs="wl_proxy,wl_init"\ shlib="drive:/WebLogic_home/weblogic81/server/bin/proxy36.dll" Init fn="wl_init"
Define which requests to be handled by the plug-in.
The type of requests to be handled by the iPlanet plug-in, and subsequently handed off to BEA WebLogic, must be declared as part of an object definition in the obj.conf file. A specific string in the URL, referred to as a ppath, can identify these requests.
To proxy all requests of a single PeopleSoft Internet Architecture site, such as ps (which would be accessed as http://crm.peoplesoft.com/ps/signon.html), define the following object tag in the obj.conf file. Define this and any other object tags directly following the default object tag.
<Object name="ps" ppath="*/ps/*"> Service fn=wl-proxy WebLogicHost=server1\ WebLogicPort=7001 </Object>
The default object tag is generally several lines long and can be identified by <Object name=default>...</Object>.
To proxy additional sites, add subsequent object tags referencing the other site names:
<Object name="hr" ppath="*/hr/*"> Service fn=wl_proxy WebLogicHost=server1\ WebLogicPort=7001 </Object>
To proxy all requests that are made to iPlanet, create a single object tag named “peoplesoft” and set the ppath parameter to *.
Apply changes to iPlanet
With these settings saved, access the iPlanet server manager, perhaps http://localhost:8888. Supply the ID and password that you specified during the iPlanet install. The default ID/password is admin/password. When prompted, click the Apply button to update iPlanet with your changes and restart it.
Start WebLogic Server.
Start the PIA server either via starPIA.cmd(.sh) or if installed as a Windows service, “NETSTART peoplesoft-PIA.
Confirm the configuration.
To confirm an installation, with both the WebLogic Server and iPlanet servers started, simply access PeopleSoft using the typical URL, http://iPlanet/ps/signon.html. If you are able to logon to PeopleSoft, your installation and configuratiion was successful.
Applying Changes to iPlanet
After saving settings, access the iPlanet server manager (for example, http://localhost:8888).
Enter the ID and password that you specified during the iPlanet installation. The default ID and password are admin and password. When prompted, click Apply to update iPlanet with your changes and restart it.
Starting the Server and Confirming the Installation
Start the PIA server with either startPIA.cmd(.sh) or, if installed as a Microsoft Windows service,NET START peoplesoft-PIA. .
To confirm an installation, with both the BEA WebLogic server and iPlanet servers started, access the PeopleSoft system by using the typical URL, http://iPlanet/ps/signon.html. If you can sign in to the PeopleSoft system, your installation and configuration was successful.
If you plan to proxy all requests for the PeopleSoft Internet Architecture through iPlanet, you must also update any URLs that are defined in the PeopleSoft database to reference the iPlanet server, not the BEA WebLogic server.
Those URLs are:
For the PeopleSoft portal, any content URLs that you have defined that directly reference PeopleSoft content (psc, psp) on the BEA WebLogic server (meaning that the BEA WebLogic server is referenced in the URL) must be updated to reference the iPlanet server in the URL
For the PeopleSoft integration gateway, any node definitions that directly reference an integration gateway on the BEA WebLogic server must be updated to reference the iPlanet server in the URLs.
For the PeopleSoft report repository, any report node definitions that directly reference a report server on the BEA WebLogic server must be updated to reference the iPlanet server in the URLs.
Any of your own definitions or objects that reference the URL of the BEA WebLogic server must be updated to reference the iPlanet server in the URLs.
The iPlanet obj.conf file is strict about the placement of text. To avoid problems, follow these guidelines:
Eliminate extraneous leading and trailing white space.
If you must enter more characters than can be fit on one line, place a backslash (\) at the end of that line and continue typing on the following line. The backslash directly appends the end of the first line to the beginning of the following line.
If a space is necessary between the words that end the first line and begin the second line, use one space, either at the end of the first line (before the backslash), or at the beginning of the second line.
Do not split attributes across multiple lines.
The BEA online documentation contains a complete listing of BEA WebLogic plug-in attributes and parameters.
See http://edocs.bea.com/wls/docs92/plugins/index.html
This section describes how to proxy content to a single server configuration of PIA. When in production, a multi server configuration would be used to perform these steps to proxy content to your managed server instance of PIA or PIA1, etc.
Apache HTTP server can be installed and configured as a reverse proxy server to WebLogic Server. For a list of certified platforms,
See http://e-docs.bea.com/platform/suppconfigs/configs92/92_over/add-ons.html#1084356
To configure Apache HTTP:
Download the Apache HTTP server.
Install Apache.
Install the Apache HTTP server plug-in.
The installation of the Apache plug-in from BEA depends on whether you are installing the plug-in as a dynamic shared object (DSO) or a statically linked module. If you have downloaded the binary distribution of Apache, you will probably install the Apache plug-in from BEA as a shared object. (If you are in doubt as to which type, install the plug-in as a DSO.) Exact instructions are available from BEA.
Specify the parameters that will be used by the Apache plug-in by defining them in an IfModule tag for BEA WebLogic in the Apache httpd.conf file.
Add this tag in the ### Section 2: 'Main' server configuration section of httpd.conf. For example, to configure the Apache to proxy all requests that it receives to a BEA WebLogic server that is running on a machine named crm.peoplesoft.com and listening on port 7001, you would define the following tag:
<IfModule mod_weblogic.c> WebLogicHost crm.peoplesoft.com WebLogicPort 7001 MatchExpression /</IfModule>
BEA provides sample and template configuration files.
See http://edocs.bea.com/wls/docs92/plugins/index.html
To proxy requests to a cluster of BEA WebLogic servers, replace the two attributes, WebLogicHost and WebLogicPort, with WebLogicCluster.
The syntax of the WebLogicCluster is wlserver1:port,wlserver2:port.
Details about clustering setup are available in a red paper.
See The red paper on the PeopleSoft Customer Connection website: Clustering and High Availability for PeopleSoft 8.4
If you specified an AuthTokenDomain during the PeopleSoft Internet Architecture installation, you must set the cookieName for the reverse proxy to that same value. To do so, add the cookieName attribute and set its value to CookieName, as specified on the BEA WebLogic server in the PORTAL web application's weblogic.xml file (for example, PS_HOME\webserv\peoplesoft\applications\peoplesoft\PORTAL\WEB-INF\weblogic.xmlˋ).
Start the Apache HTTP server following the Apache usage instructions.
Start the BEA WebLogic server with either startPIA.cmd(.sh) or, if installed, as a Microsoft Windows service, NET START peoplesoft-PIA.
To confirm an installation, with both the BEA WebLogic server and Apache servers started, access the PeopleSoft system by using the typical URL, http://Apachehost/ps/signon.html.
If you can sign in to the PeopleSoft system, your installation and configuration was successful.
See Also
http://edocs.bea.com/wls/docs92/plugins/index.html
HTTP session timeout controls are accessible on the Security page of the web profiles in the PeopleSoft database. PeopleSoft Internet Architecture no longer uses session timeout control set on the web server. The session timeouts set in the Web Profiles override any HTTP session timeouts set on the webserver at runtime.
See Configuring Portal Security.
This section describes how to change HTTP Keep-Alive settings for a single server configuration of PIA. When in production, a mult server configuration would be used to perform these steps to your managed server instance of PIA, PIA1, etc.
Keep-Alive, or more accurately termed "Persistent Connections" is a default feature of HTTP 1.1 as described in http://www.w3.org/Protocols/rfc2616/rfc2616.html. Keep-Alive allows for the client (generally a web browser) and the web server to maintain open connections between requests for specified period of time. That time period is generally less then 60 seconds. The benefit of a persistent connection is that with each subsequent request the client and the server do not need to perform the overhead of opening a new connection. Enabling keep-Alive is generally recommended, but in some situations it may introduce a problem. Sporadic "The Page cannot be displayed" can be the result of a problem with keep-Alive. In situations where keep-Alive issues are suspected, disabling the web server keep-Alive will help to determine if the problem is indeed related to connection persistence.
To enable or disable Keep-Alive:
Start the PIA server.
Start the PIA server either via startPIA.cmd(.sh) or if installed as a Windows service, " NET START peoplesoft-PIA".
Log on to the WebLogic Server Administrative Console.
In a new browser, access the WebLogic Server console at http://localhost/console and specify the WebLogic administrative ID that you specified during the PIA installation. The default ID and password are system and password, respectively.
Open Server's HTTP configuration page.
In the navigation window on the left, use the following navigation to open the PIA server's HTTP configuration settings. If you are using a custom server name, substitute that name where appropriate:
Click Environments.
Select the PIA server from the window on the right.
Click the Protocols tab and click the HTTP tab.
Change keep-alive settings.
Click the Lock & Edit button before you make any changes and click Activate Changes button after you are done making the changes.
To disable keep-Alive: Uncheck Enable Keepalives and click Save. With keep-Alive disabled, HTTP keep-Alive Duration and HTTPS keep-Alive Duration are not used.
To enable keep-Alive: Check "Enable Keepalives" and update HTTP Keep-Alive 'Duration' and 'HTTPS Keep-Alive Duration' values as deemed necessary. Once done click 'Apply'. Minimum/maximum values for HTTP are 5/120 seconds respectively. For HTTPS the minimum/maximum values are 120/360 seconds.
Restart WebLogic Server.
The WebLogic domain built by the PIA install includes the following WebLogic IDs:
system
operator
monitor
PsftUser
Each of those IDs have a default password of 'password'. It is highly recommended to change this password on any production servers.
To change the password for the system:
Start the PIA server.
Start the PIA server either via PS_HOME\webserv\weblogic_domain\startPIA.cmd(.sh) or if installed as a Windows service, " NET START peoplesoft-PIA".
Log in to the WebLogic Server Administrative Console.
Access the WebLogic Server console at http://webserver/console (for example, http://localhost/console). When prompted for a user name and password, specify the WebLogic system ID and password. If you've followed the default WebLogic Server install, the ID and password are 'system' and 'password'. Otherwise, specify the password supplied during your PIA installation.
Change a WebLogic Server user's password.
In the graphical domain structure hierarchy on the left, use the following navigation to change a user's password.
Click Security Realms.
On the right, click myrealm.
Select the Users and Groups tab.
In the table of available users, click system.
Select the Passwords tab.
Enter and re-enter a new password for this user.
Click Save.
Modify the boot.properties file with the new values:
Open PS_HOME\webserv\<domainname>\servers\PIA\security\boot.properties.
Remove the previous, encrypted system user ID and password values, and enter the new system user ID and password in clear text.
Save the file.
Note. When you run WebLogic as a Windows service, WebLogic uses the default ID of operator and its password of password. Changing the password for the WebLogic ID that runs the Windows service requires an additional manual step of updating the setEnv.cmd (PS_HOME\webserv\peoplesoft\bin\setEnv.cmd) and set the WLS_PW environment variable to the operator ID with the new password. Once that is done, reinstall the Windows service by re-running the installNTservice command file located in the same WebLogic domain directory as the setEnv.cmd that you edited.
This section provides an overview of Secure Sockets Layer (SSL) encryption with WebLogic and discusses how to:
Obtain encryption keys.
Prepare keys and certificates for the keystore.
Import keys and certificates into the keystore.
Configure WebLogic SSL encryption keys.
To use SSL encryption with WebLogic and the current PeopleTools release, the WebLogic keystore must contain the following appropriately configured encryption keys:
The web server's private key.
The web server's public key, digitally signed by a trusted certificate authority (CA).
The digitally signed public key of the same CA that signed the web server's key.
A public key is transferred and stored as a data element in a digital certificate or a certificate signing request (CSR). You can obtain public keys from a variety of sources, in several different formats.
You must ensure that the encryption keys are correctly formatted, install them in the keystore, then configure them using the WebLogic server administration console.
Note. If you've already installed and configured a set of encryption keys for use with WebLogic 5.1, 6.1, or 8.1 in a previous PeopleTools release, they're maintained by those earlier versions of WebLogic as external files. You must migrate them to the WebLogic 9.2 keystore so that they work correctly with the current release.
If you already have a set of existing encryption keys configured as external files, you don't need to obtain new ones. To find the existing keys, refer to the documentation for the PeopleTools and WebLogic releases for which those keys were installed.
The following procedure describes how to obtain new encryption keys, using as an example the 14-day free trial certificate available from Verisign.
To obtain new encryption keys:
At a command prompt, change to the following directory:
PS_HOME\webserv\domain_name
Where domain_name is the name of the installed PeopleSoft Pure Internet Architecture domain for which you want to obtain encryption keys.
Enter the following command:
pskeymanager -create
Note. Pskeymanager is a script wrapper to Java's keytool, provided by PeopleSoft to manage the WebLogic keystore. For usage information, enter pskeymanager -help.
Follow the prompts and enter the requested information to create a new private key and a CSR for your web server.
Pskeymanager uses the keystore in PS_HOME\webserv\domain_name\keystore\pskey, with a default password of password.
Pskeymanager prompts you for an alias for the new keys, for example, ServerABC. This is the name you'll use to refer to the keys in the future.
Pskeymanager prompts you for distinguished name fields. Enter the appropriate values for your organization.
Pskeymanager prompts you for information about the CSR expiration date, key size, key algorithms, and the private key password. All of these fields have default values.
Pskeymanager creates the private key inside the keystore, and creates the CSR as a file called ServerABC_certreq.txt in the current directory. You use the CSR to obtain your signed public key certificate and a root certificate from a CA.
Decide which trusted CA you want to sign your web server's public key.
You can use any CA that's compatible with Sun's Java 1.4 JKS standard, such as Verisign.
Open your CSR file in a text editor and copy its entire contents, including the first and last lines:
-----BEGIN NEW CERTIFICATE REQUEST----- ... ... -----END NEW CERTIFICATE REQUEST-----
Access Verisign's test certificate enrollment site at https://www.verisign.com/products/srv/trial/intro.html.
Verisign guides you through the CSR submission process, including:
Accepting the Verisign license agreement.
Entering your technical contact information, which includes the email address where Verisign can send your signed public key.
Pasting your CSR contents in the provided text field.
Verifying your CSR.
Confirming and submitting your order.
Verisign also provides its own digitally signed public key in a certificate, which is known as a trusted CA certificate, a root certificate, or a chain certificate.
Download the VeriSign test CA root certificate from http://digitalid.verisign.com/cgi-bin/getcacert.
When prompted, save getcacert.cer to PS_HOME\webserv\domain_name.
Note. If you need to FTP your certificate to UNIX, you must FTP it in ASCII mode to PS_HOME/webserv/domain_name.
Check your email.
Verisign digitally signs your web server's public key, then returns it to you in a certificate, called the server certificate. Following is an example of the contents of a server certificate:
-----BEGIN CERTIFICATE----- DMICHDCCAcYCEAHSeRkM2guFL+6OvHr4AS0wDQYJKoZIhvcNAQEEBQAwgakxFjAP AANVBAoTDVZlcmlTaWduLCBLbAMxRzBFBgNVBAsTPnd3dy52ZXJpc2lnbi5jb20S VcVwb3NpdG9yeS9UZXN0Q1ETIEluY29ycC4gQnkgUmVmLiBMaWFiLiBMVEQuMUYF LIGEc3VyYW5jZXMgKEMpVRMxOSDFertdsfh67TIwNDAwMDAwMFoXDTAwMTIxODIA ONT1LVoweTELMAkGA1UERhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExEzARBgNK VBAUCOBsZWFzYW50b24BEzARBgNVBAoUClBlb3BsZVNvZnQxFDASBgNVBAsUC1BT Eb3sZVVvb2xzMRUwEwADVQQDFAxEQlJPV04xMTE0MDAwXDANBgkqhkiG9w0BAQET SAALADBEAkEAucfM/GOQhdkk4Q0ZD5i1l4gp6WTYMc4IaReoCYkEAmDKAVcYzY3R Mdbp4RC8SABd3bjjDOHcoCak9U6oSwL+HQIDAQABMA0GCSqGSIb3DQEBBAUAA0EO Arm3uf634Md0fqgNxhAL+e9rbY0ia/X48Axloi17+kLtVI1YPOp+Jy6Slp5iNIFC DhskdDFH45AjSDAFhjruGHJK56SDFGqwq23SFRfgtjkjyu673424yGWE5Gw4576K DosdDFG256EDHY45yTRH67i345314GQE356mjsdhhjuwbtrh43Gq3QEVe45341tS YDY6d47lDmQxDs9wGt1bkQ== -----END CERTIFICATE-----
Copy the entire certificate contents, and save it as a text file called ServerABC-cert.pem in PS_HOME\webserv\domain_name.
Be sure to include the first and last lines.
Note. If you need to FTP your certificate to UNIX, you must FTP it in ASCII mode.
Note. It's a good idea to make backup copies of the server certificate and the root certificate before proceeding.
Your encryption keys must be in privacy enhanced mail (PEM) format, which is Base64-encoded data. Base64 encoding uses only ASCII characters. A PEM-formatted key or certificate file has an extension of either .pem or .cer. If the file is in the binary distinguished encoding rules (DER) format, it has a .der extension. Use the der2pem Java utility to convert DER-formatted keys and certificates to PEM format.
For SSL to work, your WebLogic server must present its own public key to each client browser, along with the self-signed public key of a root CA that's also in the browser's keystore, as well as any keys necessary to establish a chain of trust between the two. All of these keys must be part of the same certificate file before you can import them into the WebLogic keystore.
If you generated the private key using pskeymanager on a WebLogic platform, it's automatically correctly formatted, password protected, and installed in the keystore with no additional steps required. However, if the private key was configured as an external file on an earlier WebLogic platform/version, you must properly format it and incorporate a password, before importing it into the current WebLogic keystore along with the public key certificates.
Converting DER Files to PEM Format
It's important to convert all DER-formatted key and certificate files to PEM format before you work with them further.
To convert DER-formatted key and certificate files to PEM format:
At a command prompt, change to the following directory:
PS_HOME\webserv\domain_name
Where domain_name is the name of an installed PeopleSoft Pure Internet Architecture domain.
Enter the following command:
setenv.cmd
This sets the appropriate environment for java commands.
For each DER-formatted key or certificate file, enter the following command:
java utils.der2pem filename.der
Make sure that you include the DER file's directory path. A new PEM file by the same name is created in the same location.
If you converted a private key file to PEM format, you must modify the header and footer to be compatible with WebLogic.
To modify the private key file header and footer:
Open the PEM-formatted private key file in a text editor.
Change the following line:
-----BEGIN CERTIFICATE-----
To this:
-----BEGIN RSA PRIVATE KEY-----
Change the following line:
-----END CERTIFICATE-----
To this:
-----END RSA PRIVATE KEY-----
Save and close the private key file.
Establishing the Server Certificate Chain of Trust
Your server certificate must contain, in addition to the web server's public key, any keys necessary to establish a chain of trust that culminates in the self-signed root certificate of a trusted root CA. That CA's root certificate must be in the keystore of any browser that's used to access your web server. Most browsers have an extensive set of trusted root certificates in their keystores.
First append the root certificate of the CA who issued your server certificate to the server certificate file. If you determine that that root certificate is not likely to be in your users' browsers, you must also append to the certificate file a chain certificate that was issued to your CA by another CA, then a chain certificate issued to that CA, and so on,
For example, if your server certificate file is demo_cert.pem and the CA's root certificate is ca_cert.pem, you can open demo_cert.pem in a text editor, then insert the contents of ca_cert.pem after a newline at the end of the file. Make sure that each certificate follows the previous one on the next line, as follows:
... ... DosdDFG256EDHY45yTRH67i345314GQE356mjsdhhjuwbtrh43Gq3QEVe45341tS YDY6d47lDmQxDs9wGt1bkQ== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- DMICHDCCAcYCEAHSeRkM2guFL+6OvHr4AS0wDQYJKoZIhvcNAQEEBQAwgakxFjAP ... ...
The result is that demo_cert.pem, for example, now contains the data from both certificates.
If you determine that ca_cert.pem won't be recognized as a trusted root by all of your users' browsers, you must obtain the root certificate of the CA who issued ca_cert.pem and append that to demo_cert.pem as well, and so on, until you append a root certificate that was issued by a trusted CA to itself.
Note. You can also use the type command in Windows or the cat command in UNIX to combine the certificate files.
Password Protecting the Private Key
Private keys inside the WebLogic keystore are password protected. You can't import an external private key file into the keystore without a password. If it isn't currently password protected, use the WebLogic wlkeytool utility to incorporate a password into the private key file.
To password-protect an external PEM-formatted private key file:
At a command prompt, change to the following directory:
WL92_HOME\server\native\win\32
Where WL92_HOME is the root directory of your installed WebLogic 9.2 server, for example, C:\bea\weblogic92.
Enter the following command:
wlkeytool insecure_privatekey.pem secure_privatekey.pem
Where insecure_privatekey.pem is the name of the original private key file, and secure_privatekey.pem is the name of the resulting password-protected private key file.
Note. Make sure that you include directory paths for the private key files.
The following message appears:
Enter password to unprotect private key:
Press Enter.
The following message appears:
Private key not PKCS8 encoded, trying RSA key Private key file opened successfully Enter password to protect private key :
Enter the password that you want to use for this key.
The following message appears:
Verify password to protect private key :
Enter the password again to confirm it.
The utility creates the password protected private key file that you specified. You can now import the key into the WebLogic keystore.
Each WebLogic domain maintains its own keystore in PS_HOME\webserv\domain_name\keystore\pskey, and all servers within a domain can share the same keystore.
Two tools are available for importing keys and certificates into the keystore:
If you created the private key using the pskeymanager utility on a WebLogic platform, it's already installed in the keystore. You need only use pskeymanager to import your server certificate, which should contain your web server's signed public key, your trusted CA's root certificate, and any public keys necessary to establish a chain of trust between them.
If the private key was previously configured as an external file on an earlier WebLogic platform, you must import it into the WebLogic keystore along with the server certificate, using the ImportPrivateKey utility. The private key should be password-protected.
Using Pskeymanager to Import the Server Certificate
To import the server certificate into the WebLogic keystore:
At a command prompt, change to the following directory:
PS_HOME\webserv\domain_name\bin
Where domain_name is the name of the installed PeopleSoft Pure Internet Architecture domain.
Enter the following command:
pskeymanager -import
Note. Pskeymanager is a script wrapper to Java's keytool, provided by PeopleSoft to manage the WebLogic keystore. For usage information, enter pskeymanager -help.
Follow the prompts and enter the requested information to create a new private key and a CSR for your web server. Keep the following in mind:
Pskeymanager uses the keystore in PS_HOME\webserv\domain_name\keystore\pskey, with a default password of password.
Pskeymanager prompts you for an alias for the server certificate, for example, ServerABC. This should be the same alias that you specified for the corresponding private key when you created it.
Pskeymanager prompts you for the name of the server certificate file, for example, ServerABC-cert.pem. Include the file path if necessary.
Pskeymanager imports the server certificate into the keystore.
Using ImportPrivateKey to Import an External Private Key File with the Server Certificate
To import a password-protected private key and the server certificate into the WebLogic keystore:
At a command prompt, change to the following directory:
PS_HOME\webserv\domain_name\bin
Where domain_name is the name of an installed PeopleSoft Pure Internet Architecture domain.
Enter the following command:
setEnv.cmd
This sets the appropriate environment for Java commands.
Enter the following command:
java utils.ImportPrivateKey keystore\pskey store_pass privatekey_alias privatekey_pass servercert_file privatekey_file
The parameters for this command are as follows:
store_pass |
Specify the password for the WebLogic pskey keystore. The default password is password. |
privatekey_alias |
Specify an alias for the private key. This is the name by which the key will be accessible inside the keystore. |
privatekey_pass |
Specify the password for the private key. |
servercert_file |
Specify the path and name of the server certificate file that includes the issuing CA's root certificate. |
privatekey_file |
Specify the path and name of the private key file. |
The encryption keys are installed in the WebLogic keystore, and you can now configure them using the WebLogic server administration console.
This section describes how to configure the SSL encryption keys that you previously imported into the WebLogic keystore in PS_HOME\webserv\domain_name\keystore\pskey, where domain_name is the name of an installed PeopleSoft Pure Internet Architecture domain.
The following procedure applies to a single server configuration of PIA. In a production environment, you would perform these steps for managed server instances of PIA, PIA1, PSOL, RPS, and so on, in a multi-server domain configuration.
To configure WebLogic SSL encryption keys for the PIA server:
With the PIA server running, sign in to the WebLogic Server Administration Console.
Access the WebLogic Server console at http://webservername/console (for example, http://localhost/console). When prompted for a user name and password, enter the WebLogic system ID and password, which you defined during the PIA install. The default user name and password are system and password, respectively.
Access the keystore configuration pages.
In the lefthand navigation tree, navigate to peoplesoft, Servers, PIA.
Select the Keystores tab.
To change the Configuration section, click Lock & Edit.
Select Custom Identity and Custom Trust from the Keystores list.
Update the fields on the Configure Keystore Properties page as follows:
Field |
Value |
Comment |
Custom Identity Key Store File Name |
keystore/pskey |
This should be the relative path and name of the keystore into which you imported your SSL keys. |
Custom Identity Key Store Type |
JKS |
Don't change this value. |
Custom Identity Key Store Pass Phrase |
password |
See the following note regarding passwords. |
Confirm Custom Identity Key Store Pass Phrase |
Same as the value of Custom Identity Key Store Pass Phrase. |
|
Custom Trust Key Store File Name |
keystore/pskey |
This should be the relative path and name of the keystore into which you imported your SSL keys. |
Custom Trust Key Store Type |
JKS |
Don't change this value. |
Custom Trust Key Store Pass Phrase |
password |
See the following note regarding passwords. |
Confirm Custom Trust Key Store Pass Phrase |
Same as the value of Custom Trust Key Store Pass Phrase. |
Note. The default keystore and private key password is password. This should never be used in a production environment. You can change a private key's password and a keystore's password using pskeymanager's change password options: -changeprivatekeypassword and -changekeystorepassword, respectively.
Click Save.
Access the SSL tab, and update the values on the SSL Private Key Settings as follows:
Field |
Value |
Comment |
Private Key Alias |
Specify a unique identifier, such as the webserver's machine name. |
This is the alias that you specified for this server's private key. |
Passphrase |
password |
See the following note regarding passwords. |
Confirm Passphrase |
Same as the value of Passphrase. |
Note. The default keystore and private key password is 'password'. This should never be used in a production environment. A private key's password and a keystore's password can be changed via pskeymanager's change password options of –changekeystoreword and –changeprivatekeypassword.
Click Save.
You must click the Activate Changes button to apply your changes. If you close your browser without clicking Activate Changes, your changes will be lost.
Restart the WebLogic PIA server.
The Java options including the JVM heap size, VM mode, such as HotSpot Server, used by the WebLogic server are stored in your WebLogic domain's setEnv script (for example, PS_HOME\webserv\peoplesoft\bin\ˋsetEnv.cmd). These options are specified in the script using the JAVA_OPTIONS_OSplatform environment variable. If you need to adjust any of the java options, including changing the JVM heap size, you must manually edit the script.
The Microsoft Windows setEnv.cmd script contains the following default setting:
JAVA_OPTIONS_WIN32="-server ?Xms256m -Xmx256m -XX:MaxPermSize=128m"
The UNIX standard setEnv.sh script contains the following default settings for supported Linux and UNIX platforms:
JAVA_OPTIONS_AIX="-Xms128m -Xmx256m" JAVA_OPTIONS_HPUX="-server ?Xms256m -Xmx256m -XX:MaxPermSize=128m" JAVA_OPTIONS_LINUX="-Xms256m -Xmx256m" JAVA_OPTIONS_TRU64="-Xms256m -Xmx256m" JAVA_OPTIONS_SOLARIS="-server ?Xms256m -Xmx256m -XX:MaxPermSize=128m"
You modify the ?Xms parameter to adjust minimum heap size, and modify the ?Xmx parameter to adjust maximum heap size. You can notice that the min and max values of the heap size are set to same value (except AIX) and it is recommended to set it to same value to obtain better performance.
In a multi-server domain, the platform-specific versions of the JAVA_OPTIONS environment variable that are shown in the setEnv script apply only to managed servers. The administration server doesn't use any of these variables, but it assumes default JVM heap size values of "-Xms32m -Xmx64m".
To adjust the JVM heap size for the administration server, add the environment variable JAVA_OPTIONS_ADMINSERVER following the last entry for JAVA_OPTIONS_OSplatform, and set it to your own minimum and maximum values, for example:
JAVA_OPTIONS_ADMINSERVER="-Xms64m -Xmx128m"
Note. If you're running BEA WebLogic as a Microsoft Windows service and you modify setEnv.cmd, you must reinstall the service by running installNTservicePIA.cmd or InstallNTservice.cmd from the WebLogic domain directory again.
See Also
A summary of installed products, their versions and service pack levels, is maintained in the BEA_HOME\registry.xml file. However, to confirm version information, it's more accurate to check the BEA WebLogic log. A failed service pack install may be indicated in the log, but not found at runtime.
This section discusses how to:
Check the log
Query BEA WebLogic
Checking the Log
In the BEA WebLogic log (PS_HOME\webserv\peoplesoft\servers\<server name>\logs\weblogic_server_weblogic.log), look for an entry similar to this:
####<Nov 27, 2006 5:23:20 AM PST> <Info> <Management> <> <> <main> <> <> <> <1164633800224> <BEA-141107> <Version: WebLogic Server 9.2 Fri Jun 23 20:47:26 EDT 2006 783464 >
Querying BEA WebLogic
You can query BEA WebLogic at the command line.
Perform a query at the command line as shown in this example (for UNIX, use setEnv.sh):
PS_HOME\webserv\peoplesoft\bin\setenv.cmd java weblogic.Admin -url t3://localhost:80 –username <username> -password <password> VERSION WebLogic Server 9.2 Fri Jun 23 20:47:26 EDT 2006 783464
This section describes how to change HTTP logging for a single server configuration of PIA. When in production, a multi server configuration would be used to perform these steps to your managed server instance of PIA or PIA1, etc.
To enable or disable HTTP access log:
Start the PIA server.
Start the PIA server either via startPIA.cmd(.sh) or if installed as a Windows service, " NET START peoplesoft-PIA".
Log on to the WebLogic Server Administrative Console.
In a new browser access the WebLogic Server console at http://localhost/console and specify the WebLogic administrative ID that you specified during the PIA installation. The default ID and password are 'system' and 'password'.
Open Server's Logging configuration page.
In the navigation window on the left, navigate to the following to open the PIA server's HTTP configuration settings. (If you are using a custom server name, substitute that name where appropriate.)
Expand Environment.
Click Servers.
Select PIA on the right.
Select the Logging tab, select the HTTP tab, and click the Lock&Edit button.
Check the HTTP access log file Enabled check box to turn on the access.log. Change the Logfile name if desired.
Click Save.
Restart the WebLogic Server.