Hi Dojo Community,
The use case is that I’m trying to retrieve historical Information Events from any date ranges up to two years ago.
I’m trying to use the GetAlarmDetailsFromDbMessage from an automation script (GQI) and I’m having some issues, this is the snippet of code I’m using to create the call:
Both StartTime and EndTime values are Dates with a day difference no higher than 7 days always, the filter only contains a wildcard match on the parameter description.
The issues I’m having:
- When I set StartTime and EndTime to Dates with a day difference higher than 8 days, the call will always be empty, even if there are information events.
i.e., StartTime: 06/20/2023 EndTime: 07/06/2023
- When I set StartTime and EndTime to Dates from more than 9 days ago, even with day difference less than 7 days, the call will not retrieve any information event.
i.e., StartTime: 06/20/2023 EndTime: 06/23/2023
A colleague also tried a similar call and failed to retrieve any information events.
When I try to replicate the search through the Alarm Console, I can see the information events there.
Do you know if there are any limitations or if I’m not building the message correctly? If so, can you provide a snippet of code for these use cases?
Also, is this the most efficient way to retrieve this amount of information events? Since the amount of data retrieved can grow to hundreds of thousands of events.
Luis,
The biggest clue will probably be here what do you pass along as alarm filter object. You should at least select an element or parameter filter object or you will encounter max payload issues. The client does this async and requests the data paged. I would like to now more about the use case before continuing because if you don't pass the right arguments this is a sure way to let the SLAutomation.exe process run out of memory.
Luis, since it is a wildcard with no specific element passed along, my guess will be that the query either returns too much data or just times out. Because the wildcard logic is done in post-filtering so basically with 2 years range you’ll just get too many information events back.
I agree that two years range is probably too much data.
But after doing it with 8 days range, is not working as expected neither.
Luis these will probably be because of may payload issues or timeout issues because everything has to be done in post filtering. You can check the logging of SLNet, SLDBConnection and SLMessagebrokerSLMessageBroker_SLNet.txt to try and track the requests sent and their potential exceptions being thrown.
Davy, after some testing we reached the point where doing a Message per day is working, two days will not work. So most probably there’s too much data as you mentioned.
Also, you mentioned that filtering on element would help this? How can I know which filters will be done post-filtering and which will be help with the load?
Hi Davy, thanks for answering.
The filter I’m doing is to get only information events that contains “Based Details”, so I’m using a wildcard for that, that avoids getting all the system information events and only getting the information events generated by a specific parameter but still system-wide.
As I mention, this works for recent days but as soon as I try to retrieve from back in time it is not working