16 Optimizing BRM for Prepaid and Postpaid Convergence

This chapter describes cache residency distinction, which enables you to optimize your Oracle Communications Billing and Revenue Management (BRM) system for rating both prepaid and postpaid accounts in both real time and batch.

It assumes you have installed the components necessary for rating prepaid and postpaid accounts and have set up real-time and pipeline batch rating. For more information, see "Putting Together Your BRM System" in BRM Installation Guide.

Before reading this chapter, you should be familiar with the following:

• Basic BRM concepts. See "Introducing BRM" in BRM Concepts.

• BRM system architecture. See "BRM System Architecture" in BRM Concepts.

• Pricing and rating configuration. See "About Creating a Price List" in BRM Configuring Pipeline Rating and Discounting.

• In-Memory Database (IMDB) Cache Manager. See "Using Oracle IMDB Cache Manager".

• Basic database administration concepts. See your database documentation.

About Convergent BRM Systems

A BRM system that handles prepaid and postpaid subscribers and rates events using both real-time and batch processing is referred to as a convergent system.

To allow both types of subscriber accounts and provide both types of rating, you must set up a BRM system with prepaid and postpaid real-time and batch rating. Then you must ensure the following behaviors:

• Only the data relevant to a particular rating system is stored in its cache to improve performance and reduce memory requirements.

• The data stored in or updated by the rating components are synchronized with the database to maintain data integrity.

About Cache Residency

To perform rating, BRM caches subscriber data, such as data from /account, /billinfo, and /service objects as shown in Figure 16-1. Objects associated with prepaid subscribers are stored in IMDB Cache. Objects associated with postpaid subscribers are stored in Pipeline Manager memory. Objects associated with convergent subscribers are stored in both caches.

You can configure your BRM system so only the required objects are loaded into the appropriate memory caches after the object has been created or changed in the database or in one of the caches. This reduces the load time during initialization and data synchronization operations and minimizes memory size.

Figure 16-1 BRM Cache Residency

Description of ''Figure 16-1 BRM Cache Residency''

After events are processed and objects are recorded in the database, the Pipeline Manager memory and IMDB Cache are updated with the data from the database to maintain data integrity. The caches must be synchronized with one another to handle objects that reside in both caches.

Note:

Currently, cache residency is supported in Pipeline Manager only for the DAT_BalanceBatch module. For more information about DAT_BalanceBatch module, see BRM Configuring Pipeline Rating and Discounting.

How Cache Residency Is Determined

Objects in an IMDB Cache-enabled system have a RESIDENCY_TYPE attribute that identifies how they reside in the BRM system. This value is defined in the data dictionary. Table 16-1 lists the attribute values that identify object types and their residency.

Table 16-1 Object Residency and Attributes

Attribute Value	Object Type	Residency
0	Database objects	Owned by the BRM database.
1	In-memory objects	Owned by IMDB Cache DM.
2	Shared objects	Owned by IMDB Cache DM and the BRM database.
3	Shared objects	Control objects that are passed through IMDB Cache DM.
4	Deferred database objects	Objects owned by the database but passed through IMDB Cache DM.
5	Static reference objects	Objects owned by the database and cached in IMDB Cache when the flow back from the database.
6	Volatile objects	Objects stored only in IMDB Cache and not persistent.
7	Dynamic reference object	Reference objects that are owned by the database and are updated more frequently in IMDB Cache.

BRUM uses the residency type value to determine which objects to retrieve during request operations. Only reference objects (RESIDENCY_TYPE value of 5 or 7) are valid for caching in memory.

Objects that are updated during batch rating are cached in the pipeline DAT_BalanceBatch module, and objects that are updated during real-time rating are cached in IMDB Cache. The database is updated with all data changed during both real-time and batch processing.

You can configure which objects are eligible for which memory cache when they are updated by associating them with prepaid, postpaid, or convergent business profiles and setting up validation rules.

The following objects are valid for cache residency distinction:

• /account

• /balance_group

• /billinfo

• /group

• /group/sharing

• /group/sharing/charges

• /group/sharing/discounts

• /ordered_balgrp

• /profile

• /profile/acct_extrating

• /profile/serv_extrating

• /purchased_discount

