Configuring REN Servers

This chapter provides overviews of real-time event notification (REN) servers and Secure Sockets Layer (SSL) enabled REN servers and discusses how to:

Configure REN server security.
Configure REN servers.
Configure REN server and SSL-enabled REN server clusters.
Configure a reverse proxy server with a REN server.

Understanding REN Servers

This section discusses:

REN server failover, scalability, and security configuration.
REN server failover.
REN server clusters.

The REN server, an application server domain process, is essential to PeopleSoft MultiChannel Framework (MCF) architecture. MCF events are sent to REN servers, which deliver them to recipients of those topics.

REN servers are also used by other PeopleSoft applications to push event notifications to users, such as the Reporting Window output option and the Optimization Progress Window.

The REN server is a modified web server using the HTTP 1.0 or 1.1 communications protocol. Communication with MCF server processes and browser windows is bidirectional, as they maintain persistent connections to the REN server. Events can be sent proactively to browser windows without polling or page refreshes.

REN Server Failover, Scalability, and Security Configuration

REN servers can be configured to support both failover and scalability, and should be protected with firewalls and appropriate security measures, as illustrated in the following diagram:

REN server configuration example

REN Server Failover

Although the REN server is integrated into an application server domain, it is not a standard PeopleTools server process (it has no database connection) and therefore has a separate failover mechanism. Two scenarios exist for failure recovery:

For a standalone REN server, BEA Tuxedo restarts the server if it fails.

MCF servers and consoles reconnect to the REN server. However, any active browser sessions (such as MCF chat) will be interrupted until a connection can be reestablished between the chat console and the restarted REN server.
For clustered REN servers, each REN server in the cluster is a peer that mirrors the current state.

This configuration has two advantages over a standalone REN server:
- Clustered REN servers guard against hardware failure (provided that the clustered REN servers are on different host machines).
- Active browser sessions are not lost.

REN Server Clusters

You can configure a REN server cluster with only one REN server member. However, a REN server cluster that is configured with two or more REN servers provides failover.

All REN servers in a cluster mirror each other and appear to external processes as a single URL. The REN server cluster must have an HTTP load balancer or switch as its front end. All connections with browsers and application server processes address the front end’s URL. The load balancer should use an active standby content-switching rule to route all traffic to a designated REN server in the cluster. The front end selects an alternate member of the cluster only when the designated REN server fails to respond.

The REN server cluster maintains mirrored state in all members by relaying events with HTTP messages. The REN server cluster therefore does not address scalability issues. Clustering REN servers does not improve performance and may increase processing overhead and internal network traffic. The internal HTTP connections between cluster members should be high speed for best performance. Because of the overhead involved in synchronous cluster members, each member of a cluster can handle less load than a REN server in a cluster with only one REN server.

Note. In an environment where there are multiple REN servers within a single cluster, the primary REN server sends synchronization data to the other members of the cluster. If any of these synchronization messages fail, then the primary REN server will retry up to cluster_retry_count times. The minimum value of this parameter, cluster_retry_count in psrenconfig.txt is 0, which means that the REN server will not retry.

If a REN server crashes, it does not rejoin the cluster, because it would not be synchronized with the other clustered REN servers. The entire cluster must be shut down and rebooted to restore all members back to full participation.

Incoming cluster requests must eventually route to the front end's HTTP address. Queue servers and application servers use the cluster URL, which is typically set to be the URL of the front end. Browser clients make requests using the browser URL, which may be set to the front end, or to a server that proxies to the load balancer. If browser transactions are encrypted with SSL, then the browser URL is an HTTPS address to a reverse proxy server or SSL accelerator.

Note. If you use SSL between the browser and REN server, then you must use a reverse proxy server or SSL accelerator, unless you have configured an SSL-enabled REN server.

Understanding SSL-Enabled REN Servers

You can enable a secure channel of communication between the clients and the REN server by enabling SSL on the REN server using openssl. The SSL protocol runs above TCP/IP and below higher-level protocols, such as HTTP and IMAP4. By using TCP/IP on behalf of higher-level protocols, openssl allows an SSL-enabled server to authenticate itself to an SSL-enabled client, a client to authenticate itself to a server, and both machines to establish an encrypted connection.

