Lotus Domino auf neue Hardware umziehen

Da mein Testserver so langsam an seine Grenzen kam, stand ein Hardwarewechsel ins Haus. Aber wie mit möglichst wenig Aufwand die Software darauf umziehen? Da gibt es sicher einen einfachen Weg, auch wenn die Dokumentation zu dem Thema von IBM eher nicht vorhanden ist. Irgendwann vor langer Zeit war es schließlich sogar möglich, eine vorhandene Domino-Installation unter Windows einfach auf die neue Maschine zu kopieren.

Gut, ich fasse mich kurz, der Weg ist immer noch extrem einfach:

  • Neuen Server installieren, idealerweise die Partitionen so aufteilen, wie auf der alten Maschine
  • Lotus Domino neu installieren, den gleichen Installationspfad wie auf der alten Maschine wählen. Wenn das nicht möglich ist, muss man einiges anpassen (siehe hier: https://www-10.lotus.com/ldd/dominowiki.nsf/dx/Changing_directory_locations_when_moving_a_Domino_Server_to_new_hardware)
  • Das neue data-Verzeichnis umbenennen oder löschen
  • Die neue notes.ini umbenennen oder löschen
  • Das alte data-Verzwischnis auf den neuen Server kopieren
  • Die alte notes.ini auf den neuen Server kopieren
  • Fertig, läuft (zumindest bei mir)

Wichtig und disclaimer und so: Dies ist die einfach-und-drecking-Variante, die für produktive Server nicht so ohne weiteres zu empfehlen ist. Ein Startpunkt dafür kann folgendes Dokument von IBM sein. https://www-01.ibm.com/support/docview.wss?uid=swg21102494

Infostore – Flexible Lotus Notes Datenbank mit hoher Sicherheit

Informationen sicher und vor allem einfach abzulegen ist ein Thema, das immer wieder von meinen Kunden angesprochen wird. Gerade im Lotus Notes Umfeld scheint der Bedarf hoch zu sein, da die Standarddatenbanken von IBM nicht das erfüllen, was viele benötigen.

Ich habe die gesammelten Erfahrungen zusammengefasst und eine einfache Anwendung entwickelt, die folgende Punkte abdeckt:

Einfache Ablage

  • Textinformationen oder beliebige Anhänge können abgelegt werden
  • Die Dokumente können mit Kategorien und Titel schnell einsortiert werden

Dokumentansicht

Gute Auffindbarkeit

  • Texte und Anhänge sind volltext-durchsuchbar
  • Passende Ansichten liefern Informationen nach Kategorien oder Stichworten

Datenbankansicht

Hohe Sicherheit

  • Jede Kategorie kann mit Lesern und Bearbeitern versehen werden
  • Jedes Dokument kann auch einzeln mit Lesern und Bearbeitern gekennzeichnet werden
  • Die Anwender verstehen die einfache Berechtigungsstruktur auf Anhieb, was die Sicherheit erhöht (keine Freigabe aus Versehen)

Durchschaubare Lizenzierung

  • Die Datenbank kostet einmalig 89€ pro Serverreplik
  • Kein Jahresbeitrag
  • Keine Abhängigkeit von der Nutzeranzahl
  • Unbegrenzte Updates

Interesse, auch ein zufriedener Nutzer zu werden? Sprechen Sie mich an.

Lotus Notes Groupware-Integration für SAP CRM

Herausforderung

Eines meiner aktuellen Projekte dreht sich um die Einführung von SAP CRM in einem weltweit operierenden Unternehmen. Da dort Lotus Notes als Groupware zum Einsatz kommt, war es eine Herausforderung, die Integration von Email und Kalender einzurichten.

SAP liefert zwar Konnektoren sowohl für die Client- als auch für die Serverseite, allerdings sind diese in ihrer Funktionalität sehr limitiert. Emails können serverseitig beispielsweise nur aus dem Posteingang in das SAP CRM transferiert werden, die Anbindung an die Frei-/Gebucht-Informationen ist auch sehr sparsam.

Lösungsansatz

Darstellung des Lotus Notes Kalenders in einer Aktivität

Darstellung des Lotus Notes Kalenders in einer Aktivität

Aus diesem Grund wurde eine eigene Lösung verfolgt, die eine Lotus Notes Proxydatenbank verwendet. Das SAP CRM spricht diese Datenbank über eine Webservice-Schnittstelle an, alle Zugriffe auf Notes werden dann dort in Notes-RPCs umgewandelt. Weiterhin werden dort alle internen Übersetzungen vorgenommen, wie beispielsweise die Konvertierung von Notes-Emailadressen (CN=…/O=…) in das Internet-Format und zurück.

Die Proxydatenbank ist eine Eigenentwicklung von Waidner IT Solutions, die Gegenseite im SAP CRM wurde von reply Deutschland entwickelt.

Funktionalität

Die vom Proxy zur Verfügung gestellten Funktionalitäten sind aktuell:

  • Import von Emails aus Lotus Notes nach SAP CRM inklusive Möglichkeit, die komplette Ordnerhierarchie zu browsen. Die Emails werden mit Formatierung und allen Attachments übernommen und können beliebigen Belegen zugeordnet werden.
  • Abfrage von Frei-/Gebucht-Informationen aus Lotus Notes und grafische Anzeige in SAP CRM.
  • Weiterleitung und Konvertierung von Kalendereinledungen.
  • Weiterleitung und Konvertierung von Aufgaben, so dass diese direkt in der Lotus Notes Mailbox bearbeitet und beantwortet werden können.
  • Weiterleitung von Kontaktinformationen, so dass diese mit Duplikatsprüfung in das Lotus Notes Adressbuch übernommen werden können.
Ansicht des Posteingangs

Ansicht des Posteingangs

Neben der eigentlichen Implementierung hat sich die Performance des Netzwerks für einige Lokationen als Herausforderung dargestellt. Durch das dezentrale Notes-Netzwerk konnte dies aber durch Installation von zusätzlichen Proxy-Repliken in strategischen Lokationen gelöst werden.

Fazit

Alles in allem wurde also die Funktionalität der Groupware-Anbindung deutlich erweitert und durch die vollständige Kontrolle über beide Seiten des Programmcodes auch die Sicherheit erhöht, da niedrigere Zugriffsrechte auf die Mailboxen der User notwendig sind, als bei Verwendung der SAP-eigenen Lösung.

SAP CRM Teil 2 – Topliste der Notizen an mich selbst

In meinem letzten Artikel habe ich meine Erfahrungen in einem Einführungsprojekt zu SAP CRM beschrieben. Inzwischen ist die Testphase abgeschlossen, die User-Trainings starten und ich kann ein kleines Zwischenfazit ziehen, bevor im Oktober der GoLive erfolgt.

Zur Erinnerung: Bei der Einführung eines SAP CRM für einen weltweit agierenden Kunden übernehme bin ich an der Migration der Altdaten beteiligt, implementiere die Groupware-Integration auf Lotus Notes-Seite und berate bei den Tests. Die Implementierung des SAP CRM übernimmt eine externe Firma, der Support wird inhouse durch den Kunden bedient.

Statt den Ablauf komplett wiederzugeben, will ich kurz meine Top 8 der Notizen an mich selbst wiedergeben:

  1. Ein Bugtracker ist nur so gut, wie seine Konfiguration – Notiz an mich selbst: im Projekt immer darauf achten, dass ich Mitspracherecht dabei habe.
  2. Die Anzahl offener issues sagt nichts über deren Arbeitsaufwand aus – Notiz an mich selbst: lernen, dies dem Kunden immer wieder deutlich zu machen.
  3. Die Kommunikation zwischen Anwender und Entwickler sollte nie ohne Wörterbuch erfolgen – Notiz an mich selbst: ich bin kein schlechtes Wörterbuch
  4. Wenn Anwender und Entwickler direkt miteinander reden, ist dies um den Faktor 10.000 effektiver, als per mail/chat/bugtracker/… – Notiz an mich selbst: darauf achten, dass ich persönlich erreichbar bin.
  5. Ein unbekannter Zeitplan ist kein Zeitplan – Notiz an mich selbst: auch wenn der Projektleiter gut bezahlt ist, darf man ihn darauf hinweisen, dass sich die User unterinformiert fühlen.
  6. Wechselnde “Besatzung” zwischen Testphase ist kein gutes Zeichen – Notiz an mich selbst: dafür sorgen, dass meine Tester gut informiert sind und Testen als positive Arbeitszeit gesehen wird.
  7. Pausen sind großartig, wenn man echte Infos erhalten will. Nur so kommt man informell an die wichtigen Informationen und Stimmungsbilder – Notiz an mich selbst: Genug Pausen vorsehen, um mit Anwendern ins Gespräch zu kommen.
  8. Süßkram hebt die Stimmung – Notiz an mich selbst: das Experiment, Gummitiere mitzubringen, war erfolgreich.

Kundenprojekt: Einführung SAP CRM

Eines meiner aktuellen Kundenprojekte ist die weltweite Einführung eines SAP CRM Systems für mehrere hundert User, das die alte Lösung in Lotus Notes ablösen soll. Das Projekt läuft inzwischen ein gutes Jahr, das Konzept wurde mit allen Einheiten des Unternehmens abgestimmt und die Implementierung nähert sich dem Ende.

Mein Anteil am Projekt ist die Migration der Altdaten, die Anbindung von Lotus Notes als Groupware an das CRM sowie die Begleitung der Tests als Berater. Wir befinden uns derzeit mitten in der Testphase und ich will ein paar Einblicke liefern, wie nah wir uns an Standards wie ISTQB halten, und wo wir weit davon weg sind.

Das Team

Für die Organisation der Tests war ein kleines Team von 8 Personen zuständig, das aus einem guten Mix aus Prozesskennern, externen Implementierern und interner IT bestand. Unterschiedliches Wissen konnte so genutzt werden und auch später bei den Tests eingesetzt werden.

Phase 1 – Testkonzeption

Die Tests sind in mehrere Phasen eingeteilt; zuerst natürlich die Konzeption der Tests. Hierzu haben wir in einem kleinen Team die Testfälle für die unterschiedlichen Anwendungsbereiche (Accounts, Aktivitäten, Angebote, …) entwickelt, indem wir uns nah am Konzept entlang gearbeitet haben (also die Doku als Testorakel verwendet haben). Das klappte in vielen Bereichen erstaunlich gut, obwohl wir zu Beginn dieser Phase noch keinen Zugriff auf das System hatten. Sobald dieser möglich war, haben wir die noch sehr theoretischen Tests noch einmal genauer spezifiziert. Größtenteils waren die Testfälle sehr genau vorgegeben, da die meisten der späteren Testuser das System noch überhaupt nicht kennen und auch ohne Dokumentation auskommen müssen (letztere soll erst noch erstellt werden). Die Testfälle wurden ziemlich profan in themenorientierte Excel-Listen unterteilt, um ein paar Auswertungsspalten ergänzt und später ausgedruckt verteilt.

Phase 2 – interne Tests

Als nächsten Schritt haben wir im gleichen kleinen Kreis innerhalb von ca. 2 Wochen die Testfälle komplett durchgetestet, um die gröbsten Fehler direkt intern zu entdecken und eine Chance zu haben, vor den Usertests diese schon zu beheben. Für das Tracking der Bugs wurde ab hier Bugzilla eingesetzt. Meiner Ansicht nach ein brauchbares Programm, dessen Oberfläche und Bedienung aber eher an die Anfangszeiten der Browsertools erinnert. Aber es erfüllt seinen Zweck zuverlässig, war beim Kunden verfügbar und wurde auch schon für andere Projekte genutzt.

Phase 3 – erste Testrunde mit Anwendern

Für die ersten beiden Juniwochen stand die erste Testrunde mit Anwendern an. Für jede Unternehmenseinheit waren 1-3 Tester anwesend, die teilweise schon die Konzeption begleitet hatten, teils auch neu dabei waren. Wir starteten also mit unterschiedlichsten Wissenständen. Die Workshops wurden in 2 Gruppen durchgeführt, die sich unterschiedliche Themengebiete so vornahmen, dass in zwei Wochen je zwei Workshops zu einem Thema durchgeführt wurden und jedes Team jedes Thema einmal bearbeiten konnte.

Die Tage begannen mit einer kurzen Einführung in das System, die Erklärung des Testmodus (über die spezifizierten Testfälle) und einem Intro für ein effektives Fehlerreporting. Nach den üblichen Startschwierigkeiten waren die Tester erstaunlich motiviert bei der Sache, kaum jemand lies sich durch seine Tagesjobs ablenken. Aus meiner Sicht zeigt dies deutlich, dass eine solche frühe Beteiligung Spaß machen kann. Über den Tag kamen reichlich Fehler und Verbesserungsvorschläge zusammen, die Abends kurz im Team besprochen wurden. Es stellte sich beispielsweise sehr schnell heraus, dass die sehr genaue Spezifikation der Testfälle dazu führte, dass sich kein Anwender verloren vorkam, aber dennoch durch die gute Unterstützung jeder die Freiheit bekam, alle Aspekte des Systems ausprobieren zu können.

Phase 4 – Korrekturen und Anpassung

Nach den zwei Wochen Anwendertests waren reichlich Änderungsvorschläge und Fehler aufgelaufen, insgesamt um die 1000 Einträge. Die eingegangenen Punkte wurden von den jeweils zuständigen Teammitgliedern durchgesehen, Duplikate beseitigt, Rückfragen gestellt und ansonsten direkt den Entwicklern zugewiesen. Alle Einträge, für die es Klärungsbedarf gab, wurden in 2 Meetings komplett durchgesprochen und es wurde entschieden, wie und ob umgesetzt wird.

Für die Änderungen im Programm waren nur knappe zwei Wochen vorgesehen, die jetzt dem Ende entgegengehen. Laut Bugzilla ist die Quote der noch offenen Punkte bei unter 10%. Aus meiner Sicht bedeutet dies, dass die Priorisierung der Punkte sehr gut gelaufen ist, man viele Erweiterungspunkte auf eine spätere Version verschieben konnte und viele kleinere Probleme aufgetreten sind, die beseitigt werden konnten.

Phase 5 – zweite Testrunde mit Anwendern

Für die zweite Testrunde mit den Anwendern ist das gleiche Schema wie für Runde 1 vorgesehen, d.h. in zwei Wochen werden wieder in kleineren Gruppen jeweils einzelne Themengebiete durchgearbeitet. Diesmal ist es essentiell, dass die Anwender ihre eingekippten Punkte nachtesten und prüfen, ob diese zur Zufriedenheit beseitigt sind. Ich bin gespannt, wie gut dieses Verfahren klappt.

Phase 6 – letzte Korrekturen

Danach ist nur eine kurze Woche für die hoffentlich letzten Korrekturen vorgesehen, die dann in Phase 7 mündet.

Phase 7 – Abnahmetests

In der letzten Phase werden wir noch einmal gemeinsam alle offenen Punkte durchsehen und dann zusammen mit den Anwendern entscheiden, ob eine Produktivsetzung wie geplant stattfinden kann.

Fazit

Mein bisheriges Fazit fällt recht positiv aus. Für ein Projekt dieser Größenordnung und einer sehr hohen Diversität der Unternehmenseinheiten ist der Test sehr glatt gelaufen. Man hat einiges an offenen Punkten gefunden, aber durch die offene Kommunikation und frühe Einbindung der Anwender ist die Zufriedenheit derzeit sehr hoch.

Obwohl nicht explizit gefordert, konnte mir das ISTQB-Wissen an einige Stellen extrem weiterhelfen. Gerade bei der Konzeption der Tests konnte man gut auf Äquivalenzklassenbildung, Grenzwertanalyse und Zustandstests zurückgreifen. Auch die Zusammenstellung des Testteams hat durch den interdisziplinären Mix sehr viel zum Gelingen beigetragen. Gerade auch bei der Begleitung der User war es wichtig, sowohl IT-Fachleute dabei zuhaben, als auch Mitarbeiter, die im Geschäft des Kunden erfahren waren.

Als Testwerkzeuge für die Anwendertests kamen ausschließlich Bugzilla sowie Microsoft Excel zum Einsatz, wobei die Entwickler natürlich ihre jeweils speziellen Tools wie SOAPUI für Interfaces o.ä. verwendet haben. Hier hätte ich mir allerdings im Vorfeld noch mehr Struktur und Einflussnahme gewünscht, gerade die Statusverwaltung bei Bugzilla war zu kompliziert und vor allem falsch organisiert (bspw. “Resolved” als Status für Nachtests statt “Verified”). Hier lies sich leider durch zentrale Vorgaben zu wenig ändern.

Ich denke, nach der hoffentlich positiven Abnahme kann ich hier noch einmal mehr schreiben.

Performance-Optimierung von Lotus Notes Datenbanken

Sobald man in Lotus Notes eine Anwendung entwickelt, die etwas aufwändiger als die üblichen Dokumentenablagen ist, kommt man unweigerlich mit dem Thema Performance in Berührung. Früher oder später beschweren sich die Anwender, dass das neue Tool viel zu langsam ist. Die Admins merken, dass ihre Agenten nicht durchlaufen und die Offline-Nutzer ärgern sich über lange Replikationszeiten.
Doch Notes kann schnell…man muss nur wissen wie.
Neben der reinen Optimierung im Code auf die ich hier nicht eingehe (aber natürlich gerne durchführen oder erörtern kann) gibt es serverseitig eine Liste von Optionen, die sich positiv auf eine Datenbank auswirken können. Diese finden sich in den Datenbankeigenschaften auf dem letzten Reiter. Alle Optionen, die hier nicht beschrieben sind, haben auf die Performance keinen Einfluss.

  • Don’t maintain unread marks: ein – Sorgt dafür, dass keine ungelesen-Markierungen (die roten Sternchen) verwaltet werden. Wenn die Datenbank dies nicht benötigt, auf jeden Fall ausschalten.
  • Optimize document table map: ein – Verknüpft Dokumente mit ihrem Formular und sorgt bei allen Ansichtsformeln der Art “Form = xxx” für eine Beschleunigung. Wenn Masken selten gewechselt werden, definitiv ein Plus.
  • Don’t overwrite free space: ein – Platz, den gelöschte Dokumente einnehmen, wird nicht sofort überschrieben. Ist für Datenbanken, die nicht absolut sicherheitskritisch sind, einzuschalten
  • Maintain last accessed property: aus – Wenn die Option eingeschaltet ist, werden auch Lesezugriffe protokolliert, was zu häufigeren Schreibzugriffen in der Datenbank führt.
  • Disable transaction logging: ein – Wenn es die Backup-Strategie erlaubt, dann kann diese Option aktiviert werden. Die Schreibzugriffe werden damit reduziert.
  • Don’t support specialized response hierarchy: ein – Wenn @AllChildren und @AllDescendants in der Datenbank nicht verwendet werden, kann dies aktiviert werden.
  • Use LZ1 compression for attachments: ein – Aktiviert ein neueres, schnelleres Komprimierungsverfahren für Dateianhänge.
  • Don’t allow headline monitoring: ein – Wenn die Datenbank keine headline-feeds unterstützen muss (und das müssen sicherlich die wenigsten, ich habe in meiner ganzen Notes-Laufbahn nicht einen Anwender gefunden, der dies verwendet hat), dann kann die Option eingeschaltet werden.
  • Allow more fields: aus – Bei deaktivierter Option dürfen alle Felder in der DB zusammen 64k nicht überschreiten, was für ca. 3000 Felder ausreicht. Reduziert die Größe der Datenbank und erhöht damit die Performance.
  • Support response thread history: aus – Hiermit erhalten Dokumente zusätzliche Felder, um Antworthierarchien zu unterstützen. Kann im Regelfall deaktiviert werden, außer man entwickelt ein Diskussionsforum.
  • Compress database design: ein – Reduziert die Datenbankgröße durch Komprimierung und damit Replikations- und Ladezeiten.
  • Compress document data: ein – Reduziert die Dokumentengröße durch Komprimierung und damit Replikations- und Ladezeiten.
  • Disable automatic updating of views: aus/ein – Wenn aktiviert, sorgt es dafür, dass Views automatisch aktualisiert werden. Für die Datenbank an sich ist dies positiv, da Ansichten schnell zur Verfügung stehen. Sind allerdings viele Datenbanken auf einem Server mit dieser Option ausgestattet, senkt es die Performance, da der Server mit der Aktualisierung nicht mehr nachkommt und ständig unter Last stehe.
  • Allow soft deletions: aus – Wenn man ein undo auf Löschungen nicht benötigt, dann sollte man dies deaktivieren.
  • Limit entries in $UpdatedBy fields: 3 – Wenn man keine detaillierte Protokollierung der Änderer eines Dokuments benötigt, kann man den Wert niedrig ansetzen.
  • Limit entries in $Revisions fields: 3 – Wenn eine hohe Replikationsfrequenz für die Datenbank vorhanden ist, oder überhaupt nicht repliziert wird, kann man diesen Wert reduzieren. Sehr niedrige Werte erhöhen die Chance von Replikationskonflikten.

Zusammengefasst sieht das ganze dann so aus:

Quellen für die Informationen ist u.a. IBM, kann man hier in Englisch nachlesen. Mehr Informationen finden sich auch hier in Deutsch. Details zur View-Aktualisierung stammen hierher.

Ein weiterer Schritt, um die Performance bei Datenbanken mit sehr hohen Dokumentzahlen und Dokumentlöschungen zu erhöhen, ist die Reduzierung der Löschmarkierungen. Um eine einwandfreie Replikation zu gewährleisten, speichert Notes bei jedem gelöschten Dokument eine Löschmarkierung und gibt diese bei Replikation an andere Server/Clients weiter, damit diese ebenfalls über Löschungen unterrichtet sind. Mal davon abgesehen, dass auch dieses Verfahren nicht 100% funktioniert (siehe hier den Artikel zu PIRC), sorgt es für eine Menge Einträge in der Datenbank. Diese kann man sich mit “show database kompletter/pfad/zur/datenbank.nsf” auf der Serverkonsole anzeigen lassen. Ganz oben in der Liste tauchen die gelöschten Dokumente auf.

Reduzieren kann man diese wie folgt:

  • Replikationsoptionen der Datenbank aufrufen (Rechtsklick->Replication->Options…)
  • Reiter “Space Savers” anwählen
  • Ganz oben in der Box für “Remove documents not modified…” den eingetragenen Wert merken (im Regelfall 90)
  • Wert 0 eintragen
  • Den Haken AUF KEINEN FALL setzen, da er dafür sorgen würde, dass alte Dokumente komplett aus der Datenbank gelöscht werden
  • Dialog mit OK bestätigen
  • Die Optionen neu aufrufen, den Wert nun auf einen niedrigen Wert setzen oder den vorher gemerkten Wert eintragen. Lotus Domino hebt die Löschmarkierungen immer bis zu einem Drittel der hier eingetragenen Zeit auf.

Die Informationen stammen aus dieser Quelle.

Gerne stehe ich Ihnen für die Optimierung ihrer Datenbanken auf diese Art sowie natürlich auch für alle Fragen zur Performance-Verbesserung von Views oder Forms und dem in Datenbanken enthaltenen Programmcode zur Verfügung. Meine Kontaktinformationen für eine unverbindliche Anfrage finden Sie hier.

Lotus Domino: Löschmarkierungen und wieder auftauchende Dokumente

Eine kleine Geschichte zweier Lotus Notes Benutzer und ihrer Daten.

Herr User erzeugt sich eine lokale Replik einer Datenbank auf seinem Notebook. Herr User ist leider Chef und damit Gelegenheitsanwender, d.h. er braucht nur einmal im halben Jahr die Datenbank für ein paar Statistiken. Ansonsten wird auch nicht repliziert, da es ja zu viel Zeit kostet.

Frau Anwender ist regelmäßiger User der Anwendung, hat ebenfalls eine lokale Replik und arbeitet täglich damit. Mindestens 1x pro Tag wird repliziert. Im Zuge einer Aufräumaktion wird eines schönen Tages die Datenbank bereinigt, etliche Duplikate werden gelöscht. Die Datenqualität ist bestens, alles ist gut.

Ende des Jahres passiert das Unglück: Herr User braucht dringend die aktuellen Statistiken, schmeißt die Replikation an (“warum dauert das eigentlich immer so lange?”) und zieht eben den Report. Katastrophe, Einträge sind mehrfach vorhanden, völlig unbrauchbare Auswertung. Auch Frau Anwender trifft der Schlag, da auf einmal die ganze Aufräumaktion wieder hinfällig ist.

Was ist passiert? Notes hat eine unschöne Angewohnheit, die dazu führt, dass Löschmarkierungen entsorgt werden. In den Replikationsoptionen einer Anwendung findet sich eine scheinbar harmlose Option:

“Remove documents not modified in the last (days)” ist zwar auf 90 Tage gestellt, aber welcher Wahnsinnige aktiviert schon diese Option? Doof nur, dass Notes dies auch verwendet, um die Ablaufzeit von Löschmarkierungen zu ermitteln, und zwar egal, ob die Option aktiviert oder deaktiviert ist. Nach einem Drittel der eingestellten Zeit werden Löschmarkierungen (deletion stubs) entsorgt. Kann man hier nachlesen. Dies bedeutet für unser Beispiel, dass +/- 30 Tage nach der Aufräumaktion von Frau Anwender die Löschmarkierungen vom Server getilgt werden. Gibt es Repliken, wie die von Herrn User, die in dieser Zeit nicht repliziert haben, dann Pech: die Markierungen sind weg, die Dokumente dafür aber wieder da! Na Gratulation, da hat sich die IBM was feines ausgedacht.

Aber Rettung naht, es gibt nun PIRC (Purge Interval Replication Control). Wenn man einen 8.5.3er Server mit einem 8.5.3er Client paart, dann hat man eine neue Option auf der Replikationsseite:

Was macht diese? Verhindern, dass alter Mist wieder in die Datenbank repliziert wird. Funktioniert es? Ja, aber es muss leider pro Server pro Replik aktiviert werden. Es gibt auch einen langen Artikel, der alle Details erklärt, und einen Blogeintrag bei der Notes-Hexe, aber die Fakten sind einfach:

Repliziert eine nicht-PIRC-Replik mit einer PIRC-Replik, landen nur die Dokumente in der Datenbank, die innerhalb des angezeigten Intervals modifiziert worden sind. Nebenwirkung: Wenn man lange nicht repliziert, werden sehr alte Änderungen der lokalen Replik möglicherweise nicht übertragen. Aber das kann man zum Glück durch einfaches neu abspeichern umgehen.

Kleiner Gag am Rande: In der Doku zu 8.5.3 findet man nichts, weil es diese nicht gibt, sondern immer noch die 8.5.1 Doku ausgeliefert wird. Profiarbeit!

Erstellungsdatum einer Datenbank anhand der ReplicaID berechnen

Mein aktuelles Projekt dreht sich um die Inventarisierung von Lotus Notes Datenbanken im Zuge der Migration nach Sharepoint. Dabei sollte eine Übersicht der echten Erstellungsdaten der Datenbanken generiert werden. Das, was man normalerweise im Properties-Dialog sieht, sind ja die Daten für den aktuellen Server, hilft also nicht direkt weiter.

Aber es gibt eine eigentlich recht simple Lösung. Notes speichert der Erstelldatum in der ReplicaID der Datenbank, wie man bspw. hier nachlesen kann. Also muss die Information nur noch extrahiert werden und das geht ganz gut mit einem API-Call, nämlich ConvertTIMEDATEToText.

Die gesamte Funktion inklusive Deklarationen sieht dann so aus:

Type TIMEDATE
	Innards(0 To 1) As Long
End Type
 
Declare Function ConvertTIMEDATEToText Lib "nnotes.dll" (ByVal IntlFormat As Integer, _
ByVal TimeFormat As Integer, InputTime As TIMEDATE, ByVal retTextBuffer As String, _
ByVal TextBufferLength As Integer, retTextLength As Integer) As Integer
 
%REM
	Function calculateCreationDate
	Description: Berechnet aus der Replika-ID der Datenbank das Erstelldatum
%END REM
Public Function calculateDBCreationDate(strReplicaID As String) As NotesDateTime
	Dim apiTime As TIMEDATE
	Dim session As New NotesSession
	Dim retStr As String * 81
	Dim retLen As Integer
	Dim retCode As Integer
	Dim datResult As NotesDateTime
	Dim strDate As String
 
	apiTime.Innards(0) = Val("&H" & Right(strReplicaID, 8) & "L")
	apiTime.Innards(1) = Val("&H" & Left(strReplicaID, 8) & "L")
 
	retCode = ConvertTIMEDATEToText(0, 0, apiTime, retStr, Len(retStr)-1, retLen)
 
	strDate = Left$(retStr, retLen)
	Set datResult = New NotesDateTime(strDate)
 
	Set calculateDBCreationDate = datResult
End Function

Mit LotusScript prüfen, ob ein User eine Rolle hat

Da ich gerade mal wieder mit LotusScript programmiere, und mich ärgere, dass es völlig triviale Funktionen einfach nicht gibt, ein kleiner Tipp aus meiner Basisbibliothek. Wie ermittele ich in LotusScript elegant, ob ein User eine bestimmte Rolle der ACL innehat:

' Prüft, ob der Nutzer die übergebene Rolle hat. Der Rollenname muss ohne []
' übergeben werden.
Public Function hasRole(strRole As String) As Boolean
  Dim varResult
 
  ' =1 User hat die Rolle
  ' =0 User hat die Rolle nicht
  varResult = Evaluate(|@Contains(@UserRoles; "[| + strRole + |]")|)
  If varResult(0) = 0 Then
    hasRole = False
  Else
    hasRole = True
  End If
End Function

Der Aufruf lässt dich dann wunderbar einfach mit

if hasRole(“Admin”) then
  funktionDieRechteBraucht()
else
  funktionDieKeineRechteBraucht()
end if

einbauen. Finde ich extrem lesbar.

ByeByeNotes – hängende Lotus Notes Prozesse abschießen

Der Lotus Notes Designer ist nicht gerade die stabilste Entwicklungsumgebung und auch der Lotus Notes Client hat ab und an so seine Schwierigkeiten. Sehr beliebt ist vor allem bei Entwicklern die Meldung “CWPST007IE: The maximum number of login attempts has been exceeded.”. Unangenehm bei einem Absturz ist, dass oft eine Handvoll Prozesse im Speicher hängen bleiben, die man entweder manuell über den Taskmanager beseitigen kann, oder durch Neustart löst. Macht man dies nicht, startet Notes einfach nicht mehr. Luxus wie eine Fehlermeldung gibt es ja leider nicht.

Da mir das zu umständlich war, habe ich vor langer Zeit einmal ein Programm in VB.net geschrieben, das ich nun mit dem aktuellen dotnet 4 Framework und WPF einmal komplett neu in C# implementiert habe. Einfach starten und weg sind alle störenden Prozesse. Wer mag, kann sich hier direkt die Freeware herunterladen: ByeByeNotes

1 2
Waidner IT Solutions