4.2. Das Anlegen der ersten Nachricht in IDERI note Administrator¶
Wir werden nun unsere erste Nachricht anlegen. Wir möchten, dass ein bestimmter Benutzer in der Domäne note.dev mit dem Namen “Albert.Tross” diese Nachricht erhält. Dazu betätigen wir nun in der Multifunktionsleiste die Schaltfläche “Neu” im Feld “Nachrichten” auf dem Reiter “Start”. Es erscheint dann ein Dialog wie in Abbildung 4.3.
Wir fügen den einfachen Text “Hallo Albert!” in das Nachrichtentextfeld ein und ändern das Endedatum der Nachricht auf einen Wert, der in der Zukunft liegt. Um den Empfänger der Nachricht zu bestimmen, führen wir einen Doppelklick auf das mit “Empfänger” beschriftetet Steuerelement. Dort können wir nun den Namen des Empfängers in der Notation Domänenname\Benutzername, also note.dev\albert.tross eintragen. Alternativ können wir in dieser Eingabezeile auch die mit der Ellipsis (”...”) beschriftete Schaltfäche betätigen. Es erscheint dann der Standarddialog für die Auswahl von Benutzern und Gruppen, wie in Abbildung 4.4.
Dort können wir nun einfach “Albert.Tross” eintragen oder nach diesem Benutzer unter den in der Domäne note.dev bekannten Benutzern suchen.
Nach dem Betätigen der Schaltfläche “OK” wird dann der Name des Empfängers in das Steuerelement für die Empfänger eingefügt. Wir kreuzen auch die beiden Häkchen “Empfang an Server zurückmelden” und “Quittierung an Server zurückmelden” unter “Einstellungen:” an.
Diese beiden Einstellungen bewirken, dass der Client, der die Nachricht empfängt, Rückmeldungen schickt, sobald er die Nachricht empfangen hat und nachdem der Benutzer bestätigt hat, die Nachricht gelesen zu haben. Der Bildschirm sieht dann aus wie in Abbildung 4.5.
Nach Betätigen der Schaltfläche “OK” wird nun die Nachricht angelegt. Abbildung 4.6 zeigt den Bildschirm, nachdem die erste Nachricht angelegt wurde.
Lohnenswert ist nun, die Eigenschaften der Nachricht, die wir gerade angelegt haben, genauer anzuschauen. Dazu wählen wir die Nachricht an und betätigen dann in der Multifunktionsleiste die Schaltfläche “Eigenschaften” im Feld “Nachrichten” auf dem Reiter “Start”. Dies ruft den Eigenschaftsdialog der Nachricht auf. Die erste Seite des Eigenschaftsdialogs der Nachricht wird dabei zuerst angezeigt und sieht in etwa wie in Abbildung 4.7 aus.
Es ist erkennbar, dass diese Seite praktisch alle relevanten Daten der Nachricht im Nur-Lese-Format beinhaltet.
Zusätzlich sind alle Zeitangaben auch im UTC-Format(Coordinated Universal Time) angegeben. Im Zweifelsfall kann man also hier die lokalen Zeitangaben mit denen in UTC vergleichen. Zu beachten ist, dass intern der IDERI note Server Zeitangaben immer in UTC speichert und der IDERI note Client intern auch nur mit UTC arbeitet. Die Zeitangaben, die man jedoch im Nachrichtendialog des IDERI note Administrator macht, sind immer in lokaler Zeit. Der IDERI note Administrator weiss, in welcher Zeitzone er läuft und ob Sommerzeit aktiv ist. Vor dem Speichern benutzt er die relevanten Informationen über die Zeitzone und aktiver Sommerzeit und konvertiert die Zeitangaben in lokaler Zeit nach UTC und speichert die Daten in diesem Format auf dem Server. Dies hat Auswirkungen, wenn der IDERI note Administrator auf einem Rechner mit einer anderen Zeitzone betrieben wird, als die Clientrechner. Beispiel: Der IDERI note Administrator wird in der Firmenhauptstelle in USA betrieben und es soll eine Nachricht erzeugt werden, die am nächsten Morgen bei den Benutzern der deutschen Niederlassung um 9.00h lokaler Zeit erscheinen soll.
Dann ist es empfehlenswert, auf dem Rechner, auf dem der IDERI note Administrator betrieben wird, temporär die Zeitzone auf die der deutschen Clients umzustellen und damit dann die Nachricht für 9.00h morgens anzulegen, oder die erforderlichen Umrechnungen müssen selbst vorgenommen werden. Im letzteren Fall helfen die Zeitangaben auf der Eigenschaftsseite in UTC, die Umrechnungen zu verifizieren.
Weit wichtiger ist jedoch die zweite Seite des Eigenschaftsdialogs.
Durch Anwahl des Reiters “Sicherheit” wird die Seite mit den Sicherheitseinstellungen der Nachricht aufgerufen (Abbildung 4.8).
Diese Seite zeigt die Sicherheitseinstellungen der neuen Nachricht. Beachten Sie, dass der Erzeuger der Nachricht, Adam.Sam, volle Zugriffsrechte auf die Nachricht hat, abgesehen vom Zugriffsrecht “Nachricht empfangen”. Wir wählen nun den Benutzer “Albert.Tross” in diesem Dialog an, um die Zugriffsrechte dieses Benutzers zu betrachten (Abbildung 4.9).
Beachten Sie, dass der Empfänger der Nachricht, Albert.Tross, nur ein einzelnes Zugriffsrecht besitzt, nämlich das Recht, die Nachricht zu empfangen.
Dies ist das wichtigste Prinzip in IDERI note: Die Berechtigung, eine Nachricht zu empfangen, ist als Zugriffsrecht auf eine Ressource modelliert, so wie man auch den Zugriff auf andere Ressourcen wie Dateien, Registrierdatenbankschlüssel, etc. auf einem NT-basierten Windows®-System gestatten oder verweigern kann. Mit diesem Modell ist es ausserordentlich einfach, Empfänger für eine Nachricht auszuwählen, indem einzelnen Benutzern oder Gruppen das Zugriffsrecht “Nachricht empfangen” zugeteilt oder verweigert wird.
Achtung
Gruppen als Nachrichtenempfänger
Gruppen, die im AD ausgewählt werden können um ein Zugriffsrecht zu einer IDERI note Nachricht erteilt oder verweigert zu bekommen, beispielsweise das Recht, die Nachricht zu empfangen, müssen globale Gruppen sein, oder können im Fall einer nativen Domäne (im Gegensatz zu einer Domäne im Mischmodus), auch domänenlokale Gruppen oder universelle Gruppen sein. Sowohl in einem AD wie auch in einer Arbeitsgruppenumgebung können auch eingebaute Gruppen und lokale Gruppen des Rechners, auf dem der IDERI note Server läuft, ausgewählt werden. Während jedoch in einer Arbeitsgruppenumgebung lokale Gruppen des IDERI note Servers die einzig verwendbaren Gruppen (neben eingebauten Gruppen) sind, sollten lokale Gruppen des IDERI note Servers in einem AD nicht verwendet werden. Dies wird deshalb nicht empfohlen, weil die SIDs (Security Identifiers), die diese lokalen Gruppen repräsentieren, nur auf dem entsprechenden IDERI note Server gültig sind und bedeutungslos werden, falls die IDERI note Datenbankdateien jemals auf einen anderen Rechner umgezogen werden müssen. Active Directory® Verteilerlisten können nicht als Nachrichtenempfänger verwendet werden, weil Verteilerlisten niemals Teil eines Benutzertokens sind, der die Datenstruktur darstellt, mit der ein Benutzer identifiziert wird und der seine Gruppenmitgliedschaftsinformationen enthält. Das sollte jedoch kaum überraschend sein, da aus dem gleichen Grund andere Ressourcen im AD, wie beispielsweise Dateien, Freigaben, Registrierdatenbankschlüssel etc. auch nicht auf Verteilerlisten berechtigt werden können. Eine begrenzte Unterstützung von Active Directory® Verteilerlisten ist allerdings geplant für ein späteres Release von IDERI note.
Einem aufmerksamen Leser könnte an dieser Stelle die Frage kommen, wo die anderen Benutzer und Gruppen, die auf der Seite mit den Sicherheitseinstellungen der Nachricht aufgelistet sind, herkommen. Bevor wir diese Frage im nächsten Abschnitt beantworten, beobachten wir nun, was passiert, wenn sich Albert.Tross nun an der Workstation Client01 interaktiv anmeldet. Kurz nach der Anmeldung des Benutzers wird nun die Nachricht, die wir gerade auf dem Server erzeugt haben, vom Server geladen und eine Ansicht wie in Abbildung 4.10 wird auf dem Desktop von Albert.Tross angezeigt.
Beachten Sie, dass der Ersteller der Nachricht, “note\adam.sam”, auch in diesem Fenster angezeigt wird, weshalb die Benutzer auch immer wissen, wer eine Nachricht, die sie empfangen haben, angelegt oder zuletzt bearbeitet hat.
Wenn wir uns nun wieder der Workstation Admin01 zuwenden, wo wir unlängst die erste Nachricht angelegt haben, und dort in IDERI note Administrator F5 betätigen, dann aktualisiert das Programm seine Darstellung und wir werden in der unteren Hälfte erkennen, dass der IDERI note Client auf Client01, wo sich Albert.Tross angemeldet hat, die Rückmeldung geschickt hat, die Nachricht empfangen zu haben. Abbildung 4.11 zeigt eine einzelne Zeile in der unteren Ansicht mit einem Briefsymbol, zusammen mit dem Rechnernamen und Benutzernamen und dem Empfangszeitpunkt auf dem Client und dem Rückmeldezeitpunkt auf dem Server.
Wenn wir die Zeitpunkte des Nachrichtenempfangs und der Rückmeldung genauer anschauen, stellen wir fest, dass offenbar die Rückmeldung vor dem Nachrichtenempfang stattfand. Die Erklärung für diesen scheinbaren Widerspruch ist aber ganz einfach: Der Zeitpunkt des Nachrichtenempfangs ist der Zeitpunkt auf dem Client, an dem er die Nachricht empfängt und ist abgeleitet von dem Uhrenbaustein auf dem Clientrechner. Nach Empfang der Nachricht sendet der Client diesen Zeitstempel an den Server zurück, der beim Empfang die eigene Uhrzeit ermittelt und diese natürlich von seinem eigenen Uhrenbaustein ableitet. Was wir hier also sehen sind Auswirkungen der Zeitabweichung zwischen den Uhrenbausteinen zweier Rechner. Diese zwei Zeitstempel, die mit der Empfangsrückmeldung verbunden sind, sollten jedoch in der Regel immer relativ nahe beieinander liegen.
Wir nehmen nun weiterhin an, dass Albert.Tross, der gerade die Nachricht auf seinem Bildschirm bemerkt hat, den Link “Habe ich gelesen” auf dem Nachrichtenfenster anklickt. Der unmittelbare Effekt für Albert.Tross wird sein, dass die Nachricht nun wieder von seinem Bildschirm verschwindet. Der IDERI note Client, der auf seinem Desktop läuft, wird sich aber nach Ablauf des bei der Installation angegebenen Pollingintervalls wieder mit dem IDERI note Server verbinden.
Im Rahmen dieser Verbindungsaufnahme wird er aber nicht nur neue Nachrichten für Albert.Tross laden, sofern vorhanden, sondern er wird auch alle Quittierungsrückmeldungen zurückschicken. Wenn wir uns also nun wieder der administrativen Arbeitsstation zuwenden, auf der der IDERI note Administrator läuft, und einige Minuten warten und dann F5 betätigen um die Darstellung zu aktualisieren, werden wir die Quittierungsrückmeldung wie in Abbildung 4.12 bemerken.
Ähnlich der Empfangsrückmeldung hat die Quittierungsrückmeldung auch einen clientbezogenen Zeitstempel und einen serverbezogenen Zeitstempel. Und auch hier ist der clientbezogene Zeitstempel vom Uhrenbaustein des Clients abgeleitet und der serverbezogene Zeitstempel vom Uhrenbaustein des Servers abgeleitet. Dieses Mal ist jedoch der clientbezogene Zeitstempel der Zeitpunkt, an dem der Benutzer den Link “Habe ich gelesen” auf dem Nachrichtenfenster anklickt. Der serverbezogene Zeitstempel ist hingegen derjenige Zeitpunkt, an dem sich der Client mit dem Server neu synchronisiert und dabei die Quittierung an den Server zurückschickt.