The following modules are included in this release:

• Balance Management
• Balance Monitoring
• Billing
• Convergent Subscriber Management
• Financial Management
• Order Inventory Framework
• In-memory data management capabilities that integrate Oracle Communications Billing and Revenue Management with Oracle In-Memory Database Cache
• Invoicing
• Partner Relationship Management
• Pricing Configuration
• Real-time Rating
• Reporting
• Subscriber & Hierarchy Management
• Subscriber Groups Management
• Self-Care Manager

Some of the new features are as follows:

• Enhanced Invoice Document
• Enhancements to Oracle In-Memory DB (IMDB, formerly TimesTen)
• JCA Enhanced Transaction Management
- JCA Multiple OBRM Accounts in One Transaction
• Limits to Shared Memory Size for “Big” Shared Memory Structures
• Support for Rebilling and Corrective Invoices

The following BRM components are no longer supported in OBRM 7.5:

• AAA Gateway Manager, replaced by Oracle Mediation Controller
• RADIUS Manager, replaced by Oracle Mediation Controller
• TIMOS Manager, replaced by Oracle IMDB

Tridens, an Oracle Gold Partner, offers consulting services, such as initial OBRM implementations, proof of concept, enhancements, upgrading, etc. To read more about our Oracle BRM services please click here.

Recently, we’ve been involved in a project where the customer wanted a “safe” integration without the need of being real-time; a near real-time solution would suffice, they said. What we mean by safe integration is having a solution that will not affect any action performed, such as purchasing a product or bill creation, by a failing communication link (or any other error) between Oracle BRM and third-party software. When implementing a custom dm connector for data integration, any unsuccessfully completed operation will rollback the entire action. While this can be a desired behavior, in this case it wasn’t; therefore, we decided to go with Oracle Advanced Queuing. We’ve identified that our worst case scenario here would be database issues, but there would also be numerous other problems as well; to begin with, the BRM system would not function properly.
Other advantages we’ve identified were data persistency (events are stored in the database until the consumer application is ready to process queued messages) and an already proven Oracle AQ technology.

We’ve successfully deployed these changes to Oracle BRM version 7.3 and 7.3.1 with Oracle Database 10g (10.2.0.1.0 64bit) and 11g (11.2.0.1.0 64bit) with the Oracle Advanced Queuing (AQ) component.

The process of publishing Oracle BRM business events using Oracle Advanced Queuing works can be seen on the figure below:

Picture 1: The data synchronization process using Oracle Advanced Queuing.

To develop such a synchronization process, it is necessary to take some preliminary steps. These include:
1. EAI Manager Installation.
o EAI Connection Manager (CM) module (includes op-codes required by EAI),
o EAI Data Manager,
o Payload Generator External Module (EM) – also called EAI Java Server or eai_js.
2. After completing the EAI Manager installation, configure values in the CM and EAI DM configuration files (pin.conf), as well as the Payload Generator properties file (Infranet.properties).
3. Configure the event notification list you wish to publish by editing the configuration files for event notification ($BRM_HOME/sys/data/config/pin_notify* files) and merge them before running the load_pin_notify utility.
4. Define business events in the Payload Generator EM configuration file (payloadconfig.xml).

After the preliminary steps have been completed, it’s time to create and configure the Oracle Advanced Queue. Here are the steps (the third step may vary, as it depends on your setup):
1. Create queue:
pin_ifw_sync_oracle.pl create -l $USER/$PASS@$DB -q TEST_QUEUE -t TEST_QUEUE
2. Test queue (optional step):
pin_ifw_sync_oracle.pl test -l $USER/$PASS@$DB -q TEST_QUEUE
3. Log in to your database as SYSTEM user and set appropriate grant privileges for your ‘t_user’:
exec dbms_aqadm.grant_queue_privilege(‘ALL’, ‘PUSER.TEST_QUEUE’, ‘t_user’);
grant execute on puser.pin_event_ty to t_user;
grant execute on sys.dbms_aqin to t_user;

