Ein Plädoyer für Lotus Notes (Teil 2): Das Lego Prinzip

…oder wie ich Java und Web Services durch Lotus Notes zu lieben gelernt habe.

Einige meiner Kollegen arbeiten schon seit längerem mit Webservices und haben unter anderem schon ein komplettes User Management für Domino und eine Kalender Schnittstelle für SAP entwickelt. Ich selbst fand das schon immer sehr interessant und zukunftsweisend, habe selbst aber noch nicht damit gearbeitet.

In den letzten Tagen habe ich mich jetzt endlich mal etwas intensiver mit dem Thema beschäftigt. Es ist faszinierend was man mit diesem Lego Prinzip alles erreichen und vereinfachen kann, wenn man es konsequent einsetzt.

Konkretes Fall Beispiel

Es geht um einen relativ großen Kunden, den ich hier nicht nennen möchte. Dieser Kunde migriert seit längerem weg von Lotus Notes. Mail wurde relativ schnell migriert und jetzt fehlt noch der ganze Rest.

Anfang des Monats haben wir dort die bereits erwähnten User Management Webservices live genommen um die Userverwaltung zu vereinfachen. Es werden also jetzt im Self Service Prinzip alle Notes IDs von den Anwendern selbst beantragt, weitere Daten aus dem internen Identity Management System nachgeladen und voll automatisch angelegt. Ein ähnlicher Prozess existiert für die Anlage von Outlook Accounts und Mailboxen, das ganze läuft aber parallel und wurde nicht in einen Prozess integriert. Soweit so gut, alles läuft nahezu perfekt, wir haben bis heute schon fast 200 User accounts in knapp 2 1/2 Wochen über den Prozess angelegt.

Das Problem

Über ein Problem sind wir jedoch gestolpert: Wir erzeugen die Notes IDs, legen sie in den ID-Vault und vergeben dabei ein Initial Passwort. Dieses Passwort senden wir dem User per Mail zu. Das sollte eigentlich kein Problem sein, da das Mail System ja Outlook ist und die User damit an die Passwörter ran kommen (sollte). Jedoch hat sich herausgestellt, dass das Anlegen der Outlook Postfächer in einzelnen Fällen durchaus etwas länger dauern kann und wir deshalb die Passwörter nicht einfach verschicken können sobald wir fertig sind. Ein einfacher Zeitversatz von x Stunden war auch wenig hilfreich, da es nicht nachvollziehbar war, wie lange das Anlegen auf Exchange Seite dauert.

Der Lösungsansatz

Im Laufe des Migrationsprojektes habe ich schon für verschiedene Applikationen per Java Code Verbindungen in Richtung Active Directory und Exchange programmiert. Deshalb wollte ich in unseren User Anlage Prozess einen Workflow Schritt einbauen, der überprüft ob das Outlook Postfach erfolgreich angelegt wurde und wir das Passwort verschicken können. Ich hätte das jetzt natürlich wieder per Java direkt in die Notes Applikation bauen können, es ist aber abzusehen dass wir diese und ähnliche Funktionen in Zukunft noch an vielen Stellen benötigen werden. Deshalb war es eine gute Gelegenheit das Ganze über einen Webservice zu implementieren um es auch für zukünftige Anwendungsfälle ohne große Programmierarbeit zur Verfügung zu stellen.

Was macht den Webservice Ansatz in diesem Beispiel besser?

Natürlich kann ich meinen Code soweit wiederverwendbar machen, dass ich ihn recht einfach in unterschiedliche Applikationen integrieren kann. Es ist aber immer nur Code, den ich wieder verwende. Webservices gehen hier einen Schritt weiter, ich verwende wirklich einen Service, der sehr viel mehr als nur Code zur Verfügung stellt. In unserem konkreten Beispiel greifen wir nicht auf das interne AD, sondern auf das des externen Betreibers der Exchange Umgebung zu. Hierfür benötigen wir Zugangsdaten, Firewall Freischaltungen und weitere Details wie die richtige Searchbase um die User Accounts zu finden. Für jede Applikation muss ich also die Firewall ändern lassen und die Möglichkeit schaffen Zugangsdaten und Optionen sicher zu hinterlegen. Das ist nicht wirklich praktikabel.

