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

-? Or -help

To print out the help for the switches. Will not attempt to run.

<userlist>

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. Astun.MyAlerts.Console.exe 1,3,4

-debug

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 -debug then this must be the first parameter in the list as per the above screenshot otherwise the following parameters, which are reliant on debug being enabled, will not work.

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.

-nowrite

Only applicable in debug mode. This will stop the writing of any cache entries.

-email

Only applicable in debug mode. This will generate and send the email.

-address=<new-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.