Agendas et planification

En tant qu'administrateur, vous pouvez définir des jours fériés propres à votre société ou à votre pays. HCL Domino® est livré avec un jeu de documents Congés par défaut que vous pouvez modifier. Les utilisateurs importent ensuite directement ces informations dans leur agenda personnel.

Les fonctions d'agenda et de planning font appel à la fonction Schedule Manager (ou tâche Sched), à la fonction Calendar Connector (ou tâche Calconn) et au système de disponibilités (combinaison des tâches Sched, Calconn et nnotes). Quand vous installez Domino® sur un serveur quelconque (serveur d'annuaires excepté), les tâches Sched et Calconn sont automatiquement ajoutées au fichier NOTES.INI du serveur. Quand vous démarrez le serveur pour la première fois, la fonction Schedule Manager crée une base Disponibilités (BUSYTIME.NSF s'il s'agit d'un serveur de messagerie extérieur à une grappe ou CLUBUSY.NSF dans le cas d'un serveur de messagerie membre d'une grappe) et crée une entrée dans la base pour chaque utilisateur ayant rempli un profil d'agenda (à condition que son fichier courrier figure sur ce serveur ou sur l'un des serveurs de la grappe).

Chaque utilisateur peut disposer d'un agenda personnel et créer un profil d'agenda pour spécifier les personnes autorisées à consulter ses disponibilités en vue de la planification de réunions. Lorsque des utilisateurs invitent d'autres utilisateurs à des réunions, le système de disponibilités effectue des recherches de disponibilités. Il recherche également des informations relatives à la disponibilité des ressources. S'il est nécessaire d'effectuer une recherche dans les systèmes de disponibilités sur différents serveurs ou applications de planification, Calendar Connector se charge de l'envoi des requêtes. Lorsque des utilisateurs prévoient des rendez-vous dans leurs agendas et réservent des ressources, la tâche Schedule Manager rassemble et met à jour ces informations dans la base Disponibilités.

Par défaut, Schedule Manager a accès à la base Disponibilités. Vous n'avez donc pas besoin de définir de LCA pour cette base de documents.

Utilisation de la planification en grappe

La fonction Schedule Manager crée la base Disponibilités de la grappe (CLUBUSY.NSF) au premier démarrage d'un serveur de messagerie membre de la grappe. La version en grappe de la base fonctionne exactement de la même façon que la base Disponibilités (BUSYTIME.NSF). Chaque serveur en grappe dispose d'une réplique de la base Disponibilités, où se trouvent les informations relatives aux utilisateurs dont les fichiers courrier figurent sur des serveurs de la grappe.

Si vous ajoutez à une grappe un serveur n'ayant jamais appartenu à une grappe, Schedule Manager supprime la base de données BUSYTIME.NSF de ce serveur et crée CLUBUSY.NSF, qui est ensuite répliquée sur tous les membres de la grappe. Si vous retirez un serveur d'une grappe, Schedule Manager supprime la base CLUBUSY.NSF et la remplace par BUSYTIME.NSF. Tant que Schedule Manager ne valide pas la base de documents en vérifiant si l'emplacement des fichiers courrier des utilisateurs a changé, la base Disponibilités de la grappe contient des informations relatives aux utilisateurs dont le serveur de messagerie a été supprimé de la grappe. Ce processus de validation survient également une fois par jour (à 2 heures du matin) afin d'actualiser les informations sur les disponibilités des utilisateurs dont les fichiers courrier ont été ajoutés ou supprimés d'un serveur de messagerie. Vous avez la possibilité de mettre à jour ces informations à tout moment en entrant la commande Tell Sched Validate sur la console.

La planification en grappe a l'avantage d'offrir un accès permanent aux informations de planification, même lorsqu'un serveur hôte utilisateur est arrêté. Si vous planifiez des informations à partir de serveurs n'appartenant pas à une grappe et qu'un serveur hôte n'est pas disponible, les utilisateurs de ce dernier ne peuvent pas accéder à la base Disponibilités pour effectuer une recherche.

L'amélioration des performances et la réduction du trafic au niveau du serveur comptent parmi les autres avantages de la planification en grappe. La base Disponibilités étant accessible à tous les membres d'une grappe, le serveur qui reçoit la requête d'un utilisateur dont le serveur de messagerie appartient à la grappe n'a pas besoin d'effectuer une recherche sur un autre serveur pour trouver le planning de cet utilisateur.

Planification d'une réunion

Cette rubrique présente le processus de planification d'une réunion dans trois cas : lorsque les utilisateurs appartiennent à un même domaine et disposent d'un même serveur de messagerie, lorsqu'ils se trouvent dans des domaines distincts et lorsqu'ils exploitent d'autres applications de planning.

Dans les exemples suivants, Cathy souhaite connaître les disponibilités de trois utilisateurs afin d'organiser une réunion : Robert, qui est dans le même domaine que Cathy, Robin, qui est dans un autre domaine, et Suzanne, qui utilise une autre application de planification.

Utilisateurs membres du même domaine

1. Cathy crée une invitation et décide de s'informer des disponibilités de Robert.
2. Une requête de disponibilités est envoyée au serveur de messagerie de Cathy.
3. Le système des disponibilités recherche le nom de Robert dans la base Disponibilités (BUSYTIME.NSF ou CLUBUSY.NSF) du serveur de messagerie de Cathy.
   • Si Robert et Cathy utilisent le même serveur de messagerie ou des serveurs appartenant à la même grappe, le système de disponibilités recherche les informations sur les disponibilités de Robert et les renvoie à Cathy.
   • Si le système de disponibilités ne trouve aucune information sur Robert, il convertit le nom de Robert en nom complet.
   • Si le serveur de messagerie de Robert n'est pas disponible et que sa base Disponibilités ne fait pas partie d'une grappe, un message indiquant que le serveur n'est pas disponible s'affiche et la boîte de dialogue Disponibilités signale que les informations concernant Robert sont inaccessibles.
4. Le document Personne de Robert est recherché dans l'annuaire Domino® de Cathy. Une fois le document trouvé, Calendar Connector envoie la requête au serveur de messagerie de Robert, dont le nom est répertorié dans le document Personne de Robert.
5. Le système de disponibilités du serveur de messagerie de Robert effectue une recherche dans sa base Disponibilités et renvoie les informations à Cathy via Calendar Connector. Si le système ne trouve aucune information, la requête échoue et la boîte de dialogue Disponibilités indique que les informations relatives à Robert sont inaccessibles.

Utilisateurs appartenant à des domaines distincts

1. Cathy crée une invitation et décide de s'informer des disponibilités de Robin. Elle précise en outre le domaine de Robin dans l'invitation.
2. Une requête est envoyée au serveur de messagerie de Cathy.
3. Le système de disponibilités recherche le nom de Robin dans la base Disponibilités du serveur de messagerie de Cathy. Il constate que le serveur de messagerie de Robin se trouve dans un autre domaine.
4. Le système recherche un document correspondant au domaine de Robin dans l'annuaire Domino® de Cathy.
   • Si le système trouve un document de domaine adjacent, il recherche dans le champ Nom du serveur d'agenda le nom d'un serveur qui accepte les requêtes d'agenda pour le domaine de Robin. Le système de disponibilités transfère alors la requête au serveur pour qu'elle soit traitée.
   • S'il trouve un document de domaine adjacent dont le champ Nom du serveur d'agenda est vide, la demande échoue et la boîte de dialogue Disponibilités indique que les informations relatives à Robin sont inaccessibles.
   • S'il trouve un document de domaine non adjacent, il recherche dans le champ Acheminer les demandes via le serveur d'agenda du document le nom du serveur (résidant dans un domaine adjacent à celui de Cathy et Robin) qui accepte les requêtes d'agenda pour le domaine de Robin. Le système de disponibilités transfère alors la requête au serveur pour qu'elle soit traitée.
   • S'il trouve un document de domaine non adjacent dont le champ Acheminer les demandes via le serveur d'agenda est vide, la demande échoue et la boîte de dialogue Disponibilités indique que les informations relatives à Robin sont inaccessibles.
   • S'il ne trouve aucun document Domaine, la requête échoue et la boîte de dialogue Disponibilités indique que les informations relatives à Robin sont inaccessibles.

Utilisateurs appartenant à des domaines d'agenda distincts

1. Cathy crée une invitation et décide de s'informer des disponibilités de Suzanne.
2. Une requête est envoyée au serveur de messagerie de Cathy.
3. Le système de disponibilités recherche le nom de Suzanne dans sa base Disponibilités. Ne le trouvant pas, il convertit le nom de Suzanne en nom complet.
4. Le document Personne de Suzanne est recherché dans l'annuaire Domino® de Cathy.
5. Le système de disponibilités consulte le document Personne de Suzanne et identifie le nom de son serveur de messagerie dans le champ Serveur de messagerie ainsi que le nom de son domaine d'agenda dans le champ Domaine d'agenda.
6. Suzanne utilisant Lotus Organizer, le système de disponibilités détecte que son domaine d'agenda ne correspond pas à son domaine de serveur de messagerie. Il recherche alors un document Domaine pour le domaine d'agenda.
7. Le système de disponibilités détecte un document de domaine étranger pour le domaine d'agenda de Suzanne. Le champ Serveur d'agenda du document de domaine étranger identifie le nom du serveur qui accepte les requêtes pour le domaine de Suzanne ; le champ Système d'agenda identifie le nom de l'application utilisée, qui exécute effectivement la recherche de disponibilités sur le serveur de Suzanne. Le système de disponibilités envoie la requête au serveur approprié (celui qui est indiqué dans le champ Serveur d'agenda) pour qu'elle soit traitée.

Si le système de disponibilités ne trouve aucun document de domaine étranger, la requête échoue et la boîte de dialogue Disponibilités indique que les informations relatives à Suzanne sont inaccessibles.