My Oracle Support Banner

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 FEBRUARY 06, 2018

Applies to:

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


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.


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)

where EXPIRY >= to_date ('20111201000000','yyyymmddhh24miss')
and   EXPIRY <  to_date ('20111202000000','yyyymmddhh24miss');

---------   ------------   ----------
19289644     10566       20111201002508
27610156     10576       20111201003337
19292332     10603       20111201005551

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)


- 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).


To view full details, 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 a vibrant support community of peers and Oracle experts.