This section discusses:

Installing digital certificates.
Authenticating sever and client.
Performance and scalability for SSL-enabled REN servers.

Installing Digital Certificates

REN servers require digital certificates to work in SSL mode. The servers pick up the certificates from the PeopleTools database. The certificates must be imported into PeopleTools database from PeopleTools, Security, SecurityObjects, Digital Certificates. Certificates that are installed in the database will have a unique combination of certificate type and alias.

The certificate type that is used for the server should be of the type CERT, and the alias is <machine name>.<domain name>. When the certificate is configured with a unique alias name, it should be associated with the REN server that is SSL enabled. The REN server loads its server certificate from the database at the start up.

See Installing Digital Certificates for REN SSL.

Authenticating Server and Client

For server authentication, the server sends its certificate to the client as a part of the SSL handshake and the client authenticates by verifying the Certificate Authority (CA) of the certificate against its trusted keystore. When the REN server is configured for SSL, all clients must trust the CA of the server certificate to participate in a successful communication.

Client authentication verifies the clients's authenticity to participate in a communication with the server. When the REN server is configured for client authentication, all clients must supply a valid client certificate to participate in a successful communication.

All clients must use the REN cluster's HTTPS URL to communicate in the SSL mode. If the REN server is SSL only, access will be denied to any client trying to communicate with a HTTP URL port. The browser-based clients, the application server client, and the REN Java clients should be configured appropriately to communicate with an SSL-enabled REN server.

Performance and Scalability for SSL-Enabled REN Servers

During an SSL transaction, the handshake is an added overhead that occurs. However, for every transaction, the handshake is done once to authenticate the server and the client. After authentication, the data is digitally signed, encrypted, and exchanged on an established session. For each console, authentication establishes a session only once, and all subsequent transactions do not inherit any overhead of authentication.

Configuring REN Server Security

This section provides an overview of REN server security configuration and discusses how to define permission lists for REN server access.

Understanding REN Server Security Configuration

Protect the REN server behind firewalls. A reverse proxy server can be used between browser clients and the REN server. Browser sessions can be SSL-encrypted using a reverse proxy server or hardware SSL accelerator.

Note. The security of your PeopleSoft system, and configuration of load balancers, switches, and reverse proxy servers, is beyond the scope of this document. Refer to your PeopleBooks for more information.

REN server access from browser clients is restricted to users who are currently logged into PeopleSoft with appropriate REN server permissions. You must enable single signon security to obtain REN server access. Permission to access REN server applications is granted on permission lists, which are in turn associated with security roles and user IDs. Clients lacking access permission receive a 403 Forbidden page from the REN server.

Note. REN server access requires that single signon is enabled.

Defining Permission Lists for REN Server Access

The following REN Permissions page shows the objects and permissions that are defined for permission list PTPT1200. Customers can create their own permission list and define access to REN server in the permission list that they created.

To define permission lists for REN server access:

Select PeopleTools, Security, Permissions & Roles, Permission Lists.
On the search page, search for and select your permission list.
On the Permission List page, select the PeopleTools tab.
Click Realtime Event Notification Permissions.
On the REN Permissions page, select your permissions.

To enable REN server access for roles that are defined with the current permission list, select Full Access for each object that is required by the role. For example, users who require access to the MultiChannel Console must have Full Access defined for the MCF Agent object.

The MultiChannel Console link appears in the universal navigation header for any user with full access permissions defined for the MCF Agent object. However, the user must also be configured as an MCF or CTI agent to access the MultiChannel Console or CTI console.

Note. To enable access to the Report-to-Window functionality, add WEBLIB_RPT to the permission list's Web Libraries page, and set Reporting Window to Full Access on the REN Permissions page.

Grant full access to the MCF CTI Server object only on the permission list that is assigned to the CTI server role. No other users should have MCF CTI Server access.

