Lotusscript + ODBC = ?

So tief man als Entwickler auch mit Lotus-Notes & -Domino verbunden ist - irgendwann kommt man an den Punkt, wo eine Problemlösung nicht ohne den Zugriff auf eine relationale Datenbank möglich ist. Für den ganz großen Wurf stehen uns seit langem die Schlachtschiffe rund um DECS und LEI mit seinen Connectoren für DB2/Sybase/MS-SQL/Oracle zur Verfügung und die Java-Fans werden sofort ein Zauberwort in den Ring werfen: "JDBC". Doch was ist, wenn die Aufgabe nur ein "ganz kleines" Interface zu einer "nicht so großen" Datenbank, wie z.B. MySQL, Postgresql & Co. beinhaltet ? - Richtig: die Entwicklerkollegen aus Redmond haben uns da irgendwann mal mit einem Interface versorgt, was mittlerweile zum Standard gewachsen ist. Oft von Hardcore-Entwicklern als zu unflexibel und langsam (vor-) verurteilt, ist es in der Praxis jedoch inzwischen gut handhabbar und für kleinere Aufgaben aufgrund der Zeiteinsparung bei der Entwicklung gut einsetzbar. Auch Domino unterstützt mit seiner Lotusscript-Extension *LSXODBC ein programmatisches Interface zur Anbindung an eine ODBC-Datenquelle. Und das unabhängig davon, ob der Code auf Client oder Server, in Maske oder Agent ausgeführt wird. Kombiniert mit Server-Agent-Aufrufen vom Client aus oder - wer's zeitgemäßer mag - mit dem Einsatz von Webservices lassen sich da für kleine Alltagsaufgaben hübsche Strukturen aufbauen, die es erlauben, dass nur der Domino-Server zentral auf eine relationale Datenbank zugreift und die Daten dann über Domino-Wege vom und zum Client transportiert werden. Schön und gut, wenn da nicht wieder die eine oder andere Falle wäre, die uns das Leben von Zeit zu Zeit schwer macht. Konkret besitzt die Klasse ODBCConnection, mit der zu Beginn einer Sitzung die Verbindung zur Datenbank hergestellt wird, eine kleine aber für den Serverbetrieb extrem wichtige Eigenschaft: ODBCConnection.SilentMode - Diese ist standardmäßig mit "false" initialisiert und stellt damit unter Umständen ein Risiko für die Betriebssicherheit des Servers dar.
Warum? Ganz einfach: In diesem Zustand wird bei der Initialisierung der ODBC-Verbindung (ODBCConnection.ConnectTo) mit fehlenden oder ungültigen Zugangsdaten bzw. bei fehlender technischer Verbindung zur Datenbank (z.B. Netzwerkproblemen) auf dem Computer, der die Verbindung aufbauen möchte, eine Dialogbox des ODBC-Treibers erscheinen und die Ausführung des LotusScript-Codes wird angehalten. Bei Ausführung auf einem Client-Computer mag dieses Verhalten ja noch nachvollziehbar und unter Umständen sogar sinnvoll sein. Bei Ausführung aus einem Serveragenten heraus hat es jedoch fatale Folgen: der Agent-Code wird blockiert. Je nach Agent-Ausführungsart mit unterschiedlichen Folgen:

1. Ausführung des Codes in einem periodischen Serveragenten

Der Agent blockiert die aktuelle Instanz des Agentmanagers. Wenn nur eine Instanz zulässig ist, ist damit der Agent-Manager komplett blockiert. Bei mehreren Instanzen werden in der Datenbank, aus der der verursachende Agent stammt, keine weiteren Agenten mehr gestartet. Der Konsolenbefehl; führt nicht zum Abbruch des Agentmanagers. Wenn man den betroffenen Agenten kennt, besteht u.U. die Möglichkeit, diesen über
zu beenden. Die Laufzeiteinschränkung des Agentmanagers in der Serverkonfiguration kommt nicht zum tragen. Der Agentmanager bricht die Ausführung nicht (!) automatisch ab.

2. Ausführung des Codes in einem Agenten, der vom Client über NotesAgent.RunOnServer ausgeführt wird

Der Agent wird im Server-Task ausgeführt und bleibt wie unter 1. stehen. Allerdings besteht die Möglichkeit, vom Client aus über eine Unterbrechungsanforderung (Strg-Pause) die Ausführung abzubrechen.

3. Ausführung des Codes in einem WebQueryOpen oder WebQuerySave - Agenten

Die Ausführung des Agenten passiert im HTTP-Task des Servers. Der Agent kann nicht mehr abgebrochen werden. Je nach Konfiguration des Web-Servers (parallele Ausführung von Agenten im HTTP-Kontext) kann es damit dazu kommen, dass keine weiteren Web-Agenten mehr ausgeführt werden können und der HTTP-Task nicht runtergefahren werden kann.
Ist die Situation erst einmal eingetreten, d.h. eine ODBC-Verbindung kommt nicht zustande und der Silent-Mode ist nicht aktiviert, dann ist die Dialogbox garnicht ohne weiteres zu entdecken. Nur auf der Konsolen-Session des Servers erscheint sie (da wo auch die Domino-Konsole zu sehen ist). Besonders bei Windows Server 2008 und höher ist diese Konsole ja standardmäßig nicht mehr zu sehen.
Mit aktiviertem SilentMode wird die Dialogbox nicht angezeigt und die ODBC-Verbindung muss mit ODBCConnection.IsConnected vor der Verwendung überprüft werden. Aber auch hier gibt es noch einen Wermutstropfen: die Timeout-Zeit für den Verbindungsversuch zu einer ODBC-Datenquelle steht im Windows standardmäßig auf 20s und genau solange wird der ausführende Code blockiert, wenn die Verbindung nicht zustande kommt. Aber kein Problem ohne (Registry-) Lösung: im Registry-Schlüssel HKEY_LOCAL_MASCHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\ODBC\LoginTimeout findet sich der Wert für den TimeOut beim Verbinungsaufbau. Eine Verringerung auf ein im jeweiligen Kontext sinnvollen Wert verringert hier die Wartezeit.

Fazit: LotusScript + ODBC = Datenzugriff ohne Umwege, der aber sorgfältig geplant und umgesetzt werden sollte.