This chapter describes testing scenarios for testing an Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE) implementation in an integrated charging system.
To verify that configuration data is loaded into ECE, perform a CohQL query on the RequestSpecification cache by using the ECE query tool (query.sh).
To verify that pricing data is loaded into ECE and stored in the replicated pricing caches, perform a CohQL query on pricing related caches by using the ECE query tool.
For a list of pricing cache names, see the ECE_home/oceceserver/config/charging-cache-config.xml file.
To verify that customer data is loaded into ECE and stored in the distributed cache, perform a CohQL query on the Customer cache by using the ECE query tool.
To verify that rated events are successfully published to the Oracle NoSQL database, you can do the following:
In the Oracle NoSQL database data store directory, check the size of the data files. If the file size grows, this indicates that rated events were put into the Oracle NoSQL database.
Check Oracle NoSQL log files; a performance-related log file has statistics about the operations such as the read and write operations.
You cannot verify that a particular rated event was published to the Oracle NoSQL database.
Some types of testing may not require publishing rated events to the Oracle NoSQL database.
To disable the publishing of rated events to the Oracle NoSQL database:
Open the ECE_home/oceceserver/config/charging-cache-config.xml file.
For the RatedEventPublisher module, change the cache-store configuration entry by replacing the following:
<init-param>
<param-name>cache-store</param-name>
<param-value>oracle.communication.brm.charging.ratedevent.publisher.internal.coherence.RatedEventPublisher
</param-value>
with this:
<init-param>
<param-name>cache-store</param-name>
<param-value>oracle.communication.brm.charging.util.coherence.internal.NoPersistenceCacheStore
</param-value>
The publishing of rated events to the Oracle NoSQL database is disabled.
Save the file.
To verify that customer balances are being updated in Oracle Communications Billing and Revenue Management (BRM), you can call BRM balance opcodes.
With ECE and Rated Event Formatter running, event data record (EDR) files are created for the usage requests that ECE processes. When the BrmCdrPluginDirect Plug-in is configured, the EDR files are formatted in BRM call details record (CDR) format. To verify that they are created, check the directory to which you publish the CDRs; this is the input directory of the Rated Event (RE) Loader Batch Controller.
To verify that ECE external asynchronous notifications are being published to the JMS topic, you can use the following sample SDK notification programs:
sample_jms_client.sh
sample_jms_server.sh
Use these sample programs to check the correctness of the JMS topic.
You can also use the sample_jms_client.sh sample program to check the messages produced from the ECE side to the JMS topic.
Some types of testing may not require publishing ECE external notifications to the JMS topic.
To disable external notifications:
Open the ECE_home/oceceserver/config/charging-cache-config.xml file.
For the ServiceContext module, change the cache-store configuration entry by replacing the following:
<init-param>
<param-name>cache-store</param-name>
<param-value>oracle.communication.brm.charging.notification.internal.coherence.AsynchronousNotificationPublisher
</param-value>
with this:
<init-param>
<param-name>cache-store</param-name>
<param-value>oracle.communication.brm.charging.util.coherence.internal.NoPersistenceCacheStore
</param-value>
ECE external notifications are disabled.
Save the file.
Verifying an ECE integrated system involves verifying that ECE can process usage requests (rate events) using the ECE product and event definitions defined in the system's event definitions (request specification data published to ECE from Pricing Design Center (PDC)). To verify a custom implementation, you must create custom request specification files for all the products you offer your customers.
To verify an integrated system, you must set up only one product offering in PDC and one BRM customer account. After verifying the ECE integrated system, you must repeat certain tasks for all your product offerings to complete the integration.
You use the ECE simulator to send requests to ECE for processing. The simulator emulates network traffic coming from a network mediation system. You use the ECE query tool to verify that the usage has impacted the customer balance.
Note:
You can use Diameter Gateway or a third-party network mediation software program to send usage requests to ECE. This section describes how to use the simulator only.The simulator enables you to control the types of usage requests sent and the number and type of subscribers sending the usage requests. See the discussion about using the simulator in BRM Elastic Charging Engine Implementation Guide for more information about using the simulator.
To verify that usage requests can be processed, see the following topics:
To start all ECE charging server nodes in the cluster:
Log on to the driver machine.
Change directory to the ECE_home/oceceserver/bin directory.
Start the Elastic Charging Controller:
./ecc
Start the ECE nodes by running the following command:
start
To verify that the ECE nodes are running:
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 State Machine node
Expand StateManager.
Expand Attributes.
Verify that the stateName attribute is set to UsageProcessing.
This means the ECE nodes are running.
To run the simulator and send usage requests:
Start the ECE simulator:
start simulator
Initialize the simulator:
init simulator
Run the sample workload:
simulate simulator
The simulator will take a few seconds to complete processing the workload.
Open the invocation.log file located in ECE_home/oceceserver. You should see statistics for the sample workload.
To verify that the usage requests impacted customer's balances, use the ECE query tool.
Query for Customer Balances in the Customer Cache
Here are two examples of how to query the customer cache to return the customer balances:
$ ./query.sh Coherence Command Line Tool CohQl> "select value() from Balance where ownerId='cccc'"
$ ./query.sh Coherence Command Line Tool CohQl> "select value() from Balance where balanceId='xxxx'"
In the results of the query that are returned, locate the following string:
{currentBalance=UnitValue{quantity=amount, unit=Money{cur=USD}
where amount is the quantity amount of the balance impact.
To verify that friends and family calls are processed:
Ensure the appropriate provisioning tag is available in BRM by doing the following:
Ensure you define a provisioning tag that includes the Friends&Family extended rating attribute (ERA).
The BRM installation comes with a sample provisioning tag. For information about creating a friends and family provisioning tag in BRM, see the discussion of working with extended rating attributes in BRM Setting Up Pricing and Rating.
Ensure the provisioning tag in BRM contains the same profile specification labels provided in PDC.
The profile specification labels that come in the PDC installation are MYFRIENDS and MYFAMILY. Specify these labels in the provisioning tag when using the profile specification labels in PDC.
(Optional) If you create a new provisioning tag in BRM, rather than using the sample provisioning tag, run the SyncPDC utility to synchronize the provisioning tag name with PDC.
If not already loaded, load the sample profile attribute specification for friends and family into PDC.
The sample XML file is available at PDC_home/apps/Samples/Examples/OOB_ProfileSpecifications.xml, where PDC_home is the directory in which PDC is installed.
Use the PDC ImportExportPricing utility to load the XML file into the PDC database.
If not already loaded, load the sample custom analyzer rule for friends and family into PDC.
The sample XML file is available at PDC_home/apps/Samples/Examples/OOB_CRs.xml.
OOB_CRs.xml contains three custom rules: Friends&Family and ClosedUserGroup and SpecialDay. These custom rules are designed to be used specifically with generic selectors.
Use the PDC ImportExportPricing utility to load the XML file into the PDC database.
In PDC, configure the charge offer for friends and family calls by doing the following:
Create a generic selector with the Friends&Family custom analyzer rule.
Create the charge offer for the friends and family calling service.
For the charge offer, select the provisioning tag that specifies Friends&Family.
Create the charge for the charge offer.
For the charge, include the generic selector with the Friends&Family rule.
Tip:
You associate the friends and family rule in the generic selector with a result: a string value that maps to the rule, such as Friends&Family. At runtime, ECE uses this result in the charge to apply different rates for calls to friends and family.Verify that Pricing Updater is started.
Publish the PDC pricing data to the ECE rating engine.
Pricing Updater synchronizes the pricing data to ECE.
Verify that ECE External Manager (EM) Gateway is started.
In BRM, create the customer account, purchase the charge offer, and configure the friends and family phone numbers.
The BRM customer data updates are incorporated into the ECE cache in real time through EM Gateway. For more information, see the discussion about synchronizing BRM and ECE customer data in BRM Elastic Charging Engine Concepts.
Generate usage for a friends and family call for the customer.
Use the ECE SDK sample programs to generate usage.
Verify that balances are impacted as expected.
After you verify that friends and family calls are processed as expected using the friends and family sample data in PDC and BRM, create your own friends and family configurations.
To verify that closed user group calls are processed:
Ensure the appropriate provisioning tag is available in BRM by doing the following:
Ensure you define a provisioning tag that includes the ClosedUserGroup extended rating attribute (ERA).
The BRM installation comes with a sample provisioning tag. For information about creating a closed user group provisioning tag in BRM, see the discussion of working with extended rating attributes in BRM Setting Up Pricing and Rating.
Ensure the provisioning tag in BRM contains the same profile specification labels that are provided in PDC.
The profile specification label that comes in the PDC installation is CLOSEDUSERGROUP. Specify this label in the provisioning tag when using the profile specification labels in PDC.
(Optional) If you create a new provisioning tag in BRM, rather than using the sample provisioning tag, run the SyncPDC utility to synchronize the provisioning tag name to PDC.
If not already loaded, load the sample profile attribute specification for closed user group into PDC.
The sample XML file is available at the following:
For service-based closed user group samples:
PDC_home/apps/Samples/Examples/Sample_ServiceCUG_ProfileSpecification.xml
For customer-based closed user groups that work with sample data:
PDC_home/apps/Samples/Examples/OOB_ProfileSpecifications.xml
Use the PDC ImportExportPricing utility to load the XML file into the PDC database.
Tip:
Closed user group profiles are rating profiles (known as extended rating attributes in BRM) that have a closed-user-group affiliation. The closed-user-group affiliation is enabled by setting the useDynamicIdentifier field to true in the PDC profile attribute specification.If not already loaded, load the sample custom analyzer rule for closed user group into PDC.
The sample XML file is available at the following:
For service-based closed user group samples:
PDC_home/apps/Samples/Examples/Sample_ServiceCUG_CR.xml
For customer-based closed user groups that work with sample data:
PDC_home/apps/Samples/Examples/OOB_CRs.xml
OOB_CRs.xml contains three custom rules: Friends&Family and ClosedUserGroup and SpecialDay. These custom rules are designed to be used specifically with generic selectors.
Use the PDC ImportExportPricing utility to load the XML file into the PDC database.
In PDC, configure the charge offer for closed user group calls by doing the following:
Create a generic selector with the ClosedUserGroup custom analyzer rule.
Create the charge offer for the closed user group calling service.
For the charge offer, select the provisioning tag that specifies ClosedUserGroup.
Create the charge for the charge offer.
For the charge, include the generic selector with the ClosedUserGroup rule.
Tip:
You associate the closed user group rule in the generic selector with a result: a string value that maps to the rule, such as ClosedUserGroup. At runtime, ECE uses this result in the charge to apply different rates for calls to the closed user group.Verify that Pricing Updater is started.
Publish the PDC pricing data to the ECE rating engine.
Pricing Updater synchronizes the pricing data to ECE.
Verify that EM Gateway is started.
In BRM, for both the calling customer and the called customer, create the customer account, purchase the charge offer, and configure the required closed-user-group-profile information for the customer.
For example, if the closed user group profile is at the customer level, specify the closed user group phone number. If the closed user group profile is at the service level, specify the closed user group name.
The BRM customer data updates are incorporated into the ECE cache in real time through EM Gateway. For more information, see the discussion about synchronizing BRM and ECE customer data in BRM Elastic Charging Engine Concepts.
Generate usage for a closed user group call for the calling customer.
Use the ECE SDK sample programs to generate usage.
Verify that balances are impacted as expected.
Once you verify that closed user group calls are processed as expected using the closed user group sample data in PDC and BRM, create your own closed user group configurations.
To verify that balance impacts are assigned to bill items according to your business rules:
Important:
Before loading item type selectors into PDC, make a backup copy of the customized config_item_tags.xml and config_item_types.xml files in BRM.Ensure that a storable class for each bill item type is available in BRM.
If you are verifying that ECE can apply balance impacts to a custom bill item, ensure the custom storable class is available in BRM. For example, /item/custom.
If not already loaded, load the item type selector into PDC.
The item type selector contains item specifications and item type selector rules.
You associate item type selector rules with an item tag: a string value that maps to the item type. At runtime, ECE evaluates your item-type-selector rule. The result of the rule evaluation is a unique item type. ECE assigns balance impacts to the bill item associated to the item type.
Item-type-selector XML files are available at PDC_home/apps/Samples/Examples.
See PDC User's Guide for information about using the XML files.
See PDC User's Guide for instructions on setting item-specification attributes and creating item-type-selector-rule expressions.
Use the PDC ImportExportPricing utility to load the item-type-selector XML file into the PDC database.
Verify that Pricing Updater is started.
Verify that EM Gateway is started.
In BRM, create the customer account and purchase the charge offer for the service associated with the bill items for which you are verifying bill-item assignment.
The BRM customer data updates are incorporated into the ECE cache in real time through EM Gateway. For more information, see the discussion about synchronizing BRM and ECE customer data in BRM Elastic Charging Engine Concepts.
Generate usage for the customer that impacts the bill items for which you are verifying bill-item assignment.
Use the ECE SDK sample programs to generate usage.
Run billing.
Verify that balance impacts are assigned to bill items as expected.
To debug rating errors, you may need to verify that payloads in request specifications are correctly formed. You can view request specifications in the RequestSpecification cache by using the following CohQL command and piping the contents to a file:
select toSpecFormat() from RequestSpecification
The RequestSpecification cache contains read-only information.
If you identify an issue with a payload in a request specification, correct the issue in PDC as follows:
Export the event object.
Update the XML with the corrections.
Re-import the event object.
After the event object is re-imported, PDC re-publishes the event object, and Pricing Updater updates the request specification in ECE in the RequestSpecification cache accordingly.