Erstellung eines Prototyps zum sicheren und gesteuerten Zugriff auf Dateien und Dokumente auf Basis von Lotus Domino und Notes

Inhaltsverzeichnis

Eidesstattliche Erklärung

Danksagungen

1 Einleitung
1.1 Konzept

2 Allgemeine Grundlagen
2.1 Vorteile eines Datenbankbasierenden Archivs

3 Analyse des Ist-Zustandes
3.1 Nachteile des Ist-Zustandes

4 Festlegung des Soll-Zustandes
4.1 Kriterien des Soll-Zustandes
4.2 Vorteile des Soll-Zustandes

5 Funktionsweise der Datenbank und deren Automatismen
5.1 Verwendete und eingebundene Systeme
5.1.1 IBM AS/400
5.1.2 Novell
5.2 Datenspeichernde Komponenten (Datenbank)
5.3 Dateneinholende Komponenten (Agenten & Scripte)
5.3.1 Abgleich mit der AS/400
5.3.2 Einfügen der TIF-Dateien
5.3.3 Vergabe der Leserechte
5.3.4 Userrollen

6 Die Prototyp-Datenbank im Einsatz
6.1 Einsatz mit der Client-Software Lotus Notes
6.1.1 Verschieden Ansichten und ihre Kriterien
6.1.2 Ausführbare Aktionen
6.1.3 Volltextsuche
6.2 Einsatz über das Internet mittels Web-Browser
6.2.1 Verschiedene Ansichten
6.2.2 Aktionen
6.2.3 Volltextsuche

7 Organisation
7.1 Organisation der Arbeit
7.2 Zeitplan

8 Schlussbetrachtung und Ausblick

Anhang

A.1 Programmierungen

A.1.1 Liste der programmierten Scripte

A.1.1.1 Beschreibung der Scripte

A.1.2 Quelltexte

A.1.2.1 Quelltext Script 1 (Komplettabgleich mit dem Grafikarchiv, manuell)

A.1.2.2 Quelltext Script 2 (Update mit dem Grafik-Archiv, manuell)

A.1.2.3 Quelltext Script 3 (Vergabe der Leserechte, manuell)

A.1.2.4 Quelltext Script 4 (Löschen aller Datei-Anlagen, manuell)

A.1.2.5 Quelltext Script 5 (Update mit dem Grafik-Archiv, automatisch)

A.1.2.6 Quelltext Script 6 (Vergabe der Leserechte, automatisch)

A.2 Abbildungsverzeichnis

A.3 Tabellenverzeichnis

A.4 Glossar

Quellenverzeichnis

Eidesstattliche Erklärung

Hiermit erkläre ich, die vorliegende Diplomarbeit selbstständig angefertigt zu haben. Dabei habe ich ausschließlich die angegebenen Quellen und Hilfsmittel benutzt.

(Jan Kröger)

Danksagungen

Für die freundliche Unterstützung während meiner Diplomarbeit möchte ich mich bei meiner Betreuerin, Frau Prof. Dr. Marietta Ehret von der Fachhochschule Lippe und Höxter herzlich bedanken.

Des Weiteren gebührt mein Dank der Firma IMA Klessmann GmbH für die tatkräftige Unterstützung.

1 Einleitung

Im Zeitalter der elektronischen Datenverarbeitung werden immer mehr Informationen auf Computersystemen gespeichert und verwaltet. Um diese Datenflut, die sich innerhalb vieler Jahre ansammelt, sinnvoll zu verwalten und die Nutzung der Daten möglichst unkompliziert zu gestalten, werden die Daten in Datenbanksystemen gespeichert. Diese Systeme nehmen Daten auf, egal ob in Wort oder Bild, stellen sie dem Nutzer zur Verfügung und garantieren ein höchst mögliches Maß an Sicherheit. Der User muss sich vor der Nutzung des Systems authentifizieren^[1], meistens mit einem Usernamen und einem von ihm bestimmten Passwort. Nur mit diesen Daten kann der User auf die Datenbank und dessen Dokumente zugreifen. Die Dokumente, und damit das Know-how der Firma, sind somit für dritte Personen nicht ersichtlich. Somit können selbst sensible Daten auf diesen Systemen gespeichert werden.