Der Webservice Ansatz bietet eine Möglichkeit diesen Zugriff komplett als Service anzubieten. Ich muss also nichts wissen über die weiteren Abhängigkeiten wie Firewall, Zugangsdaten, welche Searchbase ich benötige, etc. Ich greife von meiner Applikation nur auf einen Webservice zu, übergebe als Parameter eine E-Mail Adresse und bekomme ein Ja oder Nein zurück, ob das Outlook Postfach angelegt ist oder eben nicht. Diesen Webservice kann ich dann wirklich sehr einfach in alle Applikationen integrieren, sei es nun eine Notes Applikation oder auch externe Applikationen. Den Zugriff auf meinen Webservice und damit auf die dahinter liegenden Daten kann ich schnell und einfach anhand der Domino ACL steuern und muss nicht die Zugangsdaten an x Stellen hinterlegen.

Ganz konkret sieht eine Integration des Webservices in meinen LotusScript Code genau so aus:

Dim webservice As New ActiveDirectoryWebservice
Dim isExchangeEnabled As Boolean
isExchangeEnabled = webservice.isExchangeEnabled("email@company.com")

Das ist sehr einfach in jeder beliebigen Applikation einzusetzen. Falls es Bug fixes oder Änderungen gibt, muss ich das nur im Webservice machen und nicht in jeder einzelnen Applikation die diesen nutzt.

Java und Webservices in Lotus Notes Applikationen

Ich arbeite schon länger mit Java in Notes Applikationen. Mir gefällt hier vor allem die optimale Nutzung der jeweiligen Vorteile. Java bietet eine Unmenge von Möglichkeiten um in Notes Applikationen sinnvoll zu arbeiten, aber vor allem auch recht einfach auf externe Systeme und Daten zuzugreifen. An Notes Applikationen gefällt mir die Verkapselung in eine NSF und die einfache Datenstruktur und das vorhandene Security Modell. Beides Zusammen bietet viele Vorteile. Ich entwickle komplexe Notes Applikationen und Java Code, aber trotzdem genügt es die NSF zu sichern oder auf einen anderen Server zu kopieren.

Das Manko das ich allerdings habe, ist die schlechte Verbindung von Java und LotusScript. Ja, ich kann Code der jeweils anderen Welt ausführen und integrieren, aber das ist immer sehr speziell und auch Fehler anfällig. Viel besser gefällt mir der Gedanke der Micro Services, also einzelne Teile der eigenen Applikation als Service anzubieten und diesen dann entweder innerhalb der Applikation oder auch von Außen zu verwenden. So kann ich z.B. einzelne Funktionen in Java oder LotusScript entwickeln und als Webservice miteinander verbinden.

Dadurch entsteht das eingangs erwähnte Lego Prinzip. Ich habe viele kleine Teile, die ich schnell und einfach zusammen fügen kann. Zunächst macht es natürlich etwas mehr Arbeit diesen Service Gedanken konsequent umzusetzen, aber langfristig bietet es enorme Vorteile. Die einzelnen Applikationen werden unabhängiger und einfacher zu pflegen und anpassbarer. Kommt man z.B. irgendwann an einen Punkt, an dem man für einzelne Applikationen die Plattform wechseln möchte (oder muss), bietet das enorme Vorteile. Einzelne Legosteine werden auf neue Systeme portiert und für die restlichen ist das nichts anderes als ein Wechsel der URL des Webservices, oder nichtmal das wenn man mit redirect URLs oder ähnlichem arbeitet.

Advertisements
This entry was posted in IBM Notes/Domino and tagged , , , , , . Bookmark the permalink.

3 Responses to Ein Plädoyer für Lotus Notes (Teil 2): Das Lego Prinzip

  1. Hi,
    Dazu eine Frage: Du verwendest doch PowerShell zur Anlage, warum also nicht gleich die Abfrage einbauen?
    Ich mache dass auch (Ich nutze auch XPages via PowerShell) bei diversen Aktionen. Klar funktioniert das auch mit Java, aber innerhalb der PowerShell Funktion kannst du auch gleich entsprechend reagieren (TRY/CATCH oder IF).

    • Stephan Kopp says:

      Klar, man kann das natürlich auch komplett in PowerShell machen. Dann ist man aber wieder abhängig von Betriebssystem, und dem ganzen Powershell Framework. So hab ich einen einfachen, wiederverwendbaren Java Code, den ich in einer NSF auf jeden Domino Server legen kann. Ist aber nur meine persönliche Vorliebe, jeder wie er es bevorzugt.. 😉

      • Verstehe 😉
        Ich habe nur gesehen, das euer User Tools eine ähnliche Implementierung hat wie das was ich mache. Und noch eben mit PowerShell.
        Das ist nun mal auch meine persönliche Vorliebe 😉

Comments are closed.