1. ECE Implementing Charging
  2. Customizing ECE
  3. Testing ECE

24 Testing ECE

You learn how to test your implementation of Oracle Communications Elastic Charging Engine (ECE).

Topics in this document:

About ECE Testing Utilities

ECE offers the testing utilities in Table 24-1 that you can use when implementing ECE in a charging system.

Table 24-1 ECE Testing Utilities

Utility Description

Simulator

Emulates the role of a client application sending requests to ECE. The simulator enables you to send usage requests, query requests, update requests, or policy requests to ECE for processing. You can run sample workloads for testing latency and throughput of your system.

See "Running the Simulator to Send Usage Requests".

query

Enables you to run queries on ECE data for development or debugging purposes.

See "Using the query Utility to Test ECE".

Note: The ECE data model within the Coherence cache is subject to change. Oracle does not recommend that client applications directly use the Coherence API or the query utility for accessing ECE cache data. For querying ECE cache data, write your client applications to use the ECE APIs such as the balance query and authentication query APIs.

customerGenerator

Creates XML files that represent sample customer data, which can then be loaded into ECE.

Note: The ECE customer XML data file must conform to the format of the ECE customer XML schema file (ECE_home/odi_transformation/ECE_Schema.xsd).

customerLoader

Loads customer data from BRM incrementally, in batches or in bulk. In addition to using this utility in a development system, you can use it in a production system to correct data migration errors. To do so, run the utility with the -incremental parameter. Caution! Do not run the customerLoader utility without the -incremental parameter in a production environment.
PerformanceMonitor MBean

Monitors the performance of your ECE deployment during testing. See "About Performance MBean".

About Loading Sample Data

After installing ECE, you can load sample data. Sample data is in the ECE_home/sample_data directory which includes:

  • Sample data for integrating with BRM

  • Sample data for integrating with PDC

  • Sample data for integrating with clients that send policy requests (used for policy testing)

Sample data includes sample event definitions, sample configuration data, sample product offering cross-reference data, and sample customer data. Subsets of sample data geared for ECE implementations for policy-related charging is also available.

To use sample data, you configure your data-loading utilities to load data from sample data directories.

About Performance MBean

You can use the PerformanceMonitor MBean to monitor the performance of your ECE deployment. You can monitor the CPU usage of server nodes and client nodes, such as the simulator, during your testing.

For example, when building charging extensions, you can run ECE without your extensions and use the methods to see how much CPU time is used. You can then run ECE with your extensions, and use the methods again to see how much CPU time is used. By comparing the CPU times, you can derive the additional time spent by your extension.

The following PerformanceMonitor MBean methods are available:

  • startTrackingCPU()

    The startTrackingCPU() method starts tracking CPU usage for the running process.

  • stopTrackingCPU()

    Use the stopTrackingCPU() method to stop tracking CPU usage for the running process. This method returns CPU utilization between 0 and 1 where 0 means 0% CPU usage and 1 means 100% CPU usage.

  • getTrackedCPU()

    Use the getTrackedCPU() method to get the last tracked CPU usage between [0, 1] if a previously tracked CPU usage is available. If a previously tracked CPU usage is not available, -1 is returned.

The simulator MBean exposes the throughput information through the getLastThroughput() method. The getLastThroughput() method gets the throughput number from the last successfully completed simulation run. If completed simulation runs do not exist or if a simulation run is in-progress, -1 is returned.

Changing Time and Date to Test ECE

You can change ECE's current time and date, without affecting the operating system time and date, to test time-sensitive functions associated with Rated Event Formatter and Diameter Gateway in ECE.

Note:

Changing the time and date introduces the possibility of corrupting data. Do not change the time and date in a production database.

For example, you can change ECE's current time and date to test the following:

  • Whether accounts are billed correctly. If you advance the date in BRM to the next billing cycle to test if the accounts are billed correctly, you must advance the date in ECE to the same date as set in BRM. This ensures that the events rated by ECE on that day are sent to BRM with the same date as set in BRM so that the events can be billed for the next billing cycle.

  • Whether customer's spending limit is reported correctly. If a charge offer includes a conditional balance impact and the conditional balance impact is valid only for a day, you can advance the date by a day to ensure that when the Spending-Limit-Report-Request (SLR/SLA) request is received, the spending limit for the next day is reported.

  • Whether events are rerated correctly. You can advance the date in ECE to store rated events in the Oracle NoSQL database data store with the future date to ensure that they are rerated when rerating is run in BRM for the future date.