Viele Daten der Firma IMA Klessmann GmbH, im weiteren Verlauf IMA genannt, werden bereits auf solchen Datenbanksystemen vorgehalten, angefangen von Kundendaten, über den E-Mailverkehr bis hin zu Informationen über einzelne Maschinenteile. Dabei sind mehrere Systeme im Spiel, wie z.B. IBM AS/400, Lotus Domino, Unix, Novell^[2], ect. Jedes System erfordert eine separate Anmeldung, bevor es Daten freigibt. Wenn zusammengehörige Daten auf verschiedenen Systemen getrennt voneinander gesichert werden, ist es für den User unkomfortabel, wenn er sich alle Daten einzeln zusammenstellen muss. Ein System, das diese zusammengehörigen Daten aus einer Hand liefern könnte, wäre wünschenswert. Die grundlegende Anforderung war, ein Grafik-Archiv, das auf einem Festplattenlaufwerk gespeichert ist, Internetfähig zu machen. Die Dateien sollen also in eine Datenbank kopiert werden und von jedem Internetzugang der Welt aus zugänglich sein.

Im Rahmen der vorliegenden Diplomarbeit wird eine Datenbank entwickelt, die selbständig aus einzelnen Quellen Datensätze importiert und zusammengehörende Datenelemente in Dokumente schreibt. Die Datenbank soll intern genutzt werden können, sowie über das Internet zugänglich sein.

Für den Nutzer ergeben sich folgende Vorteile:

- Das Grafik-Archiv ist übersichtlich in einer Datenbank verfügbar
- zusammenhängende Daten sind in einem Dokument vereint
- Sicherheitslücken werden geschlossen
- der Zugriff über das Internet wird möglich

1.1 Konzept

Als grundlegende Anforderung galt es, ein Dateikontingent, bestehend aus mehreren tausend Grafik-Dateien, in eine Datenbank einzufügen. Diese Datenbank sollte internen Benutzern über das Firmennetzwerk, sowie externen Nutzern über das Internet zugänglich sein. Der Zugang soll gesichert erfolgen, um illegale Zugriffe zu unterbinden, sowie gesteuert werden können, um eine Kontrolle über die freigegebene Datenmenge zu haben. Anhand dieser Anforderungen musste entschieden werden, auf welchem Basissystem die Datenbank agieren könnte.

Im nächsten Schritt musste festgelegt werden, welche einzelnen Daten überhaupt relevant sind. Nach Absprache mit den beteiligten Mitarbeitern der Firma IMA wurde eine Liste mit den notwendigen Daten und dessen Speicherorte erstellt. Ferner wurde geprüft, ob die Datenquellen vom Prototyp der Datenbank überhaupt angesprochen werden können, um die erforderlichen Daten zu erlangen.

Als nächstes wurden Routinen erstellt, welche die benötigten Daten zusammentragen und in der Datenbank abspeichern. Um die Aktualität der gespeicherten Daten zu sichern, mussten die Routinen automatisiert werden. Manuelle Eingriffe durch einen Mitarbeiter können somit minimiert werden. Diese automatischen Vorgänge sollen innerhalb des Datenbanksystems von so genannten Agenten^[3] übernommen werden.

Nachdem die Daten importiert wurden, muss der Datenbestand noch mit Leserechten versehen werden. Dies geschieht ebenfalls über einen Agenten.

Zudem musste eine Bedieneroberfläche erstellt werden, die dem User die Steuerung der Datenbank ermöglicht und das auffinden eines Datensatzes erleichtern soll. Dabei ist es unerheblich, ob eine Client Software^[4] verwendet wird, oder ein handelsüblicher Internet Browser.