The user ID that is configured to start the Process Scheduler must have full access to the Reporting Window REN permission on at least one permission list for that user ID. If the user ID does not have full access to the Reporting Window, then the pop-up window will stay in a status of queued.

Configuring REN Servers

To configure REN servers, use the REN Server (REN_SERVER_CMP) component.

This section provides an overview of selecting REN server configuration options and discusses how to:

Configure REN servers and SSL-enabled REN servers.
Define REN servers.

Understanding REN Server Configuration Options

Depending on your requirements, choose one of two REN server creation and configuration options:

To create a single REN server in a particular database using default configuration parameters, create an application server domain using PSADMIN.

Event Notification is enabled by default in the quick-configure menu. An associated REN server cluster is also created by default.
To create additional REN servers in a particular database, configure each REN server as required on the REN Server Definition and REN Server Cluster pages.

Then create the associated application server domains. Event Notification is enabled by default in the quick-configure menu.

When a REN server starts up, it looks for configuration information in the database, using the application server domain name and host name as keys. If the associated configuration information exists in the database, the REN server uses it. If no such configuration information exists, the REN server is configured using defaults, which also configure a REN server cluster for each REN server. You can change the default REN server configuration using the REN Server Configuration pages, but such changes do not take effect until the REN server starts up again.

Note. You can create only one REN server per application server domain.

This section discusses some possible REN server configurations that are dependent on domain server topology.

Simple Configuration: Mycompany.com

In this configuration, the REN server is on the host machine MachA, the REN server uses the default port number 7180, DNS addresses the host machine as MachA.mycompany.com, and no SSL or reverse proxy server is involved:

Parameter	Value
PeopleSoft Pure Internet Architecture Authentication Token Domain	mycompany.com
Authentication Domain in REN Server Cluster Configuration	mycompany.com
REN Server Cluster Root Path	/psren
REN Server Cluster URL	http://MachA:7180
REN Server Browser URL	http://MachA.mycompany.com:7180

Simple Configuration with SSL-Enabled REN Server: Mycompany.com

In this configuration, the REN server is on the host machine MachA, the REN server uses the default port number 7143, and DNS addresses the host machine as MachA.mycompany.com. The REN server is SSL-enabled.

Parameter	Value
PeopleSoft Pure Internet Architecture Authentication Token Domain	mycompany.com
Authentication Domain in REN Server Cluster Configuration	mycompany.com
REN Server Cluster Root Path	/psren
REN Server Cluster URL	https://MachA:7143
REN Server Browser URL	https://MachA.mycompany.com:7143

Reverse Proxy Server with Non-SSL Configuration

This configuration includes a single REN server and a reverse proxy server. The reverse proxy server could be either a dedicated reverse proxy server or a web server with a proxy plug-in configured to redirect both PeopleSoft Pure Internet Architecture and REN server requests. The application server host machine is MachA, and the REN server uses its default port 7180. The reverse proxy server is on MachRPS using port 8080 for HTTP. The DNS server must recognize MachRPS.mycompany.com.

Parameter	Value
PeopleSoft Pure Internet Architecture Authentication Token Domain	mycompany.com
Authentication Domain in REN Server Cluster Configuration	mycompany.com
REN Server Cluster Root Path	/psren
REN Server Cluster URL	http://MachA:7180
REN Server Cluster Browser URL	http://MachRPS.mycompany.com:8080

Reverse Proxy Server with SSL Configuration and Secure HTTP

For SSL, install certificates on the reverse proxy server, set the server to encrypt all communications, and use HTTPS URLs from the browser. In this example, the reverse proxy server uses port 8443 for SSL:

Parameter	Value
PeopleSoft Pure Internet Architecture Authentication Token Domain	mycompany.com
Authentication Domain in REN Server Cluster Configuration	mycompany.com
REN Server Cluster Root Path	/psren
REN Server Cluster URL	http://MachA:7180 Note. The cluster URL should not be a secure HTTP address if SSL is handled through a reverse proxy server.
REN Server Browser URL	https://MachRPS.mycompany.com:8443 Note. This is a secure HTTP address (HTTPS).