To change the time and date to test ECE:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE configuration node.

  3. Expand charging.server.

  4. Expand Attributes.

  5. Specify the values for the following attributes:

    • virtualTimeMode. Enter one of the following values:

      • 0. Use this to reset the time to ECE's current time. Time is changed to the operating system time.

      • 1. Use this to set the time as a constant time. Time is frozen at the specified time until this value or the time you set is changed.

      • 2. Use this to set the time to change every second. Time is changed to the time specified, and then advances one second every second.

    • virtualTime. Enter the time and date in the following format: YYYY-MM-DDTHH:mm:ss.SSS. For example, to set the time and date to 11:30:02:600 on September 03, 2016, enter 2016-09-03T11:30:02.600.

After you change the time and date, perform testing as needed. You can also change the time and date between testing stages. After completing testing, reset the time to ECE's current time and perform database cleanup if needed.

Using the query Utility to Test ECE

The query utility provides access to ECE cache content, enabling you to run queries on ECE Coherence caches. The query utility is meant to be used for debugging purposes only.

You can use the query utility to write scripts that interact with the ECE domain objects, creating CohQL queries. The query utility supports all ECE caches and objects.

Note:

Oracle recommends that you not query the cache for the entire list of customer information. Filtered/ selected query is recommended because the complete customer list would cause ECE to crash.

The query utility is included with the ECE Server software in ECE_home/bin.

To learn about query utility options, use the help command: 

$ ./query.sh -h

The following shows non-interactive use of the query utility: 

$ ./query.sh -s -c -l "select sum(getAvailableBalance(\'USD\',null).getQuantity()) from Balance"

The following shows interactive use of the query utility: 

$ ./query.sh
Coherence Command Line Tool
CohQl> select count () from Customer;
Results
1000
CohQL> select key(), value().getCode().toString() from BalanceElement
Results
840, "USD"

The query utility log file is ECE_home/logs/query_out.log.

The query statement history is contained in ECE_home/bin/.cohql-history. You can use the up and down arrows to move through the command history.

Note:

Oracle does not recommend that client applications directly use the Coherence API or the query utility for accessing ECE cache data. For querying ECE cache data, write your client applications to use the ECE APIs such as the balance query and authentication query APIs.

Example: Query the Subscriber Base Balance Summary

Here is an example of how to summarize balance amounts across the entire subscriber base (total balance) in the grid:

$ ./query.sh -s -c -l "select sum(getAvailableBalance(\'USD\',null).getQuantity()) from Balance"

Example: Query a Customer Balance

Following is an example of how to query a customer's balance. You first query a specific customer to find the balance ID, and then you query a specific balance to find the balance element and balance amount.

Tip:

You can use the same model for querying a customer's active session object.

Step 1: Query the customer to find the balance ID

To query the customer and find the balance ID:

$ ./query.sh
Coherence Command Line Tool
CohQl> select key(), value() from Customer where key() = "Cust#6500000001"
Results
"Cust#6500000001", 
 ####################################### Customer Begin ############################################