Am Ende dieser Entwicklung steht eine Testversion der Datenbank. Sie enthält alle benötigten Funktionen der Endversion, nur die Datenmenge ist aufgrund der vorhandenen Festplattenkapazität eingeschränkt. Die Endversion soll im späteren Betrieb auf einem separaten und leistungsfähigen Serversystem^[5] installiert werden. Das Testsystem ist für einen Testlauf mit wenigen Usern zwar verwendbar, aber für einen sicheren und zügigen Betrieb nicht ausgelegt. Die verwendete Datenbanksoftware, Lotus Domino, kann mit der zu verarbeitenden Datenmenge problemlos umgehen, nur die Hardware schränkt den Nutzungsgrad ein.

2 Allgemeine Grundlagen

2.1 Vorteile eines Datenbankbasierenden Archivs

Um Dokumente digital zu archivieren muss man sie auf Festplatten, Bändern, CDs oder Disketten speichern. Der Zugriff auf Dateien in einem Archiv erfolgt für gewöhnlich über ein Dateiverwaltungsprogramm, wie z.B. dem Windows Explorer. Um eine Datei zu suchen und zu öffnen, muss man sich durch verschiedene Verzeichnisse arbeiten, um am Ende mit dieser Datei arbeiten zu können. In vielen Fällen sind die verwendeten Dateinamen nicht „sprechend“. Es ist eventuell nicht möglich den Inhalt einer Datei an ihrem Namen zu erkennen. Um eine gewisse Ordnung zu schaffen, können Dateinamen mit einem Zahlencode versehen werden. Dies macht den Umgang mit dem Datenbestand und die Suche nach einem bestimmten Dokument noch aufwendiger. Ungeübte Nutzer finden eine gesuchte Datei somit nur sehr mühsam oder gar nicht.

Ein weiterer Nachteil eines Archivs auf einem Datenlaufwerk ist die mangelnde Sicherheit. Um eine einzelne Datei in einem Ordner öffnen zu können, ist ein Zugriffsrecht erforderlich. Dieses ermöglicht einem User den Zugang zu einem Dokument. Gleichzeitig kann er aber unter Umständen auch auf viele andere Dateien zugreifen, die im selben Verzeichnis untergebracht sind. Die Verwaltung dieser Zugriffsrechte würde schon bei einem Datenvolumen von ca. 1000 Dateien sehr unübersichtlich werden. Müssen zudem noch mehrere hundert Benutzer verwaltet werden, würde das den überschaubaren Rahmen sprengen.

Hier kann ein Intelligentes Datenbanksystem eingesetzt werden, um die Verwaltungsarbeit und Zugriffskontrolle zu übernehmen. Zudem ist es für den Benutzer überschaubarer und komfortabler zu nutzen. Dazu kann es seinen Datenbestand auf verschiedenen Medien, wie zum Beispiel Netzwerke, Datenträger und Internet, anbieten.

Datenbanksysteme, die mehrere Dienste übernehmen, wie zum Beispiel den E-Mailverkehr bereitstellen, Adressbücher vorhalten, ect., sind aufgrund ihrer vielfältigen Möglichkeiten und der Integrierbarkeit in andere Systeme sehr gut für den Einsatz einer Dokumentendatenbank geeignet. Übernimmt ein System bereits mehrere Aufgaben, bei denen eine Authentifizierung des Users nötig ist, ist die Implementierung einer Dokumentendatenbank sehr einfach, da bereits ein vollständiges Verzeichnis aller möglichen Benutzer vorhanden ist. Die Zuweisung der Lese- und Verwaltungsrechte ist somit sehr komfortabel und es müssen nicht mehrere Benutzerverzeichnisse geführt werden.

3 Analyse des Ist-Zustandes

