Event Notification List was not Efficient
(Doc ID 2161084.1)
Last updated on AUGUST 27, 2020
Applies to:Oracle Communications Billing and Revenue Management - Version 126.96.36.199.0 to 188.8.131.52.0 [Release 7.5.0]
Information in this document applies to any platform.
On : 184.108.40.206.0 version, Event Management
The /config/notify object in Billing and Revenue Management (BRM) is required to configure exact event POID types for every event that an user wished to send to an OPCODE via event notification.
The user has 92 event types and opcode combinations configured for event notification, the /user_activity feature needed to be used to meet partner tracking requirements and it must (by explicit requirement) track every single event generated during a user session (running through a connection pool with context info added per /user_activity feature docs).
This required the user to add 339 more event types and OPCODEs combinations to /config/notify, i.e. all possible event types (including future event types via deployment automation) to be sure to catch any event generated in the /user_activity object. Using millisecond timing, the user has discovered that this potentially added about 14 milliseconds to the rating of every single event in the system, which could have measurable impacts on daily batches which handle 1 million+ customers some days of the month.
The recommendation is to be able to match event POID type either by (optional) regular expression or to include all sub-classes of a specified event POID type in the notifications (probably an option for backwards compatibility). If nothing else, doing a linear set of string compares against the entire notification list for every event simply cannot be considered acceptable.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document