4 Installing and Configuring WebSphere for Oracle Real-Time Decisions

This chapter describes how to install and configure Oracle RTD on WebSphere.

The process of installing and configuring WebSphere for Oracle RTD consists of four major stages:

• WebSphere installation.

  This consists of installing everything that is required for a basic WebSphere cluster, including the HTTP server (software load balancer) and all WebSphere Fixpacks.

• WebSphere profile creation.

  This consists of creating a profile containing a deployment manager and a managed node.

  A subsequent step, after the initial installation, describes how to expand this setup to include an additional managed node.

• WebSphere configuration.

  After the profile is created, you must configure certain parts of that profile to make it ready for Oracle RTD deployment. This includes setting server properties, JDBC elements and configuring HTTP plugins.

• Oracle RTD deployment and post-deployment steps.

This chapter contains the following sections:

• Section 4.1, "Installing WebSphere Application Server and Associated Components"

• Section 4.2, "Configuring the Web Server Plug-in"

• Section 4.3, "Starting WebSphere and Launching the Administrative Console"

• Section 4.4, "Completing Web Server Setup"

• Section 4.5, "Configuring WebSphere for Oracle RTD"

• Section 4.6, "Deploying RTD.ear to the Cluster"

• Section 4.7, "Mapping Oracle RTD Roles to WebSphere Groups"

• Section 4.8, "Creating Custom Roles and Assigning Permissions to Custom Roles (Optional)"

• Section 4.9, "Creating startJConsole Batch Files"

• Section 4.10, "Extending the Cluster"

• Section 4.11, "Configuring New Data Sources"

• Section 4.12, "Configuring SSL for Real-Time Decision Server (Recommended)"

4.1 Installing WebSphere Application Server and Associated Components

This section describes how to install WebSphere Application Server and associated components:

• IBM Installation Manager

• WebSphere Application Server Network Deployment

• IBM HTTP Server

• Web Server Plug-ins for WebSphere Application Server

• WebSphere Customization Toolbox

Preparing /Prerequisites

The operating-system dependent installation source files consist of several sets of zip files, for both the base source files and associated Fixpacks:

• IBM Installation Manager

• WebSphere 8 Application Server Network Deployment

• WebSphere 8 Supplements (including HTTP Server and Plug-in)

• WebSphere 8 Fixpacks for the different components:

  • Fixpacks for WebSphere Application Server Network Deployment

  • Fixpacks for WebSphere Application Server Supplements

  • Fixpacks for WebSphere Customization Toolbox

  Note:

  There may also be other Fixpacks for interim fixes as recommended by IBM for your WebSphere version.

Unzip the installation source files for the "base level" software components (and combine them when there are several zip files per software component) into temporary directories, using the following table as a guideline:

Table 4-1 IBM Base Level Software Components

Software Component	Suggested Temporary Directory
IBM Installation Manager	WAS8-InstallManager
WebSphere Application Server 8.0 Network Deployment	WAS8-Main
WebSphere Application Server 8.0 Supplements	WAS8-Supplements

Unzip the installation source files for the Fixpacks into temporary directories, using the following table as a guideline:

Note:

It is convenient to incorporate the latest fix pack level in the directory names. At the time of writing, the latest Fixpack level was 8.0.0.5.

Table 4-2 Fix Packs for Websphere Application Server 8

Latest Fix Packs for...	Suggested Temporary Directory
WebSphere Application Server Network Deployment	WASFP8005AppServerND
WebSphere Application Server Supplements	WASFP8005Supplements
WebSphere Customization Toolbox	WASFP8005CustomToolbox

To install the IBM Installation Manager

Run the install command (if you have the necessary administrative rights on your target machine) or userinst from the IBM Installation Manager temporary directory.

This installs IBM Installation Manager into the Installation Manager directory (with default lowest levels /IBM/InstallationManager/eclipse), from which you can install other IBM software components.

At the end of the installation process, click Restart Installation Manager to start the process of installing IBM WebSphere Application Server and supplementary software components.

To install the IBM WebSphere Application Server and Components

This process installs the following products:

• WebSphere Application Server Network Deployment

• IBM HTTP Server

• Web Server Plug-ins for WebSphere Application Server

• WebSphere Customization Toolbox

Installing WebSphere Application Server and Associated Components

1. If you have not already started the Installation Manager, launch it from the Installation Manager directory.

2. Click Install.

3. Click the Repositories link to start configuring the repositories for installing the WebSphere Application Server and the associated components.

4. For each of the software components in Table 4-1 except IBM Installation Manager and for each of the fix packs in Table 4-2, perform the following steps:

   1. Click Add Repository...

   2. Browse to the temporary directory for the software component or fixed pack.

   3. Select the repository.config file.

   The resultant display is similar to the following:

   
   

5. Click OK.

6. In the Install Packages screen, select the packages for the four components that you want to install.

   
   

   Note:

   The components required for the cluster and Oracle RTD are:

   • WebSphere Application Server Network Deployment

   • IBM HTTP Server (to act as the cluster load balancer)

   • Web Server Plug-in (to make HTTP Server and Application Server Network Deployment work together)

   • WebSphere Customization Toolbox (to create profiles and to configure the Web Server Plug-ins)

7. Click Next.

8. If you have previously unzipped and selected repositories for extra fixes, select those fixes, and click Next.

9. Read and then accept the License agreement. Click Next.

10. In the Shared Resources Directory field, click Browse and select the directory for shared resources. Click Next.

11. You can select each package and change its Installation Directory field. Oracle recommends that you install all components into the same base directory. Then click Next.

    Note:

    In this section and subsequent sections, it is assumed that all your components are installed under one base directory, which is referred to as WAS_HOME.

12. Select the translation that you wish to install, then click Next.

13. In the Features screen, expand the packages, then select and deselect the features for your particular system.

    For example, deselect the Customization Toolbox options for z/OS unless you require them.

    Oracle recommends that all the SDK and Java options are consistent, that is, all 32-bit or all 64-bit.

    Click Next.

14. When you are prompted for the IBM HTTP Server configuration parameters:

    1. Change the HTTP Port to 8080.

    2. On Windows machines, select whether to run IBM HTTP Server as a Windows service. If you select this option, you must also specify whether the service should start automatically or manually after a system reboot.

    3. Click Next.

15. Review your selections, then click Install.

    IBM Installation Manager installs the packages that you selected in step 6.

16. When the installation process completes successfully, you are prompted to start the profile management tool to create profiles.

    Select Profile Management Tool to create a profile and click Finish.

    The WebSphere Customization Toolbox appears.

Creating a Profile

Note:

If you do not create the profile during your installation session, you can launch WebSphere Customization Toolbox using the script pmt.sh or pmt.bat under WAS_HOME/ WebSphere/AppServer/bin/ProfileManagement.

1. In the WebSphere Customization Toolbox, click Create...

2. In the Environment Selection screen, select Cell (deployment manager and a federated application server). The Cell environment creates a deployment manager node, a regular managed node and one managed server on that node. The server that is created is called "server1", but will not be required, and will be manually deleted in a subsequent step. Click Next.

3. In the Profile Creation Options screen, select Advanced profile creation (this enables you to use default configuration settings or to specify your own values), then click Next.

4. In the Optional Application Deployment screen, select Deploy the administrative console (recommended), then click Next.

