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
SQL> select ID,BALANCE_TYPE,EXPIRY
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
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)
- 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!