Tâches de maintenance planifiées
EMu comprend une suite d'utilitaires conçus pour assurer le bon fonctionnement du système. L'exécution des tâches de maintenance est planifiée à l'aide du programme Crontab.
Crontab est un planificateur de tâches utilisé par les administrateurs du système EMu pour réaliser des maintenances régulières et d'autres tâches.
Une entrée Crontab comprend six champs (séparés par un espace) dans l'ordre suivant :
Entrée Crontab |
Toutes les valeurs possibles |
---|---|
Minute |
0 to 59 |
Heure |
0 à 23 |
Jour du mois |
1 à 31 |
Mois |
1 à 12 |
Jour de la semaine |
0 à 6 (où dimanche = 0) |
Commande |
Une commande exécutée par l'invite de commande au moment spécifié |
Un exemple d'entrée Crontab est :
|
Un astérisque (*) peut se substituer à n'importe quels champs date/heure et représente toutes les valeurs possibles pour ce champ. Donc, * dans le champ Jour du mois signifie que la tâche doit s'exécuter chaque jour du mois.
Un champ peut aussi contenir un jeu de nombres séparés par des virgules ou une plage de nombres séparés par un signe moins (ex. 1-5 dans le champ Jour de la semaine).
Note: Pour éditer le fichier Crontab, il faut se connecter avec le nom d'utilisateur emu et ouvrir une cession de lignes de commandes sur le serveur EMu.
Les tâches de maintenance sont faites pour permettre au système de fonctionner aussi bien que possible. Les administrateurs du Système déterminent quelles tâches doivent être lancées et quand.
Les tâches de maintenance courantes d'EMu sont :
L'exécution de cette tâche complète l'indexation des nouveaux enregistrements et des enregistrements modifiés.
Note: Pour garantir un traitement rapide des opérations, un enregistrement n'est que partiellement indexé lors de son édition ou de son insertion. Les enregistrements partiellement indexés apparaissent comme des enregistrements complètement indexés pour les utilisateurs.
Typiquement cette tâche est lancée quotidiennement du Lundi au Vendredi.
L'exécution de cette tâche reconstruit tous les index et compresse les données, supprime les enregistrements obsolètes qui ont été marqués pour suppression et laissés après l'édition de l'enregistrement.
Note: La taille des modules Audit et Statistiques augmentera au fur et à mesure que des enregistrements y seront ajoutés. Puisque les deux modules ont un nombre très faible / inexistant de modifications d'enregistrement, il n'est pas nécessaire de compacter ces tables dans le cadre du programme de maintenance hebdomadaire. L’option COMPACT="no" peut être ajoutée au fichier emuoptions d'un module (stocké dans le répertoire des modules sur le serveur EMu) pour passer le compactage du module lors de la maintenance.
Cette tâche peut également être exécutée manuellement. Voir Comment réindexer une table pour plus de détails.
L'exécution de cette tâche supprime les vieux rapports qui ont été générés lors de l'exécution des tâches de maintenance gérées par Crontab. Les Administrateurs du Système déterminent le nombre de jours pendant lesquels ces rapports sont conservés.
Typiquement cette tâche est lancée quotidiennement du Lundi au Vendredi.
L'exécution de cette tâche contrôle le statut de chaque table d'EMu et produit un rapport.
Ce rapport devrait être contrôle tous les jours pour s'assurer que toutes les tables sont en lignes et que les tâches de maintenance ont été réalisées avec succès.
Les champs de notification sont utilisés pour informer les utilisateurs qu’un élément requiert leur attention. Ils sont inclus dans de nombreux modules EMu (notamment les modules Prêts/Emprunts, Événements, Assurance et Déplacements, et tout module avec un onglet Tâches) et sont utilisés pour envoyer une notification par e-mail à une ou plusieurs personnes à une date prédéterminée. Dans le module Prêts/Emprunts, par exemple, des dates de notification de commencement et de fin peuvent être spécifiées pour un prêt/emprunt ; le gestionnaire des prêts/emprunts reçoit automatiquement une notification par e-mail concernant le prêt/emprunt à ces dates.
Une notification comprend trois composants :
- La date à laquelle les personnes doivent recevoir une notification.
- Les personnes à notifier.
- Le rapport à envoyer comme notification.
La date et les personnes à notifier sont spécifiées par l'utilisateur dans le module concerné (Emprunts par exemple) ; les rapports sont indépendants des modules et sont construits à partir de fichiers variés.
Pour générer des rapports de notification, le script emunotify est exécuté ; il analyse tous les champs de notification et génère des fichiers HTML et un e-mail pour toutes les personnes spécifiées pour toute notification ayant atteint son heure et sa date d'échéance. L'e-mail est envoyé et les fichiers HTML sont laissés sur le serveur pour consultation par un utilisateur via la tâche Administrateur Voir les notifications.
Typiquement cette tâche est lancée quotidiennement du Lundi au Vendredi.
Deux choses doivent être faites pour ajouter une notification locale :
- L'information à propos de la notification doit être incluse dans le fichier notify.pl qui est dans le répertoire local/etc/notify. Voir Format du Fichier Inclus pour plus de détails.
- Les fichiers qui seront utilisés dans le rapport doivent être générés. Ces fichiers doivent être placés dans le répertoire local/etc/notify/en. Ce sont des fichiers HTML qui peuvent s'afficher sur le web et être envoyés par courriel sans requérir de traitements séparés
L'exemple suivant est utilisé pour les Restaurations :
<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>
Les données sont prises dans chaque enregistrement d'EMu et insérées dans des sections #Nom d'item# (ex. #irn#) du document.
Le format du Fichier inclus local (local/etc/notify/notify.pl
) est le suivant :
@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],
},
{
......
},
);
L'explication de chaque champ est :
Nom du champ |
Explication |
---|---|
|
La base de données où rechercher la notification. |
|
Le champ qui contient les références des personnes à notifier dans les enregistrements Personnes / Organisations. |
|
Si |
|
Le champ de date à consulter pour le comparer à la date de notification. |
|
Le champ à contrôler pour déterminer si cette action est terminée. |
|
Le corps du texte à utiliser pour les notifications correspondantes. |
|
L'en-tête du rapport à placer au-dessus du corps du rapport pour chaque correspondance de notification. |
|
Un titre général à placer au-dessus de tous les rapports générés pour ce champ de date et pour cette base de données. |
|
Les champs de données de l'enregistrement qui sont utilisés pour le rapport de notification. |
|
La routine qui met au bon format le champ date avant de l'insérer dans le rapport. Chaque champ de données doit avoir sa routine de format. |
Le rapport pour l'utilisateur est mis en forme comme suit :
category
header
report
header
report
....
Les routines de formats suivantes sont définies pour les champs de données :
Format |
Action |
---|---|
|
Ne change pas le champ de données. |
|
Compte le nombre de valeurs dans ce champ. |
|
Formate les noms de cette façon : Titre Prénom Initiale_du_second_prénom Nom de famille. Si c'est vide, utilise le champ Organisation. |
|
Formate l'adresse comme : |
|
Formate la date dans l'ordre spécifié dans les variables d'environnement texpress dateorder. |
|
Formate le contenu des tables imbriquées où |
|
Formate le contenu d'une table de référence partiellement imbriquée en utilisant les formats |
Des marqueurs spéciaux ont été définis pour copier des informations contenues dans un enregistrement vers un fichier :
Marqueur |
Données |
Section du rapport disponible dans |
---|---|---|
|
Prénom Nom de Famille. |
catégorie, en-tête |
|
La date du rapport. C'est une plage de dates (ex. une semaine) pour un rapport web et un jour seul pour un courriel. |
catégorie, en-tête |
|
La dernière date de la plage de dates pour ce rapport. |
catégorie, en-tête |
|
La base de données dont le rapport est issue. |
entête, rapport |
|
La date de notification. |
report |
|
Règle la couleur de fond à "E0E0E0" pour les rapports web et à "FFFFFF" pour les courriels. |
entête, rapport |
|
Disponible pour les courriels seulement, insère l'adresse électronique des personnes à notifier. |
catégorie, en-tête |
|
Disponible pour les courriels seulement, insère le prénom. |
catégorie, en-tête |
L'accès aux notifications web est paramétré via la base de données eparties. Pour qu'un utilisateur puisse voir les notifications, le champ Ajouter EMuUserId doit être rempli avec l'identifiant de connexion de l'utilisateur. La tâche Admin Voir Notification vérifie l'identifiant de l'utilisateur actuel dans la base de données eparties pour déterminer son nom, puis affiche toutes ses notifications dans son navigateur par défaut.
Il y a deux explications possibles pour cela. La première est que l'utilisateur n'en a pas pour la semaine concernée. Le serveur supprime les vieux fichiers HTML qui ont plus de sept jours. Donc, si un utilisateur n'a pas de notification pendant une semaine, ses fichiers n'existeront plus.
Le second est que l'utilisateur n'a pas été enregistré dans l'enregistrement Personnes / Organisations.
La première chose à contrôler est que l'enregistrement de cet utilisateur dans Personnes / Organisations a bien une adresse pour les courriels. Si une adresse existe, un fichier log existe dans le répertoire logs/notify
qui peut aider à déterminer pourquoi le courriel a échoué. Le fichier log s'appelle aaaa-mm-jj et les fichiers logs de la semaine la plus récente sont stockés sur le serveur.
Une raison probable de l'échec est que le script sendemail est incapable de trouver sendmail sur le serveur smtp. Par défaut, il tente de se connecter à localhost, sauf si la variable d'environnement SMTPSERVER est définie. Il tente de créer une connexion socket à sendmail sur le serveur smtp. Cela peut échouer si le réseau n'autorise pas l'accès à cette machine (essayez de lui envoyer une requête ping) ou si le nom de la machine fourni comme SMTPSERVER est incorrect. Il peut également échouer si le pare-feu du réseau bloque les connexions à sendmail. Essayez de faire un telnet sur le port 25 de SMTPSERVER pour vous assurer qu'il est possible de se connecter à sendmail.
La raison la plus probable est une faute de frappe. Vérifiez que chacun des paramètres #ItemName#
accède correctement à un nom de colonne défini dans le back-end et assurez-vous que toutes les tables imbriquées possèdent l'extension _tab sur le nom de la colonne.
La raison la plus probable pour cela est une erreur de format HTML. Visualiser la source de l'image affichée pour déterminer l'erreur et la corriger.
Chaque tâche de maintenance génère un résumé.
- Ouvrir une cession de lignes de commandes sur le serveur EMu et se connecter avec le nom d'utilisateur emu.
- Taper
client [client]
pour accéder à l'environnement du client d'EMu. - Taper
cd etc
- Taper
mkdir -p ../local/etc
- Taper
cp crontab ../local/etc
- Taper
cd ../local/etc
- Taper
vi crontab
Réaliser les changements requis.
- Taper
emu cron -i
- Ouvrir une cession de lignes de commandes sur le serveur EMu et se connecter avec le nom d'utilisateur emu.
- Taper
client [client]
pour accéder à l'environnement du client d'EMu. - Taper
cd etc
- Taper
vi logging
- Éditer le fichier de log avec les détails requis sur la livraison pour chaque rapport de maintenance. Par exemple :
# 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: Un rapport de maintenance peut être envoyé par courriel à une adresse spécifique ; sauvegardé comme un rapport au format text dans répertoire spécifié ; ou directement imprimé sur une imprimante spécifiée.
- Sauvegardez le fichier de journalisation.
Note: Par défaut, chaque rapport est automatiquement copié dans un sous-répertoire du répertoire des journaux. Conservez ces fichiers pour avoir un historique des rapports enregistrés.
Note: La tâche de maintenance Reconstruire les listes de consultation a été remplacée par un service Maintenance des listes de consultation en arrière-plan depuis EMu 4.1.