Architectural Issue With Rerating And Recycling In Multi-Db (Doc ID 789303.1)

Last updated on AUGUST 27, 2012

Applies to:

Oracle Communications Billing and Revenue Management - Version 7.3.0.0.0 to 7.3.0.0.1 [Release 7.3.0]
Information in this document applies to any platform.
This problem can occur on any platform.
Checked for relevance on 20-Aug-2012

Symptoms

-- Problem Statement:
We are facing an architectural issue regarding the use of batch pipeline, recycling and rerating in a multi-database context.

If we take an example of a 2 databases BRM systems (DB1 and DB2), we store all suspended CDR in a
single database schema (DB1) so suspended CDR for DB2 accounts are stored in DB1.

When rerating is launched on DB2 (with pin_rerate), the last step of the rerating (pin_rerate
-process recycle) is to search for CDRs that were suspended by the rating pipeline during the
rerating (new CDRs from an account being rerated are suspended : this is the BRM behavior).
It seems that pin_rerate will perform the suspended CDR search on DB2, whereas we would expect a
search on DB1,  we have no option to configure this, so this is an architectural issue.

Expectations :
- No change in the already validated architecture
- The "pin_rerate -process recycle" command should be able to process CDR from a configurable BRM
DB (that may be different from the BRM DB where the rerating is performed)
- The suspended CDR database could be outside of the BRM multi-database system (without altering
the behavior of the rerating)


Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms