This chapter provides information for customizing Oracle Communications Billing and Revenue Management (BRM) for In-Memory Database (IMDB) Cache Data Manager (DM).
The following sections describe how to customize the default BRM cache groups and how to add custom cache groups to the BRM cache groups schema.
When you modify an existing cache group definition, you must unload any data in the cache group, drop the existing cache group, create the cache group with a new definition, and reload the data. Therefore, this operation requires service downtime. See Oracle In-Memory Database Cache User's Guide for more information about cache group operations.
You can modify the default BRM cache groups by adding custom storable objects or by modifying existing storable objects.
To customize the default BRM cache groups:
Create the custom storable class or modify the existing storable class. See "Creating Custom Fields and Storable Classes".
Edit the pin_tt_schema_gen.values file (BRM_home/bin/pin_tt_schema_gen.values) and modify the existing cache group definitions as needed. See "Configuring the pin_tt_schema_gen.values File".
No:
All custom storable classes for subscriber data must be added to the existing subscriber cache group. See "About Extending Tables in the Default BRM Cache Groups" for more information.Run the pin_tt_schema_gen utility with the -t parameter. This creates a schema SQL script that includes your custom tables and fields.
Using the TimesTen ttIsql, update the BRM cache groups schema in Oracle IMDB Cache as follows:
Stop the Oracle IMDB Cache replication agent.
Stop the cache agent.
Drop the cache group schema.
Run the tt_schema.sql file to generate the schema with the new definitions.
Start the cache agent.
Start the replication agent.
Reload the cache group, if needed.
Restart the IMDB Cache DM instance.
All custom storable classes for subscriber data must be added to the existing subscriber cache group definition to support resource sharing relationships. For example, if you define a custom service storable class such as /service/voip, the corresponding custom tables should be added in the subscriber cache group schema. Custom storable classes for other data types should be added to custom cache group definitions. See "Creating a Custom Cache Group".
All custom storable classes for transient objects should to be added to the Oracle IMDB Cache local tables.
You create custom cache groups manually by defining the custom cache group information in the pin_tt_schema_gen.values file, generating the schema SQL file, and then creating the schema in Oracle IMDB Cache. You can create the custom cache group using existing BRM storable objects or custom storable objects.
To create custom cache groups in Oracle IMDB Cache:
Create the custom storable class. See "Creating Custom Fields and Storable Classes".
Edit the pin_tt_schema_gen.values file (BRM_home/bin/pin_tt_schema_gen.values) and add a new cache group definition. See "Generating the BRM Cache Group Schema".
Run the pin_tt_schema_gen utility with the -t parameter to generate the tt_schema.sql script.
Using the TimesTen ttIsql tool, update the BRM cache groups schema in Oracle IMDB Cache as follows:
Stop the Oracle IMDB Cache replication agent.
Stop the cache agent.
Drop the cache group schema.
Run the tt_schema.sql file to generate the schema for the custom cache groups.
Start the cache agent.
Start the replication agent.
Load the cache group, if needed.
Restart the IMDB Cache DM instance.
See the Oracle In-Memory Database Cache User's Guide for more information on the different types of cache groups and how to define them.
Use Developer Center to create custom fields and storable classes and to modify existing fields and storable classes in the BRM database.
For specific instructions on how to create or modify fields and storable classes, see "Creating Custom Fields and Storable Classes" in BRM Developer's Guide.
After you create custom field and classes, you must make them available to applications. For specific instructions, see "Making Custom Fields Available to Your Applications" in BRM Developer's Guide.
When you define a custom storable class, you must also set the residency type for the class. The residency type specifies where the storable object resides in the BRM system. See the discussion on about the residency type in BRM Concepts.
Object residency types are predefined in the BRM data dictionary. To determine the residency type value for your custom storable class, you can run a SQL query on the BRM database to get the residency type values. For example, to get all the objects with residency type values 1, 5, or 7, you can run the query:
Select name, residency_type from dd_objects_t where residency_type in (1,5,7);
To set the residency type value for the custom storable class, you can run a SQL query on the BRM database to set the value. For example, to set the value for a custom service class, you can run the query:
update dd_objects_t set residency_type=1 where name like '/service%' and residency_type !=5 and residency_type !=7;
After setting the residency type value for the custom storable class, restart the IMDB Cache DM instance, and the Connection Manager (CM).
When you define a custom event storable class, it inherits the attributes of the parent event storable class. Event attributes can be:
Oracle IMDB Cache resident expanded object
BRM resident expanded object
When you extend the base event class (/event), you define the subclass by setting the residency type.
To retrieve only the database schema number from POID DB (excluding the logical partition number), use the PIN_GET_SCHEMA_NO macro.
This macro returns the database schema number from the database number provided in the parameter. A database number is represented in the format 0.logical_partition_number.0.database_schema_number. The PIN_GET_SCHEMA_NO macro extracts database_schema_number from the database number.