Note. If you use SSL between the browser and REN server, you must use a reverse proxy server or SSL accelerator.

Page Used to Configure REN Servers

Page Name	Object Name	Navigation	Usage
REN Server Configuration	REN_SERVER_DET_PG	PeopleTools, REN Server Configuration, REN Server Definition	Define a REN server.

Configuring REN Servers and SSL-Enabled REN Servers

Specify REN server configuration parameters based on your network topology and server arrangement.

Define the parameters for REN server configuration in three locations:

Authentication token domain, set during PeopleSoft Pure Internet Architecture installation or in web profile configuration.
Specify REN server configuration parameters in an application server domain using PSADMIN.
REN server parameters, including cluster and browser URLs, set in the PeopleTools REN Server and REN Cluster components.

Configuration parameters that are set in the REN Server and REN Cluster components override any defaults in PSADMIN.

Authentication Domain

The authentication domain tells PeopleSoft Pure Internet Architecture the internet domain name that browser clients use when accessing PeopleSoft applications across the internet. The token is required to comply with the same-origin security policy that is enforced by most browsers. The domain name that is specified in the REN Server Configuration page must be identical to the domain name that is specified as the authentication token domain during PeopleSoft Pure Internet Architecture installation.

If authentication domain is not set during PeopleSoft Pure Internet Architecture installation, define the authentication domain in web profile configuration to match the REN server configuration.

Note. You must specify the authentication token domain if you access the REN server and the PeopleSoft Pure Internet Architecture web server using different DNS names from the browser client (for example, if they are on different machines).

Configuring a REN Server and SSL-Enabled REN Server with PSADMIN

If necessary, you can specify parameters in the PSRENSRV section of PSADMIN application server domain configuration, as illustrated in the following example:

Specify parameters as described in the following table:

Parameter	Default	Description
log_severity_level	Warning	This is the logging level for the REN server. Select from one of the following log severity levels, from less to more logged data: Error, Warning, Notice, Debug. Note. Do not use Debug in a production environment.
io_buffer_size	8192	This is the TCP buffer size in bytes that is used for serving content. Do not exceed a value of 65536. If the REN server is running on Microsoft Windows NT, change io_buffer_size to a minimum value of 56000.
default_http_port	7180	This is the REN server's HTTP port. The default value is 7180. The default_http_port parameter takes effect only when a REN server starts up for the first time and the database does not already contain configuration information for the REN server. Note. After the HTTP port number that is assigned to the REN server has been established in the database, the only way to change it is on the REN Server Definition page. Editing the port number in the psappsrv.cfg file does not overwrite the value that is stored in the database.
default_https_port	7143	This is the REN server's HTTPS port for SSL-enabled REN server. The default value is 7143. Note. The https port is used only when the REN server is SSL-enabled. The default_https_port parameter is configured in psappsrv.cfg and will be used when a SSL-enabled REN server starts up for the first time. Note. To change the default https port, use the REN Server Definition page. Changing the SSL Port requires the reboot of the REN Server.
default_auth_token	example.com	This is the fully qualified domain name of the application server. This value should match the value of the web server's authentication domain. The default_auth_token parameter takes effect only when a REN server starts up for the first time and the database does not already contain configuration information for the REN server. When configuring the REN server parameters through PSADMIN, do not place a period or dot (.) before the default_auth_token value. For example, the parameter should read default_auth_token=example.com

After specifying REN server configuration parameters, be sure to specify Y (Yes) when asked if you want event notification configured and MCF server configured. Boot this domain from the Domain Administration menu.

Note. Use PeopleSoft Pure Internet Architecture REN server definition and configuration pages to modify configuration parameters whenever possible. REN server configuration parameters that you make using PSADMIN are written to the psappsrv.cfg file in the application server directory. REN server configuration values that are found in the database override any values that are found in psappsrv.cfg.

Use static IP addresses for your web servers. If you use dynamic IP addresses (DHCP), ensure that the domain name server (DNS) can map fully qualified domain names to the dynamic IP addresses.

