My Alerts Console
How it Works
- The My Alerts Console is run once a day.
- On each run the console will generate a list of users who are to be checked:
- Those with a 'last run' date prior to the current date by the number of days set in their 'interval' setting
- For each user, retrieve the list of locations to check.
- For each location, retrieve the layer groups to check.
- For each layer group, check the previous cache version against a snapshot of the current position.
- Comparing the cache and snapshot build up a list of changes.
- If a user is found to have any changes, then an e-mail is sent.
Location-less Layer Groups
With the Virtual (location-less) Layer Groups, My Alerts also adds a check for a user's location-less Layer Groups in to the above workflow and generates snapshots if new data is found.
Configuration
You will need to make sure that you have configured your SMTP Mail Server details which are the same as for the Workflow. See the topic Notification Setup.
The following configuration options will be needed for My Alerts Console.
Option | Description |
---|---|
DebugEnabled | True/false, this flag will decide how detailed the output information is, if debug is on then the console will output detailed running information |
UsersWebServiceURL | URL for users.asmx web service |
UserManagerWebServiceURL | URL for usermanager.asmx web service |
TransactionWebServiceURL | URL for transaction.asmx web service |
To configure the above click on the MyAlerts node in Studio to display the configuration settings and click the Edit button. The above entries will be found under MyAlertsService group.
You will also need to configure the Email settings which you will find under the My Alerts Service (Email) group.
Please refer to the topic My Alerts Configuration Settings for details on the My Alerts settings.
Running the My Alerts Console
The My Alerts Console is the Astun.MyAlerts.Console.exe
application. In general it is run via a Workflow Program Task without any additional parameters.
Switches
You can modify the behaviour of the console using a number of switches / parameters. The command line help is:
Astun.MyAlerts.Console.exe [<userlist>] [-debug [-nowrite] [-email [-address=<new-email>]]] [-help|-?] [-workspace=<workspace_name>]
or in Workflow you would enter parameters in the Additional parameters box e.g.
Switch / Parameter | Effect |
---|---|
| To print out the help for the switches. Will not attempt to run. |
| Optional comma separated list of user ids. The console will only attempt to run on these users. Note that the list cannot contain any spaces. E.g. |
| To run the console in debug mode. In this mode checks are still carried out and a new snapshot written to the cache database, but no email will be generated. Switch order If you use Last run time When the console is running in debug mode it will not update the last run time in the database, even if the cache database is updated. For examples of how to set the last run time, see the SQL code in Flush out major changes below. |
| Only applicable in debug mode. This will stop the writing of any cache entries. |
| Only applicable in debug mode. This will generate and send the email. |
| Only applicable in debug mode with –email set. This will cause all emails generated to be sent to the specified address. |
-workspace=<workspace_name> | This will just run My Alerts for the specified Workspace. Only required if Workspaces are enabled. Users tied to workspaces will not be included in runs unless this parameter is specified. |
Flush out major changes
When a large number of administrative changes have been made, such as to the structure of the data or an import of new data, for example, adding a new layer, it's usually best not to send a flood of emails out to My Alerts subscribers.
This is avoided by running the console with the -debug
switch as described above, but without the -nowrite
switch set, and using the -email
and -address
switches to send all emails to your own email address for monitoring. This writes all the changes to the database, so only changes subsequent to this get sent out.
Run the console a second time with the same switches set to ensure that there are now no alerts, if there are, then something may have gone wrong.
Check all users
In order to ensure that all users are checked during the debug run, the myalert.tbl_schedule
table in the myalert
database should be updated manually. To do this, set the lastrun
value for each user to the previous day by connecting to the myalert
database and running:
UPDATE myalert.tbl_schedule SET lastrun = now() - interval '1 day';
Once the debug run has completed, update the lastrun
column of the schedule
table to the current day so that, when My Alerts runs next, it will compare the the data at that time with the snapshot taken during the debug run:
UPDATE myalert.tbl_schedule SET lastrun = now();
Exceptions
The console has been made as robust as possible so that should exceptions occur, the console will continue, but keep track of the exceptions. It will attempt to send as many good emails as possible, and at the end will send a relevant e-mail back (preferably to Astun) indicating the problems.
Currently should an exception occur whilst checking for changes in a user location (or the location-less), we would attempt to continue with the rest of the user locations.