Mit dem Modul „Redundante Postfächer“ soll die Buchungssituation eines oder mehrerer Räume sowohl in raum]für[raum als auch in Lotus Notes / Domino dargestellt werden. Raumbuchungen in raum]für[raum sollen auch im Raumkalender von Lotus Notes erscheinen und umgekehrt. Die Synchronisation zwischen raum]für[raum und Lotus Notes / Domino findet über einen Agenten statt, der auf dem Domino Server installiert werden muss. Dieser Agent wird von einem Scheduler Job in raum]für[raum in einem definierten Intervall (Einheit in Minuten) angetriggert und sorgt für die Übertragung neuer Termine in das jeweils andere System. Er sorgt ebenfalls für Modifikationen und Löschungen von Terminen.

Bei der „Verheiratung“ zweier führender Systeme sollten zur Wahrung von Transparenz, Eindeutigkeit und Datenintegrität nur grundlegende unkritische Funktionen implementiert werden. Ansonsten verliert eine Anwendung sehr schnell den Charakter, eine Hilfe zur Bewältigung der täglichen Aufgaben zu sein und wird selbst zum Problem.

Verschiedene Buchungswege

Der Buchungsweg unterscheidet sich in den beiden Systemen:

  • In raum]für[raum buchen die Benutzer die Räume direkt (bzw. fragen an) und wählen die Ressourcen hinzu, die sie für ihre Veranstaltungen benötigen. Für jeden Raum wird dabei ein Belegungs-Kalender verwaltet. In raum]für[raum ist der Buchungsprozess im Standard an die Verfügbarkeit des Raumes und die individuellen Berechtigungen der Benutzer geknüpft.

Die Bucher und die eingeladenen Personen können ihre Termine optional über die Funktion „Aus Adressbuch einladen" in Lotus Notes übernehmen.

  • In Lotus Notes wählt der Benutzer zunächst die einzuladenden Kolleginnen und Kollegen und fügt dann den Raum hinzu. Der Raum hat einen eigenen Kalender, in dem die Veranstaltung eingetragen wird.

Die über Lotus Notes eingeladenen Personen können in raum]für[raum nicht verarbeitet werden, da es nicht möglich ist, diese Informationen an raum]für[raum zu übertragen. raum]für[raum kann nur das Ressourcenpostfach auslesen, welches jedoch keine Informationen über die Teilnehmenden enthält.

Praktische Folgen

Da hier eine Koppelung zweier führender Systeme vorgenommen wird, ergibt sich in der Praxis folgendes Verhalten:

  • Das führende System, mit dem der Termin erstellt wurde, behält die Führung.
  • Das bedeutet, dass im jeweils anderen System der Termin nicht mehr verändert werden kann.
    • Beispiel: Der Termin wird in Lotus Notes erstellt. Anschließende wird der Kalendereintrag des Raumpostfaches nach raum]für[raum dupliziert. In raum]für[raum wird dann eine Buchung des betreffenden Raumes durchgeführt. Diese kann in raum]für[raum nicht geändert oder gelöscht werden.
    • Beispiel: In raum]für[raum wird ein Raum für ein Zeitfenster gebucht. Dieser Termin wird in das Postfach des Raumes im Domino Server eingetragen. Der Termin kann über Lotus Notes nicht mehr geändert oder gelöscht werden.
  • Das führende System befragt das nachfolgende System hinsichtlich Kollisionen.
  • Um Kollisionen auszuschließen, wird bei der Buchung im jeweils anderen System nach Buchungen im gewünschten Zeitfenster gesucht. Je nach Buchungsrichtung wird dies wie folgt gehandhabt:

Richtung: raum]für[raum -> Lotus Notes / Domino
raum]für[raum liest den Kalender des gewünschten Raumes aus. Die Belegung des Raumes wird in raum]für[raum dargestellt und der Benutzer kann in belegten Zeitfenstern keine Buchung durchführen.

Richtung: Lotus Notes / Domino -> raum]für[raum
Wird eine Buchung in Lotus Notes durchgeführt, dann landet im Raumpostfach zunächst nur eine Anfrage. Der Agent befragt raum]für[raum, ob diese Buchung auch in den Buchungsplan der Raumverwaltung passt. Wird keine Kollision erzeugt, wird der Termin bestätigt. Aus der Anfrage im Domino-Postfach wird eine Buchung. Ergibt sich eine Kollision, wird der Termin abgelehnt. In der Begründung der Ablehnung wird - wenn verfügbar - ein alternativer Raum aus der gleichen Raumgruppe vorgeschlagen.

Berücksichtigung von Rüst- und Nachlaufzeiten

Für den ungestörten Ablauf von Veranstaltungen sind sogenannte Rüstzeiten, in denen der Raum auf den Termin vorbereitet wird, notwendig. Das Eindecken der Tische oder die Bereitstellung von Getränken und kleinen Aufmerksamkeiten braucht Zeit, die dem Raum / der Ressource / der Sitzordnung als Eigenschaft „Rüstzeit" zugeschrieben wird. Ebenso muss der Raum nach einem Termin wieder in einen sauberen und aufgeräumten Zustand versetzt werden. Dazu wird eine Nachlaufzeit festgeschrieben.

In raum]für[raum werden diese Zeiten bei jedem Termin berücksichtigt, um dem verantwortlichen Dienstleister diese Arbeiten zu ermöglichen. In die Rüst- und Nachlaufzeiten hinein kann deshalb kein anderer Termin gebucht werden.

Buchung in Lotus Notes

Wird in Lotus Notes ein Termin gebucht, so sind die Rüst- und Nachlaufzeiten für die Bucher nicht von Interesse. Sie möchten lediglich das vereinbarte Zeitfenster in ihrem Kalender eingetragen haben und setzen voraus, dass der gebuchte Raum entsprechend vorbereitet wird. Daher wird der Termin auch nur mit den „Nettozeiten“ im Raumpostfach des Dominoservers angefragt. Die Anfrage wird anschließend von raum]für[raum bearbeitet, wobei das System zu dem Termin die Rüst- und Nachlaufzeiten hinzunimmt, also die „Bruttozeit“ berechnet, und die Anfrage auf Kollisionen prüft. Daraus kann die scheinbar paradoxe Situation entstehen, dass ein Termin in ein freies Zeitfenster des Raumes passen würde, aber nicht gebucht werden kann, weil ein Konflikt mit den Rüst- oder Nachlaufzeiten vorangegangener oder nachfolgender Termine entsteht. In diesem Falle erfolgt - wie oben beschrieben - ebenfalls eine Ablehnung der Anfrage.

Räume mit Vor- und Nachlaufzeiten oder erweiterten Services sollten daher nur in raum]für[raum verwaltet werden.

Buchung in raum]für[raum

Termine, die in raum]für[raum gebucht werden, werden mit den Nettozeiten in das Raumpostfach des Domino-Servers geschrieben.

Einordnung der Termine in das Planungsintervall

In raum]für[raum wird als Planungsintervall oft ein Zeitintervall von 15 Minuten benutzt. Diese Intervalle finden sich in allen graphischen Ansichten wieder und sorgen für eine schnelle Erkennung freier Zeitfenster. Bei Buchungen in Lotus Notes sind auch Zeitangaben für Beginn und Ende einer Veranstaltung möglich, die nicht mit den Zeitintervallen von raum]für[raum übereinstimmen. Bei der Übertragung solcher Termine nach raum]für[raum wird der Beginn auf den Anfang des betreffenden Intervalls und der Schluss auf das Ende des betreffenden Intervalls gesetzt.
Beispiel: Eine Buchung in Lotus Notes von 14:10 bis 14:35 führt in raum]für[raum zu einer Buchung von 14:00 bis 14:45.

Die Zeiten in Lotus Notes können nicht verändert werden.

Serientermine

Serientermin-Anfragen an Ressourcenpostfächer, die über Lotus Notes gebucht werden, können in raum]für[raum nicht verarbeitet werden. Die Ursache liegt darin, dass der Domino-Server Serientermine in Dokumentenform verarbeitet. Der Domino-Server liefert daher keine eindeutigen Daten, um etwaige Änderungen einer Veranstaltung in raum]für[raum zuzuordnen. Bei jeder Aktion werden im Domino-Server neue Dokumente unter einer neuen ID erzeugt. Aus diesem Grund wird der gruppierende Wert der  „APPTUNID" zur Identifikation bei Einzelterminen benötigt. Da die Einzeleinträge eines Serientermins im Domino-Server ebenfalls nur über die „APPTUNID" verbunden sind, ist es nicht möglich, die Buchungstypen „Einzeltermin" und „Wiederholtermin" in Verbindung mit den neu erzeugten Dokumenten, die bei Änderungen entstehen, zu differenzieren.

Das Buchen von Serien muss demnach, wenn keine andere technische Lösung zur Verhinderung von Serienterminen in Domino-Server möglich ist, per Dienstanweisung behandelt werden. Sollten trotzdem Serientermine in Lotus Notes eingestellt werden, so werden diese von raum]für[raum bei der Synchronisierung abgelehnt.

Modul „Redundante Postfächer" in Kombination mit dem Modul „Domino"

Sinnvollerweise wird das Modul für die redundanten Postfächer in Kombination mit dem zugehörigen Groupware-Modul eingesetzt. Dadurch erweitert sich der Buchungsprozess in raum]für[raum auf folgende Weise:

Der Bucher (oder Anfrager) wählt zu Anfang der Buchung die Teilnehmenden aus. (Technisch erfolgt eine Abfrage des Verzeichnisdienstes via LDAP.) Danach werden die Free-/Busy-Zeiten der Einzuladenden vom Server der Groupware ausgelesen und angezeigt. Ist ein freies Zeitfenster gefunden, kann ein passender Raum dazu gewählt werden. Anschließend werden noch die für den Termin benötigten Ressourcen (Getränke, Gebäck, …) hinzugewählt.

Die Buchung wird dann im Namen eines technischen Benutzers als Einladungsmail an den Groupware-Server übermittelt. Der Bucher ist hierbei ebenfalls nur eingeladener Gast. Die Buchung wird gleichzeitig im Raumpostfach eingetragen. Die Teilnehmenden können zu- oder absagen. Diese Antwort-Mails werden an den technischen Benutzer gesendet und landen in dessen Postfach. Dieses wird in regelmäßigen Abständen (Intervall gleich 1 Minute) ausgelesen und der Status der einzelnen Eingeladenen wird in raum]für[raum angezeigt.

Anmerkung:
Das Versenden von Einladungen im Namen des Buchers ist nicht möglich, da der Groupware-Server Einladungsmails an den Bucher eines Termins, den dieser selbst veranstaltet, nicht akzeptiert. Dies ist eine sehr sinnvolle Einschränkung, da der Groupware-Server zur Planung einer Veranstaltung (inklusive Einladung von Teilnehmenden) eine Authentifizierung des Buchers verlangt. Würde auf diese Authentifizierung verzichtet, so würden unsere Kalender von Terminen überquellen, die wir selbst nicht vereinbart hätten, bei denen wir als Bucher genannt werden und für die wir verantwortlich wären.

Nur einen Teil der Einladungen mit dem Absender des technischen Benutzers zu versenden ist auch nicht sinnvoll, denn dies erzeugt eine unübersichtliche Informationslage. Es ist transparenter, ein System als das Führende zu bestimmen. In diesem Fall ist raum]für[raum das führende System, da in diesem der Termin auch gebucht wird.