CustomerImpl
{ customerId='Cust#6500000001
, inTransaction='null
, defaultBalanceId='Bal#6500000001
, externalReference='1
, version=0
, profiles={Birthday=[RatingProfileValueImpl{name=NUMBER, value=2013-08-21,
 validFrom=1970-01-01T00:00:00.000Z, validTo='292278994-08-17T07:12:55.807Z}]}
, subscriberPreferences={}
, subscribedPreferences=null
, AlterationSharingAgreements ={}
, DistributionSharingAgreements ={}
, productMap={Pro#6500000001=ProductImpl{
...
, balanceId = 'Bal#6500000001'
,         profiles = {FriendsAndFamily=[RatingProfileValueImpl{name=NUMBER,
 value=6501234567, validFrom=1970-01-01T00:00:00.000Z,
 validTo='292278994-08-17T07:12:55.807Z}]}
,         subscriberPreferences = {}
,         subscribedSpendingLimitCounters = {}
,         Life cycle state = 102
,         Life cycle Expiration time = 0
,         activeSessions = {}
,         debitRefundSessions = {}
,         audited purchased charge offerings = {}
,         audited purchased alteration offerings = {}
,         audited profiles={}
,         audited UsedAlterationSharingAgreements={}
,         audited UsedDistributionSharingAgreements={}
         balance=null
}}
, balances={}
,
 billingUnits={BillingUnit#6500000001=[BillingUnitImpl
{billingUnitId=BillingUnit#6500000001},
{accountingCycle=[Triple{first=2013-08-21T11:10:16.224-07:00},
{second=2013-09-21T11:10:16.224-07:00},{third=2013-10-21T11:10:16.224-07:00},]},
{billingCycle=[Triple{first=2013-08-21T11:10:16.224-07:00},
{second=2013-09-21T11:10:16.224-07:00},{third=2013-10-21T11:10:16.224-07:00},]},
{billingFrequency=1},]}
, auditedProducts={}
, auditedProfiles={}
, audited AlterationSharingAgreements={}
, audited DistributionSharingAgreements={}
, customerRerateProcessingInfo=CustomerRerateProcessingInfoImpl
{ RerateProcessingStatus='NOT_IN_RERATING, ReratingJobId='null}
 #####################Customer End #########################################

Step 2: Query the balance to find the balance element

To query the balance to find the balance element, you specify two components of the associated key (composite key) that links the customer to the balance.

$ ./query.sh
Coherence Command Line Tool
CohQl> select value() from Balance where key().getId() = "Bal#6500000001" and
 key().getAssociatedKey() = "Cust#6500000001"
Results
[BalanceImpl{BalanceId=Bal#6500000001}
{externalRevision=0}{OwnerId=1}
{BillingUnitId=BillingUnit#6500000001}
{BillingUnit=null}ActiveReservationMap{}}
balanceItemSpecs{{USD=BalanceItemSpecImpl{beCode='USD', unit=Money{cur=USD}
, creditProfile=oracle.communication.brm.charging.config.creditprofile.internal.
CreditProfileReference@1dc79d4
, consumptionRule=EARLIEST_START}}}
balanceItems{([BalanceItemImpl{balanceItemId=0}{currentBalance=-10000}
{balanceItemSpec=BalanceItemSpecImpl{beCode='USD', unit=Money{cur=USD}
, creditProfile=oracle.communication.brm.charging.config.creditprofile.internal.
CreditProfileReference@1dc79d4
, consumptionRule=EARLIEST_START}{validity=null}{validityRule=null}]),]

Verifying that Usage Requests Can Be Processed

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 utility to verify that the usage has impacted the customer balance.

Note:

If you installed online or offline network mediation software, you can use that software instead of the ECE simulator to send usage requests for online or offline charging. 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.

To verify that usage requests can be processed, perform the steps described in these sections:

Starting ECE Nodes in the Cluster

To start all ECE nodes in the cluster:

  1. Log on to the driver machine.

  2. Go to the ECE_home/bin directory:

  3. Start the Elastic Charging Controller:

    ./ecc

  4. Start the ECE nodes:

    start

To verify that the ECE nodes are running:

  1. Access the ECE configuration MBeans in a JMX editor, such as JConsole. See "Accessing ECE Configuration MBeans".

  2. Expand the ECE Configuration node.

  3. Expand ECE State Machine.

  4. Expand StateManager.

  5. Expand Attributes.

  6. Verify that the stateName attribute is set to UsageProcessing.

    This means the ECE nodes are running.

Running the Simulator to Send Usage Requests

To run the simulator and send usage requests:

  1. Start the ECE simulator:

    start simulator

  2. Initialize the simulator:

    init simulator

  3. Run the sample workload:

    simulate simulator

    The simulator takes a few seconds to finish processing the workload.

  4. Open the invocation.log file located in ECE_home/logs. You should see statistics for the sample workload.

Verifying that Balances Are Impacted in ECE

To verify that the usage requests impacted customer's balances, use the ECE query utility.

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 returned, locate the following string:

{currentBalance=UnitValue{quantity=amount, unit=Money{cur=USD}

where amount is the quantity amount of the balance impact.

Verifying That ECE Notifications Are Published to the JMS Topic

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.

Disabling the Publishing of ECE Notifications to the JMS Topic

Some types of testing may not require publishing ECE external notifications to the JMS topic.

To disable external notifications:

  1. Open the ECE_home/config/charging-cache-config.xml file.

  2. 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.

  3. Save the file.

Verifying that Friends and Family Calls Are Processed

To verify that your ECE deployment is processing friends and family calls, perform prerequisite tasks in BRM and PDC and then generate usage for the friends and family call for the customer.

To verify that friends and family calls are processed:

  1. Ensure the appropriate provisioning tag is available in BRM as follows:

    1. Ensure you define a provisioning tag that includes the Friends&Family extended rating attribute (ERA).

    2. Ensure the provisioning tag in BRM contains the same profile specification labels provided in PDC.

      The profile specification labels that come ready-to-use in the PDC installation are MYFRIENDS and MYFAMILY. Specify these labels in the provisioning tag when using the ready-to-use profile specification labels in PDC.

    3. (Optional) If you create a new provisioning tag in BRM, rather than using the ready-to-use sample provisioning tag, run the SyncPDC utility to synchronize the provisioning tag name to PDC.

  2. 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/PDCSampleProfileSpec.xml where PDC_home is the directory in which you installed PDC.

    Use the PDC ImportExportPricing utility to load the XML file into the PDC database.

  3. 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/PDCSampleCAR.xml.

    PDCSampleCAR.xml contains two custom rules: Friends&Family 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.

  4. In PDC, configure the charge offer for friends and family calls as follows:

    1. Create a generic selector with the Friends&Family custom analyzer rule.

    2. Create the charge offer for the friends and family calling service.

    3. For the charge offer, select the provisioning tag that specifies Friends&Family.

    4. Create the charge for the charge offer.

    5. 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 run time, ECE uses this result in the charge to apply different rates for calls to friends and family.

  5. Verify that the ECE Pricing Updater is started.

  6. Publish the PDC pricing data to ECE.

    The Pricing Updater synchronizes the pricing data to ECE.

  7. Verify that EM Gateway is started.

  8. 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.

  9. Generate usage for a friends and family call for the customer.

    Use the ECE SDK sample programs to generate usage.

  10. Verify that balances are impacted as expected.

After you verify that friends and family calls are processed as expected using the ready-to-use friends and family sample data in PDC and BRM, create your own friends and family configurations.

Verifying That Closed User Group Calls Are Processed

To verify that closed user group calls are processed:

  1. Ensure the appropriate provisioning tag is available in BRM by doing the following:

    1. Ensure you define a provisioning tag that includes the ClosedUserGroup extended rating attribute (ERA).

    2. 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.

    3. (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.

  2. 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.

  3. 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.

  4. In PDC, configure the charge offer for closed user group calls by doing the following:

    1. Create a generic selector with the ClosedUserGroup custom analyzer rule.

    2. Create the charge offer for the closed user group calling service.

    3. For the charge offer, select the provisioning tag that specifies ClosedUserGroup.

    4. Create the charge for the charge offer.

    5. 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.

  5. Verify that Pricing Updater is started.

  6. Publish the PDC pricing data to the ECE rating engine.

    Pricing Updater synchronizes the pricing data to ECE.

  7. Verify that EM Gateway is started.

  8. 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.

  9. Generate usage for a closed user group call for the calling customer.

    Use the ECE SDK sample programs to generate usage.

  10. 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.

Verifying That Balance Impacts Are Assigned to Bill Items

To verify that balance impacts are assigned to bill items according to your business rules:

Note:

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.

  1. 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.

  2. 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.

    Use the PDC ImportExportPricing utility to load the item-type-selector XML file into the PDC database.

  3. Verify that Pricing Updater is started.

  4. Verify that EM Gateway is started.

  5. 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.

  6. 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.

  7. Run billing.

  8. Verify that balance impacts are assigned to bill items as expected.

Verifying That Payloads Are Correctly Formed

To debug rating errors, you may need to verify that payloads in usage requests are correctly formed. You can view payloads 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, correct the issue in PDC as follows:

  1. Export the event object.

  2. Update the XML with the corrections.

  3. Re-import the event object.

    After the event object is re-imported, PDC re-publishes the event object, and Pricing Updater updates the event definition in ECE in the RequestSpecification cache accordingly.