beGroveller Throttles Sending Buckets to beVWARS for Expiration and beVWARSExpiry Plugin Does Not Expire Buckets with Active Reservation (Doc ID 1392293.1)

Last updated on APRIL 18, 2012

Applies to:

Oracle Communications Network Charging and Control - Version 4.1.0 and later
Information in this document applies to any platform.

Symptoms

On the VWS (Voucher and Wallet Server), the beGroveller process does not report wallet ids with buckets eligible for expiration on the configured Time/Date.
The expiration of these buckets by the beVWARS process is therefore delayed.

Example:

From the be_bucket table, the following buckets are supposed to be expired on Dec 1, during the first hour:

#su - ebe_oper
$sqlplus e2be_admin/(password)

SQL> select ID,BALANCE_TYPE,EXPIRY
from BE_BUCKET
where EXPIRY >= to_date ('20111201000000','yyyymmddhh24miss')
and   EXPIRY <  to_date ('20111202000000','yyyymmddhh24miss');

ID          BALANCE_TYPE    EXPIRY
---------   ------------   ----------
19289644     10566       20111201002508
27610156     10576       20111201003337
19292332     10603       20111201005551
----skipped--------


But these buckets were not processed on the scheduled time set in (be_bucket Table / expiry Column), and beVWARS expired them with time delay.

From generated VWS EDR (Event Data Record)

BILLING_ENGINE_ID=xx|CDR_TYPE=49|RECORD_DATE=20111201033837|BALANCE_TYPES=10576|CHARGE_NAME=xxxxxxx|CLI=xxxxx|NEW_BALANCE_EXPIRIES=20120101002217|RESULT=Success|MSISDN=xxxxxxx
BILLING_ENGINE_ID=xx|CDR_TYPE=49|RECORD_DATE=20111202032808|BALANCE_TYPES=10566|CHARGE_NAME=xxxxxxx|CLI=xxxxx|NEW_BALANCE_EXPIRIES=20120101003653|RESULT=Success|MSISDN=xxxxxxx
BILLING_ENGINE_ID=xx|CDR_TYPE=49|RECORD_DATE=20111203025151|BALANCE_TYPES=10603|CHARGE_NAME=xxxxxxx|CLI=xxxxx|NEW_BALANCE_EXPIRIES=20120101003851|RESULT=Success|MSISDN=xxxxxxx



- Verifying the issue can be made also by querying the same buckets after the expiry date is reached and you will notice that the value has not been extended nor deleted.
- The  mentioned EDR samples were trimmed to include only the relative tags showing the delay in buckets expiration processing.
- By checking the RECORD_DATE (e.g. RECORD_DATE=20111202032808), you will notice that the bucket was expired with a 2 hours delay (0203) instead of within the first hour (00xx).

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