5. In the Profile Name and Location screen, you can change the names of the profiles and profile directory.

   
   

   Click Next.

6. In the Node, Host, and Cell Names screen, you can change the names of the nodes, host, and cell. You can leave the Host Name as the default DNS name, or you can set it to an IP address. If you select a DNS name, make sure that it is correctly listed and matched with an IP address in /etc/hosts.

   
   

   Click Next.

7. In the Administrative Security screen, select Enable administrative security, enter the security username and password for the Deployment Manager console, then click Next.

8. In the Security Certificate screens, enter certificate and keystore information as required, then click Next.

9. In the Port Values Assignment screens, you can change the default values as required for your system, then click Next.

   Note:

   The most significant ports for subsequent administrative tasks are:

   • WC_defaulthost - this is where the server listens for incoming HTTP traffic (when you create your own servers, this is the port used to check if they respond).

   • WC_adminhost_secure - this is where the administrative console is to be found.

   • SOAP_CONNECTOR_ADDRESS - this is where the deployment manager waits for commands (for example, it is used when you subsequently extend of the cluster).

10. On Windows machines, in the Windows Services Definition screen, you can select the following:

    • Whether to run the deployment manager as a Windows service

    • The logon option (local system account or specified user account)

    • The startup type (manual or automatic)

    Click Next.

11. As IBM HTTP Server has already been installed, you can now define a web server in the Web Server Definition screen.

    Specify names and port as appropriate for your system. For example:

    • Set Web server name = RTDWebServer

    • Set the Web server host name or IP address

    • Leave the Web server port value - that you set in step 14 - as 8080

    Click Next.

12. In the Web Server Definition (Part 2) screen, you can change the installation directory paths for the web server and web server plug-ins.

    Oracle recommends that you change the Web server plug-in installation directory path from its default location under HTTPServer to (under) WebSphere. By doing this, you will not have to subsequently edit the httpd.conf configuration file.

    
    

13. Review the information in the Profile Creation Summary screen, then click Create.

14. When the profile is created successfully, the Profile Creation Complete screen includes an option (Launch the First steps console) to enable you to open the Customization Toolbox and run the Web Server Plug-ins Configuration Tool.

    If you want to run the Web Server Plug-ins Configuration Tool at this point, select Launch the First steps console and click Finish, else simply click Finish.

4.2 Configuring the Web Server Plug-in

Configuring the Web Server plug-in is to enable IBM HTTP server to work together with WebSphere Application Server. You perform this configuration using the WebSphere Customization Toolbox.

Before you configure the Web Server plug-in, ensure that the following have been installed:

• WebSphere Application Server

• WebSphere Customization Toolbox

• IBM HTTP Server

• WebSphere Plug-ins

To configure the WebServer plug-in, complete the following steps:

1. Open the WebSphere Customization Toolbox.

   If you did not do this through the Launch the First steps console option of the Profile Management tool at the end of profile creation, you can launch the Customization Toolbox by running wct.sh or wct.bat from the directory WAS_HOME/C:/IBM/WebSphere/Toolbox/WCT.

   For example:

   • C:/IBM/WebSphere/Toolbox/WCT/wct.sh -perspective com.ibm.ws.wct.plugins.perspective

2. In the List of provided tools listbox, select Web Server Plug-ins Configuration Tool, click Launch Selected Tool, then click Add...

3. In the Add Web Server Plug-In screen, click Browse. Select the same plug-in location as the Web server plug-in installation directory path selected in step 12 of Section 4.1, "Installing WebSphere Application Server and Associated Components."

   Click Finish, then click Create...

4. On the Web Server Selection screen, select IBM HTTP Server V8, then click Next.

5. If the Web Server Architecture Selection screen appears, select the architecture (64-bit or 32-bit), then click Next.

6. In the Web Server Configuration File Selection screen, click Browse.

   Specify the httpd.conf file of the IBM HTTP Server that you installed (typically, under WAS_HOME/HTTPServer/conf). The configuration tool will make changes to this file and include the plug-in needed by WebSphere Application Server.

   In this screen, specify also the Web server port that you set in step 14 of Section 4.1, "Installing WebSphere Application Server and Associated Components."

7. In the IBM HTTP Server Administration Server screen, perform the following:

   • Select Setup IBM HTTP Server Administration Server (leave the default value)

   • Keep the suggested HTTP Administration Port

   • For the User ID and Password, specify the same information that you provided in step 7 of Section 4.1, "Installing WebSphere Application Server and Associated Components"

   • Click Next.

8. In the Setup IBM HTTP Server Administration Server screen, specify the system user id and group to enable IBM HTTP Server to be started on operating system startup.

   This user and group may already exist, or you can select the option to enable the WebSphere Customization Toolbox to create them.

   Click Next.

9. In the Web Server Definition Name screen, specify a unique web server definition name, for example, RTDWebServer. Click Next.

10. In the Configuration Scenario Selection screen, you can either select a local or remote configuration scenario. Note that if you select the remote option, you must perform some post-configuration steps.

    If you select (Remote) Host name or IP address of the application server, then enter the host name or IP address of the WebSphere Application Server that you are configuring the web server plug-in for, and click Next.

    If you select (Local) Installation of WebSphere Application Server, then select the Application Server directory (WAS_HOME/WebSphere/AppServer), and click Next. Select the application server profile that you created inSection 4.1, "Installing WebSphere Application Server and Associated Components," that is, the profile for the managed node, not the deployment manager profile. Then click Next.

11. Review the Configuration Summary, then click Configure. When the configuration has completed, click Finish.

12. If you selected to install a remote configuration, additional steps are needed to complete the configuration. These steps are listed in the configuration roadmap:

    1. Select the Launch the plug-in configuration roadmap checkbox.

    2. Click Finish.

13. Verify the plug-in configuration by examining httpd.conf (in the HTTPServer/conf directory).

    If the port for property Listen is not 8080, then change it to that value.

    If the port for property ServerName is not 8080, then change it to that value.

    At the end of the file, there should be a WebSpherePluginConfig entry with the location of the plugin-cfg.xml file. For example:

    WebSpherePluginConfig /IBM/WebSphere/Plugins/config/RTDWebServer/plugin-cfg.xml
    

After your Web Server plug-in has been configured and is ready, you can now use the WebSphere Administrative Console to configure the rest of the elements needed for Oracle RTD deployment.

4.3 Starting WebSphere and Launching the Administrative Console

Starting the deployment manager enables access to the WebSphere Administrative Console (also referred to as WebSphere Integrated Solutions Console).

Note:

In the following instructions, <dep_mgr_prof_name> and <app_srvr_prof_name> are the respective names of the Deployment Manager profile and Application server profile specified in step 5 of Section 4.1, "Installing WebSphere Application Server and Associated Components."

To start the deployment manager, run the startManager.sh or startManager.bat command, located in:

• WAS_HOME/WebSphere/AppServer/profiles/<dep_mgr_prof_name>/bin

To start the managed node, run the startNode.sh or startNode.bat command, located in:

• WAS_HOME/WebSphere/AppServer/profiles/<app_srvr_prof_name>/bin

4.3.1 Launching the WebSphere Administrative Console

Before you launch the WebSphere Administrative Console, you need to know the name of the WC_adminhost_secure port that appeared in step 9 of Section 4.1, "Installing WebSphere Application Server and Associated Components."

