I have a BAQ Report that is really slow. The BAQ takes less than 2 seconds to run. The SysRptLst table record is generated in about 30 seconds, so printing/print previewing takes about 30 seconds. I would figure that the report wouldn’t take that long to print given the BAQ processing time. Support is telling me this is expected behavior, but I don’t think we’re quite connecting on what is going on. I think support is assuming this is a slow printer problem, but this looks like it is a slow data generation process to put the data into SysRptLst or this is a System Monitor problem. We have changed the System Monitor polling times to make it more responsive for a longer period of time (because this is in our test environment), and there doesn’t appear to be a change. Any ideas?
What’s the value of the SysConfig for that environment in the SystemMonitorPriority/NonPriorityPoll and SystemMonitorPriorityPollDuration nodes?
Also, is it just this report or all reports
I originally had them as the default, from Epicor
Priority: 3000 (also tried at 2000 and 1000)
Duration: 15000 (also tried at 20000, and 30000)
This is really our first foray into BAQ Reports so this the only report we use currently. There are times if we restart the task agent that it will run in 5-6 seconds, but it’s not consistent. 9 times out of 10 when we restart it takes the full 30 seconds. If it is successful running it under 10 seconds the next time we run the report we see the 30 second delay again.
I could try to create another simple report and see if it has the same problem.
I think I found the issue. In some cases, the BAQ Report’s SubmitToAgent is not telling the System Monitor to go into Priority Mode, so it doesn’t poll until the “Normal” time comes around which is currently set to 30 seconds. Now I need to find out how to fix it.
When (or if) you do, please post. And if you can’t post what you’ve tried, so the rest of us will know better than to tackle this in the same way.
I can’t imagine this is the proper way to handle this, but I was able to force the System Monitor to go into priority mode before the BAQ Report is called. This will likely only work if you’re using a Transaction that derives from Ice.Lib.Framework.EpiReportTransaction (in Ice.Lib.EpiReportLib dll). This uses reflection so you would need to include System.Reflection in your using (or Imports).
var mi = oTrans.GetType().BaseType.GetMethod("NotifySystemMonitor", BindingFlags.NonPublic | BindingFlags.Instance);
It was unclear that you’re calling the BAQ report from code from your questions, but I think it’s an important distinction here because there’s no way to tell the quality of the code.
Does the BAQ report also have a delay when invoking it from the standard interfaces?
Yes. I implemented the custom code so I could force the System Monitor into priority mode. I made the custom code mimic exactly what the standard interface does and verified that in a trace. In fact, I used quite a bit of ILSpy generated code from the standard interface. The only difference is, now the two lines above are called and the System Monitor goes into priority mode. I could, I guess, set the user Normal polling to a shorter time and that would solve it as well, but it also causes more network traffic. I’m still hoping to find a different solution, but that’s all I have for now.