Pam,
That's exactly what we are doing at the moment, using the UUID class to
generate the requestID. We are now sort of lost on how to pair the abated
events with the onset ones with a proper key for the hash map.
Anyways, we'll try to find a way to improve it. Thanks for you prompt
Guangrong,
I would not use eventId – that is different and has different meaning. The
requestID should be unique to the Control Loop and you can use UUID java class
to generate a random one. You could simply use a HashTable in Drools memory and
insert an object in order to retain state from
Pam,
I have another question regarding the "requestID" in the control loop event.
We are now using the "eventId" which is contained in the VES events as a key to
judge whether the onset and abated alarms are in pair. To my understanding, if
the alarms are in pair, we have to fill
Guangrong,
Yes and no.
The vnf-id is important in the ONSET as Policy has to lock that VNF to ensure
multiple requests are not sent to it at the same time. The service-instance-id
(and other subsequent A information) helps performance in that Policy does
not need to look that information up
Hi Pam,
For the onset alarms, Policy requires the vnf-id and the service-instance-id in
the CL event. How about the abated ones? Do we still have to fill in these two
fields as well? I think the answer is negative because for the abated alarms,
Policy does not use them to trigger any