Next, we need a queue producer, an application which is going to enqueue the business events defined earlier. Developing a producer module is similar to building your custom connector application (see here.) It is necessary to implement a custom module (library) and define it in the dm_eai configuration file under the “plugin_name” entry.
There’s also a simpler way to go about this task. If you’ve already installed “Account Synchronization DM,” then you will find an implementation of a queue producer module under dm_ifw_sync data manager. However, if you choose this option, some additional entries are required in the dm_eai configuration file.

After you have a working queue producer. go ahead and invoke some of your business events to see if they get queued. Queues can be queried in the table defined on queue creation.

Finally, you will need a queue consumer, an application that will read and dequeue your queued messages. There are several programmatic interfaces available for accessing Oracle Streams AQ in the following programming languages: Java (JMS), PL/SQL, C (OCI), Visual Basic (OO4O), AQ XML Servlet (IDAP).
With your custom client implementation, you will have full control at how fast, when, and how many messages are going to be processed. For instance, during off-peak hours, you can process more data than during peak hours.

Hopefully, we’ve given you some valid pointers on how to go about the process of integration/synchronization between Oracle BRM and third-party systems and/or applications.

In conventional batch rating, all event data are read from CDR/EDR files after events are already finished. Event data are processed, rated, and charged.

Picture 1: Conventional batch rating

Picture 2: Real-time rating

When planning a realtime system, it needs to be designed in a way that minimizes the posibility of interrupting services or incurring any revenue losses. To minimize those, latency, high availability architecture, cm/dm separation per service for easier production maintainance, and efficient monitoring all have to be taken into consideration.

Picture 3: Monitoring of real-time traffic with Enterprise Service Manager.

With realtime rating, prepaid and postpaid users can be accommodated in one system – such a system is called convergent billing. Realtime billing offers even more benefits, such as postpaid credit limits, and realtime feedback after customer usage.

Picture 4: Postpaid accounts can get credit limits - 32 Mbytes transferred in EU countries, 32 Mbytes transferred outside EU, 30 EUR prepaid account top-ups - and a threshold for notifications can be set.

Picture 5: Realtime feedback after customer usage on Android application, WAP portal, and USSD.

In one of the next articles, more details will be presented regarding AAA GW, interaction workflow for calls (mbi,) and gprs/mms/sms (diameter.) Follow us on Twitter, and stay tuned.

Lessons Learned Over 4 Years of Realtime Convergence with Oracle BRM

Tusmobil, the third largest mobile operator in Slovenia, has used Oracle BRM 7.3 since 2007 for realtime convergent charging of voice, video telephony, SMS, MMS, GPRS, and other VAS services for both prepaid and postpaid users. Lessons learned during the design, development, and four years of operations will be presented, including how we’ve dealt with performance and system optimizations. To achieve flexibility, we’ve used agile software development, a type of software engineering based on an iterative and incremental process, coupled with release management. The end result gives Tusmobil a major competitive edge by enhancing customer experience, generating new revenue, improving productivity, curtailing time to market, and cutting costs.

Oracle BRM 7.3 database

In the database, account/customer related data such as names, addresses, profiles, current account balances, group charge sharing, and account hierarchy are stored. Deals can be purchased by the customer and associated with every account. Each customer can purchase more services. To know more, please examine the text underneath.

ACCOUNT_T
Stores information about the customer, including contact names, address, status, and customer segment information.

ACTIVE_SESSION_T
Stores data about an ongoing session.

BAL_GRP_T
Stores the balance information such as dollars, free minutes, bytes, and frequent flyer miles for various resources in an account . A balance group includes one or more sub-balances for each resource. The sub-balance contains the current amount, resource type, validity dates for the resource, rollover data, and sub-balance contributors.

BILL_T
Stores billing information, such as the amount due, amount adjusted, currency, and bill number. A /bill object is created at the beginning of a billing cycle.

