This chapter explains how to integrate Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE) with Oracle Communications Billing and Revenue Management (BRM).
Before reading this chapter, you should be familiar with ECE concepts and architecture. See the following chapters in BRM Elastic Charging Engine Concepts:
ECE Overview
ECE System Architecture
The following steps summarize what you must do to integrate ECE with BRM:
Important:
Before integrating ECE with BRM, you must load ECE event and product definitions into Pricing Design Center (PDC), define product offerings in PDC, and synchronize those product offerings with BRM. See "Integrating ECE with PDC".(Optional) Reconfigure External Manager (EM) Gateway for your system.
Load BRM configuration files into BRM.
Configure ECE to receive customer data from BRM.
Create customer accounts in BRM and associate them with your product offerings.
See the BRM documentation for information about creating customer accounts.
Load customer data from BRM into ECE.
Configure ECE for synchronizing customer data with BRM.
See "Configuring ECE for Synchronizing Customer Data with BRM".
Configure ECE for sending rated events to BRM.
(Optional) Configure ECE for rerating.
Enable ECE to rate events during account migration.
(Optional) Configure EM Gateway for high availability.
See "Configuring External Manager Gateway for High Availability".
Start BRM Gateway by running the following command:
start brmGateway
(Optional) To integrate ECE with BRM multischema environments, see "Configuring ECE for a Multischema BRM Environment".
External Manager (EM) Gateway is a mandatory ECE component used for the following tasks:
Synchronizing customer data between BRM and ECE in real time
Processing rerating requests
Fetching real-time balances from ECE
When you installed ECE, you provided information for configuring EM Gateway. To change the information you provided during installation, follow these instructions.
To reconfigure EM Gateway:
Access the ECE MBeans:
Log on to the driver machine, which is the machine on which you installed ECE.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file, where ECE_home is the directory in which ECE is installed.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.emGatewayConfigurations.Instance_Name, where Instance_Name is the name of the instance you want to configure.
Expand Attributes.
Specify values for the following attributes:
threadPoolSize: Enter the number of EM Gateway threads to start each time EM Gateway starts.
port: Specify the port number of the machine on which EM Gateway resides.
name: Enter the host name of the machine on which EM Gateway resides.
Open the ECE_home/oceceserver/config/eceTopology.conf file.
Verify that an entry exists for EM Gateway with the correct settings.
For information about configuring settings in the ECE topology file, see the discussion about configuring the ECE system in BRM Elastic Charging Engine System Administrator's Guide.
After EM Gateway is configured, you can start it. Alternatively, you can start it immediately before you perform rerating.
For information about starting EM Gateway, see the discussion about starting and stopping ECE in BRM Elastic Charging Engine System Administrator's Guide.
The ECE installation includes the following BRM configuration files, which contain specific configurations for ECE. Copy these files to your BRM installation, and configure BRM to use them.
Important:
Before loading files that may overwrite existing files, make backups of the files on your BRM system.ECE_home/oceceserver/brm_config/payloadconfig_ece_sync.xml. See the discussion about loading the ECE configuration files into your BRM environment in BRM Setting Up Pricing and Rating.
ECE_home/oceceserver/brm_config/pin_notify: See the discussion about using event notification in BRM Developer's Guide and about using the load_pin_notify utility in BRM Managing Customers.
To configure ECE to receive the initial load of customer data from BRM and then to receive customer data updates, configure Customer Updater. To configure ECE to move failed update requests from Customer Updater, configure the suspense queue. See the following for more information:
To configure Customer Updater:
Point the BRM Payload Generator External Module (EM) configuration file to the ECE payload configuration file (payloadconfig_ecc_sync.xml).
(Optional) To load data for only specified customers, enable Customer Updater to use prepopulated distribution tables as follows:
Ensure that you have created prepopulated distribution tables. To create prepopulated distribution tables, see "Creating Prepopulated Distribution Tables".
Open the ECE_home/oceceserver/config/defaultTuningProfile.properties file.
This is the default Java virtual machine (JVM) tuning file. For information about custom JVM tuning files, see the discussion about configuring JVM parameters in BRM Elastic Charging Engine System Administrator's Guide.
Add the following Java property to the file:
-DpreDistributedWorkItems=true
Save and close the file.
(Optional, Testing Only) Enable Customer Updater to continue extracting data even if validation fails as follows:
Open the ECE_home/oceceserver/config/defaultTuningProfile.properties file.
This is the default Java virtual machine (JVM) tuning file. For information about custom JVM tuning files, see the discussion about configuring JVM parameters in BRM Elastic Charging Engine System Administrator's Guide.
Add the following Java property to the file:
-DcontinueCustomerLoaderOnError=true
Note:
Set this property to true only in a testing environment. In a production environment, all customer data is loaded into ECE, so set this property to false.Save and close the file.
Open the ECE_home/config/management/migration-configuration.xml file.
Set the remoteWmThreads parameter to the number of parallel work manager threads to be used for Customer Updater.
By default, this parameter is set to 1.
Set the batchSize parameter to the number of customers to put into the repository in one put operation.
Use batchSize to optimize performance of put operations into the repository. The more customers you insert into the repository in one put operation (rather than inserting each one individually), the better the performance.
By default, this parameter is set to 5000.
Set the dbConnections parameter to the number of parallel database connections to use for initial extraction and load of customer data.
By default, this parameter is set to 1.
Set the dbFetchSize parameter to the number of records that Customer Updater should extract from the BRM database at one time.
By default, this parameter is set to 5000.
Save and close the file.
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.connectionConfigurations.oracleQueueConnection1.
Expand Attributes.
Specify values for the following attributes:
password: Enter the encrypted password for logging on to the computer on which the database queue resides.
When you install ECE, the password you enter is encrypted and stored in the keystore.
queueName: Enter the name of the database queue that holds the published business events from BRM.
jdbcUrl: Enter the Oracle JDBC URL to use to connect to the BRM database:
jdbcUrl="jdbc:oracle:thin@//hostname:port:sid"
where hostname and port are the host name and port number of the computer on which the database queue resides, and sid is the name of the BRM database service.
In a BRM multischema environment, each schema publishes business events to its own Oracle Advanced Queuing (Oracle AQ) database queue for ECE to consume. Configure one Customer Updater process for each Oracle AQ database queue. Each Customer Updater process loads the initial BRM customer data before listening for customer updates.
To configure multiple Customer Updater processes:
Open the ECE_home/oceceserver/config/eceTopology.conf file.
Add a row to the file for each Customer Updater process.
Use a unique name for each process so that Elastic Charging Controller (ECC) can distinguish between them. (All Customer Updater processes use the same role.)
For example, to configure three Customer Updater processes, add three rows in which the name value is customerUpdater, customerUpdater2, and customerUpdater3 respectively, and the role value for all three rows is customerUpdater.
Save and close the file.
Open the ECE_home/oceceserver/config/management/charging-settings.xml file.
Add the details of each BRM schema to the file.
Ensure that you map a unique ID to each schema number for each Customer Updater process.
Note:
To support account migration, the definition for each Customer Updater process in the charge-settings file must specify the fully qualified name of the Account Migration Manager (AMM) acknowledgment queue in the amtAckQueueName entry. (All BRM database schemas use the same AMM acknowledgment queue.)For example, to add the details for BRM schema 1:
<ConnectionConfiguration
config-class="oracle.communication.brm.charging.appconfiguration.beans.connection.OracleQueueConnectionConfiguration"
name="customerUpdater1"
gatewayName="CustomerUpdater"
hostName="@HOST_NAME@"
port="@PORT@"
sid="@SERVICE_NAME@"
userName="@USER_NAME@"
Password="@PASSWORD@"
queueName="@QUEUE_NAME@"
suspenseQueueName="@SUSPENSE_QUEUE_SUSPENSE@"
ackQueueName="@RERATING_ACK_QUEUE@"
amtAckQueueName="@PIN01.AMM_ACK_QUEUE@"
batchSize="1"
schemaNumber="1"
</connectionConfiguration>
And to add the details for BRM schema 2:
<ConnectionConfiguration
config-
class="oracle.communication.brm.chraging.appconfiguration.beans.connection.OracleQueueConnectionConfiguration"
name="customerUpdater2"
gatewayName="CustomerUpdater"
hostName="@HOST_NAME@"
port="@PORT@"
sid="@SERVICE_NAME@"
userName="@USER_NAME@"
Password="@PASSWORD@"
queueName="@QUEUE_NAME@"
suspenseQueueName="@SUSPENSE_QUEUE_SUSPENSE@"
ackQueueName="@RERATING_ACK_QUEUE"
amtAckQueueName="@PIN01.AMM_ACK_QUEUE@"
batchSize="1"
schemaNumber="2"
</connectionConfiguration>
Save and close the file.
ECE moves failed update requests from Customer Updater to the suspense queue.
For information about handling failed events in the suspense queue, see the discussion about handling failed update requests from BRM in ECE System Administrator's Guide.
To configure the suspense queue:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.connectionConfigurations.oracleQueueConnection1.
Expand Attributes.
Set the suspenseQueueName attribute to the name of the queue on the BRM system that holds failed update requests from BRM.
By default, Customer Updater loads all BRM customer data into ECE.
To load data for only specified customers (that is, to load data incrementally), you must use prepopulated distribution tables. Only data for the customers listed in the prepopulated distribution tables is loaded.
For example, if customers are migrated from an external billing system into BRM by a customer management tool, the customer management tool can directly load the customers into the BRM database. In such cases, the migrated customers can then be loaded into ECE by using the ECE incremental loading mechanism.
For more information about incremental loading, see "About customerLoader".
To create prepopulated distribution tables:
Open the ECE_home/oceceserver/bin/preselect_customer.groovy file.
Specify the filter criteria to use for selecting customers to load by updating the filterCondition string.
Note:
The filter criteria you specify are added to the WHERE clause of the SQL query that selects the customer account Portal object IDs (POIDs) from the BRM account_t table.Enter the following command:
./preselect_customers.sh -u dbUser -p dbPassword -s dbHost -o oracleSID -c dbPort -n noOfdbConnections -f dbFetchSize
where:
dbUser is the name of the BRM database user.
dbPassword is the password of the BRM database user.
dbHost is the host name or IP address of the BRM database user.
oracleSID is the Oracle database alias.
dbPort is the number for the Oracle database port.
noOfdbConnections is the number of connections to use when extracting BRM customer data from the database. You must set noOfdbConnections and the Customer Updater dbConnections parameter to the same value. By default, 1.
dbFetchSize is the number of records to fetch from the database at one time. You must set dbFetchSize and the Customer Updater dbFetchSize parameter to the same value. By default, 5000.
The distribution tables that Customer Updater uses to load BRM customers into ECE are created and populated with details of the selected customers.
(Multischema environment only) Run the preselect_customer.sh script in each schema.
When you run the script, specify the database credentials for that schema.
To load data from BRM into ECE:
Verify that PDC is installed.
Verify that the ECE charging server nodes are not running.
On the machine on which ECC is installed, go to ECE_home/oceceserver/bin.
Start ECC:
./ecc
Run the following commands in this order:
start start configLoader start pricingUpdater start customerUpdater
These commands start configLoader, Pricing Updater, and Customer Updater. In an integrated system:
configLoader loads mediation specification updates.
Pricing Updater loads pricing, configuration, and event definition (request specification data) updates from PDC.
Note:
Only PDC data created after Pricing Updater starts is automatically published to ECE.PDC data that existed before Pricing Updater started is not automatically published to ECE. Instead, you must first extract such data from PDC and then reload it into PDC to trigger publication to ECE. For more information on extracting and reloading the PDC pricing data, see the discussion about importing and exporting pricing and setup components in PDC User's Guide.
Customer Updater loads data keys, customer data updates, and product cross-reference data from BRM.
When RADIUS Gateway is started, the data keys are decrypted using the BRM root key in the Oracle wallet file and are stored in the memory with a data key ID for each data key. These data keys are used for decrypting the passwords in authentication responses from ECE.
After loading the initial customer data from BRM, you can load customer data incrementally, in batches or in bulk, from BRM into ECE. See "Loading Customer Data Incrementally with customerLoader".
As part of the initial load of customer data into ECE, Customer Updater loads data keys from BRM into ECE. When you add a new data key or modify an existing data key in BRM, use a JMX editor to load those data keys from BRM into ECE.
To load data keys from BRM into ECE:
Access the Customer Updater MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started) and Customer Updater.
See "Starting and Stopping ECE" in ECE System Administrator's Guide.
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the Customer Updater node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the UpdateEventhandler node.
Expand Update.
Expand Operations.
Select updateDataKeys.
Click the updateDataKeys button.
The newly added or modified data keys are loaded from BRM into ECE.
To configure ECE for synchronizing customer data with BRM, see the following topics:
Enabling Real-Time Synchronization of BRM and ECE Customer Data Updates
Configuring the CM to Get Real-Time Balances for a Service from ECE
BRM Gateway listens on a JMS topic for notifications that ECE publishes. The notifications ECE publishes to the JMS topic trigger update requests to BRM.
To configure BRM Gateway:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.connectionConfigurations.brmConnection.
Expand Attributes.
Specify connection values to the BRM Connection Manager (CM):
hostName. Enter the IP address or the host name of the computer on which BRM is installed.
password. Enter the password for logging in to BRM.
If you change the password, you must run a utility to encrypt it. See the discussion about encrypting new passwords in BRM Elastic Charging Engine System Administrator's Guide for instructions.
loginName. Enter the user name for logging in to BRM. The default is root.0.0.0.1.
numberofConnections. Enter the number of connections configured for pooling.
failOverConnectionUrls. Enter connection values to the additional BRM CMs available for failover in the following format:
hostName1:cmPort,hostName2:cmPort,hostName3:cmPort...
When this attribute is set, ECE switches to the next available BRM CM when the active connection fails.
cmPort. Enter the port number for the CM.
To configure notifications for BRM, see the following topics:
For ECE to publish external notifications, you must configure the JMS credentials for the JMS server on which the ECE notification queue (JMS topic) resides. When you install ECE, the installer prompts you to enter the JMS credentials, which are specified in the ECE_home/oceceserver/config/JMSConfiguration.xml file. BRM Gateway refers to the JMSConfiguration.xml file to obtain the JMS credentials for the ECE notification queue. To change these settings, see "Configuring JMS Credentials for Publishing External Notifications".
To configure notifications to send information (updates) to BRM from ECE, see the following topics:
Configuring Billing Notifications
To configure billing notifications:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Set the billingNotificationMode attribute to one of the following values:
To disable the generation of billing notifications, enter NONE.
To generate an external notification and send it to a notification queue (JMS topic) when the BILLING_NOTIFICATION_EVENT service event is created, enter ASYNCHRONOUS.
Configuring Notifications Replenishing POID IDs
You configure notifications that trigger BRM to update POID IDs from ECE to BRM for each BRM schema. For information about setting the initial caching of POID IDs, see "Configuring Item Assignment in ECE for BRM".
To configure notifications that trigger BRM to update POID IDs:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Set the replenishPoidIdNotificationMode attribute to one of the following values:
To disable the generation of life cycle transition notifications, enter NONE.
To generate an external notification and send it to a notification queue (JMS topic) when the REPLENISH_POIDID_NOTIFICATION_EVENT service event is created, enter ASYNCHRONOUS.
Configuring Life Cycle Transition Notifications
Configure life cycle transition notifications so that when changes occur to a customer's subscriber life cycle state in ECE, ECE sends the subscriber life cycle state information to BRM so that BRM can update the state in the BRM database.
To configure life cycle transition notifications:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Set the lifeCycleTransitionNotificationMode attribute to one of the following values:
To disable the generation of life cycle transition notifications, enter NONE.
To generate an external notification and send it to a notification queue (JMS topic) when the LIFE_CYCLE_TRANSITION_NOTIFICATION_EVENT service event is created, enter ASYNCHRONOUS.
Configuring First-Usage Validity Notifications
Configure first-usage validity notifications for synchronizing validity of first-usage resources from ECE to BRM and from ECE to NCC Notification Gateway.
To configure first-usage validity notifications:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.notification.
Expand Attributes.
Set the firstUsageValidityInitNotificationMode attribute to one of the following values:
To disable the generation of first-usage validity notifications, enter NONE.
To generate an external notification and send it to a notification queue (JMS topic) when the FIRST_USAGE_VALIDITY_INIT_NOTIFICATION_EVENT service event is created, enter ASYNCHRONOUS.
If you installed an ECE integrated installation for the first time, you can skip this task. The ECE post-installation script automatically creates the BRM Gateway suspense queue.
If you installed a patch set (for example, ECE 11.3 Patch Set 2) on top of an existing ECE integrated installation, use the WebLogic server to manually create the BRM Gateway suspense queue.
To create the BRM Gateway suspense queue manually:
Log on to a WebLogic server on which a notification queue (JMS topic) resides.
Log in to WebLogic Server Administration Console.
In the Services section, select JMS Modules.
On the Summary of JMS Modules page, click ECE Module.
In the Change Center pane, click Lock and Edit.
In the Summary of Resources table, click New.
The Summary of Resources table contains the resources of the JMS modules.
On the Create a New JMS System Module Resource page, select Queue.
Click Next.
In the Name field, enter SuspenseQueue.
In the JNDI Name field, enter ECE/SuspenseQueue.
Click Next.
From the Subdeployments list, select ECEQUEUE.
From the Targets list, select NotificationServer.
Click Finish.
Click Activate.
The changes are applied immediately.
When customer data is updated in the BRM database, the updates must be applied synchronously (in real time). For more information, see the discussion about synchronizing BRM and ECE customer data in BRM Elastic Charging Engine Concepts.
To enable real-time synchronization of BRM and ECE customer data updates:
Open the BRM_home/sys/cm/pin.conf file in a text editor.
Add the following entries to the end of the file:
-cm ece_real_time_sync_db_no DBNumber -cm em_group ece PCM_OP_ECE_PUBLISH_EVENT -cm em_pointer ece ip emGateway_host emGateway_port
where:
DBNumber is the publisher database number for EM Gateway.
Note:
By default, the publisher database number for EM Gateway is 0.0.9.8.emGateway_host is the name or IP address of the server on which EM Gateway is running.
emGateway_port is the number of the port through which EM Gateway connects to the host.
Save and close the file.
If your publisher database number for EM Gateway is not 0.0.9.8:
Open the BRM_home/sys/eai_js/payloadconfig_ifw_sync.xml file (or the merged file if you merged payload configuration files) in a text editor.
Locate the PublisherDefs section.
In the Publisher DB="DBNumber" entry, replace DBNumber with the publisher database number of your EM Gateway.
Save and close the file.
If you changed the publisher database number for EM Gateway in the payloadconfig_ifw_sync.xml file, restart the Payload Generator External Module (also called the Enterprise Application Integration (EAI) Java Server or eai_js).
Restart the CM.
See the discussion about starting and stopping the BRM system in BRM System Administrator's Guide.
The CM connects to ECE through EM Gateway.
To configure the CM to get real-time balances for a service from ECE:
Open the BRM_home/sys/cm/pin.conf file in a text editor.
Add the following entry:
- cm em_group ece_bal PCM_OP_BAL_GET_ECE_BALANCES
Set the following entry to match your environment:
- cm em_pointer ece_bal ip emGateway_host emGateway_port
emGateway_host is the name or IP address of the server on which EM Gateway is running.
emGateway_port is the number of the port through which EM Gateway connects to the host.
Save and close the file.
Stop and restart the CM.
You configure item assignment in ECE so that customer balance impacts can be applied to bill items. The default item type configuration is sufficient for default item assignments. For custom item assignments, configure item assignments and the appropriate item type selectors in PDC. See the PDC Help.
If you configured delayed billing in BRM, you must configure item assignment in ECE to process delayed usage requests in the appropriate accounting cycle.
To configure item assignment in ECE:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.itemAssignmentConfig.
Expand Attributes.
Review the following attributes:
itemAssignmentEnabled: Enter true to turn on item assignment or false to turn it off.
poidQuantityPerSchema: Double-click the Value field. A list of schemas and the quantity of POID IDs that is reserved at ECE startup for each schema appears. To add schemas to the list or to change the quantity of POID IDs for a schema in the list, see step 5.
delayToleranceIntervalInDays: Enter the number of days during which delayed usage requests are processed for the current accounting cycle. This interval must be less than the delayed billing interval (the value of the config_billing_delay entry in the BRM_home/sys/cm/pin.conf file). See the discussion about processing delayed usage requests for more information.
To add a schema to the poidQuantityPerSchema list or to change the quantity of POID IDs for a schema in the list:
Expand Operations.
Select setPoidQuantity.
Specify values for the following parameters:
schema: Enter the BRM schema number for which the POID IDs must be reserved. For example, in a multischema environment, enter 1 for the primary schema, 2 for the secondary schema, and so on.
quantity: Enter the number of POID IDs that must be reserved at ECE startup for the specified schema.
Click the setPoidQuantity button.
ECE supports the BRM subscriber life cycle state feature. If the subscriber life cycle state feature is disabled in BRM, ECE supports only the default subscriber life cycle, which has the following states: Active, Inactive, and Closed. If the subscriber life cycle state feature is enabled in BRM, ECE supports custom subscriber life cycles, which has the following states: Preactive, Active, Recharge Only, Credit Expired, Fraud Investigated, Dormant, Suspended, and Closed. See the discussions about service life cycles and enabling BRM to use custom service life cycles in BRM Managing Customers for more information.
You can customize the preconfigured subscriber life cycle state. You must configure life cycle states in ECE, so they stay synchronized with life cycle states you add in BRM.
To configure life cycle states in ECE for BRM:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.lifecycleConfiguration.
Expand Operations.
Select addLifecycleDetails.
Specify values for the operation's parameters to associate the appropriate life cycle state business rules and transitions with each product type in your system.
For more information about life cycle state business rules and transitions, see the discussion about managing service life cycles in BRM Managing Customers.
Click the addLifecycleDetails button.
Your configurations are saved to the ECE_home/oceceserver/config/management/charging-settings.xml file.
The ECE charging servers generate rated events as a result of usage-request processing. ECE sends the rated events to BRM so that customer balances in BRM can be updated.
For ECE to send rated events to BRM, you must configure the following components:
Rated Event Publisher
Rated Event Formatter
BrmCdrPluginDirect Plug-in
Rated Event Loader
Assuming these components are configured and Rated Event Formatter is running, the ECE charging servers generate event data record (EDR) files as a result of usage-request processing. The BrmCdrPluginDirect Plug-in formats the EDR files in BRM call details record (CDR) format. The EDRs can then be loaded by Rated Event (RE) Loader into the BRM database. See "Setting Up Rated Event Loader for ECE".
For ECE to send rated events to BRM, you must enable and configure Rated Event Publisher. Rated Event Publisher publishes ECE-generated rated events to the Oracle NoSQL database data store.
To verify that Rated Event Publisher is enabled and to configure Rated Event Publisher:
Obtain the BRM database schema number (PoidDB) of each target BRM database schema.
Open the ECE_home/oceceserver/config/charging-cache-config.xml file.
For the RatedEventPublisher module, verify that the following entry is used for the cache-store configuration:
<init-param>
<param-name>cache-store</param-name>
<param-value>oracle.communication.brm.charging.ratedevent.publisher.internal.coherence.RatedEventPublisher</param-value>
Save the file.
Open the ECE_home/oceceserver/config/management/charging-settings.xml file.
In the ratedEventPublisher section, set the required configuration parameters.
Table 3-1 provides configuration parameter descriptions and default values.
Table 3-1 Rated Event Publisher Configuration Parameters
| Name | Default | Description and Guideline |
|---|---|---|
|
dataStoreConnection |
"localhost:5000" |
This parameter configures Rated Event Publisher to connect to the Oracle NoSQL database; it configures the data store connection to the Oracle NoSQL database system. The Oracle NoSQL database connection string uses the format hostname:port for connecting to a pre-configured Oracle NoSQL database system. The default is "localhost:5000" for connecting to a standalone Oracle NoSQL database system (KV-Lite). |
|
dataStoreName |
"kvstore" |
This parameter configures the data store name to an Oracle NoSQL database system. The data store name is for using a pre-configured data store in an Oracle NoSQL database system. The default is "kvstore" for using a standalone Oracle NoSQL database system (KV-Lite). |
|
threadPoolSize |
"4" |
This parameter configures the number of threads in the thread pool. Multiple threads can be used in a RatedEventPublisher module where each thread can publish rated events to an Oracle NoSQL database system independently. The valid number is greater than zero. For best performance, Oracle recommends that you set this parameter to the number of Oracle NoSQL database partitions. Setting the number of threads higher than the number of partitions does not increase performance. Threads that you configure higher than the number of partitions are not used. |
Save the file.
For information about how to verify that Rated Event Publisher published rated events to NoSQL, see "Verifying That Rated Events Are Published to Oracle NoSQL Database".
To send rated events to BRM, you must install and configure Rated Event Formatter. Rated Event Formatter extracts rated events from the Oracle NoSQL database data store and formats them into CDR files in the format required for loading them into the BRM database. For information about Rated Event Formatter, see the discussion about ECE system architecture in BRM Elastic Charging Engine Concepts.
To format rated events for a non- BRM system instead of the BRM database, you must configure an additional Rated Event Formatter instance.
Rated Event Formatter is included in the ECE Server software package. Install Rated Event Formatter on a machine that is part of the ECE topology. RE Loader should be able to access the same file system as Rated Event Formatter. See "Setting Up Rated Event Loader for ECE".
To configure Rated Event Formatter:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.ratedEventFormatters.Instance_Name, where Instance_Name is the name of the instance you want to configure.
Expand Attributes.
Specify values for name and partition and for any remaining attributes you need to set for the instance.
See Table 3-2 for attribute descriptions and default values.
Table 3-2 Configuration Parameters for a Rated Event Formatter Instance
| Name | Default | Description |
|---|---|---|
|
name |
"formatter" |
The name of a Rated Event Formatter instance. Name Rated Event Formatter instances consistently and uniquely (for example, formatter1, formatter2, and so on). name must match the name of the Rated Event Formatter node instance in the ECE_home/oceceserver/config/eceTopology.conf file. |
|
"1" |
The partition for the rated events to be processed by a Rated Event Formatter instance. partition must match the target BRM database schema number for the schema to which the ECE rated event is to be exported. For example, for a BRM multischema environment, BRM schema 0.0.0.1, partition must be set to 1; for BRM schema 0.0.0.2, partition must be set to 2; and so on. See "Configuring ECE for a Multischema BRM Environment" for additional information about configuring ECE for a multischema environment. You may want to name your formatter instances to correlate with the partition number. For example, one instance of Rated Event Formatter named formatter1 can process rated events to be exported to the BRM schema 0.0.0.1 (partition value 1), and another instance of Rated Event Formatter named formatter2 can process rated events to be exported to the BRM schema 0.0.0.2 (partition value 2), and so on. |
|
|
dataStoreConnection |
"localhost:5000" |
The connection information to the Oracle NoSQL database. The connection string consists of host name and port number for connecting to an Oracle NoSQL system. |
|
dataStoreName |
"kvstore" |
The data store name to be used to access an Oracle NoSQL system. |
|
retainDuration |
0 |
The duration in seconds that rated events must be retained in the Oracle NoSQL database after they have been processed before they can be purged. Set the value to the seconds you want to retain rated events in the Oracle NoSQL database after Rated Event Formatter has published the rated events as RE Loader records (CDR records). The default is 0, which means that as soon as rated events are processed, they are purged immediately. For more information, see the discussion about managing persisted data in the Oracle NoSQL database in BRM Elastic Charging Engine System Administrator's Guide. |
|
ripeDuration |
60 |
The duration in seconds that rated events have existed before they can be processed. This setting must be greater than the time it takes for ECE charging servers to fully recover after failure. Delaying the processing of rated events up to the ripeDuration time allows time for resolving any duplicate rated events that may have been persisted to the Oracle NoSQL database. The ripeDuration value is the minimum number of seconds rated event information must be stored in the Oracle NoSQL Database before the Rated Event Formatter can read it. |
|
checkPointInterval |
4 |
The time range in seconds used by the Rated Event Formatter instance to read a set of rated events at a repeated time interval. Valid values must be the following:
This is the number of seconds Rated Event Formatter waits before reading a batch of rated event information. If rated event information in a batch has not yet met the value of ripeDuration, the Rated Event Formatter does not read it. |
|
threadPoolSize |
4 |
The number of threads used by the Rated Event Formatter instance to process a set of rated events for each time range defined by checkPointInterval. Valid values are greater than zero and up to any number the system resources allow. Tune this value to the expected workload in the deployed environment. |
|
pluginPath |
n/a |
The path to the JAR library that contains the reader plug-in implementation. A custom plug-in has a modified path to the JAR library. |
|
pluginName |
n/a |
The class name with the package path for the formatter plug-in object to be called by Rated Event Formatter. Rated Event Formatter is configured by default to use the BrmCdrPluginDirect plug-in. If you are using the BRM database to process rated events, the pluginName is: oracle.communication.brm.charging.ratedevent.formatterplugin.BrmCdrPlugin If you are using a third-party system to process rated events, the pluginName is: oracle.communication.brm.charging.ratedevent.custom.CustomPlugin |
|
logFormatterWorker |
false |
Whether to enable (true) or disable (false) logging for the worker thread pool. |
Change directory to the ECE_home/oceceserver/bin directory.
Start ECC:
./ecc
Stop and restart any Rated Event Formatter instances that you configured.
Each instance reads its configuration information by name.
For information about stopping and starting Rated Event Formatter instances, see the discussion about starting and stopping ECE in BRM Elastic Charging Engine System Administrator's Guide.
If you suspect a problem with how Rated Event Formatter processes rated events, look in the ECE_home/oceceserver/logs/rated-event-formatter.log file for errors. The log file contains information about how many rated events are processed, how many are purged, and any errors during rated-event processing.
Rated events can be processed in different formats with a BRM database or a third-party system.
To process rated events in a BRM database, you must configure the BrmCdrPluginDirect plug-in. The BrmCdrPluginDirect plug-in formats ECE-rated events into BRM format.
To process rated events using a third-party system, you must configure a custom plug-in. The custom plug-in formats ECE rated events in various formats.
For more information about the BrmCdrPluginDirect plug-in, see the discussion about ECE system architecture in BRM Elastic Charging Engine Concepts.
To configure the BrmCdrPluginDirect plug-in:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.brmCdrPlugins.Instance_Name, where Instance_Name is the name of the instance that you want to configure.
Expand Attributes.
Specify values for the following attributes as needed:
Table 3-3 BrmCdrPluginDirect Plug-in Configuration Entries
| Name | Default | Description |
|---|---|---|
|
tempDirectoryPath |
"/tmp/tmp" |
The directory path for the BrmCdrPluginDirect plug-in to store temporary files while processing the rated event objects. |
|
doneDirectoryPath |
"/tmp/done" |
The directory path for the BrmCdrPluginDirect plug-in to store completed CDR files from processing the rated event objects. |
|
doneFileExtension |
".done" |
The file extension for the completed CDR files created by the BrmCdrPluginDirect plug-in. |
Stop and start the Rated Event Formatter instance associated with the BrmCdrPluginDirect plug-in instance.
Rated Event Formatter extracts preprocessed rated events from the Oracle NoSQL database data store over TCP/IP, and the BrmCdrPluginDirect plug-in stores the completed CDR files in the directory you specify. RE Loader then picks up the CDR files from that directory for processing.
RE Loader and Rated Event Formatter can reside on the same machine or on separate machines, but they must both be able to access the same file system. Specify the output directory of the BrmCdrPluginDirect plug-in as the input directory of RE Loader. You must configure the RE Loader Batch Controller to pick up the CDR files.
For information about installing and configuring RE Loader to load preprocessed EDRs into the BRM database, see BRM Configuring Pipeline Rating and Discounting. The BRM documentation refers to Pipeline Manager when describing how to configure RE Loader to load EDRs into the BRM database; that information also applies to ECE. RE Loader processes ECE-rated events similar to how it processes pipeline-rated events.
ECE writes all event fields to CDRs. If you want RE Loader to load only specific event fields into the BRM database, you must modify the RE Loader control files to indicate which event fields you want it to load. Control files with ECE control data are included with ECE. You copy and merge these files onto the BRM system. For information about editing control files, see the Oracle database utilities documentation at the following location:
http://docs.oracle.com/cd/B10501_01/server.920/a96652/ch05.htm#1004643
You configure ECE for rerating so that it can rerate usage events when rerating is run in BRM. You might run rerating for various reasons (for example, if one of your existing charge offers was replaced between the last and next billing cycles). For information about rerating in the BRM charging system, see the discussion about rerating in BRM Setting Up Pricing and Rating. For information about how ECE rerates usage events, see the discussion about understanding charging scenarios in BRM Elastic Charging Engine Concepts.
BRM and ECE work together for rerating. You run rerating jobs from BRM and BRM sends charging requests to ECE for rerating the usage events. ECE rerates the usage events for the specified customers in the rerate jobs and then sends the rerated events back to BRM. For the overall rerating process to work, you configure various components on the ECE and BRM side.
For information about configuring ECE for rerating, see the following topics:
Important:
For ECE to perform rerating, EM Gateway must be running.After all components are configured, you can run rerating in BRM using the pin_rerate utility. For instructions about running rerating by using the pin_rerate utility, see BRM Setting Up Pricing and Rating.
For information about handling rerating errors in ECE, see the discussion about troubleshooting ECE in BRM Elastic Charging Engine System Administrator's Guide.
The rerating acknowledgment queue is used to send rerating-related acknowledgments from ECE to BRM; it is an Oracle AQ database queue on the BRM system.
The rerating acknowledgment queue is configured during installation. See the discussion about post-installation tasks in BRM Elastic Charging Engine Installation Guide for information about creating this queue. You can change the acknowledgment queue configuration.
To configure the acknowledgment queue:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.connectionConfigurations.oracleQueueConnection.
Expand Attributes.
Set the ackQueueName attribute to the name of the acknowledgment queue for posting rerating-related acknowledgment events.
To configure BRM for ECE rerating:
Enable ECE rerating in BRM.
For information, see the discussion about enabling ECE rerating in BRM Setting Up Pricing and Rating.
Configure the CM for ECE rerating.
For information, see the discussion about configuring the CM for ECE rerating in BRM Setting Up Pricing and Rating.
Verify that the acknowledgment queue (Oracle Advanced Queuing (AQ) database queue) is created.
Note:
The acknowledgment queue is created by an ECE post-installation script. For more information, see the discussion about post-installation tasks in BRM Elastic Charging Engine Installation Guide.Verify that EM Gateway is configured and running.
See "Reconfiguring External Manager Gateway".
If EM Gateway is not running, do the following:
On the driver machine, go to the ECE_home/oceceserver/bin directory.
Start ECC:
./ecc
Run the following command:
start emGateway
Verify that BRM Gateway is configured and running.
See "Configuring BRM Gateway".
If BRM Gateway is not running, run the following command:
start brmGateway
You can now run rerating using the pin_rerate utility. For more information, see the discussion about rerating and the pin_rerate utility in BRM Setting Up Pricing and Rating.
In BRM, account migration consists of transferring the data associated with accounts from a source BRM database schema to a target BRM database schema. Account migration is performed by Account Migration Manager (AMM). For more information about account migration, see the discussion about migrating accounts in BRM System Administrator's Guide.
To enable ECE to rate events during account migration:
Configure the definition of your system's AMM controllers for ECE:
Open the BRM_home/sys/amt/Infranet.properties file in a text editor.
Verify that the following entry is set to true:
controller_1_event_generation=true
If more than one controller is defined in the file, ensure that each controller's controller_controllerNumber_event_generation= entry is set to true.
Save and close the file.
The change takes effect the next time the pin_amt utility is run. For more information, see the discussion about that utility in BRM System Administrator's Guide.
Configure ECE to use the AMM acknowledgment queue. See "Configuring ECE to Use the AMM Acknowledgment Queue" for more information.
Verify that Customer Updater is correctly configured for your system and running.
ECE receives AMM business events from the BRM Account Synchronization Data Manager (DM) database queue through Customer Updater. Because account migration involves multiple database schemas, Customer Updater must be configured to support all the database schemas in your system. It must also be configured to send AMM-related acknowledgments from ECE to your system's AMM acknowledgment queue.
For information about configuring Customer Updater, see the following:
Verify that BRM Gateway is correctly configured for your system and running.
Verify that Rated Event Formatter is correctly configured for your system and running.
After you enable ECE to rate events during account migration, the AMM business events listed in Table 3-4 automatically notify ECE that an account migration job is occurring. They enable ECE to track the status of the migration, to notify BRM if ECE fails to clear its rated event data store before the migration begins (a migration prerequisite), to continue rating events while the accounts are migrated, and to update its information about the target database schema for successfully migrated accounts.
Table 3-4 ECE Response to AMM Business Events
| AMM Business Event | ECE Response |
|---|---|
|
HoldCDRProcessing |
|
|
MigrateAcct |
Sends an ACKMigrateAcct acknowledgment to the AMM acknowledgment queue. |
|
MigrateSource |
Sends an ACKMigrateSource acknowledgment to the AMM acknowledgment queue. |
|
MigrateDestination |
Sends an ACKMigrateDestination acknowledgment to the AMM acknowledgment queue. |
|
ResumeCDRProcessing |
|
For more information about the events in Table 3-4, see the discussion about AMM business events in BRM System Administrator's Guide.
The AMM acknowledgment queue is used to send AMM-related acknowledgments from ECE to BRM; it is an Oracle AQ database queue on the BRM system.
To configure ECE to use the AMM acknowledgment queue:
Access the ECE MBeans:
Log on to the driver machine.
Start the ECE charging servers (if they are not started).
Start a JMX editor, such as JConsole, that enables you to edit MBean attributes.
Connect to the ECE charging server node set to start CohMgt = true in the ECE_home/oceceserver/config/eceTopology.conf file.
The eceTopology.conf file also contains the host name and port number for the node.
In the editor's MBean hierarchy, expand the ECE Configuration node.
Expand charging.connectionConfigurations.oracleQueueConnection.
Expand Attributes.
Set the amtAckQueueName attribute to the fully qualified name of the acknowledgment queue on which the pin_amt utility listens to AMM-related acknowledgment events:
schema.ammAcknowledgmentQueue
where:
schema is the name of the BRM database schema in which the AMM acknowledgment queue resides.
ammAcknowledgmentQueue is the name of the AMM acknowledgment queue.
For example:
PIN01.AMM_ACK_QUEUE
To configure EM Gateway for high availability:
Open the BRM_home/sys/cm/pin.conf file in a text editor.
Add additional EM Gateway pointers to the file to use for failover. For example:
-cm ece_real_time_sync_db_no 0.0.9.8 -cm em_group ece PCM_OP_ECE_PUBLISH_EVENT -cm em_pointer ece ip emGateway_host1 emGateway_port1 -cm em_pointer ece ip emGateway_host1 emGateway_port2 -cm em_pointer ece ip emGateway_host2 emGateway_port3 -cm em_pointer ece ip emGateway_host2 emGateway_port4
where
emGateway_host1 is the name or IP address of the server on which one instance of EM Gateway is running.
emGateway_port1 is the primary port number for EM Gateway on host 1.
emGateway_port2 is a backup port number for EM Gateway on host 1.
emGateway_host2 is the name or IP address of the server on which another instance of EM Gateway is running. (EM Gateway can run on multiple hosts.)
emGateway_port3 is the primary port number for EM Gateway on host 2.
emGateway_port4 is a backup port number for EM Gateway on host 2.
Set the value of the following entry to 2 or higher:
- cm cm_op_max_retries 2
This entry specifies the maximum number of times an opcode is retried in the CM. The default is 1. For high availability, the value must be at least 2.
Save and close the file.
Restart the CM.
See the discussion about starting and stopping the BRM system in BRM System Administrator's Guide.
For more information, see the discussion about high availability with the Elastic Charging server in BRM Elastic Charging Engine Concepts.
This section describes configuration tasks associated with configuring ECE for a multischema BRM environment.
For a multischema BRM environment, each schema publishes business events to its own Oracle Advanced Queuing (AQ) database queue for ECE to consume. Configure one ECE Customer Updater for each AQ database queue. See "Configuring Customer Updater for a BRM Multischema Environment" for instructions.
For a multischema BRM environment, each Rated Event Formatter instance can be configured to process rated events belonging to a specific BRM schema. See "Configuring Rated Event Formatter" for instructions.
The preceding points cover the configuration you need to perform in ECE for a multischema environment. The Customer Updater instance connected to the specific schema performs the initial extract and load of customer data from the BRM schema into ECE.