Install and Configure Oracle WebLogic
Oracle Health Insurance runs on an Oracle WebLogic Server. This is known as the Oracle WebLogic Server. If it runs on more than one managed server or node, the application servers have to be configured as a cluster. Starting with WebLogic version 14.1.x Oracle added a DynamicCluster feature. A dynamic cluster uses a single server template to define configuration for a specified number of generated (dynamic) server instances. In a dynamic cluster, additional dynamic servers can be started without manually configuring them first and adding them to the cluster. Oracle Health Insurance applications are certified to work with both static and dynamic clusters.
This guide assumes experience with the installation and set up of the Oracle WebLogic Server. For details regarding the installation process please consult the product documentation.
The certification information that is available for a specific release through My Oracle Support specifies the required Java version as well as the version of the Oracle WebLogic Server software that must be installed.
It also lists the matching Oracle Application Development Runtime version that is required for any Oracle Health Insurance application.
This chapter briefly outlines the installation of the Oracle WebLogic Server software.
Installing the Oracle WebLogic and Creating a Domain
Start with the installation of the Oracle WebLogic. For that purpose make sure to use the Oracle Generic Installer.
When using the Configuration Wizard, Oracle recommends to accept the default Coherence Cluster Name and the Unicast Listen Port. Coherence Cluster settings are adjusted through the WebLogic Administration Console.
Domain Configuration for Oracle Health Insurance
This chapter contains directions for the following topics:
-
Redirecting console log output
-
Setting up the Policies properties files
-
Coherence settings
-
Setting the Oracle Health Insurance Domain environment variables
-
Setting the enforce-valid-basic-auth-credentials flag
Redirect the JVM Output to a Log File
By default, the JVM output for a WebLogic server is written to the console.
It is recommended to redirect the console output to file.
In the development mode, the default size of a logfile before it is rotated is only 500Kb. Hence, it is also recommended changing the size of the log files before rollover to 10240 Kb and to specify the number of log files that are retained. These configuration settings can be changed through the WebLogic Server Console.
Setting up the Policies Properties Files
Create a directory that holds the Policies properties and the configuration files.
This directory is referenced as <CONFIG_ROOT> throughout this document.
Copy the following files that were delivered as part of the specific release from the <OHI_ROOT>/properties directory to the <CONFIG_ROOT>:
-
logback.xml
-
ohi-policies.properties.template
Rename the copied ohi-policies.properties.template to ohi-policies.properties. A description of the properties in the properties file is available elsewhere in this guide.
Also copy file <OHI_ROOT>/util/security/ohi-security.config to the <CONFIG_ROOT>.
Coherence settings
Oracle Health Insurance applications use Oracle Coherence. The IT infrastructure on which the system is installed determines the configuration for Oracle Coherence. Coherence Cluster settings are maintained using the WebLogic Administration Console. This paragraph describes the following configuration options:
-
Control multiple Coherence clusters that are spread across multiple machines
-
Control multiple Coherence clusters that are executed on one machine
-
Specific settings for running Coherence in a Production environment
Define a Coherence Cluster for Oracle Health Insurance
Oracle recommends creating an application-specific Coherence cluster that is associated with the (application-specific) WebLogic Cluster in which the Oracle Health Insurance application is executed. For example: for Policies, create a policies_cluster and a policies_coherence_cluster. Associate the policies_cluster with the policies_coherence_cluster using the WebLogic Administration Console: navigate to the policies_cluster, under the Configuration tab select the Coherence sub tab and select the policies_coherence_cluster from the Coherence Cluster drop down list. Make sure to enable the local storage.
Run Multiple Coherence Clusters of Multiple JVMs on the Same Machine or Same Set of Machines
For controlling which JVMs can join in a particular Coherence cluster, the following options are available:
-
Use multicast addressing and have every member that needs to join the cluster define the cluster name
-
Use the Coherence Well Known Addresses (WKA) feature
Use a feature of choice to:
-
Control multiple Coherence clusters that are spread across multiple machines
-
Control multiple Coherence clusters that are executed on one machine
-
Example: use Well Known Addresses to Control which Members are allowed to join a Coherence Cluster
-
Assuming a WebLogic cluster policies_cluster that consists of the following server members:
-
An Administration Server
-
Two Managed Servers, policies_node1 and policies_node2.
The policies_cluster is associated with an existing policies_coherence_cluster.
-
for the policies_coherence_cluster define two Well Known Addresses via the WebLogic Administration Console: navigate to the policies_coherence_cluster, under the Configuration tab select the Well Known Addresses sub tab. Click New to create two Well Known Addresses with the following characteristics:
Table 1. Run Multiple Coherence Clusters of Multiple JVMs on the Same Machine or Same Set of Machines Name Listen Address Listen Port wka1
Name of the host machine that runs the managed server
A unique listen port, for example, 27111
wka2
Name of the host machine that runs the managed server
A unique listen port, for example, 27112
-
for each Managed Server, navigate to the Settings page, under the Configuration tab select the Coherence sub tab. Given that policies_cluster is already associated with the policies_coherence_cluster, the Coherence sub tab already lists the policies_coherence_cluster.
| Settings for … | Unicast Listen Address | Unicast Listen Port |
|---|---|---|
policies_node1 |
Name of the host machine that runs the managed server |
wka1 port, that is, 27111 (as used in the example) |
policies_node2 |
Name of the host machine that runs the managed server |
wka2 port, that is, 27111 (as used in the example) |
Make sure to activate the changes that were made.
For additional information refer to the Fusion Middleware documentation on Administering Clusters for Oracle WebLogic Server.
Specific Settings for Running Coherence in a Production Environment
By default, Oracle Coherence runs in the Development mode. The production checklist in the Coherence documentation states that it is recommended to use the development mode for all pre-production activities, such as development and testing. This is an important safety feature, because Coherence automatically prevents these nodes from joining a production cluster. The production mode must be explicitly specified when using Coherence in a production environment.
In the Production environment (and only in the Production environment), the system property tangosol.coherence.mode must be set to value prod in the script that is used to start Coherence nodes.
-Dcoherence.mode=prod
Set Environment Variables for the Policies
Environment variables for Policies can be set in the startWebLogic.sh script.
An alternative approach (offered as a best practice) is to create a separate shell script named setPoliciesEnv.sh in a directory (referred to hereafter as <SET_ENV_VAR_DIR>). Rationale:
-
The startWebLogic.sh file is generated by the WLS and large (clutters the view).
-
The startWebLogic.sh file can be changed by the WebLogic if the cluster configuration changes. A separate setPoliciesEnv.sh file shields from these changes.
Make sure that <SET_ENV_VAR_DIR> is a shared directory for all the managed servers in the cluster. The following is a sample setPoliciesEnv.sh script (which may have been formatted for readability):
# Memory Args
MEM_ARGS="-Xmx4096m"
export MEM_ARGS
# Java Options
JAVA_OPTIONS="${JAVA_OPTIONS} -Dohi.properties.url=file:/config/ohi-policies.properties"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dlogback.configurationFile=/config/logback_policies.xml"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djava.security.auth.login.config=/config/ohi-security.config"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dtangosol.coherence.mode=prod"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.sun.org.apache.xml.internal.dtm.DTMManager=
com.sun.org.apache.xml.internal.dtm.ref.DTMManagerDefault"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.xml.datatype.DatatypeFactory=
com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.xml.stream.XMLInputFactory=
com.sun.xml.internal.stream.XMLInputFactoryImpl"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.xml.stream.XMLOutputFactory=
com.sun.xml.internal.stream.XMLOutputFactoryImpl"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.xml.stream.XMLEventFactory=
com.sun.xml.internal.stream.events.XMLEventFactoryImpl"
export JAVA_OPTIONS
# To make Jersey filters that set certain CORS related HTTP Headers work
JAVA_OPTIONS="${JAVA_OPTIONS} -Dsun.net.http.allowRestrictedHeaders=true"
# Optional settings for JMX management
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcom.sun.management.jmxremote.ssl=false"
JAVA_OPTIONS="${JAVA_OPTIONS} -Djavax.management.builder.initial=
weblogic.management.jmx.mbeanserver.WLSMBeanServerBuilder"
export JAVA_OPTIONS
# Optional settings to enable monitoring Coherence through JMX
JAVA_OPTIONS="${JAVA_OPTIONS} -Dtangosol.coherence.management=all"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dtangosol.coherence.management.remote=true"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dcoherence.distributed.threads=1"
export JAVA_OPTIONS
Use the tangosol.coherence.mode property for production environments only.
Go to the domain directory and edit bin/startWebLogic.sh script. Add the following line (highlighted below) at the beginning as shown in this sample:
# Call setDomainEnv here.
DOMAIN_HOME="/home/domains/ohi_domain"
. ${DOMAIN_HOME}/bin/setDomainEnv.sh noderby $*
if [ "${SERVER_NAME}" = "<ohi admin server name>" ] ; then
MEM_ARGS="-Xmx1024m"
export MEM_ARGS
else
. <SET_ENV_VAR_DIR>/setPoliciesEnv.sh ${SERVER_NAME}
fi
SAVE_JAVA_OPTIONS="${JAVA_OPTIONS}"
Setting the Enforce-valid-basic-auth-credentials Flag
RESTful services in the Oracle Health Insurance applications' HTTP API use Basic Authentication as the default authentication mechanism. The RESTful API requests that use HTTP BASIC authentication must pass the WebLogic Server authentication. Upon successful authentication, the WebLogic Server creates the HTTP session objects in the JVM memory. The default session-timeout value in the WebLogic Server is 3600 seconds, so the HTTP session objects are invalidated/GC’ed only after 3600 seconds.
Since Basic Authentication is handled by Oracle Health Insurance applications, Weblogic Server’s Basic Authentication mechanism should be disabled.
To do so, set the domain wide flag enforce-valid-basic-auth-credentials to false.
For more information, please check the WebLogic documentation as well as Oracle support documents:
2178771.1 and 2235898.1.