If you are using Microsoft Internet Explorer internet security zones, include both the web server and REN server addresses in the same security zone; alternatively, exclude both addresses from security zones.

Socket Binding

The REN server listens on the port that is defined in the REN Server Definition page, which is by default 7180. However, the host name to which the REN server binds is determined by information in the psrenconfig.txt file for each application server domain. If the host machine contains multiple network interface cards (NICs), then the REN server binds by default to only one NIC, which is given by uname() on Unix, or GetComputerName() on Microsoft Windows.

To bind a REN server to a specific NIC, manually edit psrenconfig.txt for the appropriate application server domain, changing both set address and set hostname to the IP address and locally-known host name of the NIC. For example:

set address 192.168.10.1 set hostname hostsrv.example.com

Note. If you enter an invalid IP address in the psreconfig.txt file, the REN server may not start correctly. Check the REN server log for error messages that identify the issue.

Configuring TCP_NODELAY

The parameter, TCP_NODELAY in psrenconfig.txt controls whether or not to disable the TCP Nagle algorithm on the TCP packets sent by the REN server. There are two instances of TCP_NODELAY in psrenconfig.txt. TCP_NODELAY in the nssock section is used by non-SSL REN servers, and the instance in the nsopenssl section is used by SSL-enabled REN servers. The TCP Nagle algorithm is generally enabled by default and inserts a short delay before sending small TCP packets. This helps in preventing network overload.

If TCP_NODELAY is set to 0, the TCP algorithm behaves normally. This is the recommended configuration for most applications. However, for certain CTI applications, this parameter must be set to 1 to improve performance. If TCP_NODELAY is set to 1, the TCP Nagle algorithm will be disabled on operating system platforms that support disabling this feature.

Defining REN Servers

Access the REN Server Configuration page.

Application Server Domain

Enter the application server domain that is serving this REN server.

Host Machine

Enter the name of the host machine on which the specified application server domain runs.

This entry requires the host machine name, not its DNS name. However, the host machine name may need to be fully qualified, for example, machineA.example.com. On a Unix machine, determine the host name by running uname -a. On a Microsoft Windows machine, determine the host name by running hostname at a command prompt.

Port Number

Enter the HTTP port number on which this REN server is addressed.

Change the HTTP port value if multiple REN servers are running on the same host machine to avoid port conflicts.

SSL Only

Select to enable SSL on REN server.

Note. If the option is selected, you have to enter the SSL Port.

SSL Port

Enter the HTTPS port number on which this SSL-enabled REN server is addressed.

Process Instance

Reserved for future use.

Certificate Alias

Select a certificate alias to be used as a server certificate by the SSL-enabled REN server.

Note. The certificate alias is stored in the PSKEYDB, PSCERTDB, and PSREN records.

Client Authentication

Select to determine the level of client authentication.

Note. If the browser is configured for client authentication pop-up or the browser has more than one certificate configured, the SSL session ends if the user fails to provide the certificate within three heartbeats. To avoid such a session timeout, the user must either accept the client certificate within a heartbeat or increase the session timeout value in psrenconfig.txt.

The following table illustrates the client authentication values:

Parameter	Flag Value	Description
No Client Authentication	0	Client authentication is disabled.
On each Request-Verify only if Supplied	1	Client authentication is enabled The server sends a client certificate request to the client. Verification happens only if the certificate is provided. If the verification process fails, the TLS/SSL handshake is immediately terminated. If the client does not return any certificate, SSL communication still continues
On Each Request-Mandatory to Supply	3	Client authentication is enabled and mandates that the client provide the certificate. If the client does not return a certificate, the TLS/SSL handshake is immediately terminated with a handshake failure' alert. If the client returns a certificate, it is verified. The communication fails if the verification fails.
At Initial handshake Only-Verify only if Supplied	5	Client authentication is enabled and requests a client certificate on the initial TLS/SSL handshake only. Verification happens only if the certificate is provided. If the client does not provide any certificate, SSL communication still continues. If verification fails, the TLS/SSL handshake is immediately terminated.
At Initial handshake Only-Mandatory to Supply	7	Client authentication is enabled and mandates that the client provide the certificate only in initial TLS/SSL handshake.