BILLINFO_T
Stores all billing, payment method, accounting cycle, and hierarchy information necessary to bill an account. A /billinfo object is created for every account. If the billinfo is subordinate, the /billinfo object points to the parent account and the parent account’s /billinfo object.

CONFIG_T
Base table for configuration objects. Subclasses hold specific configuration information for various features, for example, /config/beid defines currency and non-currency resources.

DEAL_T
Stores information about a deal.When you use Pricing Center and connect to the database, all /deal objects in the database are shown in Pricing Center.

DEVICE_T
Stores information about devices. There is a separate /device object for every device managed by BRM. Generic data applicable to all devices is stored in the parent /device object. Subclasses such as /device/num store information specific to a particular device type.

EVENT_T
Abstract class to record system-initiated and user-initiated events. Event objects are related to a specific service or to an account. An event includes generic information such as start and end times as well the balance impacts that are incurred by the account due to this event. The /event object points to the account balance group that is impacted.

EVENT_BAL_IMPACTS_T
Stores event data.

INVOICE_T
Stores a customer invoice and information about the invoice, such as the bill it is associated with. Each /bill object can have a corresponding /invoice object.

ITEM_T
Created to bundle events, this table summarizes billable item activity by type. Rows in this table are added for each row in the BILL_T table.

PAYINFO_T
Stores generic payment method information for an account.

PRODUCT_T
Stores the information for a single product.

PROFILE_T
Abstract class to support custom account information. To use a /profile object, always create a subclass. You can link an account to any number of /profile objects.

PURCHASED_DISCOUNT_T
Contains an entry for each discount owned by an account at the time of conversion.

PURCHASED_PRODUCT_T
Contains an entry for each product owned by an account at the time of conversion.

RESERVATION_T
Tracks resources reserved for multi-service prepaid systems. Stores information about the account, balance group, and the service for which the resource reservation is created, the resource amount, and the expiration time for when the reserved resource expires.

SERVICE_T
Stores generic service type information for accounts. There is one row in this table for each applicable service for each entry in ACCOUNT_T. In addition to a row in this table, a row must be created in the service type table, such as IP service or email.

As mentioned in the previous article, Oracle BRM is capable of publishing events in the database, through http requests or in some other way, by implementing custom connectors. After some investigation and prototyping, we decided that an http requests approach would be the most suitable in our case. We dismissed a database approach because of the very frequent requests to the DB (it was requested that some specific notification events be provided to third party systems in a matter of seconds.) So, we used the ESB functionality of JBoss and exposed the http interface through an http_gateway.
This configuration allows us to handle a huge number of notification events without any performance dropdowns on the Oracle BRM side. All notification events are stored in a queue through the http_gateway and then handled appropriately using a rule engine. With defining rules in the rule engine, events are properly categorized and sent to specified services for further processing and further third party notifying.

One quite complex task was configuring rules for proper event handling. Our approach was to uniquely create messages according to event types, system ids, and other specific parameters. In this way, we were able to define priorities and specific routes for the messages. Also, we had to use several channels for sending notification events to third party systems. As is the case in many other companies, this mobile operator utilizes some legacy systems which do not have interfaces used in most modern systems. Notification events for those legacy systems are routed to special services, which communicate with them in specified way. For other systems, (SMS Gateway, CRM, ERP, WEB and WAP portal…) we used standard communication methods, such as web services and http interfaces.

In the current configuration, we are able to handle several hundred events per second from Oracle BRM to JBoss middleware. However, because all unwanted events have already been removed by the Oracle BRM Payload Generator EM, up to now there have been no such high loads on the production systems. On the other hand, we have noticed performance issues when communicating with some of the third party systems. For example, ERP is very problematic during the processing of payments, and, during this time, there should be no interference from other systems. So, for handling such bottlenecks, we are also using queues for outbound messages. All messages for those systems are put in a queue and sent out at an appropriate rate (in some cases, only one message every 5 seconds).

