Release Notes for Oracle Insurance Gateway Patch 3.21.1.0.2
This document contains the release notes for Oracle Insurance Gateway Patch 3.21.1.0.2.
Version compatibility: Oracle Insurance Gateway Release 3.21.1.x is only compatible with other Oracle Health Insurance applications release version 3.21.1.x unless explicitly stated otherwise. |
In accordance with the OHI error correction policy (Document 1494031.1 on My Oracle Support), error correction support will be provided for this release and the previous two releases. |
Upgrade Steps for Installation
To perform the upgrade, perform the following steps:
-
Perform any pre-upgrade steps.
-
Stop all the managed nodes running the .existing version of the application.
-
Perform any pre-undeploy steps.
-
Undeploy the existing version of the application.
-
Back up the database.
-
Perform any post-undeploy steps.
-
Unpack the release bundle into a directory that we refer to as OHI_ROOT from now on.
-
Change Installation Configuration: In
<OHI_ROOT>/util/install
, make a copy ofohi_install.cfg.template
and name itohi_install.cfg
. -
Edit
ohi_install.cfg
to contain your specific database connection data and other configuration settings. The settings are explained in the file itself. -
Make sure NO connections are present to the database using the OHI_xxx_USER account (where xxx is the abbreviation of the application)
-
Run the Upgrade script:
-
Open a command window and browse to
<OHI_ROOT>/util/install
. -
Run the upgrade by executing
./ohi-update.sh .
-
-
Make the required changes to the ohi properties file
-
Perform any post-upgrade steps
-
Start WebLogic application server
-
Deploy the Application
-
Perform any post-deploy steps
Bug Fixes
BugDB | SR | Internal | BP | Summary |
---|---|---|---|---|
32696856 |
3-25474233841 |
OIG-1909 |
BP |
Scheduled integrations are triggered twice when the server node is bounced |
Description: |
In a clustered OIG environment with at least two OIG nodes, is observed that when a non-senior node is bounced/stopped, integrations that run on a specific schedule are scheduled an additional time by the senior node. A senior node in this context refers to the OIG node that has been around the longest or has been designated as the 'leader' in a cluster. |
|||
Resolution: |
With this fix, every time a 'Member Left Event' is detected by the senior node, that senior node first checks whether it is already known as the 'scheduler node' in the cluster. In case it is not, the system promotes the node to the 'scheduler node' and reschedules all integrations that need to run on a specific schedule. |