Configuring REN Server and SSL-Enabled REN Server Clusters

A cluster is typically a collection of REN servers among which the session information is replicated. One cannot add both SSL and non-SSL servers in a single cluster.

To configure REN server clusters, use the REN Cluster (REN_CLUSTER_CMP) component.

This section discusses how to:

Cluster REN servers and SSL-enabled REN servers.
Specify REN server ownership.
Specify REN server cluster members.

REN server clusters address failover and scalability.

Pages Used to Configure REN Server and SSL-Enabled REN Server Clusters

Page Name	Object Name	Navigation	Usage
REN Server Cluster	REN_CLUSTER_PG	PeopleTools, REN Server Configuration, REN Server Cluster, REN Server Cluster	Define a REN server cluster.
REN Server Cluster Owner	REN_OWNER_PG	PeopleTools, REN Server Configuration, REN Server Cluster, REN Server Cluster Owner	Define the ownership of the REN server cluster.
REN Server Cluster Members	REN_CLUST_RSERV_PG	PeopleTools, REN Server Configuration, REN Server Cluster, REN Server Cluster Members	Define the REN server cluster's member REN servers.

Clustering REN Servers and SSL-Enabled REN Servers

A REN server serves requests only if it is a part of the cluster. If the REN server is SSL-enabled:

All the member REN servers must be SSL–enabled REN servers.
All the member REN servers must use the same server certificate.
Both REN Server Cluster URL and REN Server Browser URL must start with HTTPS and use the HTTPS port.

Note. When the administrator changes the REN server to be in SSL mode, he or she must also ensure that the REN server is a member of SSL clusters only. In any given REN cluster, all REN servers that are members must be either SSL–only servers or non–SSL servers. For SSL-enabled REN servers, use SSL-enabled PIA.

Access the REN Server Cluster page.

By default, if you start a REN server from PSADMIN without configuring a REN server cluster, a cluster is created with a cluster ID RENCLSTR_000n

State Flag	Select Active or Inactive. This field determines whether the cluster can receive new client requests. For scalability, configure multiple REN server clusters with the same ownership and set them to active status. Then the reporting window and customer chat applications will direct new client requests to a randomly chosen active REN server cluster. If all clusters are inactive, the client receives an error message. If the cluster supports MCF servers, current chat sessions continue even after a cluster is inactive. But the MCF system does not route any additional requests to an inactive cluster. Inactivate a cluster before deleting the cluster, or before removing a member REN server from the cluster. You can inactivate a REN server cluster without deleting the cluster.
REN Server Cluster Root Path	The default REN server cluster root path is /psren. Change this as required so that multiple REN server clusters are addressable through a single reverse proxy server. Changes to the root path should also be reflected in the URL mapping of any reverse proxy server.
REN Server Cluster URL	The REN server cluster URL is the address that is used to reach the REN server cluster internally. This is the URL that is used by internal processes. If the MCF cluster is served by a REN server cluster, the cluster URL is that of the switch or load balancer in front of the clustered REN servers. The cluster URL must be unique for each cluster. No two clusters can address the same cluster URL. Specify the cluster URL in the form <http://<DNS_machine_ name>:<port>, where: <DNS_machine_name> is the server machine name that is recognized by your DNS. <port> is the REN server port number; the default value is 7180. This port number is the REN server port number or the port number of a proxy server, load balancer, or other front end. The protocol must be HTTP if the REN server is non-SSL; for an SSL-enabled REN server, the protocol must be HTTPS.
Buffer Test	Click Buffer Test to initiate a test of the REN servers’ ability to break up and send a large file using multiple internal buffers. The buffer test bypasses REN server security, and does not depend on specified domain names (authentication domain), so you can use it to verify that the REN server is running on the network.
REN Server Browser URL	The REN server browser URL is the address that is used by external clients and by agent chat to reach the application that is served by this REN server cluster. The browser URL may be different from the cluster URL, which should not have to go through any firewall, reverse proxy server, or other outward-facing security barrier. If the REN server is reached through a load balancer, switch, or reverse proxy server, specify the fully qualified URL of that device as accessed from the user’s browser. The URL must be the address of the gateway machine (proxy server, load balancer, or SSL accelerator). Specify the address in the form http: or https://<DNS_machine_ name>.<domain_name>:<port>, where: <DNS_machine_name> is the server machine name that is recognized by your DNS. <domain_name> is the fully qualified domain name that is recognized by your DNS. <port> is the REN server port number; the default value is 7180. This port number is the REN server port number or the port number of a proxy server, load balancer, or other front end. Note. If the REN server is SSL-enabled, the browser URL must be HTTPS.
Ping Test	Click Ping Test to initiate a test of the REN server that is specified in the browser URL fields. Failure may indicate that a URL or authentication domain is incorrectly specified, the REN server is not running, or single sign-in is not implemented.
Authentication Domain	Enter the authentication domain. This must be the same as the authentication domain that is specified in the PeopleSoft Pure Internet Architecture installation or in the web profile configuration.

