71 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:

Deleting Expired Data

ECE deletes expired historic data that is no longer used 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. You can configure the retention time of expired objects in update requests but not in usage requests.

To configure the retention time (in days) 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 71-1.

    The maximum allowed retention time is 180 days.

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

MBean Attribute Default Retention Time (in Days)

expiredAuditRetentionIntervalInDays

60

expiredPurchasedProductRetentionIntervalInDays

30

expiredPurchasedAlterationRetentionIntervalInDays

30

expiredRatingProfileRetentionIntervalInDays

30

defaultExpirationRetentionIntervalInDays

30

defaultExpiredBalanceItemRetentionIntervalInDays

30

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, defaultExpiredBalanceItemRetentionIntervalInDays is used. Table 71-2 lists the expired balance elements and example retention times.

Table 71-2 Expired Balance Element Retention Times

Expired Balance Element Retention Time (in Days)

FREE_MIN

60

BONUS_POINTS

15

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.