84 Removing Data from the ECE System

Learn how to remove data from Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE).

Topics in this document:

Removing Expired Data from ECE Cache

ECE can remove expired historical data that is no longer needed for processing customer updates and usage information. This includes expired objects for audit data, purchased charge offers, and so on. The clean-up occurs during the update and usage request processes.

Note:

You can configure the retention time of expired objects in update requests, but not in usage requests.

To configure the retention time of an expired object in an update request:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand charging.expirationConfiguration.

  4. Expand Attributes.

  5. Specify values for the expiration configuration attributes listed in Table 84-1.

    The maximum allowed retention time for any attribute is 180 days.

Table 84-1 MBean Attributes to Configure Expired Object Retention Time

MBean Attribute Default Retention Time Description

expiredAuditRetentionIntervalInDays

45

Specifies how long, in days, to retain audit objects in the ECE cache before deleting them.

expiredPurchasedChargesRetentionIntervalInDays

20

Specifies how long, in days, to retain expired charge objects in the ECE cache before deleting them.

expiredPurchasedAlterationRetentionIntervalInDays

30

Specifies how long, in days, to retain expired discount/alteration objects in the ECE cache before deleting them.

expiredRatingProfileRetentionIntervalInDays

40

Specifies how long, in days, to retain expired rating profile objects in the ECE cache before deleting them.

defaultExpirationRetentionIntervalInDays

50

Specifies the default interval, in days, to retain any expired object (purchased offerings, rating profiles, audits, and so on).

This value can be overridden by setting a corresponding expiration interval for individual objects.

defaultExpiredBalanceItemRetentionIntervalInDays

60

 Specifies how long, in days, to retain expired balance item objects in the ECE cache before deleting them.

defaultExpiredRBundleHistoryRetentionIntervalInDays

30

Specifies how long, in days, to retain expired recurring bundle identifier history objects in the ECE cache before deleting them.

expiredAsoRetentionIntervalInDays

-1

Specifies how long, in days, to retain expired active sessions in the ECE cache before deleting them and releasing the corresponding reservation from the balance.

An active session object is considered expired after its reservation expires.

The supported values are:

  • Integer greater than 0: Specifies the number of days to retain expired active sessions in ECE cache. The value will be considered valid only if it is between 1 and 180.

  • -1: Expired active sessions are not removed from ECE cache.

expiredAsoRetentionIntervalInMinutes

-1

Specifies how long, in minutes, to retain expired active sessions in the ECE cache before deleting them and releasing the corresponding reservation from the balance.

An active session object is considered expired after its reservation expires.

The supported values are:

  • Integer greater than 0: Specifies the number of minutes to retain expired active sessions in ECE cache. The value will be considered valid only if it is between 1 and 259200 minutes (180 days).

  • -1: Expired active sessions are not removed from ECE cache.

Note:
  • If you do not provide a valid value (an integer greater than 0) for the parameter, the system defaults to using the expiredAsoRetentionIntervalInDays parameter.
  • The expiredAsoRetentionIntervalInMinutes parameter takes precedence over expiredAsoRetentionIntervalInDays if both are set.

debitRefundSessionCleanUpIntervalInDays

-1

Specifies how long, in days, to retain expired debit refund sessions in the ECE cache before deleting them.

  • Integer greater than 0: Specifies the number of days to retain expired debit refund sessions in ECE cache.

  • -1: Expired debit refund sessions are not removed from ECE cache.

Expired audit objects share a single common retention time. Other expired objects have individual retention times.

Expired balance items are configured at the balance element level. If there is no configuration for a given balance element, ECE uses defaultExpiredBalanceItemRetentionIntervalInDays. Table 84-2 lists the expired balance elements and example retention times.

Table 84-2 Expired Balance Element Retention Times

Expired Balance Element Retention Time (in Days)

FREE_MIN

80

BONUS_POINTS

70

Setting Eviction Policies for Cache

