Release Notes for Oracle Insurance Gateway Patch 4.23.1.0.7

This document contains the release notes for Oracle Insurance Gateway Patch 4.23.1.0.7.

Version compatibility: Oracle Insurance Gateway 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
CPN-3079	Auto purge feature As data volume in Oracle Health Insurance applications continue to grow with the processing of more data, it becomes essential to manage the database efficiently. Oracle Health Insurance applications include various PL/SQL packages for purging processes. However, these processes currently require manual intervention by customer DBAs/AMS team to configure and schedule purge jobs during planned maintenance windows. To streamline this process and automate database maintenance, we are introducing an auto-purge job feature. This feature eliminates the need for manual scheduling of various purge jobs and ensures that data is regularly purged according to predefined criteria. As part of this enhancement, we have a introduced a new PL/SQL package ohi_auto_purge_pkg.purge_all and modified the following functionalities : The structure of the following procedures has been revised, introducing an optional input parameter p_commit_size to enhance flexibility and control over the purging process cla_data_purge_pkg.purge_data ohi_repl_purge_pkg.purge_data Log message purging is now integrated into the auto-purge feature, and as a result, the following HTTP API resources have been made read-only. logeventretentionperiods API loglevelretentionperiods API Purging of PHI logs is now integrated into the auto-purge feature. So, the property ohi.logging.phi.min.retentionperiod is removed The process now integrates purging of all datafile sets into the auto-purge system, eliminating the need for separate scheduled scavenging and purging of incident files. So, the property ohi.incident.datafileset.retentionperiod is removed Oracle recommends frequent and automatic purging of technical data and operational data using the auto-purge job feature. For example, customer DBA/AMS team (in SaaS) can set up auto purge through the use of a DBMS_SCHEDULER job. See the user guide for more details and for a sample SQL script that creates auto purge job using DBMS_SCHEDULER.create_job PL/SQL procedure. Note that the initial purge job might take longer if the volume of the data is very high (for example, if the system has two years of data to purge and if the retention days for technical data are set to 60 days). So, Oracle recommends the DBA/AMS team to set a higher retention period (for example, one year and 11 months) for the initial run (so only 30 days of data is purged in the very first run). The retention days can be reduced gradually until the historical data is purged. Documentation Links: Administration Guide - Auto Purge Administration Guide - Purging Data from Technical Tables Administration Guide - Purging Data from Replication Technical Tables Administration Guide - Datafile Set Trace Files Retention Developer Guide - Purge Exchanges	4.24.1.0.0
POL-12956	Purge data files In Oracle Health Insurance applications, data files generated during various activities (e.g., extract activity, financial messages activity and data files uploaded to initiate long-running operations) remain in the system even after they have been processed/consumed. Currently, there is no mechanism in place to automatically clean up these data files once they have been processed/consumed, leading to inefficiency of the database storage space. This enhancement aims to automate the cleanup process and optimize database storage space. To enable purging data files, we have introduced a new PL/SQL package ohi_purge_datafileset_pkg. Documentation Links: Administration Guide - Purging Data from Data File Sets	4.24.1.0.0

Summary

Patch

CPN-3079

Auto purge feature

As data volume in Oracle Health Insurance applications continue to grow with the processing of more data, it becomes essential to manage the database efficiently. Oracle Health Insurance applications include various PL/SQL packages for purging processes. However, these processes currently require manual intervention by customer DBAs/AMS team to configure and schedule purge jobs during planned maintenance windows.

To streamline this process and automate database maintenance, we are introducing an auto-purge job feature. This feature eliminates the need for manual scheduling of various purge jobs and ensures that data is regularly purged according to predefined criteria.

As part of this enhancement, we have a introduced a new PL/SQL package ohi_auto_purge_pkg.purge_all and modified the following functionalities :

The structure of the following procedures has been revised, introducing an optional input parameter p_commit_size to enhance flexibility and control over the purging process
- cla_data_purge_pkg.purge_data
- ohi_repl_purge_pkg.purge_data
Log message purging is now integrated into the auto-purge feature, and as a result, the following HTTP API resources have been made read-only.
- logeventretentionperiods API
- loglevelretentionperiods API
Purging of PHI logs is now integrated into the auto-purge feature. So, the property ohi.logging.phi.min.retentionperiod is removed
The process now integrates purging of all datafile sets into the auto-purge system, eliminating the need for separate scheduled scavenging and purging of incident files. So, the property ohi.incident.datafileset.retentionperiod is removed

Oracle recommends frequent and automatic purging of technical data and operational data using the auto-purge job feature. For example, customer DBA/AMS team (in SaaS) can set up auto purge through the use of a DBMS_SCHEDULER job. See the user guide for more details and for a sample SQL script that creates auto purge job using DBMS_SCHEDULER.create_job PL/SQL procedure.

Note that the initial purge job might take longer if the volume of the data is very high (for example, if the system has two years of data to purge and if the retention days for technical data are set to 60 days). So, Oracle recommends the DBA/AMS team to set a higher retention period (for example, one year and 11 months) for the initial run (so only 30 days of data is purged in the very first run). The retention days can be reduced gradually until the historical data is purged.