Um das Grafik Archiv, also die von der CAD^[6] -Abteilung der Firma IMA angefertigten technischen Zeichnungen auch mit anderen Systemen sichtbar zu machen, werden von allen CAD-Zeichnungen Kopien im Format „TIF“^[7] angefertigt. Zurzeit sind ungefähr 80.000 TIF-Dateien in dem Grafik-Archiv gesichert. User, die auf das Archiv zugreifen müssen, werden vom Administrator des Systems dazu berechtigt. Innerhalb der Firma IMA kann über das Netzwerk der gesamte Grafikdatenbestand eingesehen werden.

Abbildung in dieser Leseprobe nicht enthalten

Bild 1: Ist-Zustand des Grafik Archivs

Die Dateien sind nach einem firmeninternen Code, der Sachnummer, benannt. Jedes Teil, was auf der CAD-Ebene gezeichnet wurde, trägt eine eindeutige Sachnummer. Auf jeder technischen Zeichnung ist diese Nummer vermerkt. Somit besteht zwischen der Zeichnung und dem Dateinamen immer ein eindeutiger Zusammenhang. Um zu einem namentlich bekannten Bauteil, beispielsweise einer Spannrolle, die technische Zeichnung zu finden, benötigt man die Sachnummer dieser Spannrolle. Diese Sachnummer findet man, indem man im AS/400-System die Datenbank nach der Spannrolle durchsucht und sich die Sachnummer notiert. Mit dieser Sachnummer kann nun in dem Zeichnungsarchiv nach der passenden Grafikdatei gesucht werden. Ist zu dem Bauteil aus bestimmten Gründen keine technische Zeichnung mehr vorhanden, war die Recherche nach dem Dateinamen umsonst.

Die Firma IMA arbeitet mit mehreren Tochterunternehmen zusammen, welche ihre Standorte nicht nur in Deutschland haben. Die Firma IMA in Lübbecke agiert dabei als Knotenpunkt der Datenverarbeitung aller angeschlossenen Tochterunternehmen. Ein permanenter Zugriff auf das Grafik-Archiv ist aus Gründen der Systemsicherheit nicht möglich, da das Archiv im so genannten „inneren Netz“ liegt und von außerhalb nicht zugänglich ist. Deshalb müssen die aktualisierten Datensätze in gewissen Zeitabständen entweder über lang andauernde Uploadvorgänge über das Internet transferiert werden, oder auf eine CD-Rom kopiert und auf dem Postweg versendet werden. Beide Möglichkeiten erfüllen zwar Ihren Zweck, sind aber aufwendig, unsicher und erfordern viel Zeit.

Da alle Tochterunternehmen über einen Internetzugang verfügen, wäre ein Zugriff über das Internet auf das Grafik-Archiv denkbar und wünschenswert. Somit würden nur die Datensätze übertragen, die auch wirklich aktuell benötigt würden.

3.1 Nachteile des Ist-Zustandes

- Datendiebstahl durch Kopieren und Versenden von Zeichnungen möglich
- Administration des Archivs unkomfortabel und unübersichtlich
- Zugriff auf das Archiv nur von internen Arbeitsplätzen möglich
- Nicht-Sprechende und somit uninformative Dateinamen innerhalb des Grafik-Archivs

4 Festlegung des Soll-Zustandes

4.1 Kriterien des Soll-Zustandes

Der Soll-Zustand wurde anhand der gestellten Anforderungen seitens der Firma IMA festgelegt.

Der Prototyp der Datenbank soll folgende Anforderungen erfüllen:

- Als Basis für die Prototyp-Datenbank sollen bereits vorhandene Softwarekomponenten verwendet werden
- Alle auf dem Novell Laufwerk vorgehaltenen TIF-Dateien sollen innerhalb der Datenbank zur Verfügung stehen
- Zu den TIF-Dateien sollen weitere Informationen zur Verfügung gestellt werden
- Der Zugriff auf die Daten soll innerhalb des Hauses, sowie von außerhalb über das Medium Internet möglich sein
- Der Verwaltungs- und Wartungsaufwand soll so gering wie möglich gehalten werden
- Die Datenbank soll autark arbeiten können und sich selbstständig aktualisieren
- Eine Zugriffkontrolle soll nur autorisierten Nutzern den Zugang zu den Daten erlauben. Die Vergabe der Zugriffsrechte soll weitgehend automatisch erfolgen
- Es sollen spezifische Kopien der Datenbank erstellt werden können (Repliken), zum Beispiel nur Datensätze, die zu einer bestimmten Firma gehören
- Die Datenbank soll alle vorhandenen TIF-Dateien aufnehmen können (zur Zeit sind ca. 80.000 Dateien vorhanden)
- Es soll die Möglichkeit bestehen, noch weitere Dateien an die Dokumente anzuhängen, wie zum Beispiel Grafiken, PDF-Dokumente, ect.

Bei der Erstellung der Prototyp Datenbank sollten möglichst alle gestellten Anforderungen abgedeckt werden. Im Folgenden werden die einzelnen Stichpunkte der Anforderungsliste genauer erörtert.

Um nicht neue Software anschaffen zu müssen, sollte nur die bereits vorhandenen Systeme der Firma IMA verwendet werden. Das Datenbanksystem Lotus Domino ist bereits bei der Firma IMA etabliert. Da auf fast jedem PC-Arbeitsplatz auch die Client-Software Lotus Notes installiert ist, bot sich die Erstellung der Prototyp-Datenbank auf der Basis von Lotus Domino an. Somit werden nur bereits verwendete Systeme für den Prototyp benutzt.

Die auf dem Laufwerk gespeicherten TIF-Dateien sollen komplett in die Datenbank übernommen werden, so dass sie nicht mehr auf Novell vorgehalten werden müssen.

Die Dateien werden zusammen mit den dazugehörigen Stammdaten, also den genaueren Einzelheiten, gespeichert. Dabei wird dann die TIF-Datei als Anlage an das Dokument angehängt. Die Anlage kann auf dem aufrufenden Computer herunter geladen und weiterverwendet werden.

Im ersten Anlauf soll die Datenbank nur innerhalb der Firma IMA zur Verfügung stehen. Die Option, das Datenangebot im Weiteren auch über das Internet anzubieten, soll zwar bestehen, aber noch nicht umgesetzt werden.

Um den Verwaltungsaufwand der Datenbank so gering wie möglich zu halten, muss sie sich automatisch auf dem Laufenden halten. Verschiedene Automatisierungen sollen den Datenabgleich mit den eingebundenen Datenquellen abwickeln und protokollieren. Auch die Zugriffsrechte sollen weitgehend automatisch zugewiesen werden. Im Prototyp-Status reichte eine Unterteilung in die einzelnen Tochterfirmen aus, so dass zum Beispiel Dokumente, die zu der Firma A gehören, nicht von Mitgliedern der Firma B gelesen werden können. Anhand dieser Unterteilung in die einzelnen Firmen kann die Datenbank spezifisch kopiert werden. So kann zu jeder Firma eine einzelne Datenbank erstellt werden, die nur Dokumente beinhaltet, die auch zu dieser Firma gehören.

Da die Anzahl der aufzunehmenden Dateien und somit die Größe der Datenbank stetig ansteigt, muss das System diese Datenmengen verarbeiten können. Im Probebetrieb wurde eine Datenbankgröße von über 6GB erreicht. Das Basissystem Lotus Domino, und somit auch die Datenbank, haben theoretisch keine Größenbeschränkung. Nur die Hardwarekapazitäten beschränken die Datenbank in ihrer Größe.

Um im späteren Betrieb noch zusätzliche Informationen einfügen zu können, sollte die Möglichkeit bestehen, weitere Datendateien an ein Dokument anhängen zu können. So können zum Beispiel Fotos, Videos oder Datenblätter zusammen mit einem Dokument gespeichert werden.

Um alle erforderlichen Daten zu bekommen, müssen verschiedene Datenquellen benutzt werden. Die Datenbank muss mit diesen Quellen kommunizieren können und die benötigten Daten herausfiltern und einordnen können.

