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 Oracle Insurance Gateway 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 Oracle Insurance Gateway Properties Files

Create a directory that holds the Oracle Insurance Gateway 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-oig.properties.template

Rename the copied ohi-oig.properties.template to ohi-oig.properties. A description of the properties in the properties file is available elsewhere in this guide.

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 Oracle Insurance Gateway, create a gateway_cluster and a gateway_coherence_cluster. Associate the gateway_cluster with the gateway_coherence_cluster while configuring 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 (not needed with WebLogic Dynamic Clusters)

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 gateway_cluster that consists of the following server members:
An Administration Server
Two Managed Servers, gateway_node1 and gateway_node2.

The gateway_cluster is associated with an existing gateway_coherence_cluster.

for the gateway_coherence_cluster define two Well Known Addresses with the following characteristics:

Name	Listen Address	Listen Port
wka1	Name of the host machine that runs the managed server	A unique listen port, for example, 27151
wka2	Name of the host machine that runs the managed server	A unique listen port, for example, 27152

Name

Listen Address

Listen Port

wka1

Name of the host machine that runs the managed server

A unique listen port, for example, 27151

wka2

Name of the host machine that runs the managed server

A unique listen port, for example, 27152

For each Managed Server, change the settings as follows:

Settings for …	Unicast Listen Address	Unicast Listen Port
gateway_node1	Name of the host machine that runs the managed server	wka1 port, that is, 27151 (as used in the example)
gateway_node2	Name of the host machine that runs the managed server	wka2 port, that is, 27152 (as used in the example)

Settings for …

Unicast Listen Address

Unicast Listen Port

gateway_node1

Name of the host machine that runs the managed server

wka1 port, that is, 27151 (as used in the example)

gateway_node2

Name of the host machine that runs the managed server

wka2 port, that is, 27152 (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 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 the Coherence nodes.

-Dtangosol.coherence.mode=prod

Set Environment Variables for the Oracle Insurance Gateway

Environment variables for Oracle Insurance Gateway can be set in startWebLogic.sh script. An alternative approach (offered as a best practice) is to create a separate shell script named setGatewayEnv.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 setGatewayEnv.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 setGatewayEnv.sh script (which may have been formatted for readability):

# Memory Args
MEM_ARGS="-Xmx2048m"
MEM_ARGS="${MEM_ARGS} -XX:+UseG1GC"
export MEM_ARGS

# Java Options
JAVA_OPTIONS="${JAVA_OPTIONS} -Dohi.properties.url=file:/config/ohi-oig.properties"
JAVA_OPTIONS="${JAVA_OPTIONS} -Dlogback.configurationFile=/config/logback_oig.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>/setGatewayEnv.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.