• /purchased_product

• /service

• /uniqueness

  Note:

  You cannot configure the /account object or the /uniqueness object with a specific cache type. Account object instances receive their cache type values from their associated /billinfo object, and /uniqueness object instances receive their cache type values from the associated services.

For information on how to configure nonreference objects for cache residency distinction, see "Configuring Nonreference Objects for Cache Residency Distinction".

About Setting Up Business Profiles for Cache Residency Distinction

You can use the business profiles listed in Table 16-2, with the CacheResidency NameValue entry in an object's validation template, to designate into which memory cache the related object instances are loaded when they are created or changed:

Table 16-2 Business Profiles for Cache Residency Distinction

Business Profile	CacheResidency	Description
Convergent	DEFAULT (0)	Object instances are loaded into both IMDB Cache and batch pipeline memory. These objects are used for rating events in both real time and batch and contain both prepaid and postpaid subscriber information.
Prepaid	REALTIME (1)	Object instances are loaded into IMDB Cache only. These objects are used for rating events in real time and contain prepaid subscriber information.
Postpaid	BATCH (2)	Object instances are loaded into batch pipeline memory only. These objects are used for rating events in batches and contain postpaid subscriber information.
Nonusage	DBONLY (3)	Object instances reside in the BRM database. These objects do not generate any usage and hence do not need to be loaded into Pipeline Manager memory or IMDB Cache.

When an object is created or modified, based on the business profile to which it is associated, BRM reads the validation template to determine the cache residency value and sets the object's PIN_FLD_OBJECT_CACHE_TYPE value accordingly. The object instance is updated in the appropriate memory cache.

Important:

The validation templates for a business profile must have compatible cache type values for all objects related to the /billinfo object.

Note:

The account object does not have a validation template. Account object instances receive their cache type values from their associated /billinfo object. All objects outside the /billinfo context and associated with the account receive their cache type values from the account. For example, an account-level product has the same PIN_FLD_OBJECT_CACHE_TYPE value as its owner account.

If you do not have cache residency distinction enabled, or do not have a business profile assigned to a reference object, BRM assigns it a Convergent business profile. This sets the cache type to DEFAULT and ensures data is loaded into both memory caches. You can change the default setting by modifying the /config/business_params object. See "Changing the Default Business Profile".

For information on setting up business profiles and validation templates, see "Managing Business Profiles" in BRM Managing Customers.

How BRM Caches Objects in a Convergent Rating System

Before loading data into the cache, BRM determines the PIN_FLD_OBJECT_CACHE_TYPE value of each object and validates that any related objects have valid cache types. For example, if a /service/GSM object has a cache type value of REALTIME, any /purchase_product objects associated with that service must have a value of REALTIME or DEFAULT.

During initialization:

• Objects with a REALTIME cache value are loaded into IMDB Cache. These include prepaid events.

• Objects with a BATCH cache value are loaded into Pipeline Manager memory. These include postpaid events.

• Objects with a DEFAULT cache value are loaded into both IMDB Cache and Pipeline Manager memory. These include both prepaid and postpaid events.

During pipeline rating, the following occurs:

1. The FCT_BillingRecord module retrieves the ObjectCacheType value of a balance group from the DAT_BalanceBatch module and publishes it in the EDR. The value can be BATCH (postpaid events) or DEFAULT (convergent events). See "DAT_BalanceBatch" in BRM Configuring Pipeline Rating and Discounting.

2. The ISC_ObjectCacheTypeOutputSplitter iScript splits the EDR into two identical files: one that is routed to the BATCH stream and one that is routed to the DEFAULT stream. See "ISC_ObjectCacheTypeOutputSplitter" in BRM Configuring Pipeline Rating and Discounting.

3. Rated Event (RE) Loader loads objects with BATCH and DEFAULT cache types into the database.

4. RE Loader loads objects with BATCH and DEFAULT cache types in the database. Then it sends a notification message to IMDB Cache DM about the updates to objects with a DEFAULT cache type. IMDB Cache DM retrieves the objects with a DEFAULT cache type and updates its cache.

About Changing the Cache Type of an Object

You can change the cache type of an object by associating it with a business profile whose validation template specifies a different cache type value.

Table 16-3 shows what happens when you change an object's cache type value:

Table 16-3 Cache Type Change Ramifications

Old Cache Type	New Cache Type	How BRM Handles the Change
Prepaid	Postpaid	All subsequent object instances are loaded only into the DAT_AccountBatch and DAT_BalanceBatch modules. The data is loaded into DAT_BalanceBatch immediately; however, the data is loaded into DAT_AccountBatch on the next business event processing for that account or service.
Prepaid	Convergent	All subsequent objects are loaded into the DAT_AccountBatch and DAT_BalanceBatch modules. The data is loaded into DAT_BalanceBatch immediately; however, the data is loaded into DAT_AccountBatch on the next business event processing for that account or service.
Prepaid	Nonusage	No change occurs.
Postpaid	Prepaid	The object instances previously loaded into the DAT_AccountBatch and DAT_BalanceBatch modules remain in the memory until the next Pipeline Manager initialization.
Postpaid	Convergent	The object instances previously loaded into the DAT_AccountBatch and DAT_BalanceBatch modules are reloaded.
Postpaid	Nonusage	The object instances previously loaded into the DAT_AccountBatch and DAT_BalanceBatch modules are reloaded, and all subsequent objects are not loaded in Pipeline Manager memory from the next initialization of Pipeline Manager.
Convergent	Prepaid	The object instances previously loaded into the DAT_AccountBatch and DAT_BalanceBatch modules remain in the memory until the next Pipeline Manager initialization. The data will not be loaded from the next initialization of Pipeline Manager.
Convergent	Postpaid	All subsequent object instances are reloaded into the DAT_AccountBatch and DAT_BalanceBatch modules.
Convergent	Nonusage	The object instances previously loaded into the DAT_AccountBatch and DAT_BalanceBatch modules are reloaded. The data will not be loaded from the next initialization of Pipeline Manager.
Nonusage	Prepaid	No changes occur.
Nonusage	Postpaid	The object instances are loaded into the DAT_AccountBatch and DAT_BalanceBatch modules. The data is loaded into DAT_BalanceBatch immediately; however, the data is loaded into DAT_AccountBatch on the next business event processing for that account or service.
Nonusage	Convergent	The object instances are loaded into the DAT_AccountBatch and DAT_BalanceBatch module. The data is loaded into DAT_BalanceBatch immediately; however, the data is loaded into DAT_AccountBatch on the next business event processing for that account or service.

Note:

Any cache residency value change is not reflected immediately in the DAT_AccountBatch module of Pipeline Manager. The data is loaded only during the subsequent business event processing for that account or service. If you change the cache residency value to a value that is not configured for batch loading, Pipeline Manager does not unload any data. However, the data is not loaded during subsequent Pipeline Manager initialization.

You change an object's cache type by calling the PCM_OP_CUST_CHANGE_BUSINESS_PROFILE opcode. For more information, see "Changing a Bill Unit's Business Profile" in BRM Managing Customers.

To configure BRM to handle all objects as postpaid, do not call PCM_OP_CUST_CHANGE_BUSINESS_PROFILE for each object. Instead, do the following:

• Disable the cache residency distinction functionality. See "Enabling Cache Residency Distinction", but in step 3, set the CacheResidencyDistinction value to disabled.

• In the wireless.reg registry file, set the ISC_ObjectCacheTypeOutputSplitter iScript's Active entry to False. (See BRM Configuring Pipeline Rating and Discounting.)

Configuring BRM for Cache Residency Distinction

The procedures in this section describe how to configure BRM for cache residency distinction.

• Enable cache residency distinction functionality. See "Enabling Cache Residency Distinction".

• Assign objects a cache residency value. See "Assigning Objects a Cache Residency Value".

• Set up cache residency validation rules. See "Setting Up Cache Residency Validation Rules".

• Set the default cache type for the system. See "Changing the Default Business Profile".

• Override the default business profile. See "Overriding the Default Business Profile".

Enabling Cache Residency Distinction

By default, cache residency distinction is disabled. You enable it by modifying a field in the billing instance of the /config/business_params object.

You modify the /config/business_params object by using the pin_bus_params utility. See "pin_bus_params" in BRM Developer's Guide.

