DECS (Domino Enterprise Connection Services) ist ein zentrales Tool für die Zusammenarbeit zwischen Lotus Domino und Datenbanken, weil darüber ein automatischer Abgleich von Informationen zwischen Notes-Dokumenten und Datensätzen in den Datenbanken durchgeführt werden kann. DECS setzt auf die bereits in anderen Artikeln in diesem Heft erwähnten Connectoren auf. Gleichzeitig überwacht der Prozess Ereignisse in Notes-Datenbanken und erkennt definierte Situationen, in denen beispielsweise Dokumente geändert werden. Entsprechend werden die Zugriffe auf die externe Datenbank ausgelöst.
Die Nutzung von DECS ist über den DECS-Administrator relativ einfach. Auch beim Design von Anwendungen nicht ist nicht allzu viel zu beachten.
Die Erstellung von Verbindungen
Der erste Schritt bei der Verwendung von DECS ist die Erstellung einer Verbindung. Dazu wird im DECS-Administrator zunächst ausgewählt, über welchen Connector die Verbindung erfolgen soll. Auch hier stehen die üblichen Schnittstellen zur Auswahl. Im nachfolgenden Beispiel wird wieder mit ODBC gearbeitet.
Im nächsten Schritt müssen die Informationen zur Verbindung eingegeben werden. Der erste Schritt ist die Definition der Datenquelle. Hier muss der Name der System-DSN eingetragen werden. Falls die Verbindung gesichert ist, müssen auch der Benutzername und das Kennwort angegeben werden, wobei darauf hingewiesen wird, dass das Kennwort nicht verschlüsselt wird.
Falls die Treiber kein Multi-Threading unterstützen, muss dies ebenfalls angegeben werden. Die ODBC Cursors lassen sich, falls gewünscht, deaktivieren. Die Cursors sind spezielle Zeiger, die für die Navigation in Ergebnissätzen verwendet werden. Die Verwendung funktioniert nicht mit allen über ODBC angesteuerten Datenquellen korrekt. Dadurch kann das Problem entstehen, dass beim Zurückschreiben von Daten die falschen Datensätze angesprochen werden. Die Alternative dazu ist der ausschließliche Zugriff über die eindeutigen Primärschlüssel.
Im unteren Bereich wird – ähnlich wie bei den Data Connection Resources (DCRs) – die Tabelle ausgewählt. Der Besitzer muss nur angegeben werden, wenn er explizit festgelegt wurde. Der Name wird über das entsprechende Auswahlfeld gewählt (Bild 2). Als Ergebnis wird nach der Auswahl die Liste der Felder mit ihren Datentypen angezeigt.
Die Erstellung von Aktivitäten
Um Aktivitäten erstellen zu können, benötigt man zunächst eine entsprechende Domino-Anwendung mit Feldern, auf die eine solche Abbildung erfolgen kann. Dann kann die Aktivität erstellt werden.
Die Aktivität verbindet jeweils eine Maske in einer Domino-Anwendung mit einer in DECS erstellten Verbindung. Beides sollte vorhanden sein, um die weiteren Schritte ausführen zu können.
Nach der Festlegung eines Namens für die Aktivität wird die Domino-Anwendung ausgewählt. Dort muss eine Maske gewählt werden, und es kann festgelegt werden, ob auch berechnete Teilmasken unterstützt werden sollen. Auf der anderen Seite wird die Lotus Connection konfiguriert. Hier lässt sich optional auch eine neue Verbindung erstellen. Es bietet sich aber an, zunächst Verbindungen zu erstellen und erst anschließend die virtuellen Feld-Aktivitäten einzurichten.
Der nun folgende Schritt ist das Mapping, also die Festlegung des Zusammenhangs zwischen verschiedenen Feldern. Dazu wird das Symbol mit dem nach unten zeigenden Pfeil neben dem Text Mapping ausgewählt. Die weitere Konfiguration kann in der nachfolgend angezeigten Maske durchgeführt werden (Bild 3). Spätestens bei der Auswahl dieser Informationen wird auch deutlich, wo man eventuell fehlerhafte Datentypen auf einer der beiden Seiten erstellt hat – so sollte beispielsweise keine Abbildung des Datentyps Integer auf ein Textfeld erfolgen.
Nun steht es an, die zu überwachenden Ereignisse auszuwählen. Unterstützt werden:
-
Create (Erstellen von Dokumenten)
-
Open (Öffnen von Dokumenten)
-
Update (Aktualisieren von Dokumenten, also die Abspeicherung bereits erstellter Dokumente)
-
Delete (Löschen von Dokumenten)
Allgemeine Optionen
Da DECS die Domino-Datenbank überwacht, handelt es sich grundsätzlich um Aktivitäten, die auf den dortigen Dokumenten ausgeführt werden, und nicht um Änderungen, die in der über ODBC oder einen anderen Connector angebundenen Datenbank vorgenommen werden.
Im unteren Bereich ist es möglich, Optionen einzustellen, und zwar die allgemeinen Optionen, zusätzlich auch für den Umgang mit mehrwertigen Einträgen, und die spezifischen Ereignisoptionen für verschiedene Arten von Ereignissen.
Bei den allgemeinen Optionen (Bild 4), also General Options, ist die Einstellung Monitor Order wichtig. Sie steuert, in welcher Reihenfolge verschiedene getrennte Aktivitäten ausgeführt werden. Das ist dann wichtig, wenn es mehr als eine solche Aktivität gibt, wenn also beispielsweise die Änderungen und Löschungen von Daten mit unterschiedlichen Aktivitäten bearbeitet werden sollen.
Interessant ist auch die Option Form Override. Normalerweise wird die Aktivität nur auf die weiter oben angegebene Maske angewendet. Optional können Felder aber auch in allen Masken, in denen sie vorkommen, überwacht werden. Über die darunter stehende Formel kann die Liste der Masken allerdings auch wieder eingeschränkt werden.
Weitere Festlegungen
Mit den weiteren Festlegungen wird unter anderem gesteuert, wie mit Daten umgegangen werden soll, die nicht 1:1 abgebildet werden können. Hier kann man zwischen einer geringeren Genauigkeit beispielsweise bei nicht ganzzahligen Werten oder einem Datenverlust beispielsweise durch das Abschneiden von Text unterscheiden. Man sollte versuchen, diese Probleme dadurch zu minimieren, dass man möglichst kompatible Datentypen wählt und falls erforderlich, beispielsweise bei Textfeldern, auch mit Eingabeprüfungen arbeitet.
Wichtig sind auch die Optionen zum Data Storage. Standardmäßig werden alle virtuellen Felder – hier noch als real-time fields bezeichnet – im Notes-Dokument vor der Speicherung gelöscht. Da sie ja auch in der angeschlossenen Datenbank abgelegt werden, wäre die Speicherung redundant. Es gibt aber auch Situationen, in denen man die Informationen zusätzlich in den Notes-Dokumenten speichern möchte, um beispielsweise auch bei einer nicht mehr bestehenden Datenbankverbindung mit diesen Daten arbeiten zu können.
Im unteren Bereich schließlich stehen noch Optionen für die Zeitsteuerung. Die Aktivität kann manuell über die Schaltflächen im DECSAdministrator, automatisch oder zeitgesteuert ausgeführt werden. Bei Auswahl der manuellen Startart kann man Aktivitäten aber bei Bedarf auch über ein Skript starten, um den Server nicht mit vielen dieser sich meist im Leerlauf befindlichen Aktivitäten zu belasten.
Im Register multi-value data lässt sich darüber hinaus steuern, ob es mehrwertige Daten gibt, bei denen Einträge in einem Domino-Dokument in Beziehung zu mehreren Datensätzen in der Datenbank stehen. Ob das erforderlich ist, hängt von den Datenstrukturen ab. In diesem Fall werden mehrere Datensätze aus der Datenbank gelesen, die mit den verschiedenen Schlüsseln, die im Domino-Dokument abgelegt sind, übereinstimmen.
Die Ereignisoptionen enthalten für jedes der möglichen Ereignisse eigene Einträge. Bei Create gibt es genau zwei Optionen. Mit der Pre-Create Formula lässt sich eine Formel definieren, die vor dem Speichern eines neu erstellten Dokuments in Notes ausgeführt werden soll. Das bietet sich beispielsweise für einfachere Integritätsprüfungen an.
Die Stored Procedure wird dagegen in der Datenbank aufgerufen und anstelle der Standardprozedur für das Erstellen neuer Datensätze verwendet. Hier wird nur der Name angegeben, auf den Zugriffe erfolgen sollen. Die Prozedur muss getrennt davon in der Datenbank angelegt werden. Eine solche Prozedur kann beispielsweise ebenfalls Daten prüfen oder automatisiert zusätzlich erforderliche Informationen generieren.
Steuerungsmöglichkeiten für das Öffnen von Dokumenten
Mehr Steuerungsmöglichkeiten gibt es für das Öffnen von Dokumenten. Zwei Formeln sind hier möglich: Eine wird vor dem Öffnen, also unmittelbar vor dem Zugriff auf die Datenbank, ausgeführt, die andere läuft im direkten Anschluss ab und kann beispielsweise für die Verifizierung von Informationen aus der Datenbank verwendet werden.
Zusätzlich lässt sich auch hier wieder eine Stored Procedure in der Datenbank nutzen, soweit das verwendete Datenbankmanagementsystem so etwas überhaupt unterstützt.
Die Einstellung Missing External Records bezieht sich schließlich darauf, wie mit fehlenden externen Datensätzen umgegangen werden soll, die eigentlich erwartet wurden. Diese können (als weitgehende leere Datensätze) generiert oder ignoriert werden oder zu einer Fehlermeldung führen. Der Standardwert ist die normale Lösung. Hier wird ein grundsätzliches Problem von DECS deutlich: DECS kann zwar überwachen, was in der Domino-Datenbank passiert, aber DECS kann nicht kontrollieren, was in der externen Datenbank abläuft. Wenn dort Datensätze gelöscht werden, auf die in Domino-Dokumenten noch Bezug genommen wird, kommt es eben zu Fehlern. Lässt sich nur durch entsprechende Realisierung auch der anderen Anwendungen vermeiden, die auf die Datenbank zugreifen. Das könnte – wenn auch aufwendig und nicht bei jedem System machbar – beispielsweise durch erweiterte Stored Procedures geschehen, die externe Aktivitäten aufrufen und wiederum in Domino prüfen, ob es beim Löschen eines Datensatzes zu Problemen kommt.
Die Optionen zur Aktualisierung (Bild 6) umfassen wie gewohnt eine Formel, die vorab ausgeführt werden kann, und eine Stored Procedure. Es kann auch eine Konfliktprüfung ausgeführt werden. Diese Prüfung analysiert, ob sich die Datensätze in der externen Datenbank seit dem Öffnen verändert haben. Interessant sind auch die Field Level Updates. Damit wird gesteuert, dass Änderungen nur für die auch tatsächlich angepassten Felder durchgeführt werden.
Die Einstellungen zum Löschen lassen sich wiederum auf die Formel und die Stored Procedure beschränken.
Neben den DCRs ist DECS der insgesamt einfachste Mechanismus, um Domino mit externen Datenbanken zu verknüpfen. Und da der LEI (Lotus Enterprise Integrator) wiederum darauf aufbaut, kann man von DECS aus auch relativ einfach zu komplexeren Lösungen gelangen.