Specifying REN Server Ownership

Access the REN Server Cluster Owner page.

REN Server Cluster Owner

Select the owner of this REN server cluster from the drop-down list box. Choose from the following values:

All

MCF

Optimization

Reporting

Specifying an owner for a REN server cluster limits client access to that cluster. This is useful to ensure performance under load.

Specifying an owner for a REN server cluster also supports security. For example, an MCF cluster can be created only on a REN server cluster that is owned by MCF or ALL.

Specifying REN Server Cluster Members

Access the REN Server Cluster Members page

REN Server ID

Select a REN server from the drop-down list box.

Each REN server can belong to only one REN server cluster.

Configuring a Reverse Proxy Server with a REN Server

This section provides an overview of reverse proxy server (RPS) configuration and provides examples.

Understanding RPS Configuration

Production PeopleSoft installations may configure the REN server behind an RPS. The RPS isolates the REN server and other web servers from the open internet, provides SSL session handling, and presents a single-server origin to outside clients. PeopleSoft customers may put REN servers and PeopleSoft Pure Internet Architecture web servers behind one RPS, or just REN servers.

This example presents one possible configuration for a REN server running on one host machine, and installs an RPS to run on a second host machine, using BEA WebLogic 8.1. The RPS redirects clients to both a REN server and to the PeopleSoft Pure Internet Architecture web server.

These examples assume that:

You have installed PeopleTools 8.48 on both host machines.
You have configured a web server using the default parameters on the first host machine.
You have configured a REN server using the default parameters on the first host machine.

Example: Configuring a WebLogic 8.1 RPS for a REN Server on Another Host Machine

To configure an RPS for a REN server on another host machine:

Install a new web server domain on the second machine.

Name the domain rps.

Configure the following values:
- AppServer Name: <application_server_machine_name>
- JSL Port: 9999
  
  The RPS will not make Jolt connections.
- HTTP Port: 8080
- HTTPS Port: 8443
Start the new web server.

Navigate to <PS_HOME>\webserv\rps, and run startPIA.cmd.
Sign in to the WebLogic Server Administrative Console for the rps web server.

Access the WebLogic Server Administrative Console at http://<webserver>:<port>/console (for example, http://localhost:8080/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.
Using the console's hierarchical navigation, navigate to rps, Deployments, Applications, PeopleSoft. Select the Targets tab.

Clear the PIA option.

Click Apply.
Using the console's hierarchical navigation, navigate to rps, Deployments, Web Application Modules, HttpProxyServlet. Select the Targets tab. Select the PIA option. Click Apply.
For better web server performance, navigate to rps, Servers, PIA. Select the Protocols tab, select the HTTP tab, and set both Duration and HTTPS Durationto 120 secs.
Stop the rps web server.

Navigate to <PS_HOME>\webserv\rps and run stopPIA.cmd.

Configure RPS parameters for the rps server.