1. Use the following command to create an editable XML file from the billing instance of the /config/business_params object:

   pin_bus_params -r BusParamsBilling bus_params_billing.xml 
   

   This command creates an XML file named bus_params_billing.xml.out in your working directory. If you do not want this file in your working directory, specify the full path as part of the file name.

2. Search the XML file for following line:

   <CacheResidencyDistinction>disabled</CacheResidencyDistinction>
   

3. Change disabled to enabled.

   Caution:

   BRM uses the XML in this file to overwrite the existing billing instance of the /config/business_params object. Changing any parameter in this file affects the associated aspects of the BRM billing configuration.

4. Save and close the file.

5. Use the following command to load the change into the /config/business_params object:

   pin_bus_params bus_params_billing.xml 
   

   You should execute this command from the BRM_home/sys/data/config directory, which includes support files used by the utility. To execute it from a different directory, see "pin_bus_params" in BRM Developer's Guide

6. Read the object with the testnap utility or Object Browser to verify that all fields are correct.

   For more information, see the following topics in BRM Developer's Guide:

   • Using testnap

   • Reading Objects by Using Object Browser

7. Stop and restart the Connection Manager (CM). For more information, see "Starting and Stopping the BRM System".

8. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb".

Assigning Objects a Cache Residency Value

To assign a cache residency value to an object, associate it with a prepaid, postpaid, or convergent business profile and define cache validation rules.

For information on setting up business profiles, see "Setting Up Business Profiles and Validation Templates" in BRM Managing Customers.

For information on cache residency validation rules, see "Setting Up Cache Residency Validation Rules".

Setting Up Cache Residency Validation Rules

You define the PIN_FLD_OBJECT_CACHE_TYPE field value by associating an object with a prepaid, postpaid, or convergent business profile and setting the CacheResidency value in an object's validation template as shown in Table 16-4.

Table 16-4 Setting Up Cache Residency Validation Rules

Business Profile	CacheResidency Key	CACHE_TYPEField Value	Memory Cache
Convergent	DEFAULT	0	BRM database, DAT_AccountBatch, DAT_BalanceBatch
Prepaid	REALTIME	1	BRM database only
Postpaid	BATCH	2	DAT_AccountBatch, DAT_BalanceBatch
Nonusage	DBONLY	3	None
Convergent	DEFAULT_INACTIVE	4	BRM database, DAT_AccountBatch, DAT_BalanceBatch
Prepaid	REALTIME_INACTIVE	5	BRM database only
Postpaid	BATCH_INACTIVE	6	DAT_AccountBatch, DAT_BalanceBatch

When you set up a business profile, each validation template you associate with it must have a compatible cache residency value for all objects related to the /billinfo object. For example, if you set up a prepaid business profile with validation templates for the /billinfo, /balance_group, and /group/sharing/charges objects, the cache residency value in each object's validation template must be set to REALTIME, DEFAULT, DEFAULT_INACTIVE, or REALTIME_INACTIVE.

Note:

• The CacheResidency entry is optional. If it is not specified in the validation template, the PIN_FLD_OBJECT_CACHE_TYPE value for the object instance gets set to DEFAULT.

• The /account object does not have a validation template; it receives its cache residency value from its related /billinfo objects.

• The /uniqueness object does not have a validation template; it receives its cache residency value from its related /service object.

Important:

If a sponsor group, a top-up group, or a hierarchical account group with nonpaying bill units contains bill units with different business profile settings, the group owner's bill unit must use a compatible business profile. You must add rules to the /billinfo object's validation template for the business profile of the group owner's bill unit.

For specific instructions on how to set up business profiles and validation templates for objects, see "Setting Up Business Profiles and Validation Templates" in BRM Managing Customers.

Changing the Default Business Profile

By default, all reference object instances get assigned an object cache type value of DEFAULT (Convergent business profile) if they have not been associated with a business profile.

To assign a REALTIME or BATCH object cache type to object instances when they are made, change the default business profile for BRM. This value is defined in the billing instance of the /config/business_params object.

Note:

Before you change the default business profile, define and load the business files into the database. See "Setting Up Business Profiles and Validation Templates" in BRM Managing Customers.

Important:

