Oracle® Real-Time Decisions Installation and Administration Guide Version 3.0.0.1 Part Number E13856-02 |
|
|
View PDF |
Oracle RTD may be deployed into a cluster to achieve any of the following objectives:
Increased processing power
Increased memory, to accommodate more concurrent sessions
Increased availability in the event of hardware failures
You can deploy Oracle RTD to several application server types. This chapter describes in general how to deploy Oracle RTD into a clustered J2EE environment. It presents an outline of the concepts and processes for implementors who are familiar with deploying J2EE applications on application servers.
Note:
This chapter does not describe how to set up the HTTP server that will be the load balancing front-end to the cluster. The HTTP server provides the publicly accessible URLs to the Oracle RTD services, but there are no special considerations about the Oracle RTD installation in that regard.For convenience, the following abbreviations are used in this chapter to describe the different Oracle RTD services:
DS - Decision Service
LS - Learning Service
DC - Decision Center
This chapter contains the following topics:
Section 13.4, "Creating Server Instances for Oracle RTD Type 3 Clusters"
Section 13.5, "Deploying Oracle RTD into an Oracle RTD Type 3 Cluster"
Oracle RTD is deployed through a J2EE application archive file, RTD.ear
, which contains multiple web applications corresponding to Decision Service (DS), Learning Service (LS), and Decision Center (DC). In a production environment, DS is typically deployed into separate cluster nodes (Oracle RTD instances) from DC and LS to prevent the activities of DC or LS from impacting the DS response times.
Two combinations of Oracle RTD services are common:
Oracle RTD Cluster Type 1
DS, DC, and LS all deployed into every Oracle RTD instance
Oracle RTD Cluster Type 3
DS deployed by itself, DC and LS deployed together
Two further cluster combinations are possible, but they are less commonly used:
Oracle RTD Cluster Type 2
DS and DC deployed together in some Oracle RTD instances
LS deployed by itself in other instances.
Oracle RTD Cluster Type 4
DS, DC, and LS each deployed into separate Oracle RTD instances
From a clustering perspective, it is important to note that Oracle RTD is delivered as a single J2EE ear
file. In some application server types, the granularity of deployment is the ear
file, and not the contained Web Application Archives (war
files). In these cases, all web applications within the enterprise application get deployed together. This chapter describes how to work around this packaging issue in order to deploy individual services of Oracle RTD into separate cluster nodes.
This chapter also describes several configuration parameters that are required when deploying Oracle RTD into a cluster. These parameters can be ignored in non-clustered environments.
Certain cluster-specific behaviors are also described, such as the role of the Oracle RTD cluster coordinator in managing cluster singletons. The cluster coordinator, for example, ensures that Learning Service runs on precisely one Oracle RTD instance at a time, restarting it on another instance should the first one fail.
The section describes both general terms and terms that have a particular meaning and usage for Oracle RTD clustering.
Application Server, Server Instance, or AS Instance
In this chapter, these three terms are equivalent to a Java Virtual Machine on which a J2EE application, such as Oracle RTD, may be deployed. Multiple AS instances may reside on the same host machine.
Note:
This definition of an AS instance is different from the definition described by Oracle Application Server (OAS). In OAS, an OAS instance can have multiple JVMs, a situation that is not supported by Oracle RTD.Oracle RTD Instance
This is an AS instance onto which the Oracle RTD application has been deployed.
Oracle RTD Cluster and J2EE Cluster
There is an important distinction between these two terms. For details, see Section 13.2.1, "Distinguishing Oracle RTD Clusters from J2EE Clusters."
Oracle RTD Cluster Coordinator
One Oracle RTD instance, the first one to announce its presence, is designated at runtime to be the Oracle RTD cluster coordinator. The coordinator monitors cluster singletons (for example, Learning Service), to ensure that precisely one deployed singleton is running at a time.
You can tell which is the current coordinator by searching the server.log
file of each Oracle RTD instance. Search backwards from the end of the file for the string "CLUSTER COORDINATOR."
It is possible for an Oracle RTD cluster to temporarily have more than one cluster coordinator, as in the case of a temporary network partitioning due to network communication failures or timeouts. Within a minute or so of the network coming back together, the multiple coordinators should relinquish their empires to a single coordinator.
Oracle RTD Home
This is the directory into which Oracle RTD was installed. It contains not only RTD.ear
(the J2EE application archive), but also sample code and required libraries.
A typical value for Oracle RTD Home on a Microsoft Windows computer is C:\OracleBI\RTD
. In this chapter, Oracle RTD Home is also referred to as RTD_HOME.
Oracle RTD Runtime Home
This is the directory in which the application server runs Oracle RTD. Although its location is application server type-specific, generally it will have the same structure as an expanded version of RTD.ear
.
In this chapter, references to Oracle RTD Runtime Home appear as RTD_RUNTIME_HOME.
The following list shows some application server specific generic names and typical examples of RTD_RUNTIME_HOME:
Oracle AS 3.3 generic names
ORACLE_HOME
\j2ee\
OC4J_INSTANCE_NAME\applications\
APP_NAME
Where:
ORACLE_HOME = C:\oracle\product\as-33
OC4J_INSTANCE_NAME = rtd1_2
APP_NAME = OracleRTD
WebLogic generic names
MW_HOME
\user_projects\domains\
DOMAIN
\servers \
SERVER_NAME
\stage\
APP_NAME
\expanded
Where:
MW_HOME = C:\Oracle\Middleware
DOMAIN = oraclertd_domain
SERVER_NAME = RTDServer1
APP_NAME = OracleRTD
WebSphere 6.1 generic names
WS_HOME
\AppServer\profiles\SERVER_NAME
\installedApps\
host_nameNode_name
\OracleRTD.ear
Where:
WS_HOME = C:\Program Files\IBM\WebSphere
SERVER_NAME = AppSrv01
The term "cluster" needs some clarification, because Oracle RTD and each application server system, Oracle AS, WebSphere, and WebLogic, all define and use the same term in different ways.
This section defines the terms Oracle RTD cluster and J2EE cluster, and compares these definitions to the other application-server specific definitions.
Oracle RTD Cluster
From the perspective of Oracle RTD, a cluster is the entire set of Oracle RTD instances running any combination of Oracle RTD services, DS, DC, or LS.
The Oracle RTD instances of an Oracle RTD cluster all share the same SDDS database, and all have the same SDGroupName setting. These two properties are really what determines which Oracle RTD instances are in an Oracle RTD cluster.
A Type 1 cluster is an Oracle RTD cluster where DS, DC, and LS all are enabled in every Oracle RTD instance.
A Type 3 cluster, the main focus of this chapter, is an Oracle RTD cluster where DS runs in separate Oracle RTD instances from the instances running DC and LS.
OAS Cluster
To Oracle Application Server, a cluster is the set of OAS instances managed by the same Enterprise Manager application, ascontrol
. J2EE applications are not necessarily deployed uniformly to all the OAS instances of an OAS cluster.
OC4J Group
In OAS, the OAS instances used by Oracle RTD run OC4J (Oracle J2EE Container For Java), and are known as OC4J instances.
OAS uses the term "OC4J group" for a collection of OC4J instances into which applications are deployed uniformly. For example, deploying Oracle RTD into an OC4J group automatically deploys it into all the OC4J instances of the OC4J group.
Deploying an Oracle RTD Type 3 cluster into OAS involves a single OAS cluster and two OC4J groups, because Oracle RTD will be deployed twice, once into each OC4J group.
WebSphere Cluster
In WebSphere, a cluster is similar to an OC4J group, in that an application is deployed uniformly to all instances of the cluster.
Deploying an Oracle RTD Type 3 cluster into WebSphere involves two WebSphere clusters, because Oracle RTD will be deployed twice, once into each WebSphere cluster.
WebLogic Cluster
A WebLogic cluster is similar to a WebSphere cluster, in that an application is deployed uniformly to all instances of the cluster.
Deploying an Oracle RTD Type 3 cluster into WebLogic involves two WebLogic clusters, because Oracle RTD will be deployed twice, once into each WebLogic cluster.
J2EE Cluster
For consistency and ease of discussion, a new term, "J2EE cluster", is used in this chapter, which means any one of the following: "WebSphere cluster", "WebLogic cluster", or "OC4J Group". An application deployed to a J2EE cluster is deployed uniformly to all instances of the cluster.
Note that the main two terms used in this chapter are "Oracle RTD cluster" and "J2EE cluster."
An Oracle RTD Type 3 cluster contains two J2EE clusters.
Oracle RTD is deployed differently into each of the two J2EE clusters in order to activate different Oracle RTD services within the two J2EE clusters.
This compares to an Oracle RTD Type 1 cluster, which contains just one J2EE cluster, because Oracle RTD is deployed uniformly across all Oracle RTD instances.
This section describes the system properties and Oracle RTD configuration settings that are typically necessary in a clustered deployment. Instructions for setting them appear in subsequent sections.
SDGroupName
This is the name of the Oracle RTD cluster. This is typically set via a system property in the JVM (Java Virtual Machine), or it can be set via the MBean, OracleRTD > SDClusterPropertyManager > Cluster. The default value is the name of the containing host, so it must be changed when multiple hosts are included in the cluster.
Each cluster must have a unique SDGroupName, in order to avoid communication conflicts with other Oracle RTD installations in the same local area network.
Each node (Oracle RTD Instance) in the cluster must have the same SDGroupName, and they must all access the same SDDS data source, where configuration data and analytic models reside.
rtd.instanceName
This is a system property set in the JVM to specify the unique name for the Oracle RTD instance within the cluster. The default value RTDServer is unsuitable in a cluster containing more than one Oracle RTD instance, because it would not be unique.
The format of the name, which must not include a space, follows file name conventions. This is because sometimes the instance name is used to distinguish log files and configuration files when multiple Oracle RTD instances are deployed to the same host.
Because Oracle RTD uses system properties, only one Oracle RTD instance can run in a given JVM.
rtd.instancesShareRuntimeHome
This is a system property set in the JVM. Its default value is false, but must be set to true in installations (typically only WebSphere) where multiple Oracle RTD instances share the same runtime home directory. When true, the Oracle RTD instance name is used as a directory name to isolate the log files, configuration cache files, and Inline Service metadata cache files for the instances on this host.
Table 13-1 shows how the values of rtd.instancesShareRuntimeHome control the locations of the Oracle RTD system files. In this table,
RTD_RUNTIME_HOME stands for Oracle RTD Runtime Home, the directory in which the application server runs Oracle RTD
RTD_INST_NAME stands for the value of the rtd.instanceName system property
Table 13-1 Locations of Oracle RTD System Files
rtd.instancesShareRuntimeHome | Value=False | Value=True |
---|---|---|
Location of log file |
|
|
Location of config cache files: |
|
|
Location of Inline Service metadata cache files |
|
|
DecisionServiceAddress
This is the cluster-wide prefix of the URL to the Decision Service, an address that typically corresponds to a virtual address managed by a load balancer.
The default value, http://myHost:8080, serves merely as an example. This must be changed when Decision Center is not co-located with Decision Service, in order to enable Decision Center's Interactive Integration Map to send test events to Decision Service. This attribute is accessed in the MBean, OracleRTD > SDClusterPropertyManager > Misc.
DecisionServiceEnabled
This can be set in a system property in the JVM options of the application server, or in the MBean, OracleRTD > SDPropertyManager > Misc.
The default value is true, but must be set to false in any Oracle RTD instances where you do not want Decision Service to run. Setting this to false is just one of the required steps to disable DS. See Section 13.5, "Deploying Oracle RTD into an Oracle RTD Type 3 Cluster."
LearningServiceEnabled
This can be set in a system property in the JVM options of the application server, or in the MBean, OracleRTD > SDPropertyManager > Misc.
The default value is true, but must be set to false in any Oracle RTD instances where you do not want Learning Service to run. Learning Service can be enabled in multiple Oracle RTD instances, but will run in only one at a time. Setting this to false is just one of the required steps to disable LS. See Section 13.5, "Deploying Oracle RTD into an Oracle RTD Type 3 Cluster."
This can be set in a system property in the JVM options of the application server, or in the MBean, OracleRTD > SDClusterPropertyManager > Cluster. The value must be the same in all Oracle RTD instances in the cluster.
The default value is 45566, and does not need to be changed unless other (non-Oracle RTD) applications on the local intranet are using the same multicast address (see JGroupsMulticastAddress) and multicast port.
If other clusters of Oracle RTD are installed and use the same multicast address and port, each Oracle RTD cluster must use a different SDGroupName and the versions of Oracle RTD must be wire-compatible.
If an old version of Oracle RTD is present whose group-communication messages are incompatible, the server.log
file for Oracle RTD will register error messages concerning each receipt of an incompatible message. These log entries are benign, but will tend to clog up the log file. These incompatibilities are not usually noticed because the default settings of Oracle RTD change between releases when necessary to avoid conflict.
This can be set in a system property in the JVM options of the application server, or in the MBean, OracleRTD > SDClusterPropertyManager > Cluster.
The value must be the same in all Oracle RTD instances of the cluster. The default value is 228.64.16.34, and does not need to be changed unless other (non-Oracle RTD) applications on the local intranet are using the same multicast address and multicast port. See more detailed discussion under JGroupsMulticastPort.
This is similar to JGroupsMulticastPort in terms of its location and scope. It is used by Decision Service in managing session affinity, when it receives a request whose session is being hosted on another Oracle RTD instance. DS uses the channel specified by JGroupsDSMulticastAddress and JGroupsDSMulticastPort to monitor and, if necessary, forward requests to other Oracle RTD instances running Decision Service.
The value must be the same in all Oracle RTD instances of the cluster, and must be different from the value of JGroupsMulticastPort. The default value is 45567.
This is similar to JGroupsMulticastAddress in terms of its location and scope. It is used by Decision Service in managing session affinity, when it receives a request whose session is being hosted on another Oracle RTD instance. DS uses the channel specified by JGroupsDSMulticastAddress and JGroupsDSMulticastPort to monitor and, if necessary, forward requests to other Oracle RTD instances running Decision Service.
The value must be the same in all Oracle RTD instances of the cluster, and does not need to be different from the value of JGroupsMulticastAddress as long as the combination of JGroupsMulticastAddress/JGroupsMulticastPort is different from the combination of JGroupsDSMulticastAddress/JGroupsDSMulticastPort. The default value is 228.64.16.34, the same as the default value for JGroupsMulticastAddress.
When RestrictClusterMembers is true, Oracle RTD only communicates with Oracle RTD instances whose host addresses have been specified in the property TrustedClusterMembers. The default value is true.
This property must have the same value across the cluster. It can be set as a system property, or in the MBean, OracleRTD > SDClusterPropertyManager > Cluster.
This is a string containing a list of hosts that may participate in the cluster. Messages from Oracle RTD instances on hosts not listed here, if RestrictClusterMembers is true, will generate authentication errors in server.log
.
The host addresses are IP addresses, not host names. Do not include port numbers in these addresses, because port assignments are dynamically allocated and hence cannot be pre-configured. Entries must be separated by a semicolon (";"). The default value is an empty string.
This property must have the same value across the cluster. It can be set as a system property, or in the MBean, OracleRTD > SDClusterPropertyManager > Cluster.
When true, Decision Service only accepts requests from host addresses that have been specified in the property TrustedDSClients. The default value is true.
This property must have the same value across the cluster. It can be set as a system property, or in the MBean, OracleRTD > SDClusterPropertyManager > Cluster.
This is a string containing a list of hosts that may send Decision Service requests to Oracle RTD. If RestrictDSClients is true (the default value), then DS requests from hosts not listed here and not part of the Oracle RTD cluster will be rejected by DS and will generate authentication errors in server.log
.
The host addresses are IP addresses, not host names. Ports may optionally be included, separated from the address by a colon (":"). Entries are separated by semicolons (";").
This property must have the same value across the cluster. It can be set as a system property, or in the MBean, OracleRTD > SDClusterPropertyManager > Cluster.
The main objective of an Oracle RTD Type 3 cluster is to have Decision Service running in separate Oracle RTD instances from the instances running Decision Center and Learning Service. This section describes how to set up the application server instances (which will become Oracle RTD instances after deployment) in an Oracle RTD Type 3 cluster, prior to deploying Oracle RTD.
This section contains the following topics:
For an Oracle RTD Type 3 cluster, create two J2EE clusters, for example, rtdGroup1 and rtdGroup2.
For an Oracle RTD Type 1 cluster, create one J2EE cluster only.
Note:
IrtdGroup1 and rtdGroup2 are J2EE clusters, not Oracle RTD clusters.Create and assign AS instances to the J2EE clusters. In this example, create a total of 4 AS instances, in 4 host machines, as in Table 13-2 and Table 13-3:
Note:
There are no assumptions in this chapter about the number of machines involved.Typically separate hosts are used to improve availability in the face of hardware failures, as well as to increase the total processing power.
Multiple instances on the same host can be used to work around the memory limitations of a 32-bit operating system on machines with greater than 2GB of memory.
This section describes the JVM options that may be used for each Oracle RTD instance.
This section contains the following topics:
In general, system properties can be used for any Oracle RTD properties supported by the OracleRTD JMX MBeans, as long as they do not need to be subsequently changed by JMX. These system properties are usually used only for settings that either do not need to be changed via JMX, or that need to be set before JMX will work. For more information, see Section 13.3, "Cluster-Specific Configuration Properties."
Table 13-4 shows the Oracle RTD settings that are usually configured through system properties. In this table, the Scope values are defined as follows:
RTD: Global to the entire Oracle RTD cluster
J2EE: Global to the J2EE cluster
AS: Specific to the AS instance
Table 13-4 Oracle RTD Settings Usually Configured Through System Properties
Name | Example Value | Scope | Description |
---|---|---|---|
SDGroupName |
MyRTDCluster |
RTD |
N/A |
rtd.instanceName |
rtd_1_1 |
AS |
Must be unique within the Oracle RTD cluster. |
rtd. instancesShareRuntimeHome |
false |
RTD |
false for OAS and WebLogic; true for WebSphere. |
DecisionServiceEnabled |
true |
J2EE |
Assuming an Oracle RTD Type 3 cluster: true, for rtdGroup1; false for rtdGroup2. As an alternative to setting this in system properties, it can be set via JConsole, as described in Section 13.5.3, "Disabling Certain Oracle RTD Services." It probably makes sense to set them as system properties, if adding an Oracle RTD instance requires copying the system properties setup anyway. |
LearningServiceEnabled |
false |
J2EE |
Assuming an Oracle RTD Type 3 cluster: false, for rtdGroup1; true for rtdGroup2. As an alternative to setting this in system properties, it can be set via JConsole, as described in Section 13.5.3, "Disabling Certain Oracle RTD Services." It probably makes sense to set them as system properties, if adding an Oracle RTD instance requires copying the system properties setup anyway |
JGroupsMulticastAddress, JGroupsMulticastPort, JGroupsDSMulticastAddress, JGroupsDSMulticastPort |
N/A |
RTD |
These do not usually need to be changed from their default values. If needed, it is better to set them as JVM system properties rather than through JConsole, because they are needed by JConsole. |
RestrictClusterMembers |
false |
RTD |
Set this to false to facilitate adding servers to the Oracle RTD cluster. If true (its default value), see Section 13.5.5, "Adding Restricted Cluster Members." |
TrustedClusterMembers |
N/A |
RTD |
When RestrictClusterMembers is true (its default value), the set of allowed cluster hosts can be set here as a system property. However, it is easier to add new hosts if TrustedClusterMembers is managed through JMX instead of as a system property. See Section 13.5.5, "Adding Restricted Cluster Members." |
RestrictDSClients |
false |
RTD |
Set this to false if there is no concern about which hosts can send Decision Service Requests. If set to true (its default value), then DS will reject requests from hosts not in TrustedDSClients and not part of the Oracle RTD cluster. |
TrustedDSClients |
N/A |
RTD |
When RestrictDSClients is true (its default value), the set of hosts allowed to send Decision Service requests can be set here as a system property. However, it is easier to add new client hosts if TrustedDSClients is managed through JMX instead of as a system property. See Section 13.5.6, "Adding Trusted Decision Service Clients." |
This section describes generic JVM options and suggested values for the options.
Set the option -Djava.net.preferIPv4Stack=true
Minimum Heap Size
Set this to -Xms512M
.
On development machines, this can be lower (for example, 128M) to reduce the required memory.
Maximum Heap Size
Set this to -Xmx1024M
.
On production machines, 2048M is a common value.
PermGen Size (not for JRockit JVM)
Set this to -XX:PermSize=256m
.
This is to reduce out-of-memory errors when redeploying Inline Services, because redeploying Inline Services temporarily introduces more java classes.
JIT (for Sun JVM)
Set this to -server
.
This section contains application server specific JVM options.
JConsole Setup
EMF Registry
Set this system property to specify the EMF (Eclipse Metadata Framework) registry implementation used by Oracle RTD.
Property Name: 'org.eclipse.emf.ecore.EPackage.Registry.INSTANCE'
Property Value: 'com.sigmadynamics.emf.util.SDEMFRegistry'
EMF Registry
Set this system property to specify the EMF (Eclipse Metadata Framework) registry implementation used by Oracle RTD.
Property Name: 'org.eclipse.emf.ecore.EPackage.Registry.INSTANCE'
Property Value: 'com.sigmadynamics.emf.util.SDEMFRegistry'
Disable MBean Routing
Property Name: 'com.ibm.websphere.mbeans.disableRouting'
Property Value: '<on>OracleRTD:*</on>'
If JConsole is to be used as the JMX console, as opposed to some other MBean browser, its configuration is application server dependent. The only consideration here that is specific to clustering, as opposed to the general information provided elsewhere in this guide, is the need to use a different jmx port setting for each AS instance.
Set the following JVM system properties, to ensure that the port is unique on the host:
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=12345
To set up JConsole for WebSphere, see Section 4.12, "Setting Up JConsole for WebSphere."
Create a jconsole-startup batch file for each Oracle RTD instance.
Before deploying Oracle RTD, you must create a JDBC connection pool and data source for each AS instance. When Oracle RTD is deployed to these AS instances, it must be able to open JDBC connections to a common shared data source, accessed by the JNDI lookup name, jdbc/SDDS.
For detailed application server specific instructions about creating the JDBC resources, refer to Chapter 8, "Configuring Data Access for Oracle Real-Time Decisions."
For instructions about how to create JDBC resources to a database shared by all AS instances, refer to your application server documentation. Depending on the J2EE application server vendor, you typically can create the connection pool and data source just once, or perhaps once per J2EE cluster.
This section describes in general terms how to deploy Oracle RTD into a clustered environment where Decision Service runs in separate Oracle RTD instances from the instances running Decision Center and Learning Service. This is an Oracle RTD Type 3 cluster, and this is expected to be the most common configuration used in production.
Generalizing these instructions for other Oracle RTD cluster types is straightforward if the following rules are followed.
Deploy RTD.ear
into separate J2EE clusters for every combination of Oracle RTD services that need to be co-located in the same Oracle RTD instance. This is illustrated in the table below.
In each deployment of RTD.ear
, change the web context roots associated with the services that will not be used, effectively hiding them so the load balancer will not send requests to Oracle RTD instances for disabled services.
Disable DS and LS, through JConsole, in the Oracle RTD instances where you do not want them to run, to avoid loading these services into memory.
Note:
Currently DC is unconditionally loaded into memory, but will not create any sessions because of step 2 above.Expanding on steps 1 and 3, you will need from one to three J2EE clusters, as detailed in the following table:
Oracle RTD Cluster Type | J2EE Clusters Required | Oracle RTD Services Enabled | Oracle RTD Services Disabled by JConsole |
---|---|---|---|
Type 1 | rtdGroup1 | DS, DC, LS | none |
Type 2 | rtdGroup1 | DS, DC | LS |
rtdGroup2 | LS | DS | |
Type 3 | rtdGroup1 | DS | LS |
rtdGroup2 | DC, LS | DS | |
Type 4 | rtdGroup1 | DS | L:S |
rtdGroup2 | DC | DS, LS | |
rtdGroup3 | LS | DS |
Expanding on step 2, the following table shows the web context roots needed by the three Oracle RTD services when enabled:
Oracle RTD Service | Context Roots |
---|---|
DS | /rtis |
DC | /ui |
/soap | |
/schema | |
LS | /ls |
The disabled services should be "hidden" by appending a string such as "-hide<n>" to their context roots, where <n> should be 1, 2, or 3, corresponding to the J2EE cluster number.
The use of <n> is to ensure that you do not use the same context root twice. It is really only useful in a Type 4 cluster, as this is the only Oracle RTD cluster type where you would be disabling the same Oracle RTD service type in more than one J2EE cluster.
Specifically for an Oracle RTD Type 3 cluster, deploy RTD.ear
twice, as follows:
First, into the J2EE cluster rtdGroup1, as application OracleRTD
Then, into rtdGroup2 as application OracleRTD2
The rest of this section contains the following topics:
Section 13.5.1, "Deploying RTD.ear Into rtdGroup1 as OracleRTD"
Section 13.5.2, "Deploying RTD.ear Into rtdGroup2 as OracleRTD2"
Some application server types, like Oracle AS, enable you to save a deployment plan file that remembers deployment-time choices, so that you do not have to manually specify them again in subsequent deployments.
When you deploy for the first time:
Use OracleRTD as the application name.
Adjust the proposed web context-roots by appending "-hide" to each of them except /rtis.
For example: /ui-hide, /ls-hide, /soap-hide, /schema-hide, /rtis.
Save the new deployment plan on the local machine to use in subsequent deployments, if your application server supports saving deployment plans.
Tip:
Use a mnemonic name for the deployment plan file. For example, when the deployment enables only the Decision Service, call the deployment plan file dsPlan.dat.The considerations and steps for the deployment into rtdGroup2 are the same as for deployment into rtdGroup1, except for the following:
The web-app context bindings will be different
The application name will be different (OracleRTD2 instead of OracleRTD)
When you deploy for the first time:
Use OracleRTD2 as the application name.
Adjust the proposed web context-roots by appending "-hide" to /rtis.
For example: /ui, /ls, /soap, /schema, /rtis-hide.
For Oracle AS, change the library path settings to refer to the new application name: ${oracle.j2ee.home}/OracleRTD2
instead of ${oracle.j2ee.home}/OracleRTD
. For details, see Section 13.5.2.1, "Configuring Classpath for OracleRTD2 in Oracle AS."
Save the new deployment plan on the local machine to use in subsequent deployments, if your application server supports saving deployment plans.
If you follow the mnemonic-name convention for the deployment file name, you could use dcLsPlan.dat for the file name, as this deployment enables Decision Center and Learning Service.
For Oracle AS 3.3, the last screen of the deployment process in Enterprise Manager allows you to adjust the class path used by various libraries. You must adjust the classpath because, as packaged in RTD.ear
, the path assumes the application is named OracleRTD, but in this deployment it is OracleRTD2.
Click the Configure Class Loading activity.
Then scroll down to the Configure Application Libraries section, and replace the three occurrences of OracleRTD with OracleRTD2.
After Oracle RTD has been started in all AS instances, use JConsole or another MBean browser to disable Decision Service or Learning Service in certain Oracle RTD instances according to the cluster type.
Note:
This is not necessary, and in fact cannot be done, if the services were enabled or disabled via system properties, as described in Section 13.4.2, "Setting JVM Options."This only needs to be done the first time, or if you are changing cluster types. It is not necessary if you are redeploying Oracle RTD into the same cluster type, because these settings are saved in the SDDS database shared by all the instances.
For each instance in the Oracle RTD cluster, perform the following steps:
Start JConsole and connect to the instance.
Disable LS.
If the instance is in the J2EE cluster rtdGroup1, disable Learning Service, because these instances run just Decision Service.
Set the LearningServiceEnabled attribute to false in the MBean, OracleRTD > SDPropertyManager > Misc.
Disable DS.
If the instance is in the J2EE cluster rtdGroup2, disable Decision Service, because these instances run just Learning Service and Decision Center.
Set the DecisionServiceEnabled attribute to false in the MBean, OracleRTD > SDPropertyManager > Misc.
For Oracle RTD Type 3 and Type 4 clusters, where DC and DS are not co-located, use JConsole to set the cluster's Decision Service address, so that DC can send test events to DS from its Interactive Integration Map view.
This can be done once in any instance. The change will be propagated automatically to all instances.
Set the DecisionServiceAddress attribute to a value like http://myHost.com:8080 in the MBean, OracleRTD > SDClusterPropertyManager > Misc.
Generally, the host and port will be that of the HTTP server serving as the load-balancer for the RTD.ear
deployment where DS is enabled. For the Type 3 cluster described in this chapter, this is the HTTP server/port hosting the web app for OracleRTD, not the one for OracleRTD2 - usually these would be same.
When the set of Oracle RTD cluster members is restricted to a specified list of hosts - a security precaution enabled via the system property RestrictClusterMembers - then additional hosts are more easily added through the use of JConsole, rather than through the system property TrustedClusterMembers, as described in Section 13.4.2.1, "Oracle RTD Clustering System Properties."
If TrustedClusterMembers is managed as a system property, then all Oracle RTD instances must be restarted, after manually adjusting this system property value for all Oracle RTD instances to include the new host.
When managing TrustedClusterMembers with JConsole, then no instances have to be restarted, except possibly the new instance if it was already running when its address was added to TrustedClusterMembers.
Oracle recommends the following sequence:
Determine the host IP address of the new Oracle RTD Cluster member. Host names are not sufficient, you need the IP address.
Through a JConsole connection to any existing Oracle RTD instance, add the new host address to the propertyTrustedClusterMembers in the MBean, OracleRTD > SDClusterPropertyManager > Cluster. This change should be propagated to all existing instances, and should be effective immediately.
Add the new AS instance to the J2EE cluster, and deploy Oracle RTD to the J2EE cluster.
When the set of Decision Service client hosts is restricted to a specified list of hosts - a security precaution enabled via the system property RestrictDSClients - then additional client hosts are more easily added through the use of JConsole, rather than through the system property TrustedDSClients, described in Section 13.4.2.1, "Oracle RTD Clustering System Properties."
If TrustedDSClients is managed as a system property, then all Oracle RTD instances must be restarted, after manually adjusting this system property value for all Oracle RTD instances to include the new client host. When managing TrustedDSClients with JConsole, then no instances have to be restarted.
Oracle recommends the following sequence:
Determine the host IP address of the new Decision Service client. Host names are not sufficient, you need the IP address.
Through a JConsole connection to any existing Oracle RTD instance, add the new host address to the property TrustedDSClients in the MBean, OracleRTD > SDClusterPropertyManager > Cluster. This change should be propagated to all existing instances, and should be effectively immediately.
Cookie name: ORA_RTD_DSServerID
Path: /rtis
Description: The contents of the cookie are a single integer identifying the RTD server instance that is hosting the request's Inline Service session.
This HTTP cookie is disabled be default, but can be enabled by setting the following MBean attribute to true:
OracleRTD > SDClusterPropertyManager > Cluster: GenerateDSServerIdCookie
Its use has not been thoroughly tested, but it is believed that in some clustered installations it could reduce the number of times that requests need to be forwarded from one Decision Service instance to another, possibly improving performance. This cookie is not used for Decision Center, only for Decision Service, the service that handles Inline Service requests.
It is only needed in installations that could be using multiple HTTP sessions to deliver Inline Service requests to the same Inline Service session.
Because most external load balancers are routinely configured to support HTTP session affinity, and Inline Service session affinity is needed that spans multiple HTTP sessions, this cookie would be set in each of the HTTP sessions so that requests from the multiple HTTP sessions would be sent by the load balancer to the same Decision Service instance.
The usefulness of this cookie depends on each HTTP session being used to access just one Inline Service session.
Another assumption is that the load balancer's session affinity algorithm can be configured to use this cookie, instead of JSESSIONID as most are routinely configured to do.
This section consists of the following topics:
Section 13.7.5, "Setting Up WebLogic Domain and Node Managers"
Section 13.7.11, "Copying WebLogic Domain to All Clustered Machines"
Section 13.7.15, "Disabling HTTP Session Affinity and Enable Request Forwarding on Each Server"
Section 13.7.16, "Deploying CrossSell Inline Service (Through Web Server Port 8080)"
This section describes the overall hardware and software setup of the WebLogic cluster, to be used as the reference configuration for all the subsequent WebLogic related subsections.
Cluster Example: 2 Machines, 6 AppServers
Machine #1: <-- Admin Server, 3 Server Instances, Apache Server
Oracle RTD Software
WebLogic Application Server
Apache HTTP Server
Machine #2: <-- 3 Server Instances
WebLogic Application Server
You must install the Oracle RTD software on machine #1, as follows:
Install rtd_3.0.0_WL_win.zip
(or rtd_3.0.0_WL_unix.cpio
if on Linux/Unix) on machine #1 (with WebLogic Admin Server).
You must initialize the Oracle RTD database on machine #1, as follows:
On machine #1, run RTD_HOME\scripts\SDDBTool.cmd
.
For more information, see Section 2.2.4, "Initializing the Oracle RTD Database Using SDDBTool."
The first step is to install the WebLogic Application Server on both machines. Then you must install the Apache HTTP Server on machine #1.
On machine #1 and machine #2 in the cluster, install WebLogic Application Server.
Note:
The following is to ensure the WebLogic Plug-in is also installed.Perform the following steps on both machines:
In Choose Install Type, select Custom, then click Next.
In Choose Components, check the WebLogic Server: Server & Web Server Plug-Ins checkboxes, and uncheck all the others.
Click Next.
In Optional Tools, uncheck Mercury profiling tools, then click Next.
In Choose Product Installation Directories, accept the defaults, then click Next.
In Install Windows Service, accept the defaults, then click Next.
In Choose Shortcut Installation, accept the defaults, then click Next.
Wait until the installation finishes.
When the installation is complete, click Done.
The first steps are to create the WebLogic domain and to copy the OracleRTD JDBC jar to the domain. Then you must start the Node Managers on both machines.
To create the WebLogic domain, perform the following steps:
On machine #1 (your Admin Server machine), click Start > All Programs > Oracle WebLogic > WebLogic Server 11gR1> Tools, run Configuration Wizard.
In the Welcome dialog, select the Create a new WebLogic Domain radio button.
Click Next.
In the Domain Source dialog, select Generate a domain configured automatically to support the following products radio button.
Click Next.
In the Configure Administration Username and Password dialog, enter admin username/password, for example weblogic/weblogic.
Click Next.
In the Configure Server Start Mode and JDK dialog, under WebLogic Domain Startup Mode, select the Development Mode radio button
In the Configure Server Start Mode and JDK dialog, under JDK Selection, select a JDK that is supported for your system configuration, for example, Sun, JRockit.
Click Next.
In the Customize Environment and Services Settings dialog, select No.
Note: this will Create Clusters and Servers using Admin Console.
Click Next.
In the Create WebLogic Domain dialog, for Domain Name, enter oraclertd_domain
and click Create.
Wait until the installation finishes.
Check the Start Admin Server checkbox.
Click Done.
Note:
To manually start Admin Server, runweblogic-install-dir
/user_projects /domains/oraclertd_domain/bin/startWebLogic.cmd
.
To manually stop Admin Server, run weblogic-install-dir
/user_projects /domains/oraclertd_domain/bin/stopWebLogic.cmd
To copy the OracleRTD JDBC jar to the domain, perform the following steps:
On machine #1 (your Admin Server machine) in RTD_HOME\lib\jdbc\
, copy one of the following jar sets to weblogic-install-dir
/user_projects/domains/oraclertd_domain/lib/
:
SQLServer: sqljdbc.jar
Oracle: ojdbc14.jar
DB2: db2jcc.jar
& db2jcc_license_cu.jar
Note:
This step removes the need to copy jdbc jars to each server instance machine.To start the machine Node Managers, perform the following steps:
Go to machine #1.
Start Node Manager by running: weblogic-install-dir
\wlserver_10.3\server\bin\startNodeManager.cmd
.
Example: c:\Oracle\Middleware\wlserver_10.3\server\bin\startNodeManager.cmd
Repeat steps 1-2 for machine #2 in the cluster.
Before proceeding, create Oracle RTD roles and users in WebLogic. See Section 5.8, "Creating Oracle RTD Roles and Users" for more information.
This process consists of creating the WebLogic machines and the WebLogic cluster, then creating the servers and setting the server JVM properties.
To create the WebLogic machines, perform the following steps:
Logon to the Admin Console (machine #1):
http://
admin-server-host-name
:7001/console
In the tree to the left under Change Center, click Lock & Edit.
In the tree to the left under Domain Structure, expand Environment and click Machines.
Click New.
For Name, enter a unique machine name, for example, Machine-1
.
Click OK.
Click the machine name.
Under the Configuration tab, click Node Manager.
For Listen Address, enter the host name of a clustered server, for example, myHostName
.
Click Save.
Repeat steps 3-10 for each machine in the cluster including the Admin Server machine.
In the tree to the left under Change Center, click Activate Changes.
The following describes the cluster setup on the two machines:
RTDCluster
(Machine #1 and Node #1)
RTDServer1a
RTDServer1b
RTDServer1c
(Machine #2 and Node #2)
RTDServer2a
RTDServer2b
RTDServer2c
To create the WebLogic cluster, perform the following steps:
In the tree to the left under Change Center, click Lock & Edit.
In the tree to the left under Domain Structure, expand Environment and click Clusters.
Click New.
For Name, enter RTDCluster
.
Click OK.
In the tree to the left under Change Center, click Activate Changes.
To create the servers, perform the following steps:
In the tree to the left under Change Center, click Lock & Edit.
In the tree to the left under Domain Structure, expand Environment and click Servers.
Click New
For Server Name, enter RTDServer1a
.
For Server Listen Port, enter 7002
.
Under Should this server belong to a cluster?, select Yes, make this server a member of an existing cluster.
For Select a cluster, select RTDCluster.
Click Next.
Click Finish.
Click the server name RTDServer1a.
Under Configuration tab General section, for Machine, select Machine-1.
Click Save.
Repeat steps 2-12 for the following remaining server/port/machine configurations:
server = RTDServer1b, port = 7003, machine = Machine-1
server = RTDServer1c, port = 7004, machine = Machine-1
server = RTDServer2a, port = 7005, machine = Machine-2
server = RTDServer2b, port = 7006, machine = Machine-2
server = RTDServer2c, port = 7007, machine = Machine-2
In the tree to the left under Change Center, click Activate Changes.
To set the server JVM properties, perform the following steps:
In the tree to the left under Change Center, click Lock & Edit.
In the tree to the left under Domain Structure, expand Environment and click Servers.
Click the server name RTDServer1a.
Under the Configuration tab, Server Start section, for Arguments, enter the following as a single line with spaces between properties (replacing jmx-remote-port with 12302
, and replacing learning with true
for RTDServer1a and false
for all other servers):
-Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=com.sigmadynamics.emf.util.SDEMFRegistry
-DRestrictClusterMembers=false
-DSDGroupName=RTDCluster
-DLearningServiceEnabled=
learning
-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=
jmx-remote-port
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
-Djava.net.preferIPv4Stack=true
Example:
-Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=com.sigmadynamics.emf.util.SDEMFRegistry -DSDGroupName=RTDCluster -DRestrictClusterMembers=false -DLearningServiceEnabled=true -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=12302 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.net.preferIPv4Stack=true
Click Save.
Repeat steps 2-5 for the following remaining server/jmx-remote-port configurations:
server = RTDServer1b, jmx-remote-port = 12303
server = RTDServer1c, jmx-remote-port = 12304
server = RTDServer2a, jmx-remote-port = 12305
server = RTDServer2b, jmx-remote-port = 12306
server = RTDServer2c, jmx-remote-port = 12307
In the tree to the left under Change Center, click Activate Changes.
Notes:
If your WebLogic version is 11g 10.3.3+ and your Oracle RTD database is in an Oracle database server, see Section 13.7.8.1, "Creating an Oracle JDBC Provider for the Oracle RTD Database on WebLogic 11g 10.3.3+."
To create the JDBC data sources, perform the following steps:
In the tree to the left under Change Center, click Lock & Edit.
Navigate the path Services -> Data Sources -> New -> Generic Data Source.
Click New.
For Name, enter RTD_DS
.
For JNDI Name, enter SDDS
.
For Database Type, select Other.
For Database Driver, select Other.
Click Next.
Uncheck the Supports Global Transactions checkbox.
Click Next.
Perform the next set of steps that is appropriate to the database that holds your data source:
If your database is Oracle, continue at step 11.
If your database is SQLServer, continue at step 23.
If your database is DB2, continue at step 35.
Oracle
For Database Name, enter your Oracle SID name, for example, ORCL
.
For Host Name, enter your database server name, for example, mydbservername
.
For Port, enter your database port number, for example, 1521.
For Database User Name, enter your Oracle user name, for example, myusername
.
For Password and Confirm Password, enter your Oracle user password, for example, SD
.
Click Next.
For Driver Class Name, enter oracle.jdbc.pool.OracleDataSource
.
For URL, enter jdbc:oracle:thin:@
db_host:db_port:sid
.
For example, jdbc:oracle:thin:@mydbservername:1521:ORCL
For Properties, enter user=
db_user_name
, for example, user=myusername
.
For Test Table Name, enter SDApps
.
Click Test Configuration.
Click Next.
Continue at step 47.
SQLServer
For Database Name, enter your SQLServer database name, for example, rtd
.
For Host Name, enter your database server name, for example, mydbservername
.
For Port, enter your database port number, for example, 1433
.
For Database User Name, enter your SQLServer user name, for example, myusername
.
For Password and Confirm Password, enter your SQLServer user password, for example, sd
.
Click Next.
For Driver Class Name, enter com.microsoft.sqlserver.jdbc.SQLServerDriver
For URL, enter jdbc:sqlserver://
db_host:db_port
For example, jdbc:sqlserver://mydbservername:1433
Note:
If the data source is on a SQL Server named instance, specify thedb_host
parameter using the format host_name\instance_name
.For Properties, enter each property on a new line:
user=
db_user_name
, for example, user=myusername
DatabaseName=
db_name
, for example, DatabaseName=rtd
For Test Table Name, enter SDApps
.
Click Test Configuration.
Click Next.
Continue at step 47.
DB2
For Database Name, enter your DB2 database name, for example, rtd
.
For Host Name, enter your database server name, for example, mydbservername
.
For Port, enter your database port number, for example, 50000
.
For Database User Name, enter your DB2 user name, for example, myusername
.
For Password and Confirm Password, enter your DB2 user password, for example, SD
.
Click Next.
For Driver Class Name, enter com.ibm.db2.jcc.DB2Driver
.
For URL, enter jdbc:db2://
db_host:db_port/db_name
For example, jdbc:db2://mydbservername:50000/rtd
For Properties, enter user=
db_user_name
, for example, user=myusername
.
For Test Table Name, enter SDApps
.
Click Test Configuration.
Click Next.
Continue at step 47.
Click Finish.
In the tree to the left under Change Center, click Activate Changes.
To create a JDBC provider when your Oracle RTD database is in an Oracle database server, and Oracle RTD is deployed on WebLogic 11g 10.3.3+, perform the following steps:
Log into the WebLogic Server Administration Console with the administrator user name and password.
Navigate the path Services -> Data Sources -> New -> Generic Data Source.
On the JDBC Data Source Properties page, follow these steps:
For Name, enter a descriptive data source name, such as RTD_DS
.
For JNDI Name, enter SDDS
.
For Database Type, select Oracle.
For the Database Driver, select Oracle's Driver (Thin) for Instance connections; Versions: 9.0.1 and later, then click Next.
On the Transaction Options page, deselect Supports Global Transactions, then click Next.
On the Connection Properties page, follow these steps:
For Database Name, enter the name of the Oracle RTD Database you created in Section 2.2.
For Host Name, enter the name of the computer hosting the database server.
For Port, enter the port number on the database server used to connect to the database.
For Database User Name, enter the name of the database run-time user.
For Password, enter the password of the database run-time user, then click Next.
On the Test Database Connection page, leave all the settings already filled, except enter SDAPPS
for Test Table Name.
Click Test Configuration. If the test fails, go back and check your settings. If the test succeeds, click Next.
Select the cluster where you want the data source to be made available (for example, RTD_Cluster). You must perform this step before completing the data source configuration.
Click Finish, then click Activate Changes.
This process consists of enabling the WebLogic proxy plug-in in the servers, then setting up the Apache HTTP server.
To enable the WebLogic proxy plug-in in the servers, perform the following steps:
In the tree to the left under Change Center, click Lock & Edit.
In the tree to the left under Domain Structure, expand Environment and click Servers.
Click the server name RTDServer1a.
Under Configuration tab General section, click Advanced.
Under Advanced, check WebLogic Plug-In Enabled checkbox.
Click Save.
Repeat steps 2-6 for each of the following remaining servers:
RTDServer1b
RTDServer1c
RTDServer2a
RTDServer2b
RTDServer2c
In the tree to the left under Change Center, click Activate Changes.
To set up the Apache HTTP server, perform the following steps:
On machine #1, copy
weblogic-install-dir
\wlserver_10.3\server\plugin \win\32\mod_wl_22.so
to
apache-install-dir
\modules\
For example:
C:\Program Files\Apache Software Foundation \Apache2.2\modules\
Open apache-install-dir
\conf\httpd.conf
.
For example:
C:\Program Files\Apache Software Foundation \Apache2.2\conf\httpd.conf
Change port for property Listen to 8080.
Change port for property ServerName to 8080.
For example: ServerName myHostName.us.oracle.com:8080
At the end of httpd.conf
, add the following lines (replacing hostName* and 7002-7007 in the WebLogicCluster
line with your servers and ports created in Section 13.7.7.3, "Creating Servers"):
LoadModule weblogic_module modules/mod_wl_22.so <IfModule mod_weblogic.c> # RTDCluster_DsDcLs <LocationMatch "/(ui|schema|soap|rtis|ls)"> SetHandler weblogic-handler WebLogicCluster hostName1:7002,hostName1:7003,hostName1:7004, hostName2:7005,hostName2:7006,hostName2:7007 </LocationMatch> </IfModule>
Save httpd.conf
.
Start Apache HTTP: Start>All Programs>Apache HTTP Server 2.2.6 >Control Apache Server>Start
(Or C:\Program Files\Apache Software Foundation
\Apache2.2\bin>httpd -k start
)
Note:
To stop, run: Start>All Programs>Apache HTTP Server 2.2.6 >Control Apache Server>Stop(Or C:\Program Files\Apache Software Foundation
\Apache2.2\bin>httpd -k stop
)
To deploy RTD.ear onto the cluster, perform the following steps:
On machine #1, in RTD_HOME
/package
, unzip RTD.ear
into a directory called expanded.
In the admin console, in the tree to the left under Change Center, click Lock & Edit.
In the tree to the left under Domain Structure, click Deployments.
Click Install.
For Location, find RTD_HOME
/package
.
Select expanded.
Click Next.
Select Install this deployment as an application.
Click Next.
Under Clusters, check the RTDCluster checkbox.
Click Next.
Under General, for Name, enter OracleRTD
.
Under Source accessibility, select Copy this application onto every target for me.
Click Next.
Click Finish.
In the tree to the left under Change Center, click Activate Changes.
Note:
RTD.ear
will be installed on every machine server instance in: weblogic-install-dir
\user_projects\domains\oraclertd_domain\servers\
server-instance-name
\stage\OracleRTD\expanded
To copy the WebLogic domain to all clustered machines, perform the following steps:
Go to machine #2 in the cluster.
Start the WebLogic Scripting Tool by running:
weblogic-install-dir
\wlserver_10.3\common\bin\wlst.cmd
For example: C:\bea\wlserver_10.3\common\bin\wlst.cmd
Connect to machine #1 (Admin server) by entering:
connect('weblogic','weblogic','t3://
admin-server-host
:7001')
For example: wls:/offline> connect('weblogic','weblogic','t3://myHostName.us.oracle.com:7001')
Enroll the machine as a managed server by entering:
nmEnroll('
weblogic-install-dir
/user_projects/domains/oraclertd_domain',
'weblogic-install-dir
/wlserver_10.3/common/nodemanager')
For example: wls:/oraclertd_domain/serverConfig>
nmEnroll('C:/bea/user_projects/domains/oraclertd_domain', 'C:/bea/wlserver_10.3/common/nodemanager')
Run disconnect(
).
For example: wls:/oraclertd_domain/serverConfig> disconnect()
Run exit()
.
For example: wls:/offline> exit().
This process consists of restarting the Admin Server and Node Managers, then starting the clustered servers.
To restart the Admin Server and Node Managers, perform the following steps:
On machine #1, find the command window where the Node Manager has been started (from startNodeManager.cmd) and hit Ctrl-C to stop it.
Repeat step 1 for machine #2.
On machine #1 (Admin Server machine), run:
weblogic-install-dir
/user_projects/domains /oraclertd_domain/bin/stopWebLogic.cmd
For example:
c:/Oracle/Middleware/user_projects/domains /oraclertd_domain/bin/stopWebLogic.cmd
On machine #1 (Admin Server machine), run:
weblogic-install-dir
/user_projects/domains/oraclertd_domain/bin/startWebLogic.cmd
For example:
c:/Oracle/Middleware/user_projects/domains /oraclertd_domain/bin/startWebLogic.cmd
On machine #1 (Admin Server machine), run
weblogic-install-dir
\wlserver_10.3\server \bin\startNodeManager.cmd
Repeat step 5 for machine #2.
To start the clustered servers, perform the following steps:
In the tree to the left under Domain Structure, expand Environment and click Clusters.
Click the cluster name RTDCluster.
Click the Control tab.
Check all servers in the cluster.
Click Start.
Click Yes.
Wait until the installation finishes.
Logs for Machine 1:
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer1a\logs\RTDServer1a.log
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer1b\logs\RTDServer1b.log
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer1c\logs\RTDServer1c.log
Logs for Machine 2:
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer2a\logs\RTDServer2a.log
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer2b\logs\RTDServer2b.log
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer2c\logs\RTDServer2c.log
To start the OracleRTD application, perform the following steps:
In the tree to the left under Domain Structure, click Deployments.
Check the OracleRTD checkbox.
Click Start and select Servicing all Requests.
Click Yes.
Wait until the installation finishes.
Logs for Machine 1:
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer1a\stage\OracleRTD\expanded\log\server.log
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer1b\stage\OracleRTD\expanded\log\server.log
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer1c\stage\OracleRTD\expanded\log\server.log
Logs for Machine 2:
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer2a\stage\OracleRTD\expanded\log\server.log
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer2b\stage\OracleRTD\expanded\log\server.log
C:\Oracle\Middleware\user_projects\domains\oraclertd_domain \servers\RTDServer2c\stage\OracleRTD\expanded\log\server.log
To set the JConsole server properties, perform the following steps:
On machine #1 or machine #2, run jconsole.exe
from a Java 1.5 installation.
For example: C:\Program Files\Java\jdk1.5.0_10\bin\jconsole.exe
In JConsole, connect to the Agent dialog, then click the Remote tab.
For Host or IP, enter the machine name of the first clustered server instance.
For example: myHostName1.us.oracle.com
For Port, enter the JMX remote port set for this server instance in Section 13.7.7.3, "Creating Servers."
For example: 12302
Click Connect.
Set any other JConsole properties as you require.
To disable HTTP session affinity and to enable request forwarding on each server, perform the following steps:
On machine #1 or machine #2, run jconsole.exe
from a Java 1.6 installation.
For example: C:\Program Files\Java\jdk1.6.0_12\bin\jconsole.exe
In JConsole, connect to the Agent dialog, then click the Remote tab.
For Host or IP, enter the machine name of the first clustered server instance.
For example: myHostName1.us.oracle.com
For Port, enter the JMX remote port set for this server instance in Section 13.7.7.3, "Creating Servers."
For example: 12302
Click Connect.
In the tree to the left, expand OracleRTD > SDClusterPropertyManager > Cluster.
For GenerateDSCookies, enter false
. Hit the Enter key.
In the tree to the left, expand OracleRTD > SDClusterPropertyManager > Misc.
For DSManagesSessionAffinity, enter true
. Hit the Enter key.
Note:
Disable request forwarding by setting DSManagesSessionAffinity to false.For DSEnforcesStrictSessionAffinity, enter true
. Hit the Enter key.
To deploy the CrossSell Inline Service through web server port 8080, perform the following steps:
On machine #1, start Oracle RTD Studio by running RTD_HOME
\eclipse\eclipse.exe
.
In top menu bar, click File then Import.
Select Existing Projects into Workspace.
Click Next.
Click Browse...
Go to RTD_HOME
\examples\CrossSell
.
Click OK.
Click Finish.
Wait until the Inline Service build is finished.
In top menu bar, click the icon Deploy the Inline Service to a server.
Click Deploy.
Note:
By default, Studio will deploy to localhost:8080 (which is machine #1 and the web server "load balancer" port)For User Name, enter sdsu
.
Click Connect.
Wait until the CrossSell Inline Service is deployed.
To create the CrossSell database tables, perform the following steps:
On machine #1, in a command console: cd to RTD_HOME
\examples\CrossSell\etc\data\Oracle
Run the following command:
InitAppDB.cmd
RTD_HOME
db_host_name port sid db_user_name admin_user_name admin_user_password
For example:
InitAppDB.cmd C:\OracleBI\RTD mydbmachine.us.oracle.com 1521 orcl MYUSERNAME MYADMINUSERNAME MYADMINPASSWORD
Note:
If the database is on a SQL Server named instance, specify thedb_host_name
parameter using the format host_name\instance_name
.To run Load Generator against the CrossSell Inline Service through web server port 8080, perform the following steps:
On machine #1, start Oracle RTD Load Generator by running:
RTD_HOME
\scripts\loadgen.cmd
Click Open an existing Load Generator script.
Go to RTD_HOME
\examples\CrossSell\etc
and select LoadGen3Threads.xml
.
Click Open.
Click the General tab.
Next to Client Configuration File, on the right, click the ellipsis (...) button.
Go to RTD_HOME
\client
.
Select clientHttpEndPoints.properties (which is already set to localhost:8080 or machine #1).
Click Open.
In the top menu bar, click File, then Save.
In the top menu bar, click the icon Runs the current Load Generator script (blue right arrow).
Oracle RTD is supported on both UNIX and Windows platforms for IBM WebSphere application server.
This section contains the following topics:
Section 13.8.7, "Creating an Administrative User and Enabling Security"
Section 13.8.9, "Creating Cluster and Servers and Setting Server Properties"
Section 13.8.11, "Adding Virtual Host HTTP Address for Servers"
Section 13.8.17, "Viewing and Changing User-Role Associations"
Section 13.8.18, "Creating Custom Roles and Assigning Permissions to Custom Roles (Optional)"
Section 13.8.22, "Running Load Generator Against CrossSell Inline Service"
This section describes the overall hardware and software setup of the WebSphere cluster, to be used as the reference configuration for all the subsequent WebSphere related subsections.
Cluster Example: 2 Machines, 6 AppServers
Machine #1: <-- Admin Server, IBM HTTP Server, 3 Server Instances (vms)
Oracle RTD Software
IBM Update Installer and FixPacks
WebSphere Network Development
IBM HTTP Server
WebSphere Application Server
Machine #2: <-- 3 Server Instances (vms)
Oracle RTD JDBC Driver Jar(s)
IBM Update Installer and FixPacks
WebSphere Application Server
To set up the host machine files, perform the following steps:
Refer to the WebSphere documentation for information about installing WebSphere. Install the IBM updater and any download FixPacks, the WebSphere application server, WebSphere Network Deployment, then the IBM HTTP Server.
Note that Core and SDK fix packs are required for cluster setup. The basic outline procedure is:
On both machines in the cluster, install Update Installer, and download any required fix packs for Core and SDK.
On both machines in the cluster, install WebSphere Application Server, then use Update Installer to apply fix packs for Core and SDK.
On machine #1, install Network Deployment, then use Update Installer to apply fix packs for Core and SDK.
On machine #1, install HttpServer, then use Update Installer to apply fix packs for Core and SDK.
For details about the versions supported, see System Requirements and Supported Platforms for Oracle Real-Time Decisions.
To install the Oracle RTD software, perform the following steps:
Install rtd_websphere_3.0.0.zip
for WebSphere on machine #1 (with WebSphere Network Deployment).
Copy the RTD jdbc jar(s) to machine #2 in the cluster.
Use the same directory structure RTD_HOME
\lib\jdbc\
as Machine #1:
SQLServer: RTD_HOME
\lib\jdbc\sqljdbc.jar
Oracle: RTD_HOME
\lib\jdbc\ojdbc14.jar
DB2: RTD_HOME
\lib\jdbc\db2jcc.jar
RTD_HOME
\lib\jdbc\db2jcc_license_cu.jar
To initialize the Oracle RTD database, perform the following step:
On machine #1, run RTD_HOME
\scripts\SDDBTool.cmd
For more information, see Section 2.2.4, "Initializing the Oracle RTD Database Using SDDBTool" in Oracle Real-Time Decisions Installation and Administration Guide.
Start the Deployment Manager, then, on both machines, add two nodes to the Deployment Manager.
The instructions in this section provide general information about adding nodes - for more specific information, refer to the WebSphere documentation as required.
The basic outline procedure for both machines in the cluster is:
Start the Deployment Manager.
For example, from the WebSphere Network Deployment Install directory, run the bin\StartManager.bat
script.
Add a node.
For example, from the WebSphere Server Install directory, run the bin\addNode.bat
script, specifying the network deployment machine name for the node.
This adds Node Agent to Deployment Manager and also starts the node agent.
If you have already enabled security in WebSphere, you can skip this section. You should still check that Java 2 security is not turned on.
Use the WebSphere Application Server Network Deployment Manager administrative console, called the Integrated Solutions Console, to create an administrative user and to enable security in WebSphere. For more information about how to use the Integrated Solutions Console, refer to the WebSphere documentation.
If security is disabled, follow these steps to enable security in WebSphere:
Access the Integrated Solutions Console at the URL http://
websphere_host
:
port
/ibm/console
. At the login prompt, enter any user name. You will not need to enter any password. On Windows, you can also access the Integrated Solutions Console through Start > Programs.
If you do not know the port number for the Integrated Solutions Console, you can find it in the virtualhosts.xml
file, located in WEBSPHERE_HOME
/AppServer/profiles/
profile_name
/config/cells/
host_name
.
In the tree on the left, expand Security, and choose Secure administration, applications, and infrastructure.
In the User account repository area, under the Available realm definitions heading, select Federated repositories, then click Set as current.
Click Apply, then Save.
Click Configure.
In the Federated repositories window, in the General Properties area, perform the following:
Enter a Realm Name, such as RTDRealm.
Enter a Primary administrative user name, such as admin.
Under the Server user identity heading, select Automatically generated server identity.
In the Administrative user password window, in the General Properties area, enter the administrative user password in both the Password and Confirm password fields.
Click OK, then Save.
Log out, stop, then restart WebSphere.
Log in to the Integrated Solutions Console.
If you do not know the port number for the Integrated Solutions Console, you can find it in the virtualhosts.xml
file, located in WEBSPHERE_HOME
/AppServer/profiles/
profile_name
/config/cells/
host_name
.
In the tree on the left, expand Security and choose Secure administration, applications, and infrastructure.
Under the Administrative security heading, select Enable administrative security.
Under the Application security heading, select Enable application security.
Under the Java 2 security heading, uncheck Use Java 2 security to restrict application access to local resources.
Click Apply, then Save.
Log out, stop, then restart WebSphere.
To add virtual host port 8080, perform the following steps:
In the tree to the left, expand Environment and click Virtual Hosts.
Click default host.
Under Additional Properties, click Host Aliases.
Click New.
For Host Name, enter '*'
.
For Port, enter 8080
.
Click OK.
Under Messages, click Preferences and check the Synchronize changes with Nodes checkbox.
This ensures that future changes will be propagated to all nodes in cluster, provided that node agents are running.
Click Apply.
Click Save.
This process consists of creating the cluster and servers, then setting the server JVM and administration properties.
The following describes the cluster setup on the two machines:
RTDCluster
(Machine #1 and Node #1)
RTDServer1a (LearningService = enabled)
RTDServer1b
RTDServer1c
(Machine #2 and Node #2)
RTDServer2a
RTDServer2b
RTDServer2c
To create the cluster and servers, perform the following steps:
In the tree to the left, expand Servers and select Clusters.
Click New.
Step 1: For Cluster name, enter RTDCluster.
Step 1: Click Next.
Step 2: For Member name, enter RTDServer1a
.
Step 2: For Select node, select the first node created in Section 13.8.6, "Adding Nodes to Deployment Manager."
Step 2: Click Next.
Step 3: For Member name, enter RTDServer1b.
Step 3: For Select node, select the same node (Node 1).
Step 3: Click Add Member.
Step 3: For Member name, enter RTDServer1c
.
Step 3: For Select node, select the same node (Node 1).
Step 3: Click Add Member.
Step 3: For Member name, enter RTDServer2a
.
Step 3: For Select node, select the second node created in Section 13.8.6, "Adding Nodes to Deployment Manager."
Step 3: Click Add Member.
Step 3: For Member name, enter RTDServer2b.
Step 3: For Select node, select the same node (Node 2).
Step 3: Click Add Member.
Step 3: For Member name, enter RTDServer2c
.
Step 3: For Select node, select the same node (Node 2).
Step 3: Click Add Member.
Step 3: Click Next.
Step 4: Click Finish.
Under Messages, click Save.
To set the server JVM properties, perform the following steps:
In the tree to the left, expand Servers and select Application servers.
Click RTDServer1a.
Under Server Infrastructure, expand Java and Process Management.
Click Process Definition.
Under Additional Properties, click Java Virtual Machine.
Under the General Properties heading, in the Generic JVM arguments field, add the following string:
-Djava.net.preferIPv4Stack=true
If there is already a value in this field, add a space after the existing value, then add the new string.
Click OK.
When you click OK, you may see an error stating that you need to provide values for Initial Heap Size and Maximum Heap Size. If you see this error, set these values as needed for your system (for example, you can set Initial Heap Size to 512
and Maximum Heap Size to 2048
).
Under Additional Properties, click Custom Properties.
Click New.
For Name, enter org.eclipse.emf.ecore.EPackage.Registry.INSTANCE
For Value, enter com.sigmadynamics.emf.util.SDEMFRegistry
Click New.
For Name, enter rtd.instanceName
.
For Value, enter RTDServer1a
(or RTDServer1b
, RTDServer1c
, RTDServer2a
, RTDServer2b
, RTDServer2c
).
Click New.
For Name, enter rtd.instancesShareRuntimeHome.
For Value, enter true
.
Click New.
For Name, enter RestrictClusterMembers
.
For Value, enter false
.
Click New.
For Name, enter SDGroupName
.
For Value, enter RTDCluster.
Click New.
For Name, enter LearningServiceEnabled
.
For Value, if server is RTDServer1a, enter true
, otherwise enter false
.
Repeat step 1, then steps 3-27 for servers RTDServer1b, RTDServer1c, RTDServer2a, RTDServer2b, RTDServer2c.
To set the server administration properties, perform the following steps:
In the tree to the left, expand Servers, and select Application servers.
Click RTDServer1a.
Under Server Infrastructure, expand Administration, and select Administration Services.
Under Additional Properties, click Custom Properties.
Click New.
For Name, enter com.ibm.websphere.mbeans.disableRouting
.
Repeat step 1, then steps 3-7 for servers RTDServer1b, RTDServer1c, RTDServer2a, RTDServer2b, RTDServer2c.
Under Messages, click Save, then click OK.
This section consists of the following topics:
To create users, perform the following steps:
Log into the Integrated Solutions Console, using the administrative user and password.
In the tree on the left, expand Users and Groups, and choose Manage Users.
Enter user and password information for the user, such as rtdadmin for the User ID.
You will use the User ID later on, when you add the user to one or more groups.
To create groups, perform the following steps:
Log into the Integrated Solutions Console, using the administrative user and password.
In the tree on the left, under Users and Groups, choose Manage Groups.
Click the Create... button.
In the Group name field, enter RTDAdminGroup.
Click Create, then Close.
In the Manage Groups page, click the group name RTDAdminGroup.
Click the Add Users... button.
Click Search to display a list of users.
In the search result list, select the user name to add to the RTDAdminGroup.
Repeat steps 2 through 10 to create each of the following groups for Oracle RTD:
RTDDCEditorGroup
RTDDCUserGroup
RTDStudioDeployerGroup
RTDStudioDownloaderGroup
RTDBatchAdminGroup
RTDChoiceEditorGroup
RTDUserGroup
In the Manage Groups page, click the group name RTDUserGroup.
In the Group Properties area, click the Members tab.
Click the Add Groups... button.
Add all the groups created for Oracle RTD except RTDUserGroup.
Click Close.
The groups specified in Section 13.8.10.2, "Creating Groups" are automatically mapped to the standard Oracle RTD roles, as shown in Table 13-5.
Table 13-5 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 |
Section 7.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.
Note:
For information about custom roles, see Section 13.8.18, "Creating Custom Roles and Assigning Permissions to Custom Roles (Optional)."This process consists of getting HTTP addresses for each server, then creating an HTTP virtual port for each unique server port.
To get HTTP addresses for each server, perform the following steps:
In the tree to the left, expand Servers and select Application Servers.
Click RTDServer1a.
Under Communications, expand Ports.
Write down the WC_defaulthost
for this server, for example: 9081.
This is used to connect with this server via HTTP.
Repeat steps 1-4 for servers RTDServer1b
, RTDServer1c
, RTDServer2a
, RTDServer2b
, RTDServer2c
.
To create an HTTP virtual port for each unique server port, perform the following steps:
In the tree to the left, expand Environment and click Virtual Hosts.
Click default host.
Under Additional Properties, click Host Aliases.
Click New.
For Host Name, enter '*'
.
For Port, enter the WC_defaulthost
port for server RTDServer1a, for example, 9081
.
Note:
You do not have to add the same port a second time for different machines.Click OK.
Repeat steps 1-8 for each unique remaining server port, for example: 9082
, 9083
.
This process consists of the following:
To create JDBC providers, perform the following steps:
In the tree to the left, expand Resources, expand JDBC, and select JDBC Providers.
Under Scope, select the cell scope, for example, Cell=myMachineCell01.
Click New.
Step 1: For Database type, select User-defined.
Perform the steps appropriate to your data source.
If your data source is SQLServer, continue at step 5.
If your data source is Oracle, continue at step 9.
If your data source is DB2, continue at step 13.
SQLServer
Step 1: For Information required Implementation class name,
enter com.microsoft.sqlserver.jdbc.SQLServerConnectionPoolDataSource
Step 1: For Name, enter RTDDataProvider.
Step 1: Click Next.
Step 2: For Class path, enter RTD_HOME
/lib/jdbc/sqljdbc.jar
.
For example, C:/OracleBI/RTD/lib/jdbc/sqljdbc.jar
Note:
The path must be the same for each machine.Continue at step 17.
Oracle
Step 1: For Information required Implementation class name,
enter oracle.jdbc.pool.OracleConnectionPoolDataSource
Step 1: For Name, enter RTDDataProvider
.
Step 1: Click Next.
Step 2: For Class path: enter RTD_HOME
/lib/jdbc/ojdbc14.jar
For example, C:/OracleBI/RTD/lib/jdbc/ojdbc14.jar
Continue at step 17.
DB2
Step 1: For Information required Implementation class name,
enter com.ibm.db2.jcc.DB2ConnectionPoolDataSource
Step 1: For Name, enter RTDDataProvider.
Step 2: For Class path: enter RTD_HOME
/lib/jdbc/db2jcc.jar;
RTD_HOME
/lib/jdbc/db2jcc_license_cu.jar
For example: C:/OracleBI/RTD/lib/jdbc/db2jcc.jar;C:/OracleBI/RTD/lib/jdbc/db2jcc_license_cu.jar
Note:
The path must be the same for each machine.Continue at step 17.
Step 3: Click Finish.
Under Messages, click Save.
To create J2C authentication aliases, perform the following steps:
In the tree to the left, expand Security, and select Secure administration, applications, and infrastructure.
Expand Java Authentication and Authorization Service and select J2C authentication data.
Click New.
For Alias, enter RTDDS_auth
.
For User ID, enter the name of the database run-time user, for example, sa1
.
For Password, enter the corresponding password for the database user, for example, sa1
.
Click OK.
Under Messages, click Save.
The J2C alias will be created in cell manager scope (host_nameCell_manager_name).
To create data sources, perform the following steps:
In the tree to the left, expand Resources, expand JDBC, and select JDBC Providers.
Click RTDDataProvider.
Under Additional Properties, click Data Sources.
Select the Cluster scope, then click New.
Step 1: For Data source name, enter RTD_DS.
Step 1: For JNDI name, enter SDDS
.
Step 1: Under Component-managed authentication alias and XA recovery authentication alias, select RTDDS_auth.
Step 1: Click Next.
Step 2: Click Next.
Step 3: Click Finish.
Under Messages, click Save.
To set data source properties, perform the following steps:
In the tree to the left, expand Resources, expand JDBC, and select Data Sources.
Click RTD_DS.
Perform the steps appropriate to your data source.
If your data source is SQLServer, continue at step 3.
If your data source is Oracle, continue at step 6.
If your data source is DB2, continue at step 9.
SQLServer
Click the Select All icon.
Enter your database name
, server name
, and port number
into the fields provided.
Note:
If the data source is on a SQL Server named instance, specify the database server name using the formathost_name\instance_name
.Oracle
Under Oracle datasource properties,
for URL, enter jdbc:oracle:thin:@
db_host:db_port:sid
.
For example, jdbc:oracle:thin:@mydbhost:1521:orcl
.
Click OK.
Under Messages, click Save to end the process.
DB2
Under DB2 Universal data source properties,
for Database name, enter the name of your database, for example, rtd
.
For Driver type, enter 4
.
For Server name, enter your database server name, for example, localhost
.
For Port number, enter your database port number, for example, 60000
.
Click OK.
Under Messages, click Save to end the process.
To set data source statement cache, perform the following steps:
In the tree to the left, expand Resources, expand JDBC, and select JDBC Providers.
Click RTDDataProvider.
Under Additional Properties, click Data Sources.
Click RTD_DS.
Under Additional Properties, click WebSphere Application Server data source properties.
For Statement cache size, enter 0
(instead of 10).
Click OK.
Under Messages, click Save.
This section describes how to restart the nodes and the Deployment manager
In the WebSphere administrative console, restart the nodes for each machine from System Administration > Node agents.
To restart the Deployment Manager, perform the following steps:
On machine #1, stop the Deployment Manager:
websphere-network-deployment-install-dir
\bin\stopManager.bat
For example: C:\Program Files\IBM\WebSphere\NetworkDeployment\bin\stopManager.bat
On machine #1, start the Deployment Manager:
websphere-network-deployment-install-dir
\bin\startManager.bat
For example: C:\Program Files\IBM\WebSphere\NetworkDeployment\bin\startManager.bat
To test the data source connection, perform the following steps:
Log on to the Deployment Manager Admin Console:
http://
deployment-manager-host-name
:9061/ibm/console
In the tree to the left, expand Resources, expand JDBC, and select JDBC Providers.
Click RTDDataProvider.
Under Additional Properties, click Data Sources.
Check the RTD_DS checkbox.
Click Test connection.
Note:
Deployment manager on machine #1 must be running for the Oracle RTD data source to be active (cell scope).This process consists of modifying the IBM HTTP server configuration file, creating the web server, generating and propagating the web server plug-in, then starting the web server.
To modify the IBM HTTP server configuration file, perform the following steps:
On machine #1, open ibm-http-server-install-dir
\conf\httpd.conf
For example: C:\Program Files\IBM\HTTPServer\conf\httpd.conf
Change the port for property AfpaPort to 8080
.
For example: AfpaPort 8080
Change the port for property Listen to 8080
.
For example: Listen 0.0.0.0:8080
Change port for property ServerName to 8080.
For example: ServerName localhost:8080
Change webserver1 to RTDWebServer for property WebSpherePluginConfig.
Note:
You can leave the name as webserver1. If you do, then make sure that you use the name webserver1 instead of RTDWebServer for the rest of the instructions.Save httpd.conf
.
To create the web server, perform the following steps:
Back in the admin console, in the tree to the left, expand Servers and select Web servers.
Click New.
Step 1: For Select node, select the node where web server will reside, for example, host_nameNode_name
. (Machine #1).
Step 1: For Server name, enter the name you used in the IBM HTTP httpd.conf
file, for example, RTDWebServer.
Step 1: For Type, select IBM HTTP Server.
Step 1: Click Next.
Step 2: Click Next.
Step 3: For Port enter 8080
.
Step 3: For Web server installation location, enter ibm-http-server-install-dir
.
For example, C:\Progra~1\IBM\HTTPServer
, not C:\Progam Files\IBM\HTTPServer
Do not enter spaces for this directory.
For Service name, enter IBMHTTPServer6.1
.
Step 3: For Plug-in installation location, enter ibm-http-server-install-dir
\Plugins
For example, C:\Program Files\IBM\HTTPServer\Plugins
Step 3: Click Next.
Step 4: Click Finish.
Under Messages, click Save.
To generate and propagate the web server plug-in, perform the following steps:
In the tree to the left, expand Servers and select Web servers.
Check the RTDWebServer checkbox.
Click Generate Plug-in.
Click Propagate Plug-in.
To start the web server, perform the following steps:
In the tree to the left, expand Servers and select Web servers.
Check the RTDWebServer checkbox.
Click Start.
The log directory is C:\Program Files\IBM\HTTPServer\logs\.
Look in access.log
and error.log
.
This creates an IBM HTTP Web Server with round-robin load balancing on port 8080.
See C:\Program Files\IBM\HTTPServer\Plugins\config\RTDWebServer\plugin-cfg.xml
.
To start the cluster and servers, perform the following steps:
In the tree to the left, expand Servers and select Clusters.
Check the cluster checkbox RTDCluster.
Click Start.
Wait until the cluster has started.
In the tree to the left, expand Servers and select Application servers.
Verify all six servers have started: look for green arrows in the Status column.
The base log directory for Machine #1 and Machine #2 is C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\
.
Look in \RTDServer1a\SystemOut.log
for Server RTDServer1a open for e-business.
Look in \RTDServer1b\SystemOut.log
for Server RTDServer1b open for e-business.
Look in \RTDServer1c\SystemOut.log
for Server RTDServer1c open for e-business.
Look in \RTDServer2a\SystemOut.log
for Server RTDServer2a open for e-business.
Look in \RTDServer2b\SystemOut.log
for Server RTDServer2b open for e-business.
Look in \RTDServer2c\SystemOut.log
for Server RTDServer2c open for e-business.
This process consists of deploying RTD.ear
to the cluster, generating and propagating the web server plug-in, then starting the OracleRTD application.
To deploy RTD.ear
to the cluster, perform the following steps:
In the tree to the left, expand Applications and select Install New Application.
For Full path, click Browse... and browse to RTD_HOME
/package/RTD.ear
.
For example, C:/OracleBI/RTD/package/RTD.ear
.
Click Next.
Step 1: For Application name, enter OracleRTD.
Step 1: Click Next.
Step 2: In Clusters and Servers:, select cluster=RTDCluster.
Step 2: Click the Select All icon.
Step 2: Click Apply.
Step 2: Click Next.
Step 3: Click Finish.
Click Save.
To generate and propagate the web server plug-in, perform the following steps:
In the tree to the left, expand Servers and select Web servers.
Check the RTDWebServer checkbox.
Click Generate Plug-in.
In the tree to the left, expand Servers and select Web servers.
Check the RTDWebServer checkbox.
Click Propagate Plug-in.
To start the OracleRTD application, perform the following steps:
In the tree to the left, expand Applications and select Enterprise Applications.
Check the OracleRTD checkbox.
Click Start.
Wait for the startup to complete.
The base log directory for Machine #1 and Machine #2 is C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\logs\
. Specific log files are as follows:
\RTDServer1a\SystemOut.log
\RTDServer1b\SystemOut.log
\RTDServer1c\SystemOut.log
\RTDServer2a\SystemOut.log
\RTDServer2b\SystemOut.log
\RTDServer2c\SystemOut.log
For both Machine #1 and Machine #2, other log information appears under the directory C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01\installedApps\
host_nameNode_name
\
. Look in \OracleRTD\logs\server.log
.
To give priority to the application classloader over the application server classloader, after you have deployed Oracle RTD, you must explicitly set the Classloader priority in the Websphere administrative console, as follows:
Log into the WebSphere administrative console, using the administrative user and password.
Expand Applications, then choose Enterprise Applications.
Click OracleRTD.
Click Class loading and update detection.
Select Classes loaded with application class loader first.
Click OK.
Restart WebSphere.
The standard Oracle RTD Roles and Roles-groups mapping have been predefined for WebSphere.
To show the Oracle RTD Roles and Roles-groups mapping, perform the following steps:
In the Integrated Solutions Console, expand Applications, then choose Enterprise Applications.
Click OracleRTD.
Under the Detail Properties section, click Security role to user/group mapping.
If you want to view or edit the user-role associations, check the role to be modified, then click either Look up users or Look up groups and change the mapping.
This section consists of the following topics:
To create custom roles for Oracle RTD, perform the following high-level steps:
Create groups in WebSphere.
To create groups in WebSphere, follow the instructions in Section 13.8.10.2, "Creating Groups" using group names of your own choice.
Specify the roles in the deployment descriptor file application.xml
, extracted from the Oracle file RTD.ear
. See Section 13.8.18.1.1, "Specifying Roles in application.xml" for details.
Map the roles to the WebSphere groups in the Integrated Solutions Console. See Section 13.8.18.1.2, "Mapping Roles to Groups" for details.
Then, perform either of the following:
Uninstall, then redeploy Oracle RTD, as follows:
Download the two deployment descriptor files, application.xml
and ibm-application-bnd.xmi
, back into RTD.ear
(the file ibm-application-bnd.xmi
contains the role-to-group mappings).
Redeploy Oracle RTD using the updated RTD.ear
. Use Uninstall, then Install.
Redeploy Oracle RTD, using Update.
The rest of this section consists of the following topics:
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:
Add an entry similar to the following:
<security-role id="SecurityRole_1241469153092">
<role-name>ILS2Users</role-name>
</security-role>
where security-role id
is any unique value.
Repeat step 1 for as many roles as you want to create.
In the Integrated Solutions Console, expand Applications, then choose Enterprise Applications.
Click OracleRTD.
Under the Detail Properties section, click Security role to user/group mapping.
Check the role to be modified, then click Look up groups and change the mapping.
Repeat step 4 for as many roles as you need to map to groups.
Note:
To view and change the user-role associations, see Section 13.8.17, "Viewing and Changing User-Role Associations."As described in Section 7.4, "Assigning Permissions," assign Cluster permissions, Inline Service permissions, and Decision Center Perspective permissions to any custom roles.
This process consists of getting bootstrap addresses for each server, then creating the JConsole startup script for each server.
To get bootstrap addresses for each server, perform the following steps:
In the tree to the left, expand Servers and select Application Servers.
Click RTDServer1a.
Under Communications, expand Ports.
Write down the BOOTSTRAP_ADDRESS for this server.
This is used to connect with JConsole for server specific configuration.
Repeat steps 1-4 for servers RTDServer1b, RTDServer1c, RTDServer2a, RTDServer2b, and RTDServer2c.
To create the JConsole startup script for each server, perform the following steps:
On machine #1, create and open a new file in Notepad for the first server instance RTDServer1a.
Add the following lines into the file:
For Windows:
call c:\program files\ibm\websphere\appserver\profiles\appsrv01\bin\setupCmdLine
"%JAVA_HOME%\bin\jconsole" "-J-Djava.class.path=%WAS_HOME%\runtimes\com.ibm.ws.admin.client_6.1.0.jar;%JAVA_HOME%\lib\tools.jar" "-J%CLIENTSSL%" "-J%CLIENTSAS%" service:jmx:iiop://HOST:PORT/jndi/JMXConnector
For Linux:
#!/bin/sh
WAS_HOME=/usr/IBM/WebSphere/AppServer
USER_HOME=/usr/IBM/WebSphere/AppServer/profiles/AppSrv01
WAS_HOST=
MACHINE_HOST
WAS_BOOTSTRAP_PORT=
BOOTSTRAP_ADDRESS
$WAS_HOME/java/bin/jconsole -J-Djava.class.path=$WAS_HOME/runtimes/com.ibm.ws.admin.client_6.1.0.jar:$WAS_HOME/java/lib/tools.jar -J-Dcom.ibm.CORBA.ConfigURL=file:$USER_HOME/properties/sas.client.props -J-Dcom.ibm.SSL.ConfigURL=file:$USER_HOME/properties/ssl.client.props service:jmx:iiop://$WAS_HOST:$WAS_BOOTSTRAP_PORT/jndi/JMXConnector
For the Linux script, replace BOOTSTRAP_ADDRESS
with the port number seen in step 4 of Section 13.8.19.1, "Getting Bootstrap Addresses For Each Server." For example, 2810
.
For the Linux script, replace MACHINE_HOST
with the machine host name for server RTDServer1a, for example, mymachine.us.oracle.com
.
Save the file as RTDServer1a_JConsole.bat
for Windows or RTDServer1a_JConsole.sh
for Linux.
Repeat steps 1-5 for servers RTDServer1b, RTDServer1c, RTDServer2a, RTDServer2b, RTDServer2c, using their corresponding ports and machine host names.
To deploy the CrossSell Inline Service, perform the following steps:
On machine #1, start Decision Studio by running RTD_HOME
\eclipse\eclipse.exe
.
In top menu bar, click File then Import.
Select Existing Projects into Workspace.
Click Next.
Click Browse...
Go to RTD_HOME
\examples\CrossSell
.
Click OK.
Click Finish.
Wait until the Inline Service build is finished.
In top menu bar, click the icon Deploy the Inline Service to a server.
Click Deploy.
Note:
By default, Decision Studio will deploy to localhost:8080, which is machine #1 and the web server "load balancer" port.For User Name, enter sdsu
.
Click Connect.
Wait until the CrossSell Inline Service is deployed.
To create the CrossSell database tables, perform the following steps:
On machine #1, in a command console: cd to RTD_HOME
\examples\CrossSell\etc\data\Oracle
Run the following command:
InitAppDB.cmd
RTD_HOME
db_host_name port sid db_user_name admin_user_name admin_user_password
For example:
InitAppDB.cmd C:\OracleBI\RTD mydbmachine.us.oracle.com 1521 orcl MYUSERNAME MYADMINUSERNAME MYADMINPASSWORD
Note:
If the database is on a SQL Server named instance, specify thedb_host_name
parameter using the format host_name\instance_name
.To run Load Generator against the CrossSell Inline Service, perform the following steps:
On machine #1, start Oracle RTD Load Generator by running:
RTD_HOME
\scripts\loadgen.cmd
Click Open an existing Load Generator script.
Go to RTD_HOME
\examples\CrossSell\etc
and select LoadGen3Threads.xml
.
Click Open.
Click the General tab.
Next to Client Configuration File, on the right, click the ellipsis (...) button.
Go to RTD_HOME
\client
.
Select clientHttpEndPoints.properties (which is already set to localhost:8080 or machine #1).
Click Open.
In the top menu bar, click File, then Save.
In the top menu bar, click the icon Runs the current Load Generator script (blue right arrow).
To create a WebSphere thread dump, perform the following steps:
On machine #1, open a command window.
Go to C:\Program Files\IBM\WebSphere\AppServer\bin
and run wsadmin.bat.
Enter set jvm [$AdminControl completeObjectName type=JVM,process=RTDServer1a,*]
, replacing RTDServer1a for each server to analyze.
Enter $AdminControl invoke $jvm dumpThreads
.
Go to C:\Program Files\IBM\WebSphere\AppServer\profiles\AppSrv01
and view the thread dump file created.
This section consists of the following topics:
This section describes how to install Oracle RTD onto two hosts, each running a cluster of OC4J instances.
In general, three types of clusters are supported, corresponding to different distributions of Oracle RTD services:
DS (Decision Service)
DC (running Decision Center's UI servlet and Studio's soap servlet)
LS (Learning Service)
The Oracle RTD cluster types have the following properties:
Type 1 cluster: a homogeneous cluster of at least two Oracle RTD instances, all running DS, DC, and LS.
Either all the instances are on one physical host or the instances are split across two physical hosts.
Type 2 cluster: a cluster of at least 4 Oracle RTD instances, two running DS and DC, and the others running LS.
Either all the instances are on one physical host or the two types of instance are split across two physical hosts.
Type 3 cluster: a cluster of at least 4 Oracle RTD instances, two running just DS, and the others running DC and LS.
Either all the instances are on one physical host or the two types of instance are split across two physical hosts.
This section concentrates on types 2 and 3, as these have the most detailed setup procedures.
For both cluster type 2 and cluster type 2, configuration starts on Host1, with 4 OC4J instances deployed into two OC4J groups, as follows:
rtdGroup
Instances:
rtd_1_1 on Host1
rtd_1_2 on Host1
rtdGroup2
Instances:
rtd_1_3 on Host1
rtd_1_4 on Host1
[Note the optional name convention: rtd_<host_number>_<instance_within_host>.]
Assuming that you want to deploy on multiple hosts, you then configure a cluster on Host2 using the same group names as on Host, as follows:
rtdGroup
Instances:
rtd_2_1 on Host2
rtd_2_2 on Host2
rtdGroup2
Instances:
rtd_2_3 on Host2
rtd_2_4 on Host2
Then you merge the two clusters into one cluster managed by Host1:
rtdGroup
Instances:
rtd_1_1 on Host1
rtd_1_2 on Host1
rtd_2_1 on Host2
rtd_2_2 on Host2
rtdGroup2
Instances:
rtd_1_3 on Host1
rtd_1_4 on Host1
rtd_2_3 on Host2
rtd_2_4 on Host2
The following sections describe the operations which are to performed on both Host1 and Host2:
After you have completed the installation process, Oracle AS will be started.
You will perform many of the Oracle AS administration tasks in the Enterprise Manager, ascontrol
. The launch URL for the Enterprise Manager is installation dependent, but is typically http://localhost:7777/em
.
After stopping Oracle AS, you can change the port by editing the file OAS_HOME
/Apache/Apache/conf/httpd.con
f. A typical location for OAS_HOME
is C:/product/10.1.3.1/OracleAS_1/
.
To stop Oracle AS, run OAS_HOME
/opmn/bin/opmnctl.exe stopall
.
Locate and open the file httpd.con
f (for example, C:/product/10.1.3.1/OracleAS_1/Apache/Apache/conf/httpd.con
f).
Search for the word Port in the file.
Replace the Port and Listen values by 8080
.
To create OC4J groups and instances, perform the following steps:
In the Enterprise Manger, create two OC4J groups: rtdGroup and rtdGroup2.
Create four OC4J instances on each host, as follows:
For Host 1, create instances rtd_1_1 and rtd_1_2 in rtdGroup
For Host 2, create instances rtd_2_1 and rtd_2_2 in rtdGroup
For Host 1, create instances rtd_1_3 and rtd_1_4 in rtdGroup2
For Host 2, create instances rtd_2_3 and rtd_2_4 in rtdGroup2
[Note the instance name convention used: rtd_<host_number>_<instance_within_host>.]
You create JDBC resources after creating the OC4J groups because when you create JDBC connection pools and data sources at the group level, they are automatically copied to each of the group's OC4J instances that exists at the time.
Later, however, when you add an OC4J instance to a group, configuration for the data sources you had created at the group level are not automatically distributed to the new OC4J instance.
To create JDBC resources, perform the following steps:
If you will be using SQLServer or DB2, first copy the corresponding jdbc jars provided with rtd_3.0.0_OC4J_win.zip
(or rtd_3.0.0_OC4J_unix.cpio
if on Linux/Unix) into each OC4J instance's applib directory, as follows:
Stop Oracle AS.
For each OC4J instance (rtd_1_1, rtd_1_2, and so on), copy the appropriate file or files:
(For SQLServer) RTD_HOME
/lib/jdbc/sqljdbc.jar
(For DB2) RTD_HOME
/lib/jdbc/db2jcc.jar
RTD_HOME
/lib/jdbc/db2jcc_license_cu.jar
into OAS_HOME
/j2ee/OC4J_INSTANCE/applib/
.
Restart Oracle AS.
In the Enterprise Manager, drill into rtdGroup.
Go to the Administration tab, then click the JDBC Resources task under the Services heading. Under the Connection Pools heading, click Create to create a new connection pool for your Oracle RTD Database.
If you are using OC4J as part of Oracle Application Server, first click home under the Groups heading, then proceed to the Administration tab.
On the Create Connection Pool - Application page, ensure that default is selected for Application, and that New Connection Pool is selected for Connection Pool Type. Then, click Continue.
On the Create Connection Pool page, enter RTDConnectionPool
for Name.
For Connection Factory Class, enter one of the following:
SQL Server: com.microsoft.sqlserver.jdbc.SQLServerDriver
Oracle Database: oracle.jdbc.pool.OracleDataSource
DB2: com.ibm.db2.jcc.DB2Driver
For JDBC URL, enter one of the following:
SQL Server: jdbc:sqlserver://
db_host
:
db_port
;databaseName=
db_name
Note:
If the database is on a SQL Server named instance, specify thedb_host
parameter using the format host_name\instance_name
.Oracle Database: jdbc:oracle:thin:@
db_host
:
db_port
:
sid
DB2: jdbc:db2://
db_host
:
db_port
/
db_name
db_host
is the name of the server running the Oracle RTD Database, db_port
is the port number for connecting to the database server, db_name
is the name of the Oracle RTD Database instance (such as rtd
), and sid
is the Oracle System Identifier that refers to the instance of the Oracle Database running on the server.
Under the Credentials heading, for Username, provide a database user name with system administration privileges for the Oracle RTD Database instance. Then, provide the corresponding password. See Oracle Fusion Middleware Security Guide for information about whether to provide a cleartext password or an indirect password.
Click Finish.
On the JDBC Resources page, under the Data Sources heading, click Create to define a new data source.
On the Create Data Source - Application & Type page, ensure that default is selected for Application, and that Managed Data Source is selected for Data Source Type. Then, click Continue.
On the Create Data Source - Managed Data Source page, enter RTD_DS
for Name, jdbc/SDDS
for JNDI Location, and select RTDConnectionPool for Connection Pool. Keep the defaults for the other options. Then, click Finish.
On the JDBC Resources page, in the Data Sources table, click Test Connection for the RTD_DS data source. Follow these steps to test the RTD_DS data source:
If you are using Oracle Database for your Oracle RTD Database, keep the default settings and click Test.
If you are using SQL Server or DB2 for your Oracle RTD Database, change the SQL Statement to select * from SDAPPS
, then click Test.
If the connection is not established successfully, restart OC4J and then test the data source again. If it still fails, ensure that your connection pool settings are correct.
The JDBC configuration that you have just created for rtdGroup will be copied to rtdGroup2, after you stop Oracle AS, as follows:
In OAS_HOME
/opmn/bin
, run opmnctl.exe stopall
To set server properties, edit the file OAS_HOME
/opmn/conf/opmn.xml
.
For each rtd instance, perform the following tasks:
To adjust start parameters, perform the following steps:
Add the following to the start parameters, all on one line:
-Drtd.instanceName=rtd_1_1 -DSDGroupName=rtdDon -DRestrictClusterMembers=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=12351 -Djava.net.preferIPv4Stack=true
For rtd.instanceName
, use the appropriate OC4J instance name (rtd_1_1, rtd_1_2, and so on). If you are not using the suggested instance name convention (rtd_<host_number>_<instance_within_host>), use any alphanumeric string that is a valid file name, with no space or special characters.
For SDGroupName
, use the same name for all OC4J instances in the cluster, across all hosts. Ensure that the name uses alphanumeric characters without spaces or punctuation.
For jmxremote.port
, use a distinct port for each instance in this host.
Tip:
Let the last digit of the port (as in the examples1235
1
, 1235
2
, 1235
3
, and so on) represent the instance number within the port.Note that the jmx properties are optional. If you prefer using Enterprise Manager to access the OracleRTD MBeans instead of JConsole, do not add the following properties:
-Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.port=12351
Reduce memory.
You may want to let each OC4J instance start with less memory, including j2ee/home, the one that runs ascontrol
.
Add or change the following options to the java start options, in the same string as the system properties listed in step 1 of this section:
-Xmx1024M
-Xms128M
-XX:MaxPermSize=128M
Disable Learning Service or Decision Service.
Note:
This step is optional at this point, because you can perform the same task through JConsole after starting the Oracle RTD instances, as described in Section 13.9.13, "Disabling Certain Oracle RTD Services."If you choose to disable Learning Service or Decision Service through system properties, add the following properties to opmn.xml
:
-DLearningServiceEnabled=false
-DDecisionServiceEnabled=false
Change the referenced web-site from default-web-site
to rtd-web-site
. For example:
<port id="
rtd-web-site
" range="12501-12600" protocol="ajp"/>
Ensure that opmn.xml
has the right group specification for each OC4J instance.
The last element inside <process-type>
is the process-set
element. Check that the process-set id
value is the same as the OC4J group name, as in the following example:
<process-set id="
rtdGroup
" numprocs="1"/>
For each of the OC4J instances in rtdGroup, you should see a file:
OAS_HOME
/j2ee/
OC4J_INSTANCE
/config/data-sources.xml
These should have been created in the previous procedures, and contain something similar to the following:
<?xml version = '1.0' encoding = 'UTF-8'?>
<data-sources xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/data-sources-10_1.xsd" schema-major-version="10" schema-minor-version="1">
<managed-data-source connection-pool-name="RTDConnectionPool" jndi-name="jdbc/SDDS" name="RTD_DS"/>
<connection-pool name="RTDConnectionPool">
<connection-factory factory-class="com.microsoft.sqlserver.jdbc.SQLServerDriver" user="userName" password="myPassword" url="jdbc:sqlserver://myhost:1433;databaseName=mydb"/>
</connection-pool>
</data-sources>
Copy one of these to the OC4J instances in the other OC4J group, rtdGroup2.
For each OC4J instance, perform the following tasks:
In the file OAS_HOME
/j2ee/
OC4J_INSTANCE
/config/server.xml
, change:
<web-site default="true" path="./default-web-site.xml" />
to
<web-site default="true" path="./
rtd-web-site.xml
" />
To create rtd-web-ste.xml, perform the following steps:
Create the file OAS_HOME
/j2ee/
OC4J_INSTANCE
/config/rtd-web-site.xml
, by copying default-web-site.xml
in the same directory.
Delete all of its <web-app>
elements (others will be added automatically when you deploy OracleRTD).
Leave the port set to 0
, since this will be adjusted automatically when OPMN starts the OC4J instance.
Leave the protocol set to ajp
. This is required for clustering.
To deploy RTD.ear
into rtdGroup as OracleRTD, perform the following steps:
Start Oracle AS, by running OAS_HOME
/opmn/bin/opmnctl.exe startall
.
Login to Enterprise Manager: http://localhost:7777/em
.
Drill into the OC4J group rtdGroup.
Select its Application tab.
Click Deploy.
Select RTD.ear in the location where you unzipped it.
The deployment plan strategy to adopt is as follows:
For Oracle RTD Type 1 and Type 2 clusters, let the deployment create its own deployment plan
For Oracle RTD Type 3 clusters, let the first-time deployment create its own deployment plan, save the plan, then use it on subsequent deployments
Click Next to upload RTD.ear.
Enter OracleRTD
as the application name.
This is required because the file orion-application.xml
provided with Oracle RTD refers to its containing directory as OracleRTD.
Select rtd-web-site as the target web-site.
Note:
This is the main point at which the deployment varies according to cluster type, where you need to specify which Oracle RTD services need to be dispatchable through the public OHS (Oracle HTTP Server) port.The requirement is for OHS (Oracle HTTP Server) to dispatch requests from Decision Center (/ui), Studio (/soap), and Decision Service clients (/rtis) to the group where these services are activated. To achieve this, the next step sets up alternative web context roots for the deactivated services.
For type 1 and 2 clusters, leave the web context-roots as they are, namely:
/ui, /ls, /soap, /schema, /rtis
For type 3 (DS only) clusters, during the first-time deployment, adjust the proposed web context-roots by appending "-ds" to each of them except /rtis, as follows:
/ui-ds, /ls-ds, /soap-ds, /schema-ds, /rtis
Save the deployment plan for subsequent deployments.
Tip:
Give the plan a name that indicates its function, such asdsPlan.dat
for a DS-only cluster.Click Next to accept the deployment plan.
Click Next to start the deployment.
The steps here are the same as for rtdGroup, except for the following:
The web-app bindings will be different.
The application name must different (OracleRTD2 versus OracleRTD) because OHS keys its routing instructions based on application name.
In the Enterprise Manager, drill into OC4J group rtdGroup2.
Select its Application tab.
Click Deploy.
Select RTD.ear in the location where you unzipped it.
Click Next to upload RTD.ear.
Enter OracleRTD2
as the application name.
Select rtd-web-site as the target web-site.
Click Next.
Edit the web context-roots as follows (for first-time deployment only):
For Type 2 (LS only) clusters:
Adjust the proposed web context-roots by appending "-2" to each of them:
/ui-2, /ls-2, /soap-2, /schema-2, /rtis-2
Edit the deployment plan:
Change the classpath settings to refer to the new application name ${oracle.j2ee.home}/OracleRTD2
instead of ${oracle.j2ee.home}/OracleRTD
.
Save the deployment plan for subsequent deployments, for example, naming it lsPlan.dat
.
For Type 3 (DC and LS) clusters:
Adjust the proposed web context-roots by appending "-2" to /rtis:
/ui, /ls, /soap, /schema, /rtis-2
Edit the deployment plan:
Change the classpath settings to refer to the new application name ${oracle.j2ee.home}/OracleRTD2
instead of ${oracle.j2ee.home}/OracleRTD
.
Save the deployment plan for subsequent deployments, for example, naming it dcLsPlan.dat
.
Click Next to start the deployment.
To verify the configuration, perform the following steps:
Stop Oracle AS.
Verify rtd-web-site.xml.
rtdGroup Verification
In the rtd_1_1 and rtd_1_2 instances, there should be web-app entries bound to /ui, /schema, and so on:
<?xml version="1.0"?>
<web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/web-site-10_0.xsd" port="12552" protocol="ajp13" display-name="OC4J 10g (10.1.3) RTD Web Site" schema-major-version="10" schema-minor-version="0" >
<default-web-app application="default" name="defaultWebApp" root="/j2ee" />
<web-app application="OracleRTD" name="ui" load-on-startup="true"
root="/ui"
/>
<web-app application="OracleRTD" name="schema" load-on-startup="true"
root="/schema"
/>
<web-app application="OracleRTD" name="soap" load-on-startup="true"
root="/soap"
/>
<web-app application="OracleRTD" name="ls" load-on-startup="true"
root="/ls"
/>
<web-app application="OracleRTD" name="rtis" load-on-startup="true"
root="/rtis"
/>
<access-log path="../log/default-web-access.log" split="day" />
</web-site>
rtdGroup2 Verification
In the rtd_1_3 and rtd_1_4 instances, there should be web-app entries bound to /ui-ls, /schema-ls, and so on:
<?xml version="1.0"?>
<web-site xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xmlns.oracle.com/oracleas/schema/web-site-10_0.xsd" port="12553" protocol="ajp13" display-name="OC4J 10g (10.1.3) RTD Web Site" schema-major-version="10" schema-minor-version="0" >
<default-web-app application="default" name="defaultWebApp" root="/j2ee" />
<web-app application="OracleRTD" name="ui" load-on-startup="true"
root="/ui-ls"
/>
<web-app application="OracleRTD" name="schema" load-on-startup="true"
root="/schema-ls"
/>
<web-app application="OracleRTD" name="soap" load-on-startup="true"
root="/soap-ls"
/>
<web-app application="OracleRTD" name="ls" load-on-startup="true"
root="/ls-ls"
/>
<web-app application="OracleRTD" name="rtis" load-on-startup="true"
root="/rtis-ls"
/>
<access-log path="../log/default-web-access.log" split="day" />
</web-site>
The port assignment is not important, as it happens automatically.
Use JConsole or other MBean browsers to disable Decision Service or Learning Service in certain Oracle RTD instances according to the cluster type. This only needs to be done when changing cluster types. It is not necessary if redeploying Oracle RTD into the same cluster type.
Note:
The instructions for type 2 and type 3 clusters are currently the same. So, if you switch from a type 2 to a type 3 cluster, or vice versa, no actions are required in this section.Start JConsole and connect to each instance. For each instance, do the following:
Cluster Type 1: No changes are required
Cluster Type 2
rtdGroup (runs DS and DC)
For instances rtd_1_1, rtd_1_2, rtd_2_1, rtd_2_2, disable LS:
- Navigate: OracleRTD > SDPropertyManager > Misc
- Set: LearningServiceEnabled = false
rtdGroup2 (runs LS)
For instances rtd_1_3, rtd_1_4, rtd_2_3, rtd_2_4, disable DS:
- Navigate: OracleRTD > SDPropertyManager > Misc
- Set: DecisionServiceEnabled = false
Cluster Type 3
rtdGroup (runs DS)
For instances rtd_1_1, rtd_1_2, rtd_2_1, rtd_2_2, disable LS:
- Navigate: OracleRTD > SDPropertyManager > Misc
- Set: LearningServiceEnabled = false
rtdGroup2 (runs DC and LS)
For instances rtd_1_3, rtd_1_4, rtd_2_3, rtd_2_4, disable DS:
- Navigate: OracleRTD > SDPropertyManager > Misc
- Set: DecisionServiceEnabled = false
Set Decision Service Address.
For Type 3 clusters, where DC and DS are not co-located, use JConsole to set the cluster's Decision Service address, so that DC can send test events from its Interactive Integration Map view.
- Navigate: OracleRTD > SDPropertyManager > Misc
- Set: DecisionServiceAddress = http://myHost.com:8080
In this example, start first with host2 first, then host1, so that host1 will be running ascontrol
at the end of the process.
Suppose you installed two separate Oracle Application Server instances (as1 on Host1 and as2 on Host2) and during the installation of both instances, you selected the option to include an Administration OC4J. You did not, however, select the option to define a multicast address and join an existing Oracle Application Server cluster.
In this scenario, each Oracle Application Server instance is running a separate Application Server Control.
To combine these two instances into one cluster topology so they are managed by one Cluster Topology page, which is displayed by one active Application Server Control, perform the following steps.
Open your Web browser and enter the Application Server Control URL for as1.
Log in to the Application Server Control, and scroll to the Administration section of the Cluster Topology page.
Click Topology Network Configuration to display the Topology Network Configuration page.
Note:
On the Topology Network Configuration page:The current application server instance is selected in the View By field.
The fields in the Topology section of the page are empty. This indicates that the application server instance does not belong to a cluster.
Select Configuring Dynamic Node Discovery Using Multicast and enter a multicast address and port number in the Discover field.
For example: 229.1.2.50:5555
The multicast address must be within the following range: 224.0.0.1 to 239.255.255.255. The port can be any four-digit number. In the configuration file, the multicast address must be preceded by an asterisk (*), but when you enter the address in this field, Application Server Control automatically includes the asterisk if you do not specify it here.
Make a note of the multicast address and port, and then click Apply.
Enter the Application Server Control URL for as2.
Repeat steps 2 through 5 for as2.
Be sure to use the same multicast address and port that you used when you configured as1.
Navigate to the Cluster Topology page.
Note that both Oracle Application Server instances now appear on the Cluster Topology page.
Click Expand All and then select the ascontrol application (which represents the Application Server Control) that is deployed to the as1 instance.
Click Stop to stop the selected ascontrol application.
Note: Do not stop the active ascontrol application, but stop any other ascontrol applications that are up and running. There is no need to run two Application Server Control applications in the same cluster.
This section describes the JBoss clustering install instructions, assuming that you have two machines to be set up as follows:
Machine #1
Oracle RTD software
JBoss Application Server
Apache HTTP Server
Machine #2
JBoss Application Server
Oracle RTD JDBC JAR and SSL Files
The rest of this section consists of the following topics:
Section 13.10.3, "Setting Up and Installing the Apache Software"
Section 13.10.9, "Undeploying RTD.ear from the JBoss Cluster"
To install the Oracle RTD software, perform the following steps:
On Machine #1, install Oracle RTD from rtd_3.0.0_jboss_win.zip
(or rtd_3.0.0_jboss_unix.cpio
if on Linux/Unix) to RTD_HOME
, for example, C:\OracleBI\RTD
.
On Machine #2, create the following directory: RTD_HOME
\lib\jdbc\
.
On Machine #1, copy the jars in RTD_HOME
\lib\jdbc\
to RTD_HOME
\lib\jdbc\
on Machine #2.
On Machine #2, create the following directory: RTD_HOME
\etc\ssl\
.
On Machine #1, copy the file RTD_HOME
\etc\ssl\sdserver.keystore
to RTD_HOME
\etc\ssl\
on Machine #2.
On Machine #2, create the following directory: RTD_HOME
\log\
.
To initialize the Oracle RTD database on Machine #1, run the following script:
RTD_HOME
\scripts\SDDBTool.cmd
For more information, see Section 2.2.4, "Initializing the Oracle RTD Database Using SDDBTool."
This section consists of the following topics:
Section 13.10.3.1, "Installing the Apache Server and Downloading mod_jk"
Section 13.10.3.4, "Creating the File uriworkermap.properties"
To install the Apache server and to download mod_jk, perform the following steps:
On Machine #1, download Apache HTTP Server 2.2.6 (apache_2.2.6-win32-x86-no_ssl.msi
) from http://archive.apache.org/dist/httpd/binaries/win32/
.
On Machine #1 in the cluster, install Apache HTTP Server 2.2.6 to APACHE_INSTALL_DIR
, for example, C:\Program Files\
.
Terminology:
From this point on,APACHE_HOME_DIR
refers to APACHE_INSTALL_DIR
\Apache Software Foundation\Apache2.2
Download Mod JK 1.2 (mod_jk-1.2.27-httpd-2.2.10.so
) from http://www.apache.org/dist/tomcat/tomcat-connectors/jk/binaries/win32/jk-1.2.27/
.
Rename it to mod_jk.so
and copy it to APACHE_HOME_DIR
\modules\
.
To configure the Apache server, perform the following steps:
On Machine #1, open APACHE_HOME_DIR
\conf\httpd.conf
.
For example: C:\Program Files\Apache Software Foundation\Apache2.2\conf\httpd.conf
Change the port for the property Listen to 8080
.
For example: Listen 8080
Change the port for the property ServerName to 8080
.
For example: ServerName myHostName.us.oracle.com:8080
At the end of httpd.conf
, add the following lines:
# Include mod_jk's specific configuration file Include conf/mod_jk.conf
Save the file httpd.conf
.
To create the file mod_jk.conf
, perform the following steps:
On Machine #1, create a new text file called mod_jk.conf
.
Add the following lines to mod_jk.conf
:
# Load mod_jk module # Specify the filename of the mod_jk lib LoadModule jk_module modules/mod_jk.so # Where to find workers.properties JkWorkersFile conf/workers.properties # Where to put jk logs JkLogFile logs/mod_jk.log # Set the jk log level [debug/error/info] JkLogLevel info # Select the log format JkLogStampFormat "[%a %b %d %H:%M:%S %Y]" # JkOptions indicates to send SSK KEY SIZE JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories # JkRequestLogFormat JkRequestLogFormat "%w %V %T" # Mount your applications JkMount /application/* loadbalancer # You can use external file for mount points. # It will be checked for updates each 60 seconds. # The format of the file is: /url=worker # /examples/*=loadbalancer JkMountFile conf/uriworkermap.properties # Add shared memory. # This directive is present with 1.2.10 and # later versions of mod_jk, and is needed for # for load balancing to work properly JkShmFile logs/jk.shm # Add jkstatus for managing runtime data <Location /jkstatus/> JkMount status Order deny,allow Deny from all Allow from 127.0.0.1 </Location>
Save the file to APACHE_HOME_DIR
\conf\mod_jk.conf
.
For example: C:\Program Files\Apache Software Foundation\Apache2.2\conf\mod_jk.conf
To create the file uriworkermap.properties
, perform the following steps:
On Machine #1, create a new text file called uriworkermap.properties
.
Add the following lines to uriworkermap.properties
:
# Simple worker configuration file # Mount the Servlet context to the ajp13 worker /jmx-console=loadbalancer /jmx-console/*=loadbalancer /web-console=loadbalancer /web-console/*=loadbalancer /ui=loadbalancer /ui/*=loadbalancer /schema=loadbalancer /schema/*=loadbalancer /soap=loadbalancer /soap/*=loadbalancer /rtis=loadbalancer /rtis/*=loadbalancer /ls=loadbalancer /ls/*=loadbalancer
Save the file to APACHE_HOME_DIR
\conf\uriworkermap.properties
.
For example: C:\Program Files\Apache Software Foundation\Apache2.2\conf\uriworkermap.properties
To create the file workers.properties
, perform the following steps:
On Machine #1, create a new text file called workers.properties
.
Add the following lines to workers.properties
, after making the two substitutions:
Replace MACHINE_1_HOST
with the Machine #1 host URL or IP address, for example, machine1.mydomain.com
Replace MACHINE_2_HOST
with the Machine #2 host URL or IP address, for example, machine2.mydomain.com
# Define list of workers that will be used # for mapping requests worker.list=loadbalancer,status # Define Node1 # modify the host as your host IP or DNS name. worker.node1.port=8009 worker.node1.host=MACHINE_1_HOST worker.node1.type=ajp13 worker.node1.lbfactor=1 # Define Node2 # modify the host as your host IP or DNS name. worker.node2.port=8009 worker.node2.host=MACHINE_2_HOST worker.node2.type=ajp13 worker.node2.lbfactor=1 # Load-balancing behaviour worker.loadbalancer.type=lb worker.loadbalancer.balance_workers=node1,node2 worker.loadbalancer.sticky_session=1 #worker.list=loadbalancer # Status worker for managing load balancer worker.status.type=status
Save the file to APACHE_HOME_DIR
\conf\workers.properties
.
For example: C:\Program Files\Apache Software Foundation\Apache2.2\conf\workers.properties
If the Apache Server has already been started, you can skip this section.
Before you start the Apache HTTP Server, check that the Apache 2.2 service has been installed. If it has not been installed, run the following command from the directory C:\Program Files\Apache Software Foundation\Apache2.2\bin
:
httpd -k install -n "Apache2.2"
To start the Apache HTTP Server on Machine #1, perform either of the following tasks:
Navigate the menu path: Start > All Programs > Apache HTTP Server 2.2.6 > Control Apache Server > Start
From the directory C:\Program Files\Apache Software Foundation\Apache2.2\bin
, run the command: httpd -k start
The logs will be in C:\Program Files\Apache Software Foundation\Apache2.2\logs\
.
Note:
To stop the Apache HTTP Server, perform either of the following:Navigate the menu path: Start > All Programs > Apache HTTP Server 2.2.6 > Control Apache Server > Stop
From the directory C:\Program Files\Apache Software Foundation\Apache2.2\bin
, run the command: httpd -k stop
To install the JBoss software, perform the following steps:
On Machine #1, install JBoss EAP 4.3.
The directory into which you installed JBoss will be referred to as
.JBOSS_HOME
For example, C:\Program Files\EnterprisePlatform-4.3.0.GA_CP03
, C:\jboss-eap-4.3
, or d:\genesis\jboss-eap-4.3
Repeat step 1 for Machine #2 in the cluster.
To configure the JBoss software, you must perform essentially the same operations on both Machine #1 and Machine #2, as described in the following sections.
On Machine #1, open the file JBOSS_HOME
/jboss-as/server/all/conf/props/jmx-console-users.properties
.
Uncomment the sample user/password (if needed): #admin=admin
.
You can create any user name and password, for example: charles=pswd
.
Save the file.
Repeat steps 1-3 on Machine #2.
On Machine #1, open the file JBOSS_HOME
/jboss-as/server/all/deploy/jboss-web.deployer/server.xml
.
For HTTP, near the top of the file at "<Connector port="8080"
...", change the port to 8081
, and add the following line after the "enableLookups"
line:
URIEncoding="UTF-8"
For example:
<Connector port="8081" address="${jboss.bind.address}" maxThreads="250" maxHttpHeaderSize="8192" emptySessionPath="true" protocol="HTTP/1.1" enableLookups="false" redirectPort="8443" acceptCount="100" URIEncoding="UTF-8" connectionTimeout="20000" disableUploadTimeout="true" />
For HTTPS, near the top of the file, replace:
<!-- <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" /> -->
with:
<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" minSpareThreads="5" maxSpareThreads="15" address="${jboss.bind.address}" keystoreFile="${rtd.home.dir}/etc/ssl/sdserver.keystore" URIEncoding="UTF-8" keystorePass="tc-ssl" />
Save the file.
Repeat steps 1-4 on Machine #2.
On Machine #1, open JBOSS_HOME
/jboss-as/server/all/deploy/jboss-web.deployer/conf/web.xml
.
Locate:
<servlet> <servlet-name>jsp</servlet-name>
and add the following servlet init
parameters, if they do not already exist in the file:
<init-param> <param-name>compilerSourceVM</param-name> <param-value>1.5</param-value> </init-param> <init-param> <param-name>compilerTargetVM</param-name> <param-value>1.5</param-value> </init-param>
Save the file.
Repeat steps 1-3 on Machine #2.
On Machine #1, open JBOSS_HOME
/jboss-as/server/all/conf/jboss-log4j.xml
.
Locate the section starting with the following lines:
<!-- ============================== --> <!-- Append messages to the console --> <!-- ============================== -->
and add the following at the end of the above section:
<!-- ============================================== --> <!-- START: Oracle RTD Appender Message Definitions --> <!-- ============================================== --> <appender name="SIGMA" class="com.sigmadynamics.util.SDRollingZipFileAppender"> <param name="Threshold" value="DEBUG"/> <param name="File" value="${rtd.log.file}"/> <param name="Append" value="true"/> <param name="MaxFileSize" value="20000KB"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d{ISO8601} %-5p [%c{1}] %m%n"/> <!-- <param name="ConversionPattern" value="%d{{HH:mm:ss,SSS}} [%t] %-5p [%c{1}] %m%n"/> --> </layout> <filter class="org.jboss.logging.filter.TCLFilter"> <param name="AcceptOnMatch" value="true"/> <param name="DeployURL" value="RTD.ear"/> </filter> <filter class="org.apache.log4j.varia.DenyAllFilter"/> </appender> <appender name="ENG_TRACE_FILE" class="com.sigmadynamics.util.SDRollingZipFileAppender"> <param name="Threshold" value="TRACE"/> <param name="File" value="${rtd.log.file}.trace"/> <param name="Append" value="true"/> <param name="MaxFileSize" value="20000KB"/> <layout class="org.apache.log4j.PatternLayout"> <param name="ConversionPattern" value="%d{{HH:mm:ss,SSS}} [%t] %m%n"/> <!-- <param name="ConversionPattern" value="%d{{HH:mm:ss,SSS}} [%t] %-5p [%c{1}] %m%n"/> --> </layout> </appender> <!-- ============================================== --> <!-- END: Oracle RTD Appender Message Definitions --> <!-- ============================================== -->
Locate the section starting with the following lines:
<!-- ====================== --> <!-- More Appender examples --> <!-- ====================== -->
and add the following at the end of the above section:
<!-- ============================================== --> <!-- START: Oracle RTD Limit Category Definitions --> <!-- ============================================== --> <!-- Messages logged to this TRACE category go only to the trace file, since its additivity flag is false. This is only used temporarily by RTD engineers for debugging low-level stuff like request queuing and load shunting. It's a place to direct topical information while avoiding all the stuff that's going to the normal log file. --> <category name="ENG_TRACE" additivity="false"> <priority value="DEBUG"/> <appender-ref ref="ENG_TRACE_FILE"/> </category> <category name="com.sigmadynamics.server.SDDistributedHashtable"> <priority value="ERROR"/> </category> <category name="com.sigmadynamics.client"> <priority value="ERROR"/> </category> <category name="com.sigmadynamics"> <priority value="DEBUG"/> <!-- <priority value="TRACE#com.sigmadynamics.util.XLevel"/> --> </category> <category name="org.jboss.messaging.core.impl.JDBCSupport"> <priority value="INFO"/> </category> <category name="org.jboss.jms.server.plugin.JDBCJMSUserManager"> <priority value="INFO"/> </category> <category name="org.jgroups.protocols"> <priority value="ERROR"/> </category> <category name="sigmadynamics.application"> <priority value="DEBUG"/> </category> <category name="request.trace.sigmadynamics.application"> <priority value="TRACE#com.sigmadynamics.util.XLevel"/> </category> <category name="request.log.sigmadynamics.application"> <priority value="DEBUG"/> </category> <!-- ============================================== --> <!-- END: Oracle RTD Limit Category Definitions --> <!-- ============================================== -->
Locate:
<!-- ======================= --> <!-- Setup the Root category --> <!-- ======================= -->
and add the following line to <root>
:
<appender-ref ref="SIGMA"/>
Save the file.
Repeat steps 1-5 on Machine #2.
Note:
This adds Oracle RTD classes for displaying Oracle RTD server logs.On Machine #1, copy RTD_HOME
/package/jboss/rtdlog4j.jar
to JBOSS_HOME
/jboss-as/server/all/lib/
.
Repeat step 1 on Machine #2 by copying over rtdlog4j.jar
to Machine #2.
Note:
This overrides the older version of the Eclipse JDT compilerjsaper-jdt.jar
.
See JBoss Bug #JBPAPP-869: https://jira.jboss.org/jira/browse/JBPAPP-869
.
On Machine #1, copy RTD_HOME
/package/jboss/ecj-3.4.jar
to JBOSS_HOME
/jboss-as/server/all/deploy/jboss-web.deployer/.
Repeat step 1 on Machine #2 by copying over ecj-3.4.jar
to Machine #2.
Note:
This replaces JBoss jgroups version 2.4 with Oracle RTD jgroups version 2.6.1.On Machine #1, rename the file JBOSS_HOME
/jboss-as/server/all/lib/jgroups.jar
to jgroups.jar.original
.
Copy RTD_HOME
/lib/jgroups-all2.6.1.jar
to the directory JBOSS_HOME
/jboss-as/server/all/lib/
, and rename the file in the receiving directory to jgroups.jar.
Repeat steps 1-2 on Machine #2 by copying over jgroups-all2.6.1.jar
to Machine #2.
On Machine #1, open JBOSS_HOME
/jboss-as/server/all/deploy/jboss-web.deployer/META-INF/jboss-service.xml
.
Locate:
<attribute name="UseJK">
and set the value to true:
<attribute name="UseJK">true</attribute>
Save the file.
Repeat steps 1-3 on Machine #2.
On Machine #1, open JBOSS_HOME
/jboss-as/server/all/deploy/jboss-web.deployer/server.xml
.
Locate:
<Engine name="jboss.web"
and add an attribute jvmRoute
as follows, with value node1
for Machine #1 (and later node2
for Machine #2):
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="node1"> ...... </Engine>
Save the file.
Repeat steps 1-3 on Machine #2.
On Machine #1, in RTD_HOME
/package/jboss
, choose your supported database and open the file appropriate to that database, as follows:
For DB2: rtd-db2-ds.xml
For Oracle: rtd-oracle-ds.xml
For SQL Server: rtd-sqlserver-ds.xml
Replace the following:
${DB_SERVER}
with your database server
For example: localhost
Note:
If the database is on a SQL Server named instance, specify the name of your database server using the formathost_name\instance_name
.${DB_PORT}
with your database port
For example: 50000
for db2, 1521
for oracle, 1433
for sqlserver
${DB_NAME}
with your database name
For example: RTD
for db2 and sqlserver, orcl
for oracle
${DB_USER}
with your database user name
For example: jsmith
${DB_PASSWORD}
with your database user password
Save the file and copy it to JBOSS_HOME
/jboss-as/server/all/deploy/.
Repeat step 3 on Machine #2 by copying over the appropriate "-ds.xml
" file to Machine #2.
On Windows
On Machine #1, open JBOSS_HOME
/jboss-as/bin/run.bat
.
If you modified run.bat
by applying the changes described in Section 6.1.4.1, "Modifying the Windows JBoss Start Script" in Oracle Real-Time Decisions Installation and Administration Guide, then revert those changes.
Near the top of the file, add the following "set
" lines, after making these substitutions:
Replace RTD_HOME_TO_REPLACE
with your actual value, for example, C:\OracleBI\RTD
Replace MACHINE_1_IP_ADDR
with Machine #1 IP address, for example, 10.234.7.2
Replace MACHINE_2_IP_ADDR
with Machine #2 IP address, for example, 10.234.7.3
Notes:
-DJGroupsMulticastPort
and -DJGroupsMulticastAddress
. For more information on the configuration properties, see Chapter 13.3, "Cluster-Specific Configuration Properties" of Oracle Real-Time Decisions Installation and Administration Guide.To make the cluster unique, that is, to create an independent JBoss cluster on the network, change the values of the parameters RTD_JGROUPS_MULTICAST_ADDR
and SDGroupName
.
For example, replace the equivalent lines in the following script with:
set RTD_JGROUPS_MULTICAST_ADDR=228.64.16.55 set JAVA_OPTS=%JAVA_OPTS% -DSDGroupName=OracleRtdCluster2
set RTD_HOME=RTD_HOME_TO_REPLACE set RTD_CLUSTER_MEMBERS=MACHINE_1_IP_ADDR;MACHINE_2_IP_ADDR set RTD_JGROUPS_MULTICAST_ADDR=228.64.16.54
set JAVA_OPTS=-Djboss.partition.name=OracleRtdPartition set JAVA_OPTS=%JAVA_OPTS% -Dorg.jboss.net.protocol.file.decodeFilePaths=true set JAVA_OPTS=%JAVA_OPTS% -Djboss.partition.udpGroup=%RTD_JGROUPS_MULTICAST_ADDR% set JAVA_OPTS=%JAVA_OPTS% -Djboss.hapartition.mcast_port=45501 set JAVA_OPTS=%JAVA_OPTS% -Dhibernate.connection.release_mode=auto set JAVA_OPTS=%JAVA_OPTS% -Dbind.address=localhost set JAVA_OPTS=%JAVA_OPTS% -Dnologging=true set JAVA_OPTS=%JAVA_OPTS% -DSDLoggingPriority=DEBUG set JAVA_OPTS=%JAVA_OPTS% -DJGroupsMulticastAddress=%RTD_JGROUPS_MULTICAST_ADDR% set JAVA_OPTS=%JAVA_OPTS% -DJGroupsMulticastPort=45502 set JAVA_OPTS=%JAVA_OPTS% -DJGroupsDSMulticastAddress=%RTD_JGROUPS_MULTICAST_ADDR% set JAVA_OPTS=%JAVA_OPTS% -DJGroupsDSMulticastPort=45503 set JAVA_OPTS=%JAVA_OPTS% -DSDGroupName=OracleRtdCluster set JAVA_OPTS=%JAVA_OPTS% -DTrustedClusterMembers=%RTD_CLUSTER_MEMBERS% set JAVA_OPTS=%JAVA_OPTS% -Drtd.home.dir=%RTD_HOME% set JAVA_OPTS=%JAVA_OPTS% -Drtd.log.file=%RTD_HOME%/log/server.log set JAVA_OPTS=%JAVA_OPTS% -DSDLoggingFileName=%RTD_HOME%/log/server.log set JAVA_OPTS=%JAVA_OPTS% -DDSPerfCounterLogFile=%RTD_HOME%/log/ds_perf.cvs set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote=true set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.port=12345 set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.authenticate=false set JAVA_OPTS=%JAVA_OPTS% -Dcom.sun.management.jmxremote.ssl=false set JAVA_OPTS=%JAVA_OPTS% -Djava.net.preferIPv4Stack=true set JBOSS_CLASSPATH=%RTD_HOME%/lib/jdbc/bijdbc14.jar set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;%RTD_HOME%/lib/jdbc/sqljdbc.jar set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;%RTD_HOME%/lib/jdbc/db2jcc_license_cu.jar set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;%RTD_HOME%/lib/jdbc/db2jcc.jar set JBOSS_CLASSPATH=%JBOSS_CLASSPATH%;%RTD_HOME%/lib/jdbc/ojdbc14.jar
Save the file.
Repeat steps 1-3 on Machine #2.
On Unix
On Machine #1, open JBOSS_HOME
/jboss-as/bin/run.sh
.
If you modified run.sh
by applying the changes described in Section 6.1.4.2, "Modifying the Unix JBoss Start Script" in Oracle Real-Time Decisions Installation and Administration Guide, then revert those changes.
Near the top of the file, add the following "set
" lines, after making these substitutions:
Replace JAVA_HOME_TO_REPLACE
with your actual value
Replace RTD_HOME_TO_REPLACE
with your actual value, for example, C:\OracleBI\RTD
Replace MACHINE_1_IP_ADDR
with Machine #1 IP address, for example, 10.234.7.2
Replace MACHINE_2_IP_ADDR
with Machine #2 IP address, for example, 10.234.7.3
Notes:
-DJGroupsMulticastPort
and -DJGroupsMulticastAddress
. For more information on the configuration properties, see Chapter 13.3, "Cluster-Specific Configuration Properties" of Oracle Real-Time Decisions Installation and Administration Guide.To make the cluster unique, that is, to create an independent JBoss cluster on the network, change the values of the parameters RTD_JGROUPS_MULTICAST_ADDR
and SDGroupName
.
For example, replace the equivalent lines in the following script with:
RTD_JGROUPS_MULTICAST_ADDR=228.64.16.55 JAVA_OPTS="$JAVA_OPTS -DSDGroupName=OracleRtdCluster2"
JAVA_HOME="JAVAHOME_TO_REPLACE" export JAVA_HOME RTD_HOME="RTD_HOME_TO_REPLACE" RTD_CLUSTER_MEMBERS=MACHINE_1_IP_ADDR;MACHINE_2_IP_ADDR RTD_JGROUPS_MULTICAST_ADDR=228.64.16.54 JAVA_OPTS=-Djboss.partition.name=OracleRtdPartition JAVA_OPTS="$JAVA_OPTS -Dorg.jboss.net.protocol.file.decodeFilePaths=true" JAVA_OPTS="$JAVA_OPTS -Djboss.partition.udpGroup=$RTD_JGROUPS_MULTICAST_ADDR" JAVA_OPTS="$JAVA_OPTS -Djboss.hapartition.mcast_port=45501" JAVA_OPTS="$JAVA_OPTS -Dhibernate.connection.release_mode=auto" JAVA_OPTS="$JAVA_OPTS -Dbind.address=localhost" JAVA_OPTS="$JAVA_OPTS -Dnologging=true" JAVA_OPTS="$JAVA_OPTS -DSDLoggingPriority=DEBUG" JAVA_OPTS="$JAVA_OPTS -DJGroupsMulticastAddress=$RTD_JGROUPS_MULTICAST_ADDR" JAVA_OPTS="$JAVA_OPTS -DJGroupsMulticastPort=45502" JAVA_OPTS="$JAVA_OPTS -DJGroupsDSMulticastAddress=$RTD_JGROUPS_MULTICAST_ADDR" JAVA_OPTS="$JAVA_OPTS -DJGroupsDSMulticastPort=45503" JAVA_OPTS="$JAVA_OPTS -DSDGroupName=OracleRtdCluster" JAVA_OPTS="$JAVA_OPTS -DTrustedClusterMembers=$RTD_CLUSTER_MEMBERS" JAVA_OPTS="$JAVA_OPTS -Drtd.home.dir=$RTD_HOME" JAVA_OPTS="$JAVA_OPTS -Drtd.log.file=$RTD_HOME/log/server.log" JAVA_OPTS="$JAVA_OPTS -DSDLoggingFileName=$RTD_HOME/log/server.log" JAVA_OPTS="$JAVA_OPTS -DDSPerfCounterLogFile=$RTD_HOME/log/ds_perf.cvs" JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote=true" JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=12345" JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false" JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false" JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true" JBOSS_CLASSPATH="$RTD_HOME/lib/jdbc/bijdbc14.jar" JBOSS_CLASSPATH="$JBOSS_CLASSPATH:$RTD_HOME/lib/jdbc/sqljdbc.jar" JBOSS_CLASSPATH="$JBOSS_CLASSPATH:$RTD_HOME/lib/jdbc/db2jcc_license_cu.jar" JBOSS_CLASSPATH="$JBOSS_CLASSPATH:$RTD_HOME/lib/jdbc/db2jcc.jar" JBOSS_CLASSPATH="$JBOSS_CLASSPATH:$RTD_HOME/lib/jdbc/ojdbc14.jar"
Save the file.
Repeat steps 1-3 on Machine #2.
On Machine #2, open JBOSS_HOME
/jboss-as/server/all/deploy/jboss-messaging.sar/messaging-service.xml
.
Locate the ServerPeerID
attribute line, and change the id from 0
to 1
as follows:
<attribute name = "ServerPeerId>${jboss.messaging.ServerPeerId:1}</attribute>
Save the file.
Note:
See JBoss Bug #JBAS-3968https://jira.jboss.org/jira/browse/JBAS-3968
.Before proceeding, create Oracle RTD roles and users in JBoss for each machine in your cluster. See Section 6.3, "Creating Oracle RTD Roles and Users" in Oracle Real-Time Decisions Installation and Administration Guide for more information.
As you follow the instructions in this section, be sure to edit the users.properties
file in the all
directory rather than the default
directory. Specifically, the directory JBOSS_HOME
/jboss-as/server/default/conf/users.properties
that is mentioned in Section 6.3.1 in Oracle Real-Time Decisions Installation and Administration Guide should be JBOSS_HOME
/jboss-as/server/all/conf/users.properties
when you are using a clustered environment. Create the file if it does not already exist.
Similarly, you should edit the roles.properties
file in the all
directory rather than the default
directory. In particular, the directory JBOSS_HOME
/jboss-as/server/default/conf/roles.properties
that is mentioned in Section 6.3.2 in Oracle Real-Time Decisions Installation and Administration Guide should be JBOSS_HOME
/jboss-as/server/all/conf/roles.properties
when you are using a clustered environment. Create the file if it does not already exist.
To start the JBoss application server, perform the following tasks:
On Machine #1, open a command window (cmd) and 'cd
' to: JBOSS_HOME
/jboss-as/bin/
.
Start JBoss by entering:
(On Windows) run.bat --configuration=all --host=0.0.0.0
(On Unix) run.sh --configuration=all --host=0.0.0.0
Repeat steps 1-2 for Machine #2.
Verify the identity of the IP addresses of Machine #1 and Machine #2 in their respective server.log files, located in JBOSS_HOME
\jboss-as\server\all\log\server.log
.
For example, search for "I am" in the log file, and the IP address appears in an INFO message.
If you have installed the Microsoft loopback adapter, the log may show a special IP address, such as 10.10.10.10. You must disable the Microsoft loopback adapter, to ensure that clustering operates as configured.
To deploy RTD.ear
to the JBoss cluster, perform the following tasks:
Make sure that each JBoss Server in the cluster is running.
On Machine #1, copy RTD_HOME
/package/RTD.ear
to JBOSS_HOME
/jboss-as/server/all/farm/
.
Wait for RTD.ear
to be deployed to Machine #2.
To undeploy RTD.ear
from the JBoss cluster, perform the following tasks:
Make sure that each JBoss Server in the cluster is running.
On Machine #1, delete RTD.ear
from JBOSS_HOME
/jboss-as/server/all/farm/
.
Wait for RTD.ear
to be undeployed from Machine #2.
To stop the JBoss application server, perform the following tasks:
On Machine #1, open a command window (cmd) and 'cd
' to: JBOSS_HOME
/jboss-as/bin/
.
Stop JBoss by entering:
(On Windows) shutdown.bat --server=localhost:1099 -S -u
username
-p
password
(On Unix) shutdown.sh --server=localhost:1099 -S -u
username
-p
password
The JBoss log is located at JBOSS_HOME
/jboss-as/server/all/log/server.log
.
The Oracle RTD log is located at RTD_HOME
/log/server.log
.