If you did not note this down, you can find this value in the properties file at:

• WAS_HOME/WebSphere/AppServer/profiles/<dep_mgr_prof_name>/properties/portdef.props

To launch the WebSphere Administrative Console, open a browser and enter a URL according to the following format:

• https://<server>:<wc_adminhost_secure_port>/ibm/console

For example:

• https://localhost:9045/ibm/console

4.3.2 Setting Synchronize Changes with Nodes

Synchronizing changes with nodes is not an essential step, but it makes it easier to perform the configuration steps. Otherwise you will have to synchronize nodes manually every time you save something.

Changes are saved into the deployment manager, which keeps a master copy. However, nodes are not aware of the changes until the changes are synchronized. Saving your changes does not mean they are automatically effected throughout the system, but turning this feature on ensures that synchronization commands are issued automatically, thereby keeping all your nodes in sync. After you have finished the major configuration steps needed initially for Oracle RTD, you may decide to turn this option off in your production environment.

Table 4-3 Synchronize Changes With Nodes

Access path	Object	Summary Description
System administration > Console Preferences	Synchronize changes with Nodes checkbox	Select this checkbox.

Note:

The WebSphere Customization Toolbox created a server called server1. This is not required for system topologies based on servers in a cluster, and can be safely deleted.

4.4 Completing Web Server Setup

After configuring the web server in the WebSphere Customization Toolbox, you complete the web server setup in WebSphere Administrative Console.

This section contains the following topics:

• Section 4.4.1, "Generating and Propagating Web Server Plug-in"

• Section 4.4.2, "Starting the Web Server"

4.4.1 Generating and Propagating Web Server Plug-in

To generate and propagate the web server plug-in, perform the following steps in the WebSphere Administrative Console:

Table 4-4 Web Server Plug-in Generation and Propagation

Access path	Object	Summary Description
Servers > Server Types > Web servers	RTDWebServer (or the web server name set up in step 11 of Section 4.1, "Installing WebSphere Application Server and Associated Components")	Select the checkbox for the web server. Click Generate Plug-in. Click Propagate Plug-in.

4.4.2 Starting the Web Server

Table 4-5 Starting the Web Server

Access path	Object	Summary Description
Servers > Server Types > Web servers	RTDWebServer (or the web server name set up in step 11 of Section 4.1, "Installing WebSphere Application Server and Associated Components")	Select the checkbox for the web server. Click Start.

4.5 Configuring WebSphere for Oracle RTD

This section contains the following topics:

• Section 4.5.1, "Setting Global Security Options"

• Section 4.5.2, "Creating Cluster and Server"

• Section 4.5.3, "Adding Virtual Host Port 8080"

• Section 4.5.4, "Setting Server Properties"

• Section 4.5.5, "Setting Server Administration Properties"

• Section 4.5.6, "Setting Server Session Management Properties"

• Section 4.5.7, "Configuring the JDBC Subsystem"

• Section 4.5.8, "Creating Groups and Users for Oracle RTD"

• Section 4.5.9, "Adding Virtual Host HTTP Address for Servers"

4.5.1 Setting Global Security Options

To set the correct global security options for Oracle RTD, perform the steps described (or confirm that the options are as described) in the following table:

Table 4-6 Creating the Cluster and Servers

Access path or Screen area	Targeted objects	Summary Description
Security > Global security	Settings for Administrative, Application, and Java 2 security	Select Enable administrative security. Select Enable application security. Do not select Use Java 2 to restrict application access to local resources.
Messages	Save link	Click Save.

Note:

In all the following WebSphere Integrated Solutions Console processes, as in the one described in the preceding table, click Save at the end of the process.

4.5.2 Creating Cluster and Server

To create the cluster and a single server, perform the following steps:

Table 4-7 Creating the Cluster and Servers

Access path or Screen area	Targeted objects	Summary Description
Servers > Clusters > WebSphere application server clusters > New	Cluster + one server (Suggested names, used throughout these sections): RTDCluster RTDServer1	Cluster name: Cluster name, for example, RTDCluster Member name: Server name, for example, RTDServer1 Select node: Application server node name created during profile creation (see step 6 of Section 4.1, "Installing WebSphere Application Server and Associated Components") Weight: Keep default value (2) Generate unique HTTP ports: Keep default value (selected) Select basis for first cluster member: Create the member using an application server template >(default) Next > Finish

4.5.3 Adding Virtual Host Port 8080

This operation is to define the host alias to be used by cluster servers, so that the Web Server plug-in can forward requests coming from IBM HTTP Server at port 8080.

To add virtual host port 8080, perform the step shown in the following table.

Table 4-8 Adding Virtual Host Port 8080

Access path or Screen area	Targeted objects	Summary Description
Environment > Virtual hosts	default_host	Host Aliases > New Host Name: * Port: 8080

4.5.4 Setting Server Properties

To set the server JVM properties, perform the following steps:

1. In the Integrated Solutions Console, expand Servers, then Server Types > WebSphere application servers.

2. Select the server, for example, RTDServer1.

3. Select Java and Process Management > Process Definition > Java Virtual Machine > Custom Properties > New.

   At this point, you must enter certain mandatory properties, and you can enter other optional properties.

   The mandatory properties are as follows:

   • rtd.instanceName - the name of the node, can be any name.

     The rtd.instanceName value can only contain alphanumerics, underscore, dash, and period.

   • rtd.HTTPHostAndPort - in format <host>:<port> - specifies the RPC host:port for this node.

     Set the port to value of WC_defaulthost displayed at the path Communications > Ports for this server.

     Important:

     Each node in an Oracle RTD cluster must be assigned these two JVM system properties, rtd.instanceName and rtd.HTTPHostAndPort, which must be unique to the node across the cluster.

   • org.eclipse.emf.ecore.EPackage.Registry.INSTANCE

     This must be set to com.sigmadynamics.emf.util.SDEMFRegistry.

Notes:

1. The system property, rtd.skipIlsTestLoad, can be used to bypass test loading of an Inline Service (ILS) during ILS deployment. If unspecified in the JVM start parameters, the property has a default value of false, which means ILS test loading will be performed during ILS deployment.

   If the logging level is set to DEBUG, a message similar to the following can be seen in the server log file:

   2013-12-10 11:04:10,142 DEBUG [DeployAppCommand] Performing test load on CrossSell with deployment state 5.
   

   Set the property to true, that is, add -Drtd.skipIlsTestLoad=true to bypass ILS test loading. This may be helpful in ILS redeployments from Decision Center in a clustered environment.

2. If your Inline Services have many external rules, add the following JVM parameter to improve the initial load time of these external rules:

   -Dsun.reflect.inflationThreshold=2147483647

4.5.5 Setting Server Administration Properties

To set the server administration properties, perform the steps in the following table.

Table 4-9 Setting Server Administration Properties

Access path or Screen area	Targeted objects	Summary Description
Servers > Server Types > WebSphere application servers	RTDServer1	Select the server, then add the server administration property in the next step.
Administration > Administration services > Custom properties > New	(See Summary Description)	Name=com.ibm.websphere.mbeans.disableRouting Value=<on>OracleRTD:*</on>

4.5.6 Setting Server Session Management Properties

To set the server session management properties, perform the following steps:

Table 4-10 Setting Server Session Management Properties