Documentation Links:
Administration Guide - Auto Purge
Administration Guide - Purging Data from Technical Tables
Administration Guide - Purging Data from Replication Technical Tables
Administration Guide - Datafile Set Trace Files Retention
Developer Guide - Purge Exchanges

4.24.1.0.0

POL-12956

Purge data files

In Oracle Health Insurance applications, data files generated during various activities (e.g., extract activity, financial messages activity and data files uploaded to initiate long-running operations) remain in the system even after they have been processed/consumed. Currently, there is no mechanism in place to automatically clean up these data files once they have been processed/consumed, leading to inefficiency of the database storage space.

This enhancement aims to automate the cleanup process and optimize database storage space. To enable purging data files, we have introduced a new PL/SQL package ohi_purge_datafileset_pkg.

Documentation Links:
Administration Guide - Purging Data from Data File Sets

4.24.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 of ohi_install.cfg.template and name it ohi_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:
1. Open a command window and browse to <OHI_ROOT>/util/install.
2. 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

Configuration Properties

Ref	Action	Description
CPN-3079	Removed	ohi.incident.datafileset.retentionperiod Purging of all datafile sets is now integrated into the auto-purge system, hence, eliminating the need for separate scheduled scavenging and purging of incident files. So, this property is removed.
CPN-3079	Removed	ohi.logging.phi.min.retentionperiod Purging of logs is now integrated into the auto-purge feature. So, this property is removed. The default retention for PHI logs with the auto-purge function is 2560 days (7 years) and can be managed through the autopurgemetadata API

Ref

Action

Description

CPN-3079

Removed

ohi.incident.datafileset.retentionperiod

Purging of all datafile sets is now integrated into the auto-purge system, hence, eliminating the need for separate scheduled scavenging and purging of incident files. So, this property is removed.

CPN-3079

Removed

ohi.logging.phi.min.retentionperiod

Purging of logs is now integrated into the auto-purge feature. So, this property is removed. The default retention for PHI logs with the auto-purge function is 2560 days (7 years) and can be managed through the autopurgemetadata API

Web Services

Ref	Action	Description
CPN-3079	Added	autopurgemetadata API Added a new autopurgemetadata API
CPN-3079	Removed	loglevelretentionperiods API loglevelretentionperiods API supports only GET operation. POST/PATCH/PUT/DELETE operations are not longer supported
CPN-3079	Removed	logeventretentionperiods API logeventretentionperiods API supports only GET operation. POST/PATCH/PUT/DELETE operations are not longer supported

Ref

Action

Description

CPN-3079

Added

autopurgemetadata API

Added a new autopurgemetadata API

CPN-3079

Removed

loglevelretentionperiods API

loglevelretentionperiods API supports only GET operation. POST/PATCH/PUT/DELETE operations are not longer supported

CPN-3079

Removed

logeventretentionperiods API

logeventretentionperiods API supports only GET operation. POST/PATCH/PUT/DELETE operations are not longer supported

Data Conversion

This section intentionally left blank.

Dynamic Logic

This section intentionally left blank.

UI Changes

This section intentionally left blank.

Breaking Changes

Ref	Action	Description
CPN-3079	Removed	logeventretentionperiods API logeventretentionperiods API support only GET operation. POST/PATCH/PUT/DELETE operations are no longer supported. So, it is not possible to purge log messages based on a specific log level. Instead purging of logs (irrespective of the log level) is now integrated into the auto-purge feature
CPN-3079	Removed	loglevelretentionperiods API loglevelretentionperiods support only GET operation. POST/PATCH/PUT/DELETE operations are no longer supported. So, it is not possible to purge log messages based on a specific log level. Instead purging of logs (irrespective of the log level) is now integrated into the auto-purge feature

Ref

Action

Description

CPN-3079

Removed

logeventretentionperiods API

logeventretentionperiods API support only GET operation. POST/PATCH/PUT/DELETE operations are no longer supported. So, it is not possible to purge log messages based on a specific log level. Instead purging of logs (irrespective of the log level) is now integrated into the auto-purge feature

CPN-3079

Removed

loglevelretentionperiods API

loglevelretentionperiods support only GET operation. POST/PATCH/PUT/DELETE operations are no longer supported. So, it is not possible to purge log messages based on a specific log level. Instead purging of logs (irrespective of the log level) is now integrated into the auto-purge feature

Bug Fixes

BugDB	SR	Internal	Summary
36662895	3-36813495181	OIG-3835	Buffer too small for CLOB to CHAR conversion during subflow recovery
Description:	In the sub-exchanges during recovery , using a VARCHAR2 data type as a placeholder to parse the Exchange Properties JSON string of data type CLOB caused issues when the string length exceeded 32700 bytes. This is a code-related issue.
Resolution:	Changed the data type of placeholder to CLOB to hold the Exchange Properties.
37073859	3-36839446281	OIG-4041	OIG OOM issue due to accumulating of in-memory logs in JVM heap memory
Description:	The issue is due to the buildup in OIG heap memory caused by already opened financial transactions in policies that push notification messages.
Resolution:	We implemented a code fix to create a transaction and commit after every 50 downloaded notification messages. This change will help prevent any impact on the OIG JVM heap memory.
36668982	3-36840886581	OIG-3840	Scheduled Exchanges are triggered multiple times
Description:	If multiple Integrations with schedule are updated at a time, then all future scheduled exchanges are rescheduled. In a multi-node setup, due to an issue with scheduling mechanism, it is executed on multiple nodes at the same time. As a result, multiple instances of exchanges would be triggered.
Resolution:	The scheduling mechanism executes on one node at a time, thus avoiding creation of multiple instances of scheduled exchanges.
36662861	3-36788604651	OIG-3832	Exchange stops processing when Fusion ERP Job status polling fails due to an Error response from Fusion
Description:	If Fusion ERP Job status polling fails due to an Error response from Fusion (eg - 502 Bad Gateway), exchange stays in Waiting on External System (W) status. No logs are added, exchange does not Fail and recovery is not possible from this scenario.
Resolution:	If an Error response is received during Fusion ERP Job status polling, exchange fails with proper error message in exchange logs. Upon recovery, Fusion ERP Job status polling is restarted for the same job.
37153117		OIG-4070	Outbound exchange : There is no option to build and download data set
Description:	Actions to build and download were not available.
Resolution:	Build, download and other applicable actions are available to the user.
36067365	3-34591482241	OIG-3507	Purge requests of exchanges errors out with deadlock detected message.
Description:	Purge of exchanges errors out with deadlock detected message when the RAC database service is configured as active/active.
Resolution:	The dead lock error while purging the exchanges is resolved by removing the on delete cascade constraint on OIG_EXCHANGE_LOGS table.
36867370	3-35833647381	OIG-3927	Multiple filters are not working in JET UI screens once you perform quick search
Description:	Select filters by checking the checkbox on Exchange status (started, failed). Then do quick search on any Integration code. The filters are not retained while performing quick search . The results include exchanges in status complete as well.
Resolution:	The filters are retained with quick search in Exchanges page

BugDB

Internal

Summary

36662895

3-36813495181

OIG-3835

Buffer too small for CLOB to CHAR conversion during subflow recovery

Description:

In the sub-exchanges during recovery , using a VARCHAR2 data type as a placeholder to parse the Exchange Properties JSON string of data type CLOB caused issues when the string length exceeded 32700 bytes. This is a code-related issue.

Resolution:

Changed the data type of placeholder to CLOB to hold the Exchange Properties.

37073859

3-36839446281

OIG-4041

OIG OOM issue due to accumulating of in-memory logs in JVM heap memory

Description:

The issue is due to the buildup in OIG heap memory caused by already opened financial transactions in policies that push notification messages.

Resolution:

We implemented a code fix to create a transaction and commit after every 50 downloaded notification messages. This change will help prevent any impact on the OIG JVM heap memory.

36668982

3-36840886581

OIG-3840

Scheduled Exchanges are triggered multiple times

Description:

If multiple Integrations with schedule are updated at a time, then all future scheduled exchanges are rescheduled. In a multi-node setup, due to an issue with scheduling mechanism, it is executed on multiple nodes at the same time. As a result, multiple instances of exchanges would be triggered.

Resolution:

The scheduling mechanism executes on one node at a time, thus avoiding creation of multiple instances of scheduled exchanges.

36662861

3-36788604651

OIG-3832

Exchange stops processing when Fusion ERP Job status polling fails due to an Error response from Fusion

Description:

If Fusion ERP Job status polling fails due to an Error response from Fusion (eg - 502 Bad Gateway), exchange stays in Waiting on External System (W) status. No logs are added, exchange does not Fail and recovery is not possible from this scenario.

Resolution:

If an Error response is received during Fusion ERP Job status polling, exchange fails with proper error message in exchange logs. Upon recovery, Fusion ERP Job status polling is restarted for the same job.

37153117

OIG-4070

Outbound exchange : There is no option to build and download data set

Description:

Actions to build and download were not available.

Resolution:

Build, download and other applicable actions are available to the user.

36067365

3-34591482241

OIG-3507

Purge requests of exchanges errors out with deadlock detected message.

Description:

Purge of exchanges errors out with deadlock detected message when the RAC database service is configured as active/active.

Resolution:

The dead lock error while purging the exchanges is resolved by removing the on delete cascade constraint on OIG_EXCHANGE_LOGS table.

36867370

3-35833647381

OIG-3927

Multiple filters are not working in JET UI screens once you perform quick search

Description:

Select filters by checking the checkbox on Exchange status (started, failed). Then do quick search on any Integration code. The filters are not retained while performing quick search . The results include exchanges in status complete as well.

Resolution:

The filters are retained with quick search in Exchanges page

Issues that were backported in previous Release / Patch

No backports.