I’m troubleshooting a problem with a SSRS report with Epicor support.
The support person is telling me “it must be due to one of you method or data directives”…my feeble brain wants me to believe reports cannot cause BPMs to execute since no data is being updated.
Am I wrong ?
Methods can include a lot of operations that are not the “update” operation. So technically yeah, even pulling data can trigger a method directive. Not likely to be a data directive, but could be a method directive. Run a trace the reproduce the problem. The trace should show which methods are called.
I’d think printing would hit the tables which could fire off Data Directives at the least. There are a ton of methods one some BOs that could be called perhaps. I haven’t ran a trace when just printing though.
Its definitely possible. There could be bpms on the submittoagent method. The systask or systask param tables. Or even just the record itself - a lot of things capture the print action in an autoprint or mass print checkbox that gets updated once you print.
This may be the same thing @aosemwengie1 was saying… that Printing may just be part of the events taking place.
For example, printing a job travel prints the traveler… but also updates the “Last Printed” value on the job. So, “printing” may be a trigger for other events to take place… and one of THOSE is causing your issue.
For the reasons stated above, yes, but I would like more context, as my spidey sense is tingling.
Give us some more context so we can see if they are feeding you a line of bs.
So, has to do with Sales order pick list report,
originally started as a performance problem when there were lots of orders on a given date,
like everything it got blamed on our customizations.
So was told to try the standard report, which ran, but also slow,
but then instructed to copy it and incrementally add customizations to narrow down the problem.
Got to this situation where for a specific date (picked because of the number of orders), the standard report would run, but the identical copy of it would not.
Was repeatedly getting a timeout during rendering on the copied report style (the timeout is well below our setting for report timeouts.)
So now support is reluctanct to look at it since we do have lots of BPMs on SalesOrder/Order Tables
Go into pilot, turn off all bpms. Reproduce the issue. I really can’t blame them for wanting to point the finger there first so prove them wrong.
I use this mostly for scheduled BAQ Exports, but it would be easy to do with SSRS using a Data Directive on SysTask where the TaskStatus == "COMPLETE" && TaskDescription == "Name of Report";
I use this to email BAQ Export files. My Condition widget with custom code:
foreach(var task in ttSysTask) {
var taskLog = Db.SysTaskLog.FirstOrDefault( x => x.SysTaskNum == task.SysTaskNum );
// Handle Tasks with no log (e.g. Reports)
if ( taskLog == null )
return false;
// Task is correct Dynamic Query Export
bool isCorrectBAQ = taskLog.MsgText.Contains( thisBAQ );
// Task completed Successfully
bool taskSuccessful = task.TaskStatus == "COMPLETE";
// Return true in loop so all may be checked
if ( taskSuccessful && isCorrectBAQ )
return true;
}
return false;
Is not that a BPM to trigger an export not having the act of printing trigger a BPM as the OP was asking.
Nope. It’s a data directive on SysTask that triggers after the BAQ Export is finished. Usually the next widget is a function call to email the BAQ Exported CSV file. I use those with BAQ Export Process so I can schedule monthly / weekly / daily emails of data to people who want it.