Install and Configure Oracle Fusion Middleware using Slim Installer
Oracle Health Insurance runs on an Oracle Fusion Middleware Application Server. This is known as the Oracle WebLogic Server. The slim installer is for development and production usage of Docker or CRI-O images and containers in Kubernetes, when WebLogic console monitoring and configuration is not required. It includes all the Oracle WebLogic Server and Oracle Coherence server runtime applications, but excludes examples, the WebLogic console, WebLogic clients, Maven plug-ins and Java DB. Oracle Health Insurance includes the APIs and JET UI for slim version of the Oracle Fusion Middleware, it does not include the ADF UI.
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 12.1.x Oracle added a DynamicCluster feature. A dynamic cluster uses a single server template to define the configuration for a specified number of generated (dynamic) server instances. In a dynamic cluster, additional dynamic servers can be started without having to first manually configure and add 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 additional information regarding the installation process refer to the product documentation.
The certification information is available for a specific release on My Oracle Support. It specifies the required Java version as well as the version of the Oracle WebLogic Server software that must be installed.
This chapter briefly outlines the installation of the Oracle WebLogic Server software.
Installing the Oracle Fusion Middleware and Creating a Domain
Installation of the Oracle Fusion Middleware is the initial requirement. The Slim Installer is used for the Oracle WebLogic Server and Oracle Coherence.
A WebLogic Domain can be created using the Fusion Middleware Configuration Wizard, from the command line or by using WLST scripts. Once a WebLogic Domain is created be aware that slim installation does not include the WebLogic Console. All changes in the Weblogic Domain after that have to be done through the WLST or via RESTful Management API. When using the Configuration Wizard, make sure to select the WebLogic Coherence Cluster Template. Any other templates are optional and are not required for running the Oracle Health Insurance applications.
When using the Configuration Wizard, Oracle recommends accepting the default Coherence Cluster Name and Unicast Listen Port.
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 recommended to change 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 accordingly.
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. 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 Domain. 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 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 with the following characteristics:
Table 1. Well-Known Addresses 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, change the settings as follows:
| 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, 27112 (as used in the example) |
For additional information refer to the Fusion Middleware documentation on Administering Clusters for the Oracle WebLogic Server.
Specific Settings for Running Coherence in a Production Environment
By default, Oracle Coherence runs in 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 the Coherence nodes.
-Dtangosol.coherence.mode=prod
Set Environment Variables for the Policies
Environment variables for Policies can be set in 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 WLS and large (clutters the view).
-
The startWebLogic.sh file can be changed by WebLogic if the cluster configuration changes. A separate setPoliciesEnv.sh file shields from these changes.
Ensure 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 has been formatted for readability):
# Memory Args
MEM_ARGS="-Xmx4096m"
MEM_ARGS="${MEM_ARGS} -XX:+UseG1GC"
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"
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 HTTP session objects in the JVM memory. The default session-timeout value in WebLogic Server is 3600 seconds, so the HTTP session objects are invalidated/GC’ed only after 3600 seconds.
Since Basic Authentication is handled by the Oracle Health Insurance applications, the Weblogic Server’s Basic Authentication mechanism must be disabled.
To do so, set the domain wide flag enforce-valid-basic-auth-credentials to false.
For additional information refer to the WebLogic documentation as well as the Oracle support documents:
2178771.1 and 2235898.1.