Scheduled maintenance tasks

Crontab is a task scheduler used by EMu System Administrators to run regular maintenance and other tasks.

A Crontab entry comprises six fields (separated by a space) in the order:

An example of a Crontab entry is:

An asterisk (*) can substitute for any of the date / time fields and represents all possible values for that field. Thus * in the day of the month field means that the task will run every day of the month.

A field can also contain a set of numbers separated by commas, or a range of numbers separated by a minus sign (e.g. 1-5 in the Day of the week field).

Note: You must open a command line session on the EMu server and log in with the username emu in order to edit the Crontab file.

Running this task completes the indexing of new and modified records.

Note: To ensure fast System operation a record is only partially indexed when it is edited or inserted. Partially indexed records appear the same as fully indexed records to the user.

Typically this task is run daily, Monday through Friday.

Running this task rebuilds all indexes and compresses data, deleting obsolete records that have been marked for deletion and left after a record has been edited.

Note: The size of the Audit and Statistics modules will grow over time as more records are added to them. Since both modules have a very small / non-existent number of record changes it is not necessary to compact these tables as part of the weekly maintenance schedule. An option COMPACT="no" may be added to a module's emuoptions file (stored in the module directory on the EMu server) to skip the compaction of the module when maintenance is performed.

This task can also be run manually. See How to re-index a table for details.

Running this task deletes historic reports that were logged when a maintenance task was run by Crontab. The System Administrator determines the number of days that reports are retained.

Typically this task is run daily, Monday through Friday.

Running this task checks the status of each EMu table and produces a report.

This report should be checked daily to ensure that all tables are online and all maintenance tasks have been completed successfully.

Notification fields are used to inform users that something requires their attention. They are included in many EMu modules (notably the Loans, Events, Insurance and Movements modules, and any module with a Tasks tab) and are used to send an email notification to one or more people at a pre-determined date. In the Loans module, for instance, commencement and completion notification dates may be specified for a loan; the loans manager is automatically sent notification by email about the loan at these dates.

A notification comprises three components:

• The date on which people are to be notified.
• The people to be notified.
• A report to send as the notification.

The date and people to be notified are specified by a user in the relevant module (Loans, for example); reports are independent of the modules and are constructed from various files.

In order to generate notifications reports the emunotify script is run; it scans all notify fields and generates HTML files and an email message for everyone specified for any notification that has reached its due time and date. The email is sent and the HTML files are left on the server for viewing by a user through the View Notifications Admin Task.

Typically this task is run daily, Monday through Friday.

How to add a local notification report

Two things must be done to add a local notification:

1. The information about the notification must be included in the include file notify.pl in the local/etc/notify directory. See Include File Format for details.
2. The files that will be used in the report must be generated. These files should be placed in the local/etc/notify/en directory. These are HTML files so that they can be displayed on the web and sent as email without requiring separate processing.

The following example is used for Conservations:

<TABLE WIDTH="75%" BORDER="0" cellspacing="0">

<TR>

<TD WIDTH="10%" nowrap bgcolor="#bgcolor#"><I><font face="Arial" size="3" color="#000080">Expected Completion Date:</font></I></TD>

<TD WIDTH="70%" bgcolor="#bgcolor#"><font face="Arial" size="3" color="#000080">#ReqRequestedCompletionDate# </font></TD>

</TR>

<TR>

<TD WIDTH="10%" nowrap><I><font face="Arial" size="3" color="#808080">IRN:</font></I></TD>

<TD WIDTH="70%"><font face="Arial" size="3" color="#808080">#irn#</font></TD>

</TR>

<TR>

<TD WIDTH="10%" nowrap><I><font face="Arial" size="3" color="#808080">Conservation Identifier: </font></I></TD>

<TD WIDTH="70%"><font face="Arial" size="3"color="#808080">#ReqConservationIdentifier#</font></TD>

</TR>

<TR>

<TD WIDTH="10%" nowrap><I><font face="Arial" size="3" color="#808080">Requested By:</font></I></TD>

<TD WIDTH="70%"><font face="Arial" size="3" color="#808080">#ReqRequestedByRef#</font></TD>

</TR>

<TR>

<TD WIDTH="10%" nowrap><I><font face="Arial" size="3" color="#808080">Date Requested:</font></I></TD>

<TD WIDTH="70%"><font face="Arial" size="3" color="#808080">#ReqDateRequested#</font></TD>

</TR>

<TR>

<TD WIDTH="10%" nowrap><i><font face="Arial" size="3" color="#808080">Notification Date:</font></i></TD>

<TD WIDTH="70%"><font face="Arial" size="3" color="#808080">#NotifyDate#</font></TD

</TR>

</TABLE>

Data is taken from each EMu record and inserted into the #ItemName# (e.g. #irn#) sections of the document.

Include file format

The local include file (local/etc/notify/notify.pl) format is as follows:

@LocalFields =

