2.1. La fenêtre de message IDERI note

Le client IDERI note (IDERI note Client) est un programme (inotecln.exe) qui est généralement exécuté dans le contexte d’un utilisateur connecté de manière interactive. La configuration par défaut démarrera le programme client immédiatement après la connexion via la clé de registre suivante :

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

Le programme client se connecte à intervalles réguliers à son serveur IDERI note afin de récupérer les dernières mises à jour des messages que l’utilisateur, sous les auspices duquel le programme client s’exécute, est autorisé à recevoir. L’intervalle d’interrogation utilisé pour ces connexions périodiques au serveur est généralement compris entre une et plusieurs minutes, la valeur par défaut étant 5 minutes. Le client met en scène les messages reçus du serveur dans des bases de données locales par utilisateur et attend que l’un des messages soit dû. Si un message arrive à échéance, un processus est généré et affichera le message à l’utilisateur connecté. L’utilisateur peut alors reconnaître avoir lu le message ou annuler le message. Dans les deux cas, le message disparaîtra de l’écran de l’utilisateur, et si d’autres messages sont dus, le message suivant s’affichera. La figure 2.1 montre un exemple de message d’alerte sur le bureau d’un utilisateur.

Figure 2.1: Exemple d’un message d’alerte

Le programme client veille à ce qu’au maximum un message soit affiché à l’utilisateur et que les messages les plus importants soient affichés à l’utilisateur en premier. Cela signifie que si plusieurs messages sont dus en même temps, les messages d’alerte seront affichés en premier, puis les messages d’avertissement et enfin les messages d’information.

Si un utilisateur annule un message en cliquant sur la croix située dans le coin supérieur droit du message, il réapparaîtra après la prochaine connexion du client au serveur, dans le cas où le message serait toujours valide. Un message peut devenir invalide pour plusieurs raisons : la fin de sa durée de validité peut avoir été atteinte, ou l’utilisateur peut avoir été supprimé de la liste des destinataires du message ou le message peut avoir été supprimé par un administrateur. Si un utilisateur reconnaît avoir lu le message en cliquant sur le lien intitulé « J’ai lu le message », il n’apparaîtra plus, sauf s’il est modifié par un utilisateur administratif et est donc reçu par le programme client pour une nouvelle révision. Selon la configuration du message qui a été effectuée précédemment par le créateur du message, un accusé de réception confirmant que l’utilisateur a lu le message est renvoyé au serveur lorsque le programme client se reconnecte à son serveur. De la même manière, un message peut être configuré pour être confirmé comme ayant été reçu et affiché sur le client immédiatement après sa réception. Les messages créés avec cette option d’accusé de réception peuvent toujours être affichés sur le client après coup à l’aide de l’application d’historique client IDERI note. L’application d’historique peut être lancée par l’utilisateur à l’aide du menu contextuel qui apparaît en haut de l’icône de la zone de notification du système client IDERI note.

En plus de ce modèle « pull », où un client interroge le serveur à intervalles réguliers pour de nouveaux messages, un modèle de type « push » peut être configuré pour « pousser » des messages d’alerte, qui nécessitent une attention immédiate des utilisateurs, vers le client des ordinateurs. Pour que cela fonctionne, les composants Client doivent être configurés pour démarrer un serveur RPC que le serveur peut contacter directement. De plus, les restrictions sur le pare-feu local de l’ordinateur Client doivent être quelque peu assouplies afin de permettre les connexions entrantes aux « Services de fichiers et d’impression ». Étant donné qu’une telle configuration peut interférer avec les politiques de sécurité de l’entreprise pour les ordinateurs Client, le modèle « push » n’est pas une exigence. Cependant, le modèle « pull » est la configuration standard que le programme client réutilise pour recevoir des messages de son serveur. D’un autre côté, de nombreuses configurations de client d’entreprise ont explicitement ces restrictions de pare-feu déjà assouplies car sinon les capacités d’administration à distance comme le registre distant, l’accès aux services à distance, WMI et DCOM ne fonctionneraient pas aussi bien.