Abbildung in dieser Leseprobe nicht enthalten

Bild 2: Soll-Zustand des Grafik Archivs

4.2 Vorteile des Soll-Zustandes

Der angestrebte Soll-Zustand des Grafik-Archivs bietet dem User, wie auch dem Administrator, viele Vorteile gegenüber der Ist-Situation.

- Der Benutzer erhält zu der Grafik weitere Zusatzinformationen, die den Inhalt der Grafikdatei genauer beschreiben
- Die Suche nach einem bestimmten Dokument oder einer bestimmten Grafik fällt dank einer integrierten Volltextsuche einfach
- Es ist unerheblich, ob der Benutzer innerhalb des Firmennetzwerkes agiert, oder über das Internet arbeitet. Die Datensätze sind identisch.
- Es ist möglich, noch weitere Dokumente an den Datensatz anzuhängen (Word, Excel-Dateien, Videos, Fotos, ect.)
- Der Benutzer bekommt, dank Zugriffskontrolle, nur Datensätze angeboten, die für Ihn zutreffend sind
- Anhand von Firmenkürzeln innerhalb der Datensätze können firmenspezifische Kopien der Datenbank angelegt werden. Für jede beteiligte Firma ist ein Firmenkürzel vergeben worden (siehe Tabelle 1). Dieses ist bei der Bereitstellung im Internet von Vorteil, da das Datenvolumen pro Datenbank gering gehalten wird. Jede Firma kann via Internet-Browser auf ihre separate Datenbank zugreifen.
(Siehe Bild 3)

- Die Datenbank kann als Replik auf Notebooks auch ohne Internet- oder Netzwerkanbindung verwendet werden, dabei ist die Aktualität vom letzten Abgleich mit der Originaldatenbank abhängig

Tabelle 1: Aufschlüsselung der Firmenkürzel

Abbildung in dieser Leseprobe nicht enthalten

Abbildung in dieser Leseprobe nicht enthalten

Bild 3: Firmenspezifische Repliken der Datenbank

5 Funktionsweise der Datenbank und deren Automatismen

Die Prototyp-Datenbank besteht aus 2 wesentlichen Komponenten. Zum einen aus der Datenspeichernden Komponente, also der Datenbank als solches, und aus den Dateneinholenden Komponenten, den so genannten Agenten.

5.1 Verwendete und eingebundene Systeme

Als Grundlage für den Prototyp muss ein Datenbanksystem verwendet werden, das allen Anforderungen seitens der Firma IMA gerecht wird.

Eine Einbindung ins Internet soll gegeben sein, weiterhin muss das System mit den vorhandenen Mitteln der Firma genutzt werden können und es muss mit allen benötigten Datenquellen verbunden sein.

Die Wahl des gesuchten Systems fiel auf ein, innerhalb der Firma IMA bereits vorhandenes und vielfach eingesetztes, Datenbanksystem der Firma IBM Lotus Software, namens Lotus Domino. In Verbindung mit der Clientsoftware Lotus Notes aus demselben Hause bildet Lotus Domino ein leistungsstarkes Datenbank-Verwaltungssystem, das allen Anforderungen gerecht wurde.

Um eine unnötige Belastung und eventuell auftretende Fehler des Hauptservers während der Entwicklungsphase zu vermeiden, wurde ein separater Server aufgesetzt, auf dem Lotus Domino installiert und konfiguriert wurde. Es handelt sich um eine
IBM IntelliStation M-Pro mit einem Pentium 3 Prozessor und dem Betriebssystem Windows NT. Diese Workstation fungiert während der gesamten Entwicklungs- und Testphase als Domino-Server. Die Arbeitsgeschwindigkeit dieses Servers ist allerdings nicht mit der des Hauptservers der Firma IMA zu vergleichen. Zudem ist das Festplattenvolumen eingeschränkt, so dass nicht der gesamte Datenbestand (ca. 6 GB) gespeichert werden konnte. Um die Funktionalität des Prototyps zu demonstrieren reicht aber ein Teil des gesamten Datenbestands aus (ca. 1 GB).

