8 BRM System Architecture
Learn about the Oracle Communications Billing and Revenue Management (BRM) system components.
Topics in this document:
About the Four-Tier Architecture
The BRM system uses a four-tier architecture consisting of the following tiers:
Figure 8-1 shows the BRM system architecture:
Figure 8-2 shows how the BRM components process a login name when a user starts a BRM client application.
Application Tier
The application tier consists of the following types of client applications:
-
BRM client applications used to create accounts and manage customers and their accounts, such as Billing Care or Customer Center
-
Third-party customer account management applications used by customer service representatives (CSRs), such as applications that capture data from customer service usage
-
BRM service integration applications such as Global System for Mobile Communications (GSM) Manager and General Packet Radio Service (GPRS) Manager
-
Network connection clients; such as Offline Mediation Controller
-
Custom applications that you write to manage customers or support custom services and integrate your applications with BRM
Business Process Tier
The business process tier is responsible for running BRM functionality, such as the following:
-
Online and offline charging, discounting, and promotions
-
Customer and subscription management
-
Real-time balance and credit management
-
Billing
-
Service usage authorization
-
Payments and A/R management
The business process tier consists of the following components:
-
Connection Managers (CMs): CMs provide an interface between clients and the rest of the system. All client applications connect to the BRM system through a CM.
-
Facilities Modules (FMs): CMs run FMs that process the data captured by the client. For example, when a user logs in, FMs process the login name and password. See "About Facilities Modules (FMs)".
-
External Modules (EMs): EMs serve similar functions to FMs but must be started separately as a service or process. See "About External Modules (EMs)".
-
Elastic Charging Engine (ECE): ECE performs online charging and offline charging. During online charging, ECE performs real-time authorization and balance management.
If you are using Pipeline Manager for rating and discounting events in batch and real-time, see "About Pipeline Rating" in BRM Configuring Pipeline Rating and Discounting.
CMs run as daemons. When a client application requests a connection, the parent CM process spawns a child process to handle the connection. At that point, the application no longer communicates with the parent CM; all communication flows from the application to the child CM as depicted in Figure 8-3.
About Facilities Modules (FMs)
When an application connects to a CM, the data sent by the application is processed first by the FMs that are included in the CM.
There are separate FMs to handle different types of tasks. For example, if a CSR changes a customer's password, the Customer FM validates that the new password has the correct number of characters.
FMs manage BRM activity and ensure that data is processed correctly. When you configure a CM, you specify the FMs that are linked to the CM. Typically, you use the default set of required FMs for each CM. Figure 8-4 depicts a CM configured with several FMs.
Each FM is dynamically linked to a CM when the CM starts. You can link optional or custom FMs to any CM.
Because FMs are linked to CMs, the FMs can get configuration information from the CM configuration files. Therefore, one of the ways you can customize BRM policies is by editing the CM configuration file.
You can customize policy FMs or add custom FMs to a CM. See BRM Developer's Guide.
About External Modules (EMs)
An External Module (EM) is similar to an FM; it is a set of opcodes that perform BRM functions. However, it is not linked to a CM in the same way that an FM is. Instead, it runs as a separate process that you must start and stop.
The Payload Generator is an EM that processes events that are exported to external systems by using the optional Enterprise Application Integration (EAI) framework.
Figure 8-5 shows where an EM fits in the system architecture:
Figure 8-5 External Module in BRM System Architecture
Description of "Figure 8-5 External Module in BRM System Architecture"
About Connection Manager Master Processes (CMMPs)
Instead of configuring an application to connect directly to a CM, you can configure it to connect to a Connection Manager Master Process (CMMP).
When an application connects to a CMMP, the CMMP selects a CM from a list you provide and gives the application the machine name and port of that CM. The application then uses that address to connect to the CM.
Figure 8-6 shows how an application connects to a CM using a CMMP:
Figure 8-6 Using a CMMP to Connect to a CM
Description of "Figure 8-6 Using a CMMP to Connect to a CM"
For more information, see the information about improving performance in BRM System Administrator's Guide.
Data Management Tier
The data management tier consists of Data Managers (DMs), which translate requests from CMs into a language that the database can understand. For the BRM database, the language is SQL. There are also DMs for credit card processors, Vertex, and so forth. See "About Data Managers (DMs)".
About Data Managers (DMs)
Data Managers (DMs) translate BRM operations into a form that can be understood by the data access system.
BRM includes the following DMs:
-
The Oracle DM (dm_oracle) provides an interface to an Oracle BRM database.
-
The Paymentech DM (dm_fusa) provides an interface to the Paymentech credit-card payment processor.
-
The Vertex DM (dm_vertex) provides an interface to the Vertex Sales Tax Q Series and Communications Tax Q Series database.
Child processes are not spawned when a DM receives a connection request. Instead, child processes are spawned when a DM starts. You define the number of child processes in the DM configuration file.
When a DM receives a connection from a CM, the parent process or thread assigns a child process or thread to the connection. At that point, the client no longer communicates with the parent DM, and all communication flows from the CM to the child DM.
DMs run as a set of processes. Each process handles a single database transaction.
About Data Manager (DM) Back Ends
Each DM has a set of front-end processes that receive connection requests and send them to a shared-memory queue for processing by back-end processes. The back-end processes translate the transaction into the database language.
DM back ends are single-threaded. Therefore, a back end is dedicated to a single transaction for the duration of the transaction.
From the BRM database perspective, the back ends communicate to database back-end (shadow) processes. One database back-end process is started for each DM back end. See your database documentation for information on shadow processes.
You can write a new DM back end to integrate BRM with any relational, object-oriented, or legacy database management system. You can also layer BRM on top of basic file managers. For more information, see the documentation about writing a custom Data Manager in BRM Developer's Guide.
Data Tier
The data tier consists of the BRM database and other data access systems, such as the Paymentech credit-card processing service.
About the BRM Database
The BRM database stores all of your business information and data, such as information about customer accounts, your product offerings, and the services you provide. All information stored in the BRM database is contained in objects.
An object is equivalent to a database record or a set of database records. Each type of object contains a set of related information. For example, an account object includes the customer's name and address.
Related database objects are linked to each other. For example, an account object is linked to the payment information object that stores a customer's credit card number.
To see examples of objects, use Object Browser.
Note:
The term object does not refer to an object request broker (ORB) or to the object programming environment. Instead, object refers to the BRM object data model. For more information about the object model, see BRM Developer's Guide.
About the Residency Type
RESIDENCY_TYPE is an attribute of an object that defines where the object resides in a BRM system. Residency type values are predefined in the data dictionary in the BRM database.
Table 8-1 lists the BRM residency types:
Table 8-1 Residency Type Descriptions
| RESIDENCY_TYPE Value | Object Type | Description |
|---|---|---|
| 0 | Database object | Resides in the BRM database. |
| 9 | Global database view object | Resides in the data dictionary. Use with database views to perform distinct searches on multiple storable classes using pagination and ordering. See "Performing Distinct Searches with Ordering and Pagination" in BRM Developer's Guide. |
| 101 | Routing database object | A /uniqueness object that resides in the primary schema of the BRM database. |
If you create a custom object, you must set its residency type to the correct value.
About the Multischema Architecture
In multischema systems, the database layer of your BRM system consists of one primary schema and one or more secondary schemas in a single database. A primary DM is connected to the primary schema and secondary DMs are connected to the secondary schemas. Data is separated between the schemas as follows:
-
The primary database schema stores two types of global objects: objects that the secondary DMs can only read, such as configuration and pricing objects, and objects that the secondary DMs can both read and update, such as uniqueness objects. The primary schema also stores subscriber data.
-
The secondary database schemas store subscriber data, such as event and account objects.
The primary DM updates global read-only objects in the primary schema, and the secondary DMs read the data from views in the secondary schema on tables from the primary schema.
The secondary DMs use schema qualifications to read and modify updatable global objects stored in the primary schema.
For information about how to set up a multischema system, see "Managing a Multischema System" in BRM System Administrator's Guide.
About Multidatabase Manager
Multidatabase Manager is an optional feature that enables you to have multiple BRM database schemas in a single installation. This option can support very large installations (more than a few million subscribers). It enables you to split the main database into multiple schemas.
Configuring the Four-Tier Architecture
All BRM processes can run on the same computer, or they can be distributed among different computers. Distributed processing provides a lot of flexibility in configuring your system, especially if you have multiple machines running CMs and DMs. For example, you can do the following:
-
Run redundant system processes (for example, Billing Care, billing applications, CMs, and DMs).
-
Connect clients to specific CMs, or use a CMMP to route to any available CM.
For more information, see BRM Installation Guide.
Communication between System Components
Communication between applications and CMs, and CMs and DMs, is accomplished by TCP/IP. You assign each component an IP port and host name. TCP/IP facilitates the use of firewalls, proxies, and filters.
Any kind of network connection that supports TCP/IP supports BRM (for example, local area network, virtual private network, and PPP).
Communication between DMs and data access systems uses the protocol required by the data access system. For example:
-
DM-to-Oracle communication is carried out using Oracle SQL*Net, a product that lets distributed computers access a central Oracle database.
-
DM-to-Paymentech communication uses the Paymentech protocol.
For information about the configuration file entries that enable communication between BRM components, see the documentation about configuration files in BRM System Administrator's Guide.
Four-Tier Architecture and Failure Recovery
The four-tier architecture provides high reliability in the event of system component failures:
-
If the BRM database is offline, any interrupted transactions are rolled back when the database is restarted. The DM automatically attempts to connect to the database until a connection is made.
-
If a DM is offline, any interrupted transactions are timed out and rolled back by the database. The CM automatically attempts to connect to the DM until a connection is made. You can provide each CM with a list of DMs. If a DM is unavailable, the CM can connect to a different one.
If a DM fails while there are transactions in its queue, the transactions must be resubmitted. The contents of the queue are lost when the DM fails.
-
If a CM is offline, the database rolls back any interrupted transactions. You can use a CMMP to provide multiple CMs for clients to connect to. See "About Connection Manager Master Processes (CMMPs)".
-
If a client fails, any interrupted transaction is timed out and rolled back by the database.
In all cases, errors are reported to the client application. Depending on its capabilities, the client can display an error, log the error, or retry the transaction.
-
In all cases, broken transactions are rolled back by the database, so no partial transactions are recorded.
ECE System Architecture
ECE can be seen as a separate sub-system with the overall BRM system. ECE includes its own components, and connects to most of the other BRM components, including PDC and the BRM server.
The Elastic Charging Server runs all of the charging, balance query, and policy control functions. The Elastic Charging Server runs on Oracle Coherence, which distributes processing across multiple processing nodes, ensuring high availability and scalability (giving the server elastic properties). ECE nodes perform multiple functions; for example, charging nodes run the charging logic, and cache nodes store the customer data and product offering data required for charging.
The ECE system architecture can be divided generally into these functional areas:
-
Communicating with the network elements that ECE receives events from.
-
Communicating with other BRM components (BRM server and PDC) to synchronize customer data and product offerings.
-
Sending rated events to the BRM database.
Figure 8-7 shows the ECE system architecture:
A dotted line depicts the data flow for storing rated events using Oracle NoSQL Database (only if data persistence is disabled).
To communicate with the network elements, ECE uses these components:
-
Elastic Charging Clients provide the interface between network elements and the ECE server. For example, Offline Mediation Controller uses an Elastic Charging Client to send offline rating usage requests to the Elastic Charging Server.
-
Diameter Gateway and RADIUS Gateway provide integrations to Diameter and RADIUS clients. In both cases, the gateways handle requests and responses between the network elements and ECE. Both gateways use an Elastic Charging Client to manage communication with the Elastic Charging Server.
-
Diameter Gateway handles usage requests and usage responses.
-
RADIUS gateway manages authentication and accounting requests.
Diameter Gateway reads from the ECE notification queue (JMS topic) and processes push notifications from Elastic Charging Server. From the ECE push notifications (ECE re-authorization request (RAR) notifications, ECE spending limit notifications, and ECE subscriber preferences notifications), Diameter Gateway constructs Sy and Gy messages and sends them back to Diameter clients (for example, for answering back to push-notification-request (PNR), subscribe-notification-request (SNR), and RAR notifications).
-
-
Diameter Gateway also communicates with PCRF policy clients. When integrating PCRF policy clients with ECE, ECE acts as the Subscriber Profile Repository (SPR) because it stores the customer profile information used by the PCRF. ECE offers a combined Sp and Sy interface which the PCRF uses to retrieve customer preferences and policy counter information.
-
Top-up clients use the ECE API to communicate directly with the Elastic Charging Server.
Figure 8-8 shows the communication that occurs between the network elements and the Elastic Charging Server.
Figure 8-8 Communication Between ECE and the Network
To integrate with the BRM server and PDC, ECE uses the following components:
-
Pricing Updater listens on a JMS queue and receives updates to product offerings from PDC. It then loads the updated product offering data into an ECE cache whenever you change product offering data in PDC.
Caution:
When configuring a development system, you can use the pricingLoader utility to load sample product offerings. However, do not use pricingLoader utility on a production system, or on a test system that includes Pricing Updater.
-
Customer Updater receives customer data from the BRM server. Customer Updater does the following:
-
Performs the initial loading of customer data, credit limit data, offer profiles, product offering cross-reference data, and configuration objects, from BRM and loads the data into ECE.
Product offering cross-reference data is stored in ECE and enables ECE to map the pricing components stored in the BRM database to the pricing components stored in ECE. ECE maps pricing components by using the pricing component POIDs. The product offering cross-reference data is initially loaded into ECE by Customer Updater. Subsequent new or modified pricing components are loaded into or updated in ECE through EM Gateway.
-
Handles asynchronous updates from BRM to ECE of the following data: rerating, account migration, discount, and product.
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 Oracle 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.
-
-
The EM Gateway receives customer data from the BRM server in real time. The EM Gateway does the following:
-
Loads customer data from the BRM server into an ECE cache in real time.
-
The BRM rerating utility uses the EM Gateway to send rerating requests from BRM to ECE during the rerating process.
-
Custom BRM applications can use the EM Gateway to send balance query requests to ECE.
Customer Updater and the EM Gateway both receive updates to customer data from BRM server and load it into the ECE customer data cache. However, they load data differently.
The EM Gateway loads customer data in real time. When an event occurs that changes customer data in the BRM database:
-
A transaction is opened to update the BRM database.
-
Before the transaction can be completed, the BRM server sends the updated data to ECE by using the EM Gateway.
-
ECE updates the data and returns a message to the BRM server.
-
The transaction is completed in the BRM database. If ECE is not able to update the data, the transaction is rolled back.
This process ensures that the data is synchronized in ECE and in the BRM database.
-
-
The BRM Gateway sends information to the BRM server when processes must be triggered in the BRM server, or data must be updated in the BRM database. For example, if auto-triggered billing is enabled, ECE uses the BRM Gateway to trigger billing in the BRM server.
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.
If data persistence is enabled in ECE, all the data received from BRM and PDC are persisted in an Oracle database by default. When you restart the components, the data in this database are reloaded into the ECE cache.
Figure 8-9 shows the communication that occurs between the Elastic Charging Server, BRM server, and PDC:
A dotted line depicts the flow for sending rated events to BRM using Oracle NoSQL Database.
Figure 8-9 Communication Between Elastic Charging Server, BRM Server, and PDC
The components that send rated events to the BRM database are Rated Event Publisher, Rated Event Formatter, and Rated Event Loader. These components load rated events from the Elastic Charging Server into the BRM database.
If data persistence is enabled, ECE stores the rated events into an Oracle database. Rated Event Formatter extracts the rated events from the Oracle database and formats the event data into a format that can be loaded into the BRM database. Rated Event Loader loads the events into the BRM database.
If data persistence is disabled, Rated Event Publisher publishes rated events from the Elastic Charging Server to an Oracle NoSQL database. Rated Event Formatter extracts the rated events from the Oracle NoSQL database and formats the event data. Rated Event Loader loads the events into the BRM database.
The Oracle NoSQL database deletes duplicate rated events. For example, when an ECE charging server node fails after having sent rated events to the NoSQL database, the node will resend the rated events to the NoSQL database upon startup. Oracle NoSQL Database overrides the existing data to prevent duplicate data entries.
To configure and manage the ECE system, you perform two basic types of tasks:
-
Connect the ECE server with external clients and systems, such as Offline Mediation Controller, the BRM Gateway, and the EM Gateway. These connections are managed by JMS queues, and are configured during the ECE installation. You can change them after installation to tune performance.
-
Manage the running ECE system. To manage ECE, you configure a driver machine. The driver machine stores the configuration files that define the ECE system. You log in to the driver machine to run ECC.
Managing the ECE system includes managing nodes, such as adding charging server nodes that perform rating and store data. Running the ECE software and storing data on multiple nodes provides high availability for usage charging.
PDC System Architecture
The PDC application architecture consists of the following components:
-
PDC UI. The PDC UI is a Web-based user interface that you use to create and manage your product offerings.
-
PDC database. The PDC database stores the pricing components and setup components that you configure in PDC, as well as the pricing data defined in Oracle Communications Billing and Revenue Management (BRM) and rating systems that are synchronized with PDC.
-
BRM Integration Pack. The BRM Integration Pack provides the interface between PDC and BRM.
-
ImportExportPricing utility. The ImportExportPricing utility provides an XML-based command-line interface for importing pricing and setup components to and exporting pricing and setup components from PDC.
Figure 8-10 shows the PDC application architecture and the process flow when used with BRM:
Figure 8-10 PDC and BRM Integration Architecture
Description of "Figure 8-10 PDC and BRM Integration Architecture"
About the PDC and BRM Integration Process Flow
The BRM Integration Pack provides the interface between PDC and BRM to transform and load the pricing data configured in PDC into BRM and to synchronize the pricing data defined in BRM and the rating system with PDC.
The BRM Integration Pack contains:
-
Transformation engines: The transformation engines convert pricing components and setup components configured in PDC into the format required by BRM and then loads the components into the BRM database.
-
SyncPDC utility: The SyncPDC utility provides the capability to synchronize setup components defined in BRM with PDC. It also synchronizes event data defined in the rating system with PDC.
BRM uses the pricing and other data to measure customer activity and determine how much to charge the customer for the use of the services. See BRM documentation for information on how the rating is performed.