If the business profile you set as the default business profile has not been loaded into the database or is not valid, the Convergent business profile is used.

Modify this object by using the pin_bus_params utility. See "pin_bus_params" in BRM Developer's Guide.

1. Use the following command to create an editable XML file from the billing instance of the /config/business_params object:

   pin_bus_params -r BusParamsBilling bus_params_billing.xml 
   

   This command creates an XML file named bus_params_billing.xml.out in your working directory. If you do not want this file in your working directory, specify the full path as part of the file name.

2. Search the XML file for following line:

   <DefaultBusinessProfile>Convergent</DefaultBusinessProfile>
   

3. Change Convergent to one of the following:

   • Prepaid: Sets the default cache type of all new objects to REALTIME (1).

   • Postpaid: Sets the default cache type of all new objects to BATCH (2).

     Caution:

     BRM uses the XML in this file to overwrite the existing billing instance of the /config/business_params object. If you delete or modify any other parameters in the file, these changes affect the associated aspects of the BRM billing configuration.

4. Save and close the file.

5. Use the following command to load the change into the /config/business_params object:

   pin_bus_params bus_params_billing.xml 
   

   You should execute this command from the BRM_home/sys/data/config directory, which includes support files used by the utility. To execute it from a different directory, see "pin_bus_params" in BRM Developer's Guide.

6. Read the object with the testnap utility or Object Browser to verify that all fields are correct.

   For more information, see the following topics in BRM Developer's Guide:

   • Using testnap

   • Reading Objects by Using Object Browser

7. Stop and restart the Connection Manager (CM). For more information, see "Starting and Stopping the BRM System".

8. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb".

Overriding the Default Business Profile

To override the default business profile that is assigned to an object during account creation, pass the business profile POID in the input flist of the PCM_OP_CUST_COMMIT_CUSTOMER opcode.

About Selective Account Loading

Pipeline Manager loads the subscriber data based on the service types configured for batch rating. If the service type is the same for both the prepaid and the postpaid subscribers, Pipeline Manager loads the prepaid subscriber data also.

You can configure your BRM system to load subscriber data selectively in Pipeline Manager based on the business profiles assigned to the accounts. For example, if you use selective account loading, you can load only data for postpaid services instead of postpaid and prepaid data, even though the service type is the same. You can configure any cache residency type data to be loaded into Pipeline Manager memory.

Selective account loading in Pipeline Manager provides:

• Reduced load time during initialization because less data is retrieved from the database.

• Improved memory usage because only selective subscriber information is stored in memory.

When rating the CDRs, Pipeline Manager treats the data as valid only if the cache residency value of the data at the time of the event matches with the values configured for loading data into Pipeline Manager.

Configuring Pipeline Manager for Selective Account Loading

You can configure Pipeline Manager to load selective accounts during initialization by enabling selective account loading functionality. See "Enabling Selective Account Loading".

Note:

For selective account loading functionality, you must enable the cache residency distinction parameter. See "Enabling Cache Residency Distinction".

Enabling Selective Account Loading

By default, selective account loading functionality is disabled. You can enable this functionality by loading and configuring an optional business parameter, CacheResidenciesForBatchPipeline, in the BRM_home/sys/data/config/bus_params_selective_loading.xml file.

To load and configure the values in the CacheResidenciesForBatchPipeline business parameter:

1. Search the bus_params_selective_loading.xml file for following line:

   <CacheResidenciesForBatchPipeline>0,1</CacheResidenciesForBatchPipeline>
   

2. Change 0,1 to any cache residency values of accounts you want to load, separated by comma. For example, to load convergent, prepaid, and postpaid accounts into Pipeline Manager, change 0,1 to 0,1,2.

3. Save and close the file.

4. Use the following command to load the change into the /config/business_params object:

   pin_bus_params bus_params_selective_loading.xml 
   

   You should execute this command from the BRM_home/sys/data/config directory, which includes support files used by the utility. To execute it from a different directory, see "pin_bus_params" in BRM Developer's Guide.

5. Read the object with the testnap utility or Object Browser to verify that all fields are correct.

   For more information, see the following topics in BRM Developer's Guide:

   • Using testnap

   • Reading Objects by Using Object Browser

