2 BRM System Overview

Learn about the Oracle Communications Billing and Revenue Management (BRM) system architecture.

Topics in this document:

• About the BRM System Architecture

• How BRM Handles Data

About the BRM System Architecture

The BRM system architecture consists of:

• Client applications, such as Billing Care, Customer Center, Pricing Center, and PDC.

  Note:

  Pricing Center can only be used with Pipeline Manager. It cannot be used in a system with ECE.

• The BRM Server, which includes these components:

  • Connection Managers (CMs) which receive connections from client applications, and run the BRM business logic.

  • Data Managers (DMs) which handle connections to the BRM database, as well as optional databases such as a tax database.

  • The BRM database, which stores all of the BRM data.

• ECE, the BRM charging engine.

• Pipeline Manager, which rates and discounts events in batch and real-time. If you are using Pipeline Manager, see "About Pipeline Rating" in BRM Configuring Pipeline Rating and Discounting.

Figure 2-1 shows the components in a typical BRM system.

Figure 2-1 BRM System Components

Description of "Figure 2-1 BRM System Components"

In this figure:

• Billing Care and Customer Center are BRM clients. You use one of them to connect to BRM through the Connection Manager (CM). In a typical BRM installation, the CM handles many client connections. For example, running a billing utility from a command line connects to a CM to access the BRM system.

  In addition to providing client access to BRM, CMs run the business-logic software that performs BRM functionality. For example, the CM runs the software that creates accounts, changes passwords, and runs billing.

• The CM connects to the Oracle Data Manager (DM). The Oracle DM typically handles connections from multiple CMs. In addition to connecting the CM to the BRM database, it also translates the BRM system language into SQL commands that the database can understand.

  A typical BRM system includes additional Data Managers, each of which connects the BRM database to other clients and databases. For example, the Vertex Data manager connects BRM to Vertex, to perform tax calculations.

• PDC sends pricing data to the BRM database. PDC also sends pricing data to ECE. ECE uses the pricing data to rate usage.

  Note:

  PDC can also send pricing data to Pipeline Manager if your system is configured to do so. If you are using Pipeline Manager, see "About Pipeline Rating" in BRM Configuring Pipeline Rating and Discounting.

• When a subscriber makes a phone call, the call is processed by a mediation system:

  • Prepaid calls are handled by the ECE Diameter Gateway. Diameter Gateway runs as part of the ECE system.

  • The CDRs recorded from postpaid calls are handled by Offline Mediation Controller. Offline Mediation Controller is a client application of ECE.

• ECE rates the events and applies the charges to the customer balances that are stored in ECE. ECE also sends data about the rated events to BRM by using Rated Event Loader.

• Rated Event Loader sends the data about rated events to the BRM database, and update the customer's balance in the BRM database. This ensures that the balance is synchronized in ECE and the BRM database.

The following sections describe how these components are used by different business processes.

Creating an Account

Figure 2-2 shows the BRM components that are used for creating an account.

Figure 2-2 BRM Components Used for Creating an Account

Description of "Figure 2-2 BRM Components Used for Creating an Account"

To create an account:

1. A CSR creates an account in Billing Care or Customer Center.

2. Billing Care or Customer Center connects to the CM.

3. The CM runs the business-logic software that creates the account, configures bill units, associates the payment option, and so on.

4. The CM sends the customer data to the Oracle DM, which translates the data into SQL commands that can be read by the database.

5. When the account is created in the BRM database, two things happen:

   • A message is sent back to Billing Care or Customer Center to inform the CSR that the operation completed successfully.

   • The EAI Java Server, initiated by the CM, sends a message to ECE and adds the new account to the ECE data cache. ECE can now rate usage for the account.

Components Used for Setting Up Product Offerings

Figure 2-3 shows the components used for setting up product offerings.

Figure 2-3 Components Used for Pricing

Description of "Figure 2-3 Components Used for Pricing"

In this figure:

1. You create pricing components in PDC.

2. PDC sends updated pricing data to the BRM database and to ECE:

   • PDC loads pricing data into the BRM database through the CM and DM.

   • PDC uses the ECE Pricing Updater utility to load pricing data into the ECE data caches.

Note:

If you are using Pricing Center to create your pricing components, see Pricing Center Help.

Components Used for Usage Charging in ECE

Figure 2-4 shows the components used for usage charging.

Figure 2-4 Components Used for Usage Charging

Description of "Figure 2-4 Components Used for Usage Charging"

To charge for usage:

1. The customer makes a call, which is handled by one of the mediation controllers.

   • For a prepaid call, Diameter Gateway manages the call. It carries out authorization and re-authorization by obtaining balance information from ECE customer data.

   • For a post-paid call, Offline Mediation Controller receives a record of the call and prepares it for rating. ECE then rates the call.

2. After the call is rated, ECE uses Rated Event Loader to send a record of it to the BRM database and updates the customer's balance.

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.

How BRM Handles Data

If you configure BRM, you need to know how BRM handles data, so you can customize BRM functionality. There are two primary elements that manage BRM data:

• Opcodes, which run the operations that control all of the BRM data. For example, when Billing Care or Customer Center creates an account, it uses the PCM_OP_CUST_CREATE_CUSTOMER opcode to create an account.

• Objects, which store the BRM data. For example, when BRM creates an account, the customer's name and contact information is stored in the BRM database in an /account object.

Opcodes are packaged in Facilities Modules (FMs), which are libraries run by CMs. When a BRM client connects to a CM, it can use any of the FMs that are being run by the CM.

Each FM has a function (for example, the billing FM runs billing, and the customer FM creates accounts and passwords). Each opcode in an FM carries out a specific function. For example the customer FM includes the following opcodes:

• PCM_OP_CUST_POL_VALID_NAMEINFO, which validates the data provided for a customer's name

• PCM_OP_CUST_POL_VALID_PASSWD, which validates a password

• PCM_OP_CUST_SET_NAMEINFO, which updates the customer name

• PCM_OP_CUST_SET_PASSWD, which updates a password

In these examples, two types of opcodes are shown, standard opcodes and policy opcodes. The policy opcodes include POL in their name. Policy opcodes are customizable, but standard opcodes are not. In this example, policy opcodes are used for customizing how to validate customer name information and passwords. For example, you can specify that passwords contain certain required characters.

Opcodes handle data in BRM by using a mechanism called an flist. An flist is a list of data that the opcode needs to carry out its function. For example, to read an object, the opcode needs to pass an flist containing the account POID. However, the Oracle database cannot read the flist format, so the CM sends the flists to the DM to translate into SQL.

Objects are containers for the BRM data. Each object holds the data for a specific BRM entity; for example, there are /account objects, /bill objects, /service objects, and so on.

Each object has a set of fields, and each field holds a piece of data, or an array of data. For example, the /account object includes these fields:

• PIN_FLD_CURRENCY holds the currency that the account uses.

• PIN_FLD_NAME holds the custom names and contact information

• PIN_FLD_STATUS holds the status of the account, such as Active or Inactive.

Objects stored in the database are created from storable classes. A storable class is a template that is used for each object in the database. For example, when an account is created, BRM uses the /account storable class to create a new /account object.

You can customize the data that BRM can store by customizing storable classes. For example, if you want to store custom data in a BRM account, you can customize the /account storable class by adding a field. All /account objects would then be created with your custom field.

To manage data, each object has a unique ID, known as a Portal Object ID, or POID. POIDs allow objects to link to each other. For example, the /account object includes the PIN_FLD_BAL_GRP_OBJ field. This field contains the POID of the /balance_group object that stores the customer's account balance.