This chapter explains concepts critical for implementing Oracle Communications Billing and Revenue Management Elastic Charging Engine (ECE).
Before reading this chapter, you should be familiar with ECE concepts and architecture. See BRM Elastic Charging Engine Concepts for information about how ECE works as a rating and balance management application.
To implement ECE in a charging system, you configure integration points to other applications in the charging system so that ECE can send data to and receive data from those applications. For information about configuring integration points for an Oracle Communications Billing and Revenue Management (BRM) charging system, see "About Integration Points".
For ECE to rate events, the definition of those events must be stored in ECE. You define each of your events by creating or editing an event specification in BRM. You then export the event specification to Oracle Communications Pricing Design Center (PDC), where information required for network mediation processing, pricing, charging, and billing is added. The event specification in PDC is then published through Pricing Updater to ECE, where it is stored in the ECE event cache. See "Integrating ECE with PDC" for information about how event specifications are enriched in PDC for ECE.
You can configure various business rules for charging and runtime behavior of the ECE system. To implement business rules and charging-related configurations in ECE, see "Implementing Charging Configurations".
ECE APIs align with standards in the charging industry to facilitate integrating ECE with client programs and network charging functions. For information about integrating ECE with client programs, see "Integrating ECE with Client Programs".
For information about testing an ECE implementation, see "Testing an ECE Implementation".
After installing ECE, you need to integrate it with your charging system. A first-time implementation of ECE in a BRM charging system requires that you perform tasks in a particular order.
ECE implementation tasks include the following:
Defining your events in BRM and PDC and storing those definitions in ECE so ECE can rate the events
You define each of your events by creating or editing an event storable class definition in BRM. You then export the definition as an event specification to PDC, where information required for processing usage requests is added. The event specification in PDC is then published through Pricing Updater to ECE, where it is stored in the ECE event cache.
Defining and loading your pricing so that events can be rated
A pricing analyst typically defines pricing for events when pricing and services are set up in BRM. Pricing often determines which events you define in BRM. You define pricing by creating pricing components in PDC. You use those pricing components to create product offerings. You then load this pricing data into ECE. See "About Loading Data from PDC".
Configuring integration points so that ECE can connect to other applications in the charging system
For example, you configure integration points for connecting to and communicating with BRM so that ECE can send rated events to BRM. You also configure integration points for connecting to PDC so that ECE can receive pricing data from PDC. See "About Integration Points".
Loading required data into ECE caches so that ECE has the data required for charge processing
You must load your mediation specification (if you use Diameter Gateway for network integration for online charging), your pricing data, and your customer data. See "About Loading Data from BRM" and "About Loading Data from PDC".
Configuring notifications so that ECE charging servers can send data to client applications such as network mediation software programs
Configuring usage-charging preferences so that ECE charging servers apply the charging business logic required for your business
When implementing ECE in a charging system, you have already defined the attributes from your network requests that are associated with each event you will charge for. You define event attributes by creating or editing an event storable class definition in BRM. You then export the event storable class definition as an event specification to PDC, where information ECE requires for processing usage requests is added. The event specification in PDC is then published through Pricing Updater to ECE, where it is stored in the ECE cache.
ECE must contain definitions of the events for which you charge your customers so that it can rate the events when processing usage requests. ECE stores request specification data objects, which contain the definition of the events defined in BRM and PDC.
Client applications, such as network mediation software programs, create usage requests and submit them to ECE for charging. The network mediation software program maps the usage attributes relevant to charging from the network request to the usage attributes in the ECE usage request.
ECE usage requests contain fixed attributes that apply for all of the events in ECE, such as the attribute that represents the public user identity of the person or entity using the product. Fixed attributes are mandatory in all usage requests. ECE usage requests also contain configurable attributes that represent the usage of the customer.
When you introduce products or extend ways of charging customers for your products, you extend usage requests by adding the products, events, or attributes required for the new type of charging. See the discussion about enriching event definitions in PDC User's Guide.
For information about building usage requests (useful if you use third-party network mediation software), see "Integrating Charging Clients with ECE".
Request specification data objects must be deployed into the ECE runtime environment before charging applications can send usage requests to ECE. See "Integrating Charging Clients with ECE".
For an ECE standalone system, you can use sample request specification files in the ECE_home/oceceserver/sample_data/config_data/specifications directory to load request specification data objects into the ECE cluster.
This section describes integration points ECE uses for communicating with software products in a BRM charging system.
ECE uses the following integration points for PDC, which are set up in the PDC system.
Java Message Service (JMS) queue
Pricing Updater listens on the JMS queue to which PDC publishes pricing data; it dequeues pricing data for loading into ECE.
See "Integrating ECE with PDC" for instructions on integrating ECE with PDC.
ECE uses the following integration points for BRM, which are set up in the BRM system:
Connection Manager (CM)
BRM Gateway connects to the CM to make BRM opcode calls.
The CM calls opcodes implemented in an external manager (EM). External Manager (EM) Gateway receives requests from the CM at a predefined port. EM Gateway is used, for example, for ECE to receive charging requests from BRM during rerating operations.
Rated Event (RE) Loader
The BrmCdrPlugDirect Plug-in creates RE Loader files (rated event files). RE Loader loads rated events from the files into the BRM database.
Account Synchronization Data Manager (DM) Oracle Advanced Queuing (Oracle AQ) database queue
When events occur that update rerating, account migration, discount, and product data in the BRM database, the updates are published asynchronously (not in real time) to ECE through Customer Updater. To do so, the updates are sent in business events to the Account Synchronization DM, which publishes the business events to an Oracle AQ database queue. Customer Updater retrieves the business events from the queue and updates the ECE cache accordingly.
For information about synchronizing customer data updates, see the discussion about synchronizing BRM and ECE customer data in BRM Elastic Charging Engine Concepts.
Suspense queue (Oracle AQ database queue)
The suspense queue stores failed update requests that BRM tried to send to ECE until they can be reprocessed.
For information about processing failed update requests from BRM, see the discussion on troubleshooting ECE in BRM Elastic Charging Engine System Administrator's Guide.
For information about configuring the suspense queue, see "Configuring the Suspense Queue".
ECE Acknowledgment Queue (Oracle AQ database queue)
BRM uses the Acknowledgment Queue for sending messages that the rerating process is set to start or has completed. ECE uses the Acknowledgment Queue for sending data to BRM about the state of processing rerating jobs.
See "Integrating ECE with BRM" for instructions on integrating ECE with BRM.
ECE uses the following integration points for network mediation software for online charging. Network mediation software would leverage these open interfaces to integrate with ECE.
Note:
This information is relevant to those integrating a third party network mediation system with ECE for online charging.If you use Diameter Gateway for receiving Diameter messages and translating them into ECE requests, Diameter Gateway is prebuilt to use these interfaces for constructing all of the requests that ECE supports.
Elastic Charging Client
Elastic Charging Server accepts usage requests and policy requests submitted from the Elastic Charging Client.
ECE request specification data
Request builders use the request specification data (generated automatically and deployed to ECE from PDC) for building usage requests in the correct format.
ECE charging API
The network mediation software uses the ECE charging API to populate the payload blocks of usage requests.
ECE policy API
The network mediation software uses the ECE policy API to build and submit policy requests.
See "Integrating Charging Clients with ECE" and "Integrating Policy Clients with ECE" for related information.
ECE uses the following integration points for Oracle Communications Offline Mediation Controller, which are set up on the Offline Mediation Controller system:
Elastic Charging Client
Elastic Charging Server accepts charging requests submitted from the Elastic Charging Client.
ECE request specification data
Request builders use the request specification data deployed in ECE for building requests in the correct format.
ECE charging API
Offline Mediation Controller uses the ECE charging API to populate the payload blocks of usage requests.
See "Integrating ECE with Offline Mediation Controller" for instructions on integrating ECE with Offline Mediation Controller.
See "Integrating Charging Clients with ECE" for related information.
Implementation tools that help you configure and test an ECE implementation include the following:
Java Management Extensions (JMX) editor
A JMX editor enables you to edit ECE MBeans made accessible by the ECE configuration service. You use a JMX editor to configure most ECE nodes. After ECE is running, your edits to configuration parameters impact the running system.
Simulator
The simulator emulates the role of a client application, such as a network mediation software program, sending requests to ECE.
loader utility
The loader utility, used with the simulator, loads sample data into ECE caches required for processing requests and loads sample request specification files used to validate requests sent by the simulator.
Customer File Generator
Customer File Generator generates customer files according to provided specifications; it allows you to create customer data without having to create it in BRM.
Sample programs
Sample programs demonstrate how to use the ECE API for sending requests to ECE.
Query tool
The query tool enables you to execute queries on ECE Coherence caches for development or debugging purposes.
Data-loading utilities enable you to prime ECE caches with required data and reload data as needed in testing environments.
configLoader utility
pricingLoader utility (used only when PDC is not used)
customerLoader utility (used only when BRM is not used)
Each time you start an ECE charging server node with JMX management enabled, the ECE configuration service makes ECE configuration parameters accessible by exposing them as MBeans.
When you are logged on to the JMX-management-enabled charging server node using the valid host name and JMX port (the default port is 9999), the JMX MBean editor displays the ECE MBeans. You can expand the MBeans navigation tree to view and modify the ECE configuration parameters associated with them.
The ECE system components obtain configuration settings from an application-configuration replicated cache in the ECE charging nodes. When you modify an ECE configuration parameter in the JMX MBean editor, the ECE configuration service validates the modified value in its source XML file, updates that file, and updates the parameter in the application-configuration replicated cache, thus making the new values available to all nodes in the ECE charging system.
This section describes the data that ECE needs from BRM for processing usage requests.
Customer data is information about customers, such as customer account details, account status, and product details.
When you install ECE, its caches are empty, and you must load customer data from BRM into ECE. To do so, you use Customer Updater, which extracts the customer data and product cross-reference data that ECE requires from the BRM database and loads it into the ECE caches. See "Loading Data from BRM into ECE" for more information.
You load only the customer data relevant for processing usage requests. For example, you load the customer data that ECE uses to charge for network events, such as what product the customer has purchased.
After the initial load of data, Customer Updater automatically extracts all new or modified customer data from BRM and loads it into ECE. See "About Customer Updater" for more information.
The initial load of customer data into ECE includes customer offer profiles and systemwide credit profiles, which are created and managed in BRM.
Credit profiles define the credit limits, credit floors, and credit threshold combinations that can be associated with balance elements. When you create systemwide credit profiles in BRM, you must include the default systemwide credit profiles for currency and noncurrency that ECE will use. See "Defining Systemwide Credit Profiles" for more information.
Configuration data also includes the following:
Request specification data used to define events. The pricingUpdater utility loads this data into ECE (see "About Pricing Data").
Mediation specification data required by Diameter Gateway. The configLoader utility loads mediation specification data into ECE (see "configLoader").
The initial load of BRM customer data into ECE includes product cross-reference data.
Product cross-reference data is stored in ECE and enables ECE to map the BRM product offering identifier to the product offering migrated from PDC. The product offering is loaded into ECE from PDC. ECE maps the product offering to a BRM charge offer, discount offer, or chargeshare offer with the BRM Portal object ID (POID) in the offering. The product cross-reference data is initially loaded into ECE by Customer Updater. Subsequent new or modified offerings are updated in ECE through EM Gateway (see the discussion about synchronizing BRM and ECE customer data in BRM Elastic Charging Engine Concepts).
Customer Updater does the following:
Performs the initial extraction of customer data, credit profiles, offer profiles, configuration objects, and pricing cross-reference data from BRM and loads the data into ECE.
Handles asynchronous updates from BRM to ECE of the following data: rerating, account migration, discount, and product.
The rerating, account migration, discount, and product data stored in ECE must stay current with the corresponding data in the BRM database.
When events occur that update that data in the BRM database, the updates can be published asynchronously (not in real time) to ECE through Customer Updater. To do so, the updates are sent in business events to Account Synchronization DM, which publishes the business events to an Oracle AQ database queue. Customer Updater retrieves the business events from the queue and updates the ECE cache accordingly.
When you install ECE, configure Customer Updater to dequeue update requests sent from BRM. For example, you provide the name of the Oracle Advanced Queuing (AQ) database queue to which BRM publishes business events. To change the information you provide during installation, see "Configuring Customer Updater".
If ECE cannot process update requests from BRM, ECE puts the update requests in the suspense queue to process later. See "Configuring the Suspense Queue".
Customer Updater extracts and loads all customer data into ECE by default. However, you can configure Customer Updater to load only preselected customer data. To do so, prepopulate the Customer Updater distribution tables with customers whose data you want to load. You specify filter criteria that determines which customers to include; for example, you can filter based on whether customers are in a closed or preprovisioned state. Customer Updater extracts and loads only data for the selected customers. See "Creating Prepopulated Distribution Tables".
This section describes the data that ECE requires from PDC for processing usage requests.
After you install ECE, the pricing cache contains no data. You must load the pricing data relevant to processing usage requests into ECE.
You define your pricing data (when you create your product offerings) in PDC. See "Creating Pricing Data for the ECE Runtime Environment".
Pricing Updater loads the pricing data into ECE. See "About Pricing Updater".
Important:
The pricingLoader utility is an ECE utility that loads sample pricing data into the ECE pricing cache from XML files.Do not run pricingLoader and Pricing Updater on the same ECE deployment.
Use pricingLoader only on a standalone system when PDC is not used.
For information about loading pricing data, see "Loading Pricing Data into ECE".
Pricing Updater reads pricing updates from the JMS queue, where PDC publishes pricing data, and loads it into ECE.
Whenever you create or modify pricing data in PDC and publish it, Pricing Updater automatically loads the pricing data updates into ECE. After you install ECE, you start Pricing Updater. As long as it is running, it loads pricing data updates from PDC.
For information about configuring Pricing Updater, see "Configuring the Pricing Updater".
After installing an ECE standalone system, you can load sample data. Sample data is in the ECE_home/oceceserver/sample_data directory, which includes the following:
Sample customer data
Sample pricing data
Sample data for integrating with clients that send policy requests (used for policy testing)
Sample data includes sample ECE request specification files, 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. See "Using Data-Loading Utilities" for more information.