Access path or Screen area	Targeted objects	Summary Description
Servers > Server Types > WebSphere application servers	RTDServer1	Select the server, then add the server session management property in the next step.
Session Management > Custom properties > New	(See Summary Description)	Name=InvalidateOnUnauthorizedSessionRequestException Value=true

4.5.7 Configuring the JDBC Subsystem

Configuring the JDBC subsystem in WebSphere consists of the following three stages:

• Creating a JDBC provider - this specifies which database and database driver to use

• Creating a J2C Authentication Alias - this specifies how to login to your database

• Creating a JDBC data source - this enables Oracle RTD to find and access the database

This section contains the following topics:

• Considerations and Prerequisite

• Creating JDBC Provider

• Creating J2C Authentication Alias

• Creating Data Source

• Restarting the Node

• Testing Data Source Connection

4.5.7.1 Considerations and Prerequisite

For JDBC, the concept of scope is important. All JDBC elements set up for Oracle RTD should be defined in cluster scope, which localizes them to the cluster, and hides them from other software components that you may install or may have installed outside of the cluster.

Important:

As a prerequisite, you must perform the instructions in RTD_HOME\lib\jdbc\readme.txt to download and install the JDBC driver ojdbc6.jar.

The directory into which to put the driver must be accessible to the WebSphere Application Server.

For example, create a directory oracleJDBC under WAS_HOME/Websphere/AppServer/ and place the .jar file there.

You can optionally create a cluster-scoped WebSphere variable, such as ORACLE_JDBC_DRIVER_PATH, to point to this directory.

In a subsequent setup step, you will need to specify this directory - either explicitly or using the WebSphere variable - in the Class path for the JDBC provider.

4.5.7.2 Creating JDBC Provider

To create a JDBC provider, perform the following steps:

Table 4-11 Creating JDBC Provider

Access path or Screen area	Targeted objects	Summary Description
Resources > JDBC > JDBC providers > New	JDBC provider	Scope: Select cluster scope Database type: Oracle Provider type: Oracle JDBC Driver Implementation type: Connection pool data source Name: Keep the default (Oracle JDBC Driver) Click Next. Class path: Specify the fully-qualified name for the ojdbc6.jar file in the directory in which you placed it. For example, if you previously created the cluster-scoped WebSphere variable ORACLE_JDBC_DRIVER_PATH, enter ${ORACLE_JDBC_DRIVER_PATH}/ojdc6.jar Next > Finish

4.5.7.3 Creating J2C Authentication Alias

To create a J2C authentication alias, perform the following steps:

Note:

Unless you must have compatibility with earlier releases, you do not need to select the option Prefix new alias names with the node name of the cell.

Table 4-12 Creating J2C Authentication Alias

Access path or Screen area	Targeted objects	Summary Description
Security > Global security > Java Authentication and Authorization Service > J2C authentication data > New	J2C authentication alias	Enter the Alias name (suggested name RTDDS_Auth). Enter UserId and Password, for the database runtime user.

4.5.7.4 Creating Data Source

To create the data source for the Oracle RTD database, perform the following steps:

Table 4-13 Creating Data Source

Access path or Screen area	Targeted objects	Summary Description
Resources > JDBC > Data sources > New	Data source for SDDS	Scope: Select cluster scope Data source name can be any name JNDI name must be SDDS Click Next. Select an existing JDBC provider: Select the JDBC provider that you created in Section 4.5.7.2, "Creating JDBC Provider." Click Next. URL: Enter the URL using the format: jdbc:oracle:thin:@{database_host}:{database_port}:{database_name} For example, jdbc:oracle:thin:@myhost:1521:orcl Data store helper class name: Oracle11g data store helper Click Next. Component-managed authentication alias: Select the alias that you created in Section 4.5.7.3, "Creating J2C Authentication Alias." Keep the default settings of None for Mapping-configuration alias and Container-manager authentication alias. Next > Finish.

4.5.7.5 Restarting the Node

Before you can use - or even test - your new data source, you have to restart the WebSphere managed node. You do not need to restart the Deployment Manager.

To restart the node, perform the following steps:

1. Stop the node from either from the console (System Administration -> Nodes) or by using the appropriate command file from the command line, using the following format:

   WAS_HOME/WebSphere/AppServer/profiles/<app_srvr_prof_name>/bin/<stopnode_cmd> -username <adminuser> -password <adminpass>

   where:

   • <app_srvr_prof_name> is the name of the Application server profile specified in step 5 of Section 4.1, "Installing WebSphere Application Server and Associated Components."

   • <stopnode_cmd> is either stopNode.sh for Linux or stopNode.bat for Windows

     of the Application server profile specified in step 5 of Section 4.1, "Installing WebSphere Application Server and Associated Components.".

   • <adminuser> and <adminpass> are administrative user name and password respectively.

2. Start the node by using the appropriate command file from the command line, using the following format (note that username and password are not required):

   WAS_HOME/WebSphere/AppServer/profiles/<app_srvr_prof_name>/bin/<startnode_cmd>

   where:

   • <app_srvr_prof_name> is the name of the Application server profile specified in step 5 of Section 4.1, "Installing WebSphere Application Server and Associated Components."

   • <startnode_cmd> is either startNode.sh for Linux or startNode.bat for Windows

4.5.7.6 Testing Data Source Connection

To test the data source connection, perform the following steps:

Table 4-14 Testing Data Source Connection

Access path or Screen area	Targeted objects	Summary Description
Resources > JDBC > Data sources	Data source for SDDS database	Select the data source, then Test connection.

4.5.8 Creating Groups and Users for Oracle RTD

This section consists of the following topics:

• Section 4.5.8.1, "Creating Groups"

• Section 4.5.8.2, "Creating Users for Oracle RTD"

Note:

After creating or modifying user groups and/or users you must restart the WebSphere managed node, as described in Section 4.5.7.5, "Restarting the Node".

4.5.8.1 Creating Groups

To create the groups for Oracle RTD and to make each of the groups a member of RTDUserGroup, perform the following steps:

Table 4-15 Creating Groups for Oracle RTD

Access path or Screen area	Targeted objects	Summary Description
Users and Groups > Manage Groups > Create...	Standard Oracle RTD groups: RTDAdminGroup RTDDCEditorGroup RTDDCUserGroup RTDStudioDeployerGroup RTDStudioDownloaderGroup RTDBatchAdminGroup RTDChoiceEditorGroup RTDUserGroup	Create the groups Enter the group name, then Create, then Close. Repeat for all the listed standard Oracle RTD groups.
Users and Groups > Manage Groups	(See Summary Description)	Add users to the groups For each group: Add Users, Search, select users to add, then Add, then Close
Users and Groups > Manage Groups	RTDUserGroup	Add the other standard Oracle RTD groups as members of RTDUserGroup For RTDUserGroup: Members tab> Add Groups > select the other standard Oracle RTD groups, then Close

4.5.8.2 Creating Users for Oracle RTD

To create users, perform the following step:

Table 4-16 Creating Users for Oracle RTD

Access path or Screen area	Targeted objects	Summary Description
Users and Groups > Manage Users > Create...	Users (including administrative user)	Enter the administrative user name (for example, rtdadmin) and password, then Create, then Close. Repeat for other users.

You can then assign users to one or more groups, for example:

• User rtduser to group RTDDCUserGroup