The identity cache stores customer public user identity information. The pricing cache stores pricing information, and the configuration cache stores configuration information. You can set eviction policies for these caches to remove entries from them when a maximum number of entries is reached. The default settings are:

  • Eviction policy = HYBRID

  • High-units = 20,500,000

By default, the entries in the pricing-and-configuration near caches that have not been used for more than 10 days are evicted. You can reset the size limit for the front cache by changing the front-size-limit parameter for the pricing or configuration caches in the ECE_home/config/charging-cache-config.xml file. Ensure that this parameter is set to a non-zero value.

For more information, see the Oracle Coherence documentation.

Purging Rated Events from the Oracle NoSQL Database

Rated Event Formatter purges rated events from the NoSQL database immediately after sending them to Rated Event Loader. You can retain events for a period of time before purging them. For example, you can retain them for an hour if legal requirements mandate that, or to give another program time to get data from the rated events.

To configure how rated events are purged from Oracle NoSQL database:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand charging.ratedEventFormatters.Instance_Name, where Instance_Name is the name of the instance you want to configure.

  4. Expand Attributes.

  5. Set the retainDuration attribute to the number of seconds to wait before purging rated events.

  6. Use Elastic Charging Controller to stop and restart the Rated Event Formatter instances that you configured.

The Rated Event Formatter instance purges the rated events and writes log information to the Rated Event Formatter log file.

About Purging Accounts from the ECE Cache

To optimize and efficiently manage memory, ECE allows you to purge inactive and dormant accounts from the ECE cache. You can purge the accounts synchronously from both BRM and ECE in real time using EM Gateway.

When you delete an account from the BRM database using the PCM_OP_CUST_DELETE_ACCT opcode, BRM sends the update request to ECE through EM Gateway. ECE processes the update request and purges the account from the ECE cache if there are no active sessions associated with that account. The BRM database and the ECE cache are updated within the same transaction in real time, ensuring that the BRM and ECE data remain synchronized.

When purging the account from the ECE cache, ECE purges the customer data associated with the account, which includes:

  • Customer information

  • Customer balance history

  • Recurring bundle history

  • Account top-up history

  • Sharing customer state history

  • Billing trigger cycle information

  • Public user identity (PUID), if it is not associated with any other active account

To purge the accounts synchronously in BRM and ECE, you must enable synchronous updates in BRM and ECE. For more information, see "Enabling Real-Time Synchronization of BRM and ECE Customer Data Updates" in ECE Implementing Charging.

Setting Retention Policies for ECE Tables with SecureFiles LOBs

By default, ECE stores data in the following tables as SecureFiles LOBs:

  • BALANCE

  • CUSTOMER

  • CUSTOMERGROUP

  • RATEDEVENT

  • RECURRINGBUNDLEIDHISTORY

  • TOPUPHISTORY

The data in these tables grow continuously and cannot be purged. To prevent these tables from growing too large, configure ECE to reuse space in these tables by setting their data retention policy to NONE.

To set retention policies for tables with SecureFiles LOBs:

  1. Connect to the BRM database with SQL*Plus:

    sqlplus userName@databaseAlias
Enter password: password

    where:

    • userName and password are the login name and password for connecting to the BRM database.

    • databaseAlias is the BRM database alias.

  2. Set the retention policy to NONE: 

    SQL> alter table tableName modify lob (c_lob) (retention NONE);
Table altered.

    where tableName is the name of one of the tables that store data in SecureFiles LOBs.

    For example, you would enter this for the RECURRINGBUNDLEIDHISTORY table:

    SQL> alter table RECURRINGBUNDLEIDHISTORY modify lob (c_lob) (retention NONE);
Table altered.

  3. Type exit to quit SQL*Plus.

For more information about setting the retention of SecureFiles LOBs, see the "How to change retention of securefile Lob segment (Doc ID 2175438.1)" knowledge article on My Oracle Support.