1. ECE Implementing Charging
  2. Using the ECE Java API
  3. Configuring Balance Queries

6 Configuring Balance Queries

You can configure third-party clients to query Oracle Communications Elastic Charging Engine (ECE) for balance information.

Topics in this document:

Integrating Balance Query Clients

You can write client applications to query data in ECE, such as query the login and password information of a customer, or query the customer's account balance.

ECE returns the balance element ID of each balance in the ECE balance query response. ECE returns the balance element ID of balances for SUMMARY, DETAILED, ALL, and TURBO balance query modes. Client applications could use this information, for example, when customer balances are stored in multiple subscriber profile repositories and it is required to map the balances between the repositories.

To use the query APIs:

  • For the ECE authentication and query API: oracle.communication.brm.charging.messages.query

  • For the ECE PriceEnquiry of the charging API: oracle.communication.brm.charging.brs and oracle.communication.brm.charging.messages

For information about running sample programs that demonstrate how to use the ECE query APIs, see "ECE Sample Programs".

About Sending Authentication Queries

Use the authentication API to query the login and password of subscribers.

Use the login and password information for:

  • Implementing authentication methods outside of the ECE charging server

  • Enabling subscribers to validate their login and password credentials against a charge offer to which they are subscribed

About Sending Balance Queries

Use the Balance API to query balances for one or more subscribers.

Use the subscriber balance for:

  • Making policy decisions

  • Sending the balance information to subscribers so they can monitor their network-usage expenses, validate their credit limit, or monitor their active reservation

ECE returns the balance element numeric ID of each balance in the ECE balance query response. Client applications could use this information, for example, when customer balances are stored in multiple subscriber profile repositories and it is required to map the balances between the repositories.

Configuring Debit Request History

For a debit request, ECE returns a correlation ID in the usage response and stores the correlation ID in a debit map for each charge offer. If a refund request is later received for the debit request, ECE uses the correlation ID to validate the refund request (refund requests are valid only when they are associated with a debit request correlation ID).

The debit request information in the debit map is transient data and you can configure the number of debit requests to be retained per charge offer. By default, debit request information is stored for ten debit request operations (for each charge offer) at any given time. For example, if the debit map contains ten entries and a new debit request is received, the entry for the oldest debit request is deleted from the debit map, and an entry for the new debit request is added.

To configure the debit request history:

  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. Set the debitRefundSessionEvictionSize attribute to the maximum number of debit requests to log in the debit map at one time.

    This is the number of debit requests to keep in history so that refunds can be made against them.

About Balance Query Requests

When building a balance query request, you have the option to use the following balance query modes to restrict the contents of the balance query response that ECE returns:

  • SUMMARY: The balance query response contains the balance element ID and the total balance at the balance element level.

  • DETAILED: The balance query response contains the balance element ID and the detailed balance for each balance element. This includes balance element specification information (such as credit limits), grantor information (such as grantor ID and grantor type), reservation information (such as the active and consumed reservation), and rollover balance information (such as the rollover balance and the number of times the balance has been rolled over).

  • ALL: The balance query mode specifies to return all the sub-balances after a particular timestamp. It is in the EM Gateway response.

  • TURBO: The balance query mode specifies to return information about the balance element level, the current principal balance, and the loan balance. It is in the Diameter Gateway response.

The balance query response mode you use may impact the overall performance of your system.

For details about the balance API, see the documentation for oracle.communication.brm.charging.messages.query in Elastic Charging Engine Java API Reference.