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 18.104.22.168.0 to 22.214.171.124.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
-- 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.
- 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)
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!