6. Stop and restart the CM. For more information, see "Starting and Stopping the BRM System".

7. Stop and restart Pipeline Manager.

8. (Multischema systems only) Run the pin_multidb script with the -R CONFIG parameter. For more information, see "pin_multidb".

The following is a sample bus_params_selective_loading.xml file:

BusParamConfigurationClass>
  <BusParamsSelectiveLoading>
    <CacheResidenciesForBatchPipeline>0,1,2</      CacheResidenciesForBatchPipeline >
  </BusParamsSelectiveLoading>
</BusParamConfigurationClass>

Here, 0,1,2 specifies the cache residency types DEFAULT, REALTIME, and POSTPAID. After the CacheResidenciesForBatchPipeline business parameter is loaded, Pipeline Manager loads all accounts with Convergent, Prepaid, and Postpaid business profiles.

Configuring Pipeline Manager to Process Prepaid CDRs

By default, Pipeline Manager rates only one event type per service (for example, delayed session event for GSM telephony service).

If the selective account loading functionality is enabled, you can load prepaid subscribers in Pipeline Manager. However, Pipeline Manager rejects any prepaid CDRs of the prepaid subscribers if the delayed event type configured for batch rating is not present in any of the products owned by the service or account. This is because of the difference in the prepaid and postpaid event types. For example, real-time session event for prepaid events and delayed session event for postpaid events.

To allow the CustomerSearch module to accept the prepaid CDRs, you can use the FCT_Account module DisableRatingProductCheck registry entry to configure how product rating is checked:

• If you enable this entry, FCT_Account does not reject any prepaid CDRs of the prepaid subscribers if the configured event for batch rating is not present in any of the products owned by the service or account. Pipeline Manager does not rate CDRs, but the DAT_AccountBatch plug-in provides the subscriber information. You can use this subscriber information for any customized processing. For example, to pass rated roaming prepaid CDRs through Pipeline Manager, you can customize the action on the CDRs based on the subscriber information.

• If you disable this entry, the FCT_Account rejects any prepaid CDRs of the prepaid subscribers if the configured event for batch rating is not present in any of the products owned by the service or account. By default, DisableRatingProductCheck is set to False.

Customizing Cache Residency Distinction

You can customize cache residency by performing any of the following tasks:

• Configure nonreference storable classes or custom storable classes for cache residency distinction. See "Configuring Nonreference Objects for Cache Residency Distinction".

• Create, change, or delete business profiles. See "Setting Up Business Profiles and Validation Templates" in BRM Managing Customers.

• Create new validation templates (subclasses of the /config/template base class). See "Creating Custom Fields and Storable Classes" in BRM Developer's Guide.

• Customize the ISC_ObjectCacheTypeOutputSplitter iScript. See "ISC_ObjectCacheTypeOutputSplitter" in BRM Configuring Pipeline Rating and Discounting.

Configuring Nonreference Objects for Cache Residency Distinction

For specific instructions on how to create and modify storable classes, see "Creating Custom Fields and Storable Classes" in BRM Developer's Guide.

To configure nonreference objects:

1. Use Storable Class Editor to define a new class or modify an existing BRM class, and add the RESIDENCY_TYPE attribute and PIN_FLD_OBJECT_CACHE_TYPE field to the class. See the Storable Class Editor Help.

2. Create a validation template for the new storable class. See "Setting Up Business Profiles and Validation Templates" in BRM Managing Customers.

   Important:

   This is necessary to validate the cache residency value. Be certain to set the CacheResidency key value to Prepaid, Postpaid, or Convergent.

3. Associate the new validation template with a business profile.

4. Add or modify iScript validation rules to determine the PIN_FLD_OBJECT_CACHE_TYPE value for related object instances.

   Note:

   BRM does not supply iScript rules for business profile validation. Instead, you must create your own rules. For information about creating iScript validation rules, see "Creating iScripts and iRules" in BRM Developer's Guide.

5. Configure the iScript in the validation templates to return a list of object POIDs and the cache residency value for each one.

6. Customize the appropriate opcode to call the validation template. Perform a WRITE_FLDS operation on the object instances to set their PIN_FLD_OBJECT_CACHE_TYPE value.