I believe I understand what needs to be done. General outline:
- Extend the search description in the database to include an alert field
- We can keep a list of saved searches with alert fields not null in memory (also maintain this list upon searches being saved/deleted/updated from the GUI)
- Upon addMetaDataLogEntry check the new entry against all the searches in the alert search list in memory, and execute the alert if the entry conforms to a search.
- Define an interface for the alert sending mechanism. Have various implementations to this interface (SMS, email, IM message etc.).
public interface Alert{
public void setSearch(Search triggerSearch);
public void setMetaDataLogEntry(MetaDataLogEntry triggerMetaDataLogEntry);
public void execute();
}
- Store the alert interface implementation class name as part of the the search description in the database.
Do we need a GUI interface for configuring any extra parameters for the alerts (like destination address etc.), or will the alert implementation get all needed information from the search parameter values and the Search and MetaDataLogEntry that triggered it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
General outline is fine. I believe as you say that we need a way to configure destination address. It would probably be a good idea to either configure destination addresses from a separate parameter - or from a field in the search result - just like in the report generator. What you think of this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think using a field from the search result as destination address is a valid option. Because the Alert implementation will be passed the whole MetaDataLogEntry it can extract the value from any of its fields.
A use case where a separate parameter can be used is to notify a single person for all triggered alert (e.g. notify the admin when a fatal erro occurs for any user). This parameter can override the extracted one.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=1384657
Originator: NO
I believe I understand what needs to be done. General outline:
- Extend the search description in the database to include an alert field
- We can keep a list of saved searches with alert fields not null in memory (also maintain this list upon searches being saved/deleted/updated from the GUI)
- Upon addMetaDataLogEntry check the new entry against all the searches in the alert search list in memory, and execute the alert if the entry conforms to a search.
- Define an interface for the alert sending mechanism. Have various implementations to this interface (SMS, email, IM message etc.).
public interface Alert{
public void setSearch(Search triggerSearch);
public void setMetaDataLogEntry(MetaDataLogEntry triggerMetaDataLogEntry);
public void execute();
}
- Store the alert interface implementation class name as part of the the search description in the database.
Do we need a GUI interface for configuring any extra parameters for the alerts (like destination address etc.), or will the alert implementation get all needed information from the search parameter values and the Search and MetaDataLogEntry that triggered it?
Logged In: YES
user_id=1038911
Originator: YES
General outline is fine. I believe as you say that we need a way to configure destination address. It would probably be a good idea to either configure destination addresses from a separate parameter - or from a field in the search result - just like in the report generator. What you think of this?
Logged In: YES
user_id=1384657
Originator: NO
I think using a field from the search result as destination address is a valid option. Because the Alert implementation will be passed the whole MetaDataLogEntry it can extract the value from any of its fields.
A use case where a separate parameter can be used is to notify a single person for all triggered alert (e.g. notify the admin when a fatal erro occurs for any user). This parameter can override the extracted one.
Logged In: YES
user_id=1038911
Originator: YES
Sounds ok to me!