Comments (4)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 SASHULL commented Permalink

Very good and interesting article. We had this requirement for one of our business clients and approached it an entirely different way versus creating the actual cron task instance. <div>&nbsp;</div> Your way is cleaner because in ours, we had to have the engine a) execute the report immediately (which caused the change status to take longer, so we eventually had to move it to an escalation for performance) and b) we had to temporarily store the report on the server to then add it as an attachment. I'm actually contemplating rewriting our process to accommodate the functionality you added. <div>&nbsp;</div> One of the best articles to date.

2 agrippa commented Permalink

Hi SASHULL, <div>&nbsp;</div> Thanks for the feedback. I like the approach where I can delegate to the Cron infrastructure to execute the report on a dedicated Cron JVM. The trick was in figuring out where precisely to hook into the reporting framework. <div>&nbsp;</div> One thing I noted during testing was that report execution errors also end up getting sent to the intended recipient via email: <div>&nbsp;</div> "Ad Hoc PO Report via script [FAILED TO RUN]" <div>&nbsp;</div> This is standard functionality and the user could forward this to the system administrator for resolution. A good practice here would be to test the report execution with "immediate" option and then enable the script. <div>&nbsp;</div> Sam

3 Booshan commented Permalink

Excellent and interesting aticle

4 raquino84 commented Permalink

Thank you Agrippa <div>&nbsp;</div> the output to the report is empty, it's necessary include a variable "where" for the BIRT <div>&nbsp;</div> Regards