Such a design allows us to add new notification events or to extend notification event service to another third party system with a very limited number of changes and without affecting currently running services. In most cases, it requires only changes in the configuration files. For example, sending an additional notification event would require a change in the Oracle BRM payloadconfig.xml file and adding a rule for routing this new message in the JBoss Rule engine.

With the successful implementation of this solution in a production environment, we have proved that the integration of Oracle BRM with third party systems is very efficient and reliable, using Oracle BRM EAI on the billing side and Red Hat JBoss Enterprise SOA Platform with ESB on the middleware side.

1. A change occurs, which generates an event object.
2. Data is generated in the Connection Manager and sent to the Data Manager.
3. The Data Manager publishes the payload object.

The figure below illustrates an outlined EAI framework manager architecture and data flow:

To get the ball rolling, the EAI Manager first needs to be installed. This includes three EAI features:

• EAI Connection Manager (CM) module (includes the opcodes required by EAI)
• EAI Data Manager
• Payload Generator External Module (EM) – also called EAI Java Server or eai_js

Once the EAI framework manager has been installed, it’s time for the configuration step. The installation program assigns default values in the CM and EAI DM configuration (pin.conf) files, as well as the Payload Generator properties (Infranet.properties) file.

Next, make sure that:

1. the dm_pointer in the CM pin.conf points to the same port as the dm_port configured in the EAI DM pin.conf;
2. the em_pointer in the CM pin.conf points to the same port as the infranet.server.portNr in the eai_js Infranet.properties;
3. the startup and shutdown scripts are changed appropriately for the new processes to start/stop accordingly.

In addition to this basic configuration, the event notification feature, which calls the opcode (name: PCM_OP_PUBLISH_GEN_PAYLOAD; number: 1301) that caches the Oracle BRM event in the Payload Generator, will need to be configured. To enable event notification, run the load_pin_notify utility to load the configuration file containing the event notification list into the Oracle BRM database. Before running the utility, however, the configuration files for event notification in the $BRM_HOME/sys/data/config/pin_notify_eai file must first be merged. Optionally, add, modify, or delete entries in the final event notification list.

Should there be custom fields in the notification events, ensure they are included in the eai_js Infranet.properties and that the compiled custom java classes are in the classpath when starting eai_js. Otherwise, the result will be opcode numbers in the FLISTs instead of opcode names.

The last configuration task is defining Oracle BRM business events. A business event is an operation so defined in the Payload Generator EM configuration file (payloadconfig.xml). For example, one such business event is ProductPurchase, which is created when a customer buys a product. The configuration file can be edited to do the following:

• Add events to be published;
• Remove unwanted events from the list
• Specify whether the events are to be published in XML or FLIST format.

After configuring everything, it’s time to provide access to BRM event data for enterprise applications by building a module connector application that handles transaction management and transformation schemes specific to your environment. The directory $BRM_HOME/sys/dm_eai already contains sample implementations of the EAI functions in flist and XML format. Optionally, the EAI Manager can be used to publish information from the Oracle BRM database to an HTTP port for use by a third-party application such as CRM (customer relationship manager). To publish to an HTTP port, use the dm_http module.

Once a working connector application is in place, the successful integration of Oracle BRM with a third-party application is complete.

1. Compiles the total amount of balance impacts that have occurred in the past month. This can include usage fees and subscription fees.
2. Changes the status of all the bill items associated with the bill from pending to open so that they stop accumulating charges, and payments can be applied to them. In addition, a payment due date is added to the bill.
3. Automatically requests payments from a credit card processor or requests payments by sending invoices.
4. Automatically updates a customer’s account balance when a payment is recorded in the BRM database.

Picture 1: Oracle BRM billing process

So, how is all this done in practice?

Before running a billing on production, it is necessary that all the prerequisite steps be executed. The first step is to prepare a copy of the production environment – this can either be a preproduction or some testing environment. This step includes the installation of the latest production release onto this environment and the copying of the production database. Next, the environment configurations have to reflect those of production. Here are the main configurations, which should be set appropriately:

• cm configuration ($HOME/pin/sys/cm/pin.conf),

o Verify loglevel entry is set to 1

o Change the entry for agent_return parameter to 0

o Change the entry for simulate_agent parameter to 1

These two last changes are done so as not to involve any provisioning action during the bill-run.

• dm_oracle configuration ($HOME/pin/sys/dm_oracle/pin.conf),

o Set dm_bigsize parameter to 8388608 or higher

o Set dm_shmsize parameter to 33554432 or higher

o Set dm_n_fe to 8

o Set dm_max_per_fe to 16

o Set dm_n_be to 24

o Set dm_trans_be_max to 22

• pin_bill_accts configuration ($HOME/pin/apps/pin_billd/pin.conf),

o Verify loglevel. Change it to the appropriate value depending on what needs to be checked during the bill test, either 1 or 3.

o Change children parameter for pin_billd and pin_mta to 5

o Change per_batch parameter for pin_billd and pin_mta to 20000

o Change fetch_size parameter for pin_billd and pin_mta to 150000

• pin_inv_accts configuration ($HOME/pin/apps/pin_inv/pin.conf),

o Verify loglevel. Change it to the appropriate value depending on what needs to be checked during the bill test, either 1 or 3.

o Change children parameter for pin_billd and pin_mta to 5

o Change per_batch parameter for pin_billd and pin_mta to 2000

o Change fetch_size parameter for pin_billd and pin_mta to 15000

To get the best possible simulation of production, the billrun pin_virtual_time has to be set to the date when the real billrun on production will be executed. Once that’s done, the billrun can be started.

We run billing monthly with pin_bill_day script which creates about 100.000 bills per hour. The script creates bills for accounts where the billing date is any day before midnight of the day we run billing. So what does pin_billd_day script actually do? It runs the following billing utilities:

• pin_deferred_act: Executes deferred actions; for example if an account should become inactive, this utility performs the status change on the scheduled date.
• pin_bill_accts: Calculates the balance due for accounts and creates a bill for the balance due.
• pin_collect: Collects the balance due for accounts that use credit cards and directs debit payment methods.
• pin_refund: Finds accounts that have refund items and makes online refund transactions.
• pin_inv_accts: Creates an invoice for each account that is billed.
• pin_cycle_fees: Applies the cycle forward fee balance impact to the customer’s account and cancels products that have an expired pending cancellation date.

To verify the progress and performance of the pin_bill_day script, we run queries against the database to get information on how many bills are done, how many are yet to be done, if there are any bills with errors, etc.

After the billing part is over and all the bills are created, invoicing starts. After the invoices are created, they are exported to XML documents, which are then converted into PDF format.

Besides the queries mentioned earlier, there are also other queries that need to be executed once billing and invoicing has finished, in order to verify the accuracy of the data generated by this process. We execute batch of queries; here are some of them:

• Has billing failed?

select * from billinfo_t where billing_state = 4 and bill_info_id<>’Bill Unit(1)’;

–Expected results: No rows found

• Are there any unbilled accounts?

select poid_id0, first_name,last_name,a.status from account_t a, account_nameinfo_t an where

a.poid_id0=an.obj_id0 and

created_t<<bill_cycle_end_date> and

not exists (select b.account_obj_id0 from bill_t b

where end_t=<bill_cycle_end_date> and

b.account_obj_id0=a.poid_id0);

–Expected results: No rows found

• Are there any bills without a bill number?

select * from bill_t where end_t=<bill_cycle_end_date> and bill_no is null;

– Expected: No rows found

Any problems found are then investigated and fixed through the versioning control system, where fixes are later included in the next release version.