Zu den eingebundenen Systemen zählen das Datenbanksystem IBM AS/400 und das NetWare System Novell.

5.1.1 IBM AS/400

Auf dem Datenbanksystem IBM AS/400 wird bei der Firma IMA unter anderem ein Teilestamm verwaltet. In einem Teilestamm stehen Daten über einzelne Bauteile, über Baugruppen bis hin zur kompletten Holzbearbeitungsmaschine. Innerhalb des Teilestamms sind viele Felder, also Datenhäppchen, vorhanden, die in der Prototyp-Datenbank von Nutzen sind. Unter anderem sind zur Umschreibung eines Datensatzes die eindeutige Sachnummer, die Bezeichnung, die zuständige Firma, ect wichtig. Mit diesen Informationen und einer dazugehörigen technischen Zeichnung kann die Datenbank wichtige und zusammenhängende Informationen vereinen.

5.1.2 Novell

Auf der Netware Ebene Novell wird das Grafik Archiv in Form von TIF-Dateien vorgehalten. Das Laufwerk steht jedem im Netzwerk angemeldetem User zur Verfügung, der Leserechte auf dieses Laufwerk vom Administrator bekommen hat. Das Schreiben oder Löschen ist nur Administratoren und beteiligten Servern erlaubt.

Die Prototyp-Datenbank, bzw. dessen Agenten dürfen lediglich die Daten von diesem Laufwerk lesen, jedoch nicht verändern.

Um einen automatischen Abgleich zu erleichtern, und die Belastung des Servers so gering wie möglich zu halten, werden die Grafikdateien in zwei verschiedenen Ordnern gespeichert. In dem einen Ordner ist das gesamte Archiv auf mehrere Unterordner verteilt. Alle aktuell dazugekommenen Dateien werden zusätzlich in einen separaten Ordner gesichert. Somit beinhaltet dieser Ordner nur Zeichnungen und Scan´s, die nicht älter als 30 Tage sind. Beim konventionellen Abgleich mit dem Grafik-Archiv werden nur die aktuellen Dateien in die Datenbank eingefügt, bzw. ersetzt. Der Umfang der Datenmenge, die von der Prototyp-Datenbank bearbeitet werden muss, wird damit von ca. 80.000 Dateien auf weniger als 300 Dateien beschränkt. Falls ein kompletter Abgleich mit den Grafikdateien erforderlich ist, kann auf den kompletten Bestand der Grafikdateien zugegriffen werden.

5.2 Datenspeichernde Komponenten (Datenbank)

Die Datenbank selbst besteht aus folgenden Komponenten:

- Navigationselemente, mit welcher der User die Datenbank steuern kann
- Ansichten, in denen die gespeicherten Datensätze in bestimmten Sortierungen angezeigt werden können
- Felder, in denen die Datenelemente geschrieben werden

Alle optischen Elemente, zum Beispiel die Navigation und die Ansichten, werden wie bei einer Internetseite von einer Frameseite^[8] zusammengefügt und angezeigt. Mittels der Navigationselemente kann der Benutzer zwischen verschiedenen Frame-Elementen wechseln. Falls der User die benötigten Rechte besitzt, kann er auch die angebotenen Automatismen der Datenbank manuell starten.

Die Ansichten sortieren die vorhandenen Elemente nach bestimmten Kriterien, wie zum Beispiel nach einer Nummer, nach der dazugehörigen Firma oder es werden nur Datensätze angezeigt, die eine Datei als Anhang besitzen. Somit kann der User schneller den gesuchten Datensatz finden. Die Datensätze werden in den Ansichten zeilenweise angezeigt, jeder Datensatz belegt also eine Zeile. Um eine bessere Übersicht zu gewährleisten, kann jeder Datensatz separat in einem einzelnen Fenster angezeigt werden. Innerhalb dieses Fensters können dazu berechtigte Nutzer auch Datenelemente ändern und Dateianlagen einfügen oder löschen.

