Release Notes for Oracle Health Insurance Enterprise Policy Administration Patch 4.23.1.0.12
This document contains the release notes for Oracle Health Insurance Enterprise Policy Administration Patch 4.23.1.0.12.
Version compatibility: Oracle Health Insurance Enterprise Policy Administration Release 4.23.1.x is only compatible with other Oracle Health Insurance applications release version 4.23.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. |
Enhancements
ID | Summary | Patch |
---|---|---|
POL-16651 |
Memory optimization in premium calculation activity Optimized memory footprint of schedule dimension value configuration data during premium calculation. |
4.24.1.0.9, 4.25.1.0.0 |
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 | Summary |
---|---|---|---|
36976071 |
3-37787970011 |
POL-15730 |
NullPointerException is thrown when running sample calculation for policies having surcharge of type amount |
Description: |
NullPointerException is thrown on screen on running sample calculation for policies having surcharge of type amount and policy enrollment product ending before the PCP (yearly PCP) |
||
Resolution: |
The exception was handled and the surcharge was derived based on the policy enrollment product duration. |
||
37576302 |
3-33766349291 |
POL-16612 |
Registrations are not re-applied |
Description: |
Policy calculation periods are deleted based on look back date in order to (re-)apply registrations. This is to trigger recalculation. First the initial look back date is determined to select applicable registrations. Then existing registrations are unzipped (applied registration status is set to N(ew)). But then policy calculation periods are deleted based on the initial look back date, not the look back date that is based on the 'unzipped ' registrations. This is causing the registrations not to be re-applied. This bug is present apply registrations activity only, not the integration points. Scenario to reproduce: 1) Create Policy with a Policy Collection Setting starting on 01/01 and Span Reference Date 15/01; 2) Create a single enrollment and a premium of $10 a day; 3) Create (and apply) Registration accounting for the first period ($142) and a Pay Date of 01/01; 4) Calculate Premium with Calculation Input Date 14/01 5) Create (and apply) Registration accounting for the first period ($138) and a Pay Date of 15/01; 6) Create (and apply) Registration accounting for the first period ($142) and a Pay Date of 14/01; Expected: Look Back Date should be set to 01/01 and all registrations need to be re-applied. Instead: look back date is not updated. |
||
Resolution: |
After unzip of registrations, the look back date is recalculated first before policy calculation periods are deleted, so the registrations are re-applied. |
||
37577855 |
3-39664837951,3-39998017091 |
POL-16617 |
Activities are not getting marked with TE status when system runs into critical memory state |
Description: |
When extract activity threw "TooManyRequestsException" exception, the activity status did not change to TE. But the trace file got created. Such activities stay in 'IP' status forever until restart happens. |
||
Resolution: |
When activities fails due to memory issue, the status of the activities are now updated via the native query. |
||
37605486 |
3-39664837951,3-39711991321,3-39998017091 |
POL-16672 |
Plan Objects Not Cleaned Up When OutOfMemoryProtector Triggers During Calculate Premium Activity |
Description: |
Necessary configurations for Calculate Premium activity are fetched once and stored in plan objects within the distributed Coherence cache. When OutOfMemoryProtector triggers, activity remains stuck in IP status and plan cache does not get cleared, overtime this degrades JVM performance. |
||
Resolution: |
Clearing plan cache when system reaches CRITICAL state reduces GC overhead, improving JVM performance. It also allows stuck activities to reach final state. |