Locate the file web.xml at PS_HOME/webserv/rps/applications/HttpProxyServlet/WEB-INF.

Edit web.xml in a text editor, changing the WebLogic port and WebLogic host from 8080 to 80 (the value 8080 is a default value that is derived during installation of the domain rps). For example:

<init-param>
	<param-name>WebLogicPort</param-name>
	<param-value>80</param-value>
	<description>HTTP listen port of WebLogic PIA/PORTAL server.</description>
</init-param>

To specify the associated REN server, (which is on another machine), edit web.xml, changing the REN server host machine, port, and root URL from their default RPS values. For example:

<init-param>
	<param-name>WebLogicHost</param-name>
	<param-value>MACHINE_2</param-value>
	<description>Hostname of REN server.</description>
</init-param>
<init-param>
	<param-name>WebLogicPort</param-name>
	<param-value>7180</param-value>
	<description>Listen port of REN server.</description>
</init-param>

Another example is:

<servlet-mapping>
	<servlet-name>RENHttpProxyServlet</servlet-name>
	<url-pattern>/psren/*</url-pattern>
</servlet-mapping>

Reboot the RPS web server.

Navigate to <PS_HOME>\webserv\rps, and run startPIA.cmd.
(Optional) Configure and enable SSL on the RPS machine.

Note. When using Apache 1.3.x or 2.0.x RPS, you must configure the kn_response_flush_override and the flush_rps_buffer_size_for_knjs parameters in the psrenconfig.txt file. If you are using Apache 1.3.x, set both of these parameters to 4096. If you are using Apache 2.0.x, set both parameters to 8192. Apache needs both parameters present with the same buffer size. The kn_response_flush_override parameter flushes a message, while the flush_rps_buffer_size_for_knjs parameter flushes the stay-alive.

Example: Configuring Oracle Application Server (OAS) to Proxy for a REN Server

If your site uses Oracle Application Server (OAS) as the PIA/portal web server, then special proxy configuration is required to work with REN server. OAS automatically deploys the Oracle Http Server (OHS), an Apache-based reverse proxy server. OHS is installed to proxy requests to the PIA Web Application.

To proxy for RenServer, find and edit the httpd.conf configuration file (typically at OAS_HOME\Apache\Apache\conf). Make the following modifications to the file:

Move the line LoadModule proxy_module modules/ApacheProxyModule.dll to the bottom of the file.
Comment out the line AddModule mod_proxy.c.

Add the following five lines after LoadModule proxy_module:

<IfModule mod_proxy.c> 
  ProxyRequests Off 
  ProxyPass /psren http://machine:7180/psren 
  ProxyPassReverse /psren http://machine:7180/psren 
</IfModule>

Reboot OAS and OHS.

Application Server Domain	Enter the application server domain that is serving this REN server.
Host Machine	Enter the name of the host machine on which the specified application server domain runs. This entry requires the host machine name, not its DNS name. However, the host machine name may need to be fully qualified, for example, machineA.example.com. On a Unix machine, determine the host name by running uname -a. On a Microsoft Windows machine, determine the host name by running hostname at a command prompt.
Port Number	Enter the HTTP port number on which this REN server is addressed. Change the HTTP port value if multiple REN servers are running on the same host machine to avoid port conflicts.
SSL Only	Select to enable SSL on REN server. Note. If the option is selected, you have to enter the SSL Port.
SSL Port	Enter the HTTPS port number on which this SSL-enabled REN server is addressed.
Process Instance	Reserved for future use.
Certificate Alias	Select a certificate alias to be used as a server certificate by the SSL-enabled REN server. Note. The certificate alias is stored in the PSKEYDB, PSCERTDB, and PSREN records.
Client Authentication	Select to determine the level of client authentication. Note. If the browser is configured for client authentication pop-up or the browser has more than one certificate configured, the SSL session ends if the user fails to provide the certificate within three heartbeats. To avoid such a session timeout, the user must either accept the client certificate within a heartbeat or increase the session timeout value in psrenconfig.txt.