The introduction of rating differentiation for specific accounts can be configured using Promotions. Promotions in Oracle BRM provide a way to give customers special rates or discounts based on a specific attribute of a service or account, such as a telephone number. Promotions are called extended rating attributes (ERAs) in the Pricing Center and elsewhere in Oracle BRM. Adding a closed user group promotion is achieved by opening the Customer Center and selecting the Promotion tab. There, select Closed User Group from the account-level Promotion Type list, enter the phone number or account login ID in the Name column, enter the name of the closed user group in the Value column, and optionally select Valid From and Valid To dates. Note that while you can assign multiple closed user groups to an account, each number can be assigned to only one closed user group at any time.

For our customers, however, we have designed and implemented CUG functionality in a different way. In the first phase, the idea was to allow cheaper outgoing voice calls among accounts in the same hierarchy. For the hierarchy to be CUG-compliant, the parent has to have an account-level product called CUG1. Now, when a voice call is made between child accounts in this hierarchy, a pre-rating opcode checks whether or not both A subscriber and B subscriber belong to the same hierarchy. If they do, a flag is set for the rating engine to charge this event at a lower rate.

Picture 1: Calls between any two accounts in this hierarchy are discounted

The second phase introduces an extension to the original functionality by allowing subscribers to belong to the same CUG group without being in the same hierarchy. As long as A subscriber and B subscriber belong to the same CUG2 group (having a corresponding CUG2 product with the same description – group name) and do not belong to CUG1 hierarchy, the call is rated according to the CUG2 product rate. Note, CUG1 always has the higher priority, so if it exists for both A and B subscribers, only the CUG1 charge can be applied.

Picture 2: Calls between accounts having CUG 2 products with the same description are discounted (regardless of hierarchy membership)

Issue 2
If you can’t start the pipeline and you get this error message: »Error: Could not start event handler, cannot proceed.», then you need to kill the event handler process. See the example that follows:
/opt/portal/pre_dia/log/process/ $ tail -f dia_1_P.out
;
Pipeline Server / Version 7.3 10095 started at 06.01.2009 16:23:11.
Copyright (c) 1998 – 2007 Oracle Corporation. All rights reserved.

Too many failed attempts at starting event handler daemon.
Error: Could not start event handler, cannot proceed.

Pipeline Server / Version 7.3 10095 finished at 06.01.2009 16:23:11.

Resolution:
$ pss | grep dia
pin 27727 1 0 15:50:21 pts/3 00:00 /opt/portal/pre_dia/bin/ifw_eventhandler64
pin 3055 4463 1 16:24:18 pts/3 00:00 grep dia
$ kill -9 27727

Issue 3
To rebalance the MBI pipeline, run the following command:
cd /opt/portal/pre_mbi/bin/
./pin_ctl snmpset rebalanceAaaGw aaa

To rebalance the DIAMETER pipeline, run the following command:
cd /opt/portal/pre_dia/bin/
./pin_ctl snmpset rebalanceAaaGw aaa

Issue 4
If you get this error message: »ERR_TAM_INIT_FAILED,« then you need to delete files in the tam directory.

bin/ifw: An error occurred during creation.
Originator : ifw.Pipelines.ExceptionPipeline.TransactionManager
Destination :
Message : ERR_TAM_INIT_FAILED
Arguments : ifw.Pipelines.ExceptionPipeline.TransactionManager
State : false
Severity : CRITICAL
Thread : 1

Resolution:
cd /opt/portal/
/tam
Backup the files to other location
rm TamTrans*.dat
rm ExceptionBinaryLogFile.dat

Issue 5
If you get this error message: »ERR_REG_LOCK_FILE_EXISTS,« then you need to delete the lock file.

*** Log not initialised.
*** Tried to write message ‘[T:1] ERR_REG_LOCK_FILE_EXISTS’
*** argument (0): ./custom/conf/rt_1_P.reg.lock

bin/ifw: An error occurred during creation.
Originator : ifw
Destination :
Message : ERR_REG_LOCK_FILE_EXISTS
Arguments : ./custom/conf/rt_1_P.reg.lock

State : false
Severity : CRITICAL
Thread : 1

Resolution:
cd /opt/portal/
/custom/conf
rm rt_1_P.reg.lock