Um die Datenelemente überhaupt sichtbar zu machen werden Felder benötigt. Jede Ansicht besteht aus vielen Feldern, in denen die benötigten Datenelemente geschrieben werden. Wird ein bestimmter Datensatz geöffnet, werden in Echtzeit die einzelnen Datenelemente aus der Datenbank gelesen, in Felder geschrieben und dem User angezeigt.

5.3 Dateneinholende Komponenten (Agenten & Scripte)

Um die erforderlichen Daten in die Datenbank zu bekommen, sind mehrere kleine Routinen nötig. Diese Routinen können über eine Schaltfläche gestartet werden, oder werden mittels eines Agenten gestartet.

Agenten sind kleine Programme, die nach einer Zeitvorgabe gestartet werden können. Dabei arbeiten sie ein vorher programmiertes Script^[9] ab und führen dessen Befehle aus.

Die verwendeten Agenten erledigen innerhalb der Prototyp-Datenbank folgende Aufgaben:

- den Datenabgleich mit der AS/400
- das Suchen und Einfügen von TIF-Dateien
- die Vergabe der Leserechte

5.3.1 Abgleich mit der AS/400

Die Stammdatensätze bekommt die Datenbank von der AS/400, aber nicht auf direktem Weg. Innerhalb der AS/400 arbeitet ein kleines Programm, das auf Aufforderung des Abgleichagenten die Datenelemente sammelt. Anschließend werden diese Datensätze in eine Pufferdatei innerhalb der AS/400 geschrieben. Über einen FTP^[10] -Vorgang wird diese Datei auf den Domino-Server kopiert. Der Abgleichagent liest diese Datei aus und schreibt die Elemente in die Datenbank. Danach wird die Pufferdatei wieder vom System gelöscht.

Der Abgleichagent protokolliert jeden Vorgang. Die Anzahl der abgeglichenen Datensätze, auftretende Fehler und Warnungen werden in diesem Protokoll festgehalten. Der Agent läuft nach einem festgelegten Zeitplan mehrmals am Tag an, kann aber auch manuell gestartet werden.

Der Datenbankabgleich mit der AS/400 wird im Gegensatz zu den anderen Agenten nicht innerhalb der Prototyp-Datenbank ausgeführt, sondern erfolgt separat in einer eigenständigen Notes-Datei. Dabei handelt es sich um eine innerhalb der Firma IMA bereits vorhandene Abgleichroutine, die nur entsprechend modifiziert werden musste.

Abbildung in dieser Leseprobe nicht enthalten

Bild 4: Funktionsprinzip des Abgleichagenten AS/400

Die Bedienung des Abgleichagenten erfolgt über eine Konfigurationsansicht. In dieser Ansicht kann der Agent eingestellt, gestartet, ein- und ausgeschaltet und kontrolliert werden.

Abbildung in dieser Leseprobe nicht enthalten

Bild 5: Konfigurationsansicht des Abgleichagenten AS/400

Die Konfiguration des Agenten, also die Laufzeit, die Datenquelle, das Datenziel, Benennung der Datenfelder, ect. erfolgt über eine weitere Ansicht innerhalb der Abgleichagenten.

Abbildung in dieser Leseprobe nicht enthalten

Bild 6: Konfigurationsdaten des Abgleichagenten AS/400

[...]

^[1] Authentifizieren: siehe Glossar

^[2] AS/400, Lotus Domino, Unix, Novell: siehe Glossar

^[3] Agenten: siehe Glossar

^[4] Client Software: siehe Glossar

^[5] Serversystem: siehe Glossar

^[6] CAD: siehe Glossar

^[7] TIF: siehe Glossar

^[8] Frameseite: siehe Glossar

^[9] Script: siehe Glossar

^[10] FTP: siehe Glossar