From PTAGISWiki
Report Completion Messages – Redesign
version 0.2, dated 10/12/07, by Marton Nagy
Introduction
It has been reported that the messages signaling the completion of reports arrive too soon. This document
describes the cause of the problem and suggests an alternate design as a solution. This alternate design is
planned to be used with the new MyMessages module.
Analysis
Current Design
When queries are run or scheduled a StyleReport task is created whose actions include running the report
and sending a notification to the user. The details are:
1.a ScheduleTask is created (called e.g. nagym_qb_myquery_1) and set up to have the following components
a.a TimeCondition referring to either now or a future date (depending on whether the report is ran or scheduled)
b.a ReportAction, that executes the report, then saves it
c.a UserAction, that sends a message to the user (an instance of the class called MyMessageSreeAction)
Issue
The problem with the current approach is that the StyleReport ScheduleTask executes its actions in parallel
(probably by different threads), i.e. sending the message and executing the report starts at the same time.
Consequently if a report execution will take a long time the message will arrive much earlier and the link
within the message will point to a report that does not yet exists.
New Design
When queries are run or scheduled two StyleReport tasks are created, so that the second is set up to run after
the first has been completed. The first task’s action will run the report and the second’s action will send
a notification to the user. The details are:
1.a ScheduleTask is created (called e.g. nagym_qb_myquery_1) and set up to have the following components
a.a TimeCondition referring to either now or a future date (depending on whether the report is ran or scheduled)
b.a ReportAction, that executes the report, then saves it
c.a UserAction, that logs the start of the report execution (TBD class)
2.a second ScheduleTask is created (called e.g. nagym_qb_msg_myquery_1) and set up to have the following components
a.a CompletionCondition referencing the first ScheduleTask (i.e. to trigger execution when the first ScheduleTask completes)
b.a UserAction, that sends a message to the user (an instance of the class called MyMessageSreeAction)
This design relies on the fact that even though 2 actions of a task cannot be set up to execute sequentially,
2 tasks can be set up to execute that way.
Naming Convention
The following naming conventions will be adopted for the tasks:
Given a <folder> and a <reportname>
the existing/first task is called: <folder>_<reportname>
the second task is called: <folder>_msg_<reportname>
For instance:
A query example:
query folder: nagym_qb
query name: myquery_1
task1: nagym_qb_myquery_1
task2: nagym_qb_msg_myquery_1
A report template example:
report folder: nagym
report name: myreport
task1: nagym_qb_myreport
task2: nagym_qb_msg_myreport