(

	{

database	=>	 "eloans",

reffield	=>	"DatCommenceNotifyRef_tab",

nested		=>	0,

datefield	=>	"DatLoanCommenceNotifyDate",

overduefield	=>	"",

report		=>	"loan.htm",

header		=>	"startloan.htm",

category	=>	"outloan.htm",

datafields	=>	["irn", "InfLoanNumber", "InfDirection", "InfBorrowerLenderRef", 

			"InfReasonForLoan", "ObjObjectsLoanedRef_tab", "DatLoanCommencementDate", 

			"DatLoanDueDate"],

format		=>	[\&none, \&none, \&none, \&address, \&none, \&count, \&date, \&date],

	},

	{

	......

	},

);

The explanation of each field is:

Field Name	Explanation
database	The database to search for the notification.
reffield	The field that contains the references to the Parties records for the people to be notified.
nested	Whether or not the reffield forms part of a nested group of fields. 0 for no and 1 for yes. An example of a nested group is the Task tab found in many modules.
datefield	The date field to be searched to match against the notify date.
overduefield	The field to be checked to determine if this action has been completed.
report	The report body to be used for any notification matches.
header	The report header to be placed above the report body for each notification match.
category	A heading to be placed above all of the reports generated for this data field from this database.
datafields	The data fields from the record that are used in the notification report.
format	A processing routine to format the data field prior to putting it in the report. Each data field should have a corresponding format routine.

The report to the user is output as follows:

category

header
report

header
report

....

The following data field format routines are defined:

Format	Action
\&none	Do not change field data.
\&count	Count the number of values in this field.
\&name	Formats name as: Title Firstname Middlename_initial Surname. If this is blank, uses the organisation field.
\&address	Formats address as: Title Firstname Middlename_initial Surname organisation Street Address City State Postal_Code Country
\&date	Formats date in the dateorder as specified by the texpress dateorder environment variable.
\&table	Formats the contents of a nested table where nested=0.
\&nametable	Formats the contents of a nested party reference table using the \&name and \&table formats.

Special #markers#

Special markers have been defined for passing information that is not contained in a record to the reports:

Marker	Data	Report Section Available In
#FullName#	Firstname Lastname.	category, header
#ReportDate#	The date of this report. This is a range (a week) for web reports and a single day for email.	category, header
#EndDate#	The last date in the date range for this report.	category, header
#Database#	The database that this report is from.	header, report
#NotifyDate#	The notification date.	report
#BGCOLOR#	Sets the background colour to "E0E0E0" for web reports and to "FFFFFF" for email.	header, report
#Email#	Available for email only and inserts the email address of the people to be notified.	category, header
#FirstName#	Available for email only and inserts Firstname.	category, header

How to set up access to view web notifications

Access to the web notifications is set up through the eparties database. In order for a user to be able to view notifications, the Add EMuUserId field must be filled with the user's login id. The View Notification Admin Task checks the current user's id against the eparties database to determine the user's name and then displays any notifications they have in their default browser.

Troubleshooting

A user cannot access their web notifications

There are two possible explanations for this. The first is that they do not have any for the week. The server cleans up old HTML files that are more than seven days old. If a user does not have any notifications for a week, their file will no longer exist.

The second is that their user id has not been recorded in their Parties record.

A user is not receiving their notification email

The first thing to check is that the user's Parties record has an email address. If an address exists, a log exists in the logs/notify directory that may help determine why the email failed. The logfile is named yyyy-mm-dd and the most recent week's worth of logs is stored on the server.

A likely reason for failure is that the sendemail script is unable to find sendmail on the smtp server. As a default it tries to connect to localhost unless the environment variable SMTPSERVER is set. It attempts to create a socket connection to sendmail on the smtp server. This could fail if the network does not allow access to that machine (try pinging it) or if the machine name supplied as the SMTPSERVER is incorrect. It could also fail if the network firewall is blocking connections to sendmail. Try to telnet to port 25 on the SMTPSERVER to ensure that it is possible to connect to sendmail.

My web pages are not displaying the EMu record information correctly

The most likely reason for this is a typing error. Check that each of the #ItemName# settings correctly accesses a defined column name from the back-end and ensure that any nested tables have the _tab extension on the column name.

My web pages do not display correctly

The most likely reason for this is an HTML formatting error. View the source of the displayed page to determine the error and then correct it.

1. Open a command line session on the EMu server and log in with the username emu.
2. Type client [client] to go to the required EMu client environment.
3. Type cd etc
4. Type mkdir -p ../local/etc
5. Type cp crontab ../local/etc
6. Type cd ../local/etc
7. Type vi crontab

   Make changes as required.

8. Type emu cron -i

1. Open a command line session on the EMu server and log in with the username emu .
2. Type client [client] to go to the required EMu client environment.
3. Type cd etc
4. Type vi logging
5. Edit the logging file with the required delivery details for each maintenance report. For example:

   # Standard KE EMu daemons

   batch mailto:admin@kesoftware.com

   file:logs/batch/%year-%month-%day

   reindex mailto:admin@kesoftware.com

   file:logs/reindex/%year-%month-%day

   Note: A maintenance report can be emailed to a specific address; saved as a text report in a specified directory; or printed directly on a specified printer.

6. Save the logging file.

   Note: By default, each report is automatically copied into an appropriate sub-directory of the logs directory. Retain these files for a history of the reports logged.