• User rtdadmin to group RTDAdminGroup

• User rtddesigner to groups RTDChoiceEditorGroup, RTDDCEditorGroup, RTDStudioDeployerGroup, RTDStudioDownloaderGroup

4.5.9 Adding Virtual Host HTTP Address for Servers

This process consists of getting HTTP addresses for each server, then creating an HTTP virtual port for each unique server port.

4.5.9.1 Getting HTTP Addresses For Each Server

To get HTTP addresses for each server, perform the following steps:

Table 4-17 Getting HTTP Addresses For Each Server

Access path or Screen area	Targeted objects	Summary Description
Servers > Server Types > WebSphere application servers	RTDServer1	Select the server, then Ports. Write down the WC_defaulthost for the server. This is used to connect with this server via HTTP.

4.5.9.2 Creating an HTTP Virtual Port For Each Unique Server Port

To create an HTTP virtual port for each unique server port, perform the following steps:

Table 4-18 Creating HTTP Virtual Ports for Each Server Port

Access path or Screen area	Targeted objects	Summary Description
Environment > Virtual hosts	Host Aliases for default_host for each server	Select default_host, then Host Aliases > New. Create, for each server: Host Name = * Port = the WC_defaulthost port noted from Section 4.5.9.1, "Getting HTTP Addresses For Each Server" Note that you do not have to add the same port a second time for different machines.

Note:

Oracle recommends that, at this point, you do not start the server or cluster. This is to enable you to make configuration changes during the deployment of Oracle RTD, and thereby avoid the need to restart the server or cluster after the deployment.

4.6 Deploying RTD.ear to the Cluster

This process consists of deploying RTD.ear to the cluster, then starting the OracleRTD application.

This section contains the following topics:

• Section 4.6.1, "Deploying RTD.ear to Cluster (Fast Path option)"

• Section 4.6.2, "Deploying RTD.ear to Cluster (Detailed option)"

• Section 4.6.3, "Changing Class Loader Priority"

• Section 4.6.4, "Starting the Server"

4.6.1 Deploying RTD.ear to Cluster (Fast Path option)

To deploy RTD.ear to the cluster using the Fast Path option, perform the following steps:

Table 4-19 WebLogic Installation Screens

Access path or Screen area	Targeted objects	Summary Description
Applications > New Application > New Enterprise Application	RTD.ear	Local file system or Remote file system, click Browse... and browse to RTD_HOME/package/RTD.ear. Fast path, then clickBrowse... and browse to RTD_HOME/package/RTD.ear. Application name: OracleRTD Deploy to the cluster (and if webserver set up, to the webserver).

Following the successful deployment of RTD.ear using the Fast Path option, you must perform three post-deployment processes, as highlighted in the General Properties list for OracleRTD:

The Class loading and update detection process is described in Section 4.6.3, "Changing Class Loader Priority."

The Security role to user/group mapping process is described in Section 4.7.2, "Mapping Roles to Groups After RTD.ear Deployment."

When you click Resource references, the Resource references screen that appears is the same as the Map resource references to resources screen that appears in step 6 of Section 4.6.2, "Deploying RTD.ear to Cluster (Detailed option)" - which describes Step 7 of the Detailed deployment process.

You must perform the same task as described in that section, that is, you must ensure that all resource references to SDDS are matched to the data source target resource with JNDI name SDDS.

4.6.2 Deploying RTD.ear to Cluster (Detailed option)

To deploy RTD.ear to the cluster using the Detailed option, perform the following steps:.

1. Select WebSphere enterprise applications, click Install, select Remote file system, then select RTD.ear from where you unpacked it.

   
   

2. Select Detailed.

   
   

3. Leave all defaults in deployment Step 1, ensuring that the Application name is OracleRTD.

   
   

4. In the Map modules to servers screen (Step 2), ensure that you target the deployment to your cluster and web server rtd_cluster and rtd_webserver1 in the example screenshot.

   
   

5. In deployment Steps 3 to 6, accept the defaults.

6. In the Map resource references to resources screen (Step 7), ensure that the deployer picks up the JDBC data source with JNDI name SDDS.

   
   

   If it does not, click Browse… and select SDDS for all Oracle RTD modules.

7. In the Map virtual hosts for Web modules screen, (Step 8), select default host.

8. In the Map context roots for Web modules screen, (Step 9), accept the defaults.

9. In the Map security roles to users or groups screen (Step 10) - you can perform a number of mapping operations or keep the default mappings.

   If you are not satisfied with default mapping between Oracle RTD Roles and Websphere user groups, you can change the mapping. For instructions, including all the options, see Section 4.7, "Mapping Oracle RTD Roles to WebSphere Groups".

10. Accept defaults for the rest of deployment steps, review the summary, finish the deployment and save the configuration.

4.6.3 Changing Class Loader Priority

Note:

You must perform this post-deployment step whether you deployed Oracle RTD using the Fast Path or the Detailed method.

To change the class loader priority, perform the following step:

1. For the OracleRTD application, select the property Class loading and update detection.

2. Select Classes loaded with local loader class first (parent last).

   
   

3. Click OK.

4.6.4 Starting the Server

At this point, the deployment manager and managed node are running, the server (rtd_server1) and webserver (rtd_webserver1) are stopped, and OracleRTD has been deployed:

Start the server, then check its log:

{WAS_HOME}/WebSphere/AppServer/profiles/rtd_node01/logs/rtd_server1/SystemOut.log.

There should be no exceptions or anything suspicious.

OracleRTD should have started automatically. If this has not happened, then start OracleRTD.

Now perform the verification tasks specified in Section 3.2, "Verification Tasks."

4.7 Mapping Oracle RTD Roles to WebSphere Groups

Standard Oracle RTD roles are defined in the RTD.ear file, but can be re-mapped to different WebSphere groups either during or after Oracle RTD deployment.

Table 4-20 displays the list of the standard Oracle RTD roles and the WebSphere groups (the creation of which is described in Section 4.5.8, "Creating Groups and Users for Oracle RTD") to which, by default, the roles must be mapped.

Table 4-20 Standard Oracle RTD Roles and Group Associations

Role	Group
RTDUsers	RTDUserGroup
RTDAdministrators	RTDAdminGroup
RTDDecisionCenterEditors	RTDDCEditorGroup
RTDDecisionCenterUsers	RTDDCUserGroup
RTDStudioDeployers	RTDStudioDeployerGroup
RTDStudioDownloaders	RTDStudioDownloaderGroup
RTDBatchAdministrators	RTDBatchAdminGroup
RTDChoiceEditors	RTDChoiceEditorGroup

Note:

Section 5.2, "Standard Oracle RTD Roles" and its component subsections describe how default permissions are already assigned to the standard Oracle RTD roles. These become active immediately after Oracle RTD is installed and started on WebSphere.

The process of mapping the roles to groups can either be performed during the deployment of RTD.ear, or as a post-deployment process.

During the deployment, this process occurs at Step 10 of the Detailed deployment, where the screen Map security roles to users or groups appears.

4.7.1 Changing of Roles to Groups Mapping

Description of the illustration rimage027.png

To map the standard Oracle RTD roles to the corresponding WebSphere groups, perform the following steps:

1. Select one of the roles (RTDUsers for example) and click Map Groups.

   
   

   The Search and Select Groups screen appears.

   
   

2. Click Search.

   This displays the list of Available user groups:

   
   

3. Select one group and move it to the Selected list.

   
   

   This group then appears in the Selected list.

   
   

4. Click OK.

   You have successfully mapped the standard Oracle RTD role RTDUsers to the WebSphere group RTDUserGroup.

   
   

5. Now repeat steps 1 to 4 for the rest of the roles until you have everything mapped.

   
   

6. If you have performed these steps during—and not after—the deployment of RTD.ear, you can click Next and complete the remaining deployment steps, that is, continue at step 10 of Section 4.6.2, "Deploying RTD.ear to Cluster (Detailed option)."

4.7.2 Mapping Roles to Groups After RTD.ear Deployment

If you chose to perform a Fast Path deployment of RTD.ear, then you can check mapping between the standard Oracle RTD roles to WebSphere groups after you have deployed Oracle RTD.

To start this procedure after the deployment of Oracle RTD:

1. Click OracleRTD in Enterprise Applications screen.

   
   

2. Click Security role to user/group mapping.

   This displays the same screen Map security roles to users or groups that appears at Step 10 (Map security roles to users or groups) of the Detailed deployment of Oracle RTD.

   Depending on what appears in that screen, you must follow one of the processes described in Section 4.7, "Mapping Oracle RTD Roles to WebSphere Groups."

   As described in that section, you must perform either the instructions in Section 4.7.1, "Changing of Roles to Groups Mapping" or Section 4.7.2, "Mapping Roles to Groups After RTD.ear Deployment."

4.8 Creating Custom Roles and Assigning Permissions to Custom Roles (Optional)

This section consists of the following topics:

• Section 4.8.1, "Creating Custom Roles"

• Section 4.8.2, "Assigning Permissions to Custom Roles"

4.8.1 Creating Custom Roles

To create custom roles for Oracle RTD, perform the following high-level steps:

1. Create groups in WebSphere.

   To create groups in WebSphere, follow the instructions in Section 4.5.8.1, "Creating Groups" using group names of your own choice.

2. Specify the roles in the deployment descriptor file application.xml, extracted from the Oracle file RTD.ear. See Section 4.8.1.1, "Specifying Roles in application.xml" for details.

3. Map the roles to the WebSphere groups in the Integrated Solutions Console. See Section 4.8.1.2, "Mapping Roles to Groups" for details.

Then, perform either of the following:

1. Uninstall, then redeploy Oracle RTD, as follows:

   1. Download the deployment descriptor file, application.xml back into RTD.ear.

   2. Redeploy Oracle RTD using the updated RTD.ear. Use Uninstall, then Install.

2. Redeploy Oracle RTD, using Update.

The rest of this section consists of the following topics:

• Section 4.8.1.1, "Specifying Roles in application.xml"

• Section 4.8.1.2, "Mapping Roles to Groups"

4.8.1.1 Specifying Roles in application.xml

To serve as an example, this section describes the addition of a new role, ILS2Users.

After extracting RTD.ear from RTD_HOME\package, edit the file META-INF\application.xml as follows:

1. Add an entry similar to the following:

   <security-role>
      <role-name>ILS2Users</role-name>
   </security-role>
   

2. Repeat step 1 for as many roles as you want to create.

3. Update RTD.ear with the new application.xml.

4.8.1.2 Mapping Roles to Groups

1. In the Integrated Solutions Console, expand Applications, then choose Enterprise Applications.

2. Click OracleRTD.

3. Under the Detail Properties section, click Security role to user/group mapping.

4. Check the role to be modified, then click Look up groups and change the mapping.

5. Repeat step 4 for as many roles as you need to map to groups.

4.8.2 Assigning Permissions to Custom Roles

As described in Section 5.4, "Assigning Permissions," assign Cluster permissions, Inline Service permissions, and Decision Center Perspective permissions to any custom roles.

4.9 Creating startJConsole Batch Files

This process consists of getting bootstrap addresses for each server, then creating the JConsole startup script for each server.

This section consists of the following topics:

• Section 4.9.1, "Getting Bootstrap Addresses For Each Server"

• Section 4.9.2, "Setting Up a JConsole Batch File for Windows"

• Section 4.9.3, "Setting Up a JConsole Batch File for Linux Systems"

4.9.1 Getting Bootstrap Addresses For Each Server

To get bootstrap addresses for each server, perform the following steps:

1. In the tree to the left, expand Servers and select Application Servers.

2. Click RTDServer1.

3. Under Communications, expand Ports.

4. Write down the BOOTSTRAP_ADDRESS for this server.

   This is used to connect with JConsole for server specific configuration.

4.9.2 Setting Up a JConsole Batch File for Windows

On Windows operating systems, for each server, create a batch file named startJConsole.bat and include a file similar to the following (you must specify your own values for WAS_BOOTSTRAP_PORT and file directories):

@echo off
@rem WAS_HOME should point to actual directory where WAS AS is installed
set WAS_HOME=C:\IBM\WebSphere\AppServer\
@rem PROFILE_HOME is where your local node profile is; deployment manager profile is a good place
set PROFILE_HOME=C:\IBM\WebSphere\AppServer\profiles\rtd_dmgr01
set WAS_HOST=localhost
set WAS_BOOTSTRAP_PORT=2812
set CP=%WAS_HOME%/runtimes/com.ibm.ws.admin.client_8.0.0.jar
set CP=%CP%:%WAS_HOME%/runtimes/com.ibm.ws.ejb.thinclient_8.0.0.jar
set CP=%CP%:%WAS_HOME%/runtimes/com.ibm.ws.orb_8.0.0.jar
set CP=%CP%:%WAS_HOME%/java/lib/tools.jar
set CP=%CP%:%WAS_HOME%/java/lib/jconsole.jar
set SSL_PROPS=-J-Dcom.ibm.CORBA.ConfigURL=file:%PROFILE_HOME%/properties/sas.client.props
set SSL_PROPS=%SSL_PROPS% -J-Dcom.ibm.SSL.ConfigURL=file:%PROFILE_HOME%/properties/ssl.client.props
%WAS_HOME%\java\bin\jconsole -J-Djava.class.path=%CP% %SSL_PROPS% service:jmx:iiop://%WAS_HOST%:%WAS_BOOTSTRAP_PORT%/jndi/JMXConnector

Tip:

Ensure that the JConsole command at the end of this file ("%WAS_HOME%\java\bin\jconsole...") is all on one line.

4.9.3 Setting Up a JConsole Batch File for Linux Systems

On Linux systems, for each server, create a shell script named startJConsole.sh similar to the following (you must specify your own values for WAS_BOOTSTRAP_PORT and file directories):

#!/bin/sh
# WAS_HOME should point to actual directory where WAS AS is installed
WAS_HOME=/opt/IBM/WebSphere/AppServer/
# PROFILE_HOME is where your local node profile is; deployment manager profile is a good place
PROFILE_HOME=/opt/IBM/WebSphere/AppServer/profiles/rtd_dmgr01
WAS_HOST=localhost
WAS_BOOTSTRAP_PORT=2809
CP=$WAS_HOME/runtimes/com.ibm.ws.admin.client_8.0.0.jar
CP=$CP:$WAS_HOME/runtimes/com.ibm.ws.ejb.thinclient_8.0.0.jar
CP=$CP:$WAS_HOME/runtimes/com.ibm.ws.orb_8.0.0.jar
CP=$CP:$WAS_HOME/java/lib/tools.jar
CP=$CP:$WAS_HOME/java/lib/jconsole.jar
SAS_PROPS=-J-Dcom.ibm.CORBA.ConfigURL=file:$PROFILE_HOME/properties/sas.client.props
SSL_PROPS=-J-Dcom.ibm.SSL.ConfigURL=file:$PROFILE_HOME/properties/ssl.client.props
$WAS_HOME/java/bin/jconsole -J-Djava.class.path=$CP $SAS_PROPS $SSL_PROPS service:jmx:iiop://$WAS_HOST:$WAS_BOOTSTRAP_PORT/jndi/JMXConnector

Tip:

Ensure that the JConsole command at the end of this file ($WAS_HOME/java/bin/jconsole...) is all on one line. Also, ensure the startJConsole.sh file has the appropriate execute permissions.

Note:

Oracle recommends that you create or edit the file startJConsole.sh directly on the Linux system.

If you first create or edit the file on a Windows system, and subsequently transfer it to a Linux system using ftp, then make sure that you use binary transfer node, not ascii.

4.10 Extending the Cluster

Extending the cluster to a second machine (or further) is similar to the initial installation and configuration. In summary, the steps required are the following:

• Install WebSphere Application Server Network Deployment on the second machine

• Create a profile with just a node, no servers

• Make the Deployment manager aware of new node

• Add the cluster member via WebSphere Administrative Console

This section contains the following topics:

• Section 4.10.1, "Preparing the Second Machine"

• Section 4.10.2, "Installing Installation Manager"

• Section 4.10.3, "Running Installation Manager"

• Section 4.10.4, "Running the Profile Management Tool"

• Section 4.10.5, "Adding New Node to Existing Cell"

• Section 4.10.6, "Creating Additional Server in the Cluster"

• Section 4.10.7, "Fixing Properties on the Additional Server"

4.10.1 Preparing the Second Machine

Copy all the WebSphere source files to the second machine, and unpack them into separate directories as on the first machine.

4.10.2 Installing Installation Manager

As on the first machine, install Installation Manager.

4.10.3 Running Installation Manager

When running Installation Manager, in the Install Packages screen, select only IBM WebSphere Application Server Network Deployment (and any interim fixes recommended by IBM).

4.10.4 Running the Profile Management Tool

1. Start the Profile Management Tool by running {WAS_HOME}/WebSphere/AppServer/bin/ProfileManagement/pmt.sh (or the equivalent .bat file on a Windows machine).

2. Create a new Custom profile (not a Cell profile, as on the first machine).

3. Select "Advanced profile creation", name the profile (for example, rtd_node2) and select its location (for example, /scratch/IBM/WebSphere/AppServer/profiles/rtd_node2).

4. For the Node and Host Names, name the new node (for example, rtd_cell_node02), and ensure that the Host Name is either the DNS name or the IP address of the second machine.

5. On the Federation screen, select Federate this node later.

6. Accept the defaults for SSL certificate generation and port assignments, then create the profile.

7. Exit the Profile Management Tool.

4.10.5 Adding New Node to Existing Cell

To add the new node to the existing cell on the first machine:

1. Check what SOAP port deployment manager is on:

   System administration > Deployment manager, then, under Additional Properties > Ports, look up the port for SOAP_CONNECTOR_ADDRESS.

2. Using this port and host name of machine 1, run the following command (or its Windows .bat equivalent):

   • WAS_HOME/bin/addNode.sh {host} {port} -username {user} -password {password}

   where {host} and {port} define the machine where the Deployment manager is listening, and {user} and {password} are administrative credentials, and WAS_HOME typically has a sub-directory path like .../IBM/WebSphere/AppServer.

   When this completes successfully and the node is federated, the cell is extended and includes the additional node, as displayed in the System administration > Nodes screen. Note that the Host Name for the new node displays the name (or IP Address) of the second machine.

3. Copy ojdbc6.jar driver to the new machine and fix the JDBC WebSphere path variable ORACLE_JDBC_DRIVER_PATH.

   Typically the directory path for ojdbc6.jar will be identical on both the source and target machines. When you add a node, ORACLE_JDBC_DRIVER_PATH is blank for the new node. So, after copying ojdbc6.jar to the new machine, edit ORACLE_JDBC_DRIVER_PATH there, specifying the correct path.
   
   

When working with WebSphere variables, make sure that you have selected the correct scope or select ”All scopes” and look at the scope column. There could be several ORACLE_JDBC_DRIVER_PATH variables in different scopes. Change the variable in the appropriate scope only.

4.10.6 Creating Additional Server in the Cluster

To extend the cluster, and ensure that the new server is located o the second node, perform the following steps:

1. Select Clusters > WebSphere application server clusters > rtd_cluster > (Cluster members) > New.

2. For Member name, enter rtd_server2, for Select node, select the new node (for example, rtd_cell_node02), then click Add Member.

   The new member appears in the list at the foot of the screen.

3. Click Next > Finish.

The cluster has been extended - see WebSphere application server clusters > rtd_cluster > (Cluster members).

Because OracleRTD is targeted to the cluster, OracleRTD is deployed on the second server automatically - it appears in WebSphere application server clusters > rtd_cluster > Cluster members > rtd_server2 > Installed applications.

4.10.7 Fixing Properties on the Additional Server

To fix the properties on the additional server, perform the following steps:

1. Enter or change the properties for the second server in the following screens:

   
   
   
   

   Note: only rtd.HTTPHostAndPort and rtd.instanceName have to change, the rest are the same.

2. Add the default host alias for the second node and make sure that the ports on the second machine match the default host aliases.

   
   

   If they are not, fix the Host aliases to use the actual ports that the server is using.

3. Now start rtd_server2.

   
   

4. Verify that Oracle RTD is running on the second machine, for example by running Decision Center.

   
   

5. Ensure that you generate and propagate Web Server plug-in:

   
   

6. Ensure that Oracle RTD is accessible via HTTP server port 8080 with requests routed to both cluster servers

4.11 Configuring New Data Sources

Configuring a new data source consists of the following steps:

• Creating J2C Authentication Alias - this specifies how to login to your database

• Creating JDBC Data Source - this enables Oracle RTD to find and access the database

Note:

It is possible that you may need an additional step to create a new JDBC provider, depending on user requirements, but this section assumes that you are reusing the existing JDBC provider you created in Section 4.5.7.2, "Creating JDBC Provider."

Testing the new J2C authentication alias and data source consists of the following steps:

• Restarting the Node

• Testing New Data Source Connection

4.11.1 Creating J2C Authentication Alias

To create a J2C authentication alias for the new data source, perform the following steps:

Note:

Unless you must have compatibility with earlier releases, you do not need to select the option Prefix new alias names with the node name of the cell.

Table 4-21 Creating J2C Authentication Alias

Access path or Screen area	Targeted objects	Summary Description
Security > Global security > Java Authentication and Authorization Service > J2C authentication data > New	J2C authentication alias	Enter the Alias name. Enter UserId and Password, for the database runtime user.

4.11.2 Creating JDBC Data Source

To create the new data source, perform the following steps:

Table 4-22 Creating Data Source

Access path or Screen area	Targeted objects	Summary Description
Resources > JDBC > Data sources > New	Data source for SDDS	Scope: Select cluster scope Data source name can be any name JNDI name can be any name (except SDDS) Click Next. Select an existing JDBC provider: Select the JDBC provider that you created in Section 4.5.7.2, "Creating JDBC Provider." Click Next. URL: Enter the URL using the format: jdbc:oracle:thin:@{database_host}:{database_port}:{database_name} For example, jdbc:oracle:thin:@myhost:1521:orcl Data store helper class name: Oracle11g data store helper Click Next. Component-managed authentication alias: Select the alias that you created in Section 4.11.1, "Creating J2C Authentication Alias." Keep the default settings of None for Mapping-configuration alias and Container-manager authentication alias. Next > Finish.

4.11.3 Restarting the Node

To test your new data source, you must restart the WebSphere managed node, as described in Section 4.5.7.5, "Restarting the Node." This node restart automatically activates the new J2C authentication alias.

4.11.4 Testing New Data Source Connection

To test the new data source connection, perform the following steps:

Table 4-23 Testing Data Source Connection

Access path or Screen area	Targeted objects	Summary Description
Resources > JDBC > Data sources	New data source	Select the data source, then, for Test Table, enter the name of an existing table in the database. Click Test connection.

4.12 Configuring SSL for Real-Time Decision Server (Recommended)

Follow the steps in this section to set up SSL for all client connections to Real-Time Decision Server. Before you begin, ensure that you followed the instructions in Section 2.5, "Using SSL with Oracle Real-Time Decisions" to change the default Oracle RTD keystore and truststore passwords. Also, ensure that WebSphere is started.

Note:

If you want to use your own keystore and truststore, you do not need to complete the instructions in Section 2.5.

To configure SSL for Real-Time Decision Server:

1. Access the Integrated Solutions Console at the URL http://websphere_host:port/ibm/console. At the login prompt, enter the administrator user name and password. On Windows, you can also access the Integrated Solutions Console through Start > Programs.

2. In the tree on the left, expand Security and choose SSL certificate and key management.

3. Under the Related Items heading, click Key stores and certificates.

4. Create the Oracle RTD keystore, as follows:

   1. Click New.

   2. For Name, enter OracleRTD_KeyStore.

   3. For Path, enter RTD_HOME/etc/ssl/sdserver.keystore. Alternatively, if you do not want to use the default Oracle RTD keystore, enter the path to your own keystore.

   4. For Password and Confirm password, enter the password for your keystore. If you are using the default Oracle RTD keystore, enter the password you created in Section 2.6.

   5. For Type, select JKS.

   6. Click OK.

5. Create the Oracle RTD truststore, as follows:

   1. On the Key stores and certificates page, click New.

   2. For Name, enter OracleRTD_TrustStore.

   3. For Path, enter RTD_HOME/etc/ssl/sdtrust.store. Alternatively, if you do not want to use the default Oracle RTD truststore, enter the path to your own truststore.

   4. For Password and Confirm password, enter the password for your truststore. If you are using the default Oracle RTD truststore, enter the password you created in Section 2.6.

   5. For Type, select JKS.

   6. Click OK.

6. Return to the SSL certificate and key management page and create an SSL configuration for Oracle RTD, as follows:

   1. Under the Related Items heading, click SSL configurations.

   2. Click New.

   3. For Name, enter OracleRTD_SSL.

   4. For Trust store name, select OracleRTD_TrustStore.

   5. For Keystore name, select OracleRTD_KeyStore.

   6. Click Get certificate aliases.

   7. Click OK.

7. Set the Transport Chain HTTPS port, as follows:

   1. In the tree on the left, expand Servers and choose Application servers.

   2. Click the name of the application server where you have installed Oracle RTD (for example, server1).

   3. Under the Container Settings heading, expand Web Container Settings and choose Web container transport chains.

   4. Click WCInboundDefaultSecure.

   5. Under the Transport Channels heading, click the name of the TCP inbound channel (for example, TCP inbound channel (TCP 4)).

   6. Under the Related Items heading, click Ports.

   7. Click WC_defaulthost_secure.

   8. Change the Port to 8443.

   9. Click OK, then click Save.

8. Set the Virtual Host HTTPS Port, as follows:

   1. In the tree on the left, expand Environment and choose Virtual Hosts.

   2. Click default_host.

   3. Under the Additional Properties heading, click Host Aliases.

   4. For port 9443, click *.

   5. Change the Port to 8443.

   6. Click OK.

9. Set the HTTPS port to use the Oracle RTD SSL configuration you created in Step 6, as follows:

   1. In the tree on the left, expand Security and choose SSL certificate and key management.

   2. Under the Configuration settings heading, click Manage endpoint security configurations.

   3. Under the Local Topology heading, expand Inbound > cell_name > nodes > node_name > servers > server_name, then click WC_defaulthost_secure.

   4. Under the heading Specific SSL configuration for this endpoint, select Override inherited values, then select OracleRTD_SSL for SSL configuration.

   5. Click Update certificate alias list.

   6. For Certificate alias in key store, select your keystore password.

   7. Click Apply.

10. Click Save.

11. Restart WebSphere.

    Note:

    For a truly secure environment, you should also disable the regular HTTP port to ensure that all client connections are routed through the SSL port. To do this, perform the following step:

    • Disable the HTTP port for your Web server using application server tools. Refer to the WebSphere documentation for more information.

12. If you are using your own keystore and truststore, perform the following additional steps to enable SSL for Decision Studio. You do not need to perform these steps if you are using the default Oracle RTD keystore and truststore.

    1. Open RTD_HOME\eclipse\eclipse.ini for editing.

    2. Locate the following line:

       -Djava.net.ssl.trustStore="..\etc\ssl\sdtrust.store"
       

    3. Replace ..\etc\ssl\sdtruststore with the full path to your truststore file.

    4. Save and close the file.

    5. Open RTD_HOME\scripts\sdexec.cmd for editing.

    6. Locate the line beginning with %SD_START%, near the bottom of the file. Near the end of the line, locate the following string:

       -Djavax.net.ssl.trustStore="%SD_ROOT%\etc\ssl\sdtrust.store"
       

    7. Replace %SD_ROOT%\etc\ssl\sdtruststore with the full path to your truststore file.

    8. Save and close the file.

4.12.1 Testing the SSL Configuration

To verify that the SSL port is functioning properly, go to Decision Center at the URL https://server_name:ssl_port/ui. If the SSL port is functioning property, your browser will display the "Welcome to Decision Center" login screen.

You may get a message from your Web browser, similar to ”Do you want to accept this certificate?” This message is generated because the browser does not know about the self-signed certificate that was shipped with the default Oracle RTD keystore. This self-signed certificate is suitable for development and test environments, but it is not recommended for production environments.

For production environments, Oracle recommends the self-signed certificate be replaced with a certificate from a trusted certificate authority (CA), like Verisign/Thawte, by submitting to the CA a certificate request generated by Sun's keytool utility.

For instructions on generating a certificate request, and for importing the certificate from the CA into the keystore, go to one of the following URLs:

For Linux and Solaris:

http://docs.oracle.com/javase/7/docs/technotes/tools/solaris/keytool.html

For Windows:

http://docs.oracle.com/javase/7/docs/technotes/tools/windows/keytool.html