enaio ist ein leistungsfähiges Dokumentenmanagement-, Workflow- und Archivsystem. Ein besonderes Kennzeichen der Produktfamilie ist die hohe Konfigurierbarkeit und ihre Schnittstellenstärke, die es erlaubt, an den unterschiedlichsten Stellen eine Integration in andere Systeme vorzunehmen.
Im nachfolgenden Dokument werden die durch die enaio Server-API bereitgestellten Funktionen detailliert beschrieben. Das Dokument hat den Charakter einer Funktionsreferenz. Nähere Informationen über den Aufbau von enaio und der einzelnen Komponenten sind den entsprechend verfügbaren Dokumentationen zu entnehmen.
Der enaio-Server dient als Laufzeitumgebung für diverse Engines im Archiv, DMS und Workflow-Umfeld. So werden durch den Server verschiedene Aufgaben zum dokumentenorientierten Informationsfluss wahrgenommen. Dies sind etwa die Aufnahme, Verwaltung und Bearbeitung von Dokumenten und den dazugehörigen Indexdaten, die Volltextrecherche, das Workflowmanagement, die Archivierung und viele weitere Funktionen.
Eine Engine – auch Executor genannt – wird durch den Applikationsserver geladen und dadurch befähigt, Jobs auszuführen. Jeder Executor verwaltet einen oder mehrere Namespaces, in denen die Serverjobs organisiert sind. Folgende Engines werden standardmäßig ausgeliefert:
Jobs sind Aufgaben, die durch den Server ausgeführt werden sollen, und eine bestimmte Akquise, Manipulation von Daten oder Steuerungsfunktionen abbilden. Somit lassen sich Jobs auch mit Funktionen vergleichen. Ein Serverjob hat folgenden allgemeinen Aufbau:
Zur Ausführung der Jobs muss zwischen der anfordernden Instanz -auch Client genannt- und dem Server eine so genannte Session erzeugt werden. Diese besteht einerseits aus einer Verbindung über ein technisches Protokoll (z. B. TCP) und andererseits aus verschiedenen Informationen zu dieser Verbindung, wie z. B. Authentifizierungs-, Stations- und Lizenzdaten. Über das technische Protokoll wurde zur Formulierung der Anfragen und Ergebnisse der Bearbeitung das Protokoll XML-RPC gelegt. Dieses Protokoll legt fest, wie Anfragen, Parameter und Ergebnisse dargestellt werden müssen. Den Verlauf Kommunikation zwischen Client und Server entspricht folgendem Schema:
Der Client ruft einen Job auf, indem die Jobbezeichnung und die dazugehörigen Parameter in XML verpackt und zum Server gesandt werden. Danach wartet der Client auf eine Antwort. Der Server-Kernel hingegen interpretiert die empfangenen Daten. Es wird ermittelt, welche Engine den Job ausführen kann und an dessen Queue-Mechanismus zur Bearbeitung übergeben. Das Ergebnis wird dann von der Engine über den Server-Kernel an den Client übermittelt. Die Jobs, die durch die Engines bereitgestellt werden, sind in der nachfolgenden Referenz beschrieben.
Das XML-RPC-Format sieht vor, dass alle Parameter innerhalb einer XML-Struktur mit entsprechenden Typen übertragen werden. Bei der Übertragung von Dateien (also Binärdaten) wäre es deshalb notwendig, die Dateien durch eine MIME- Kodierung in einen String umzuwandeln. Aus Gründen der Performance und des Speicherbedarfs wurde hier vom Standard abgewichen. Die Dateien werden nach dem Versand der Jobparameter als TCP-Stream gesondert übertragen. Einige Parameter, insbesondere XML-Strukturen, werden zur Übertragung aber in das MIME-Format konvertiert, um evtl. Steuerzeichen zu entfernen.
Um die interne Kommunikation vor den fachlichen Anforderungen zu verbergen, stehen mehrere Möglichkeiten offen, das Protokoll auch ohne tiefere Kenntnisse der Kommunikationsabfolge zu benutzen. Zu diesem Zwecke existieren Klassen und Bibliotheken, die von OPTIMAL SYSTEMS bereitgestellt werden.
Dies sind:
Vom prinzipiellen Aufbau gleichen sich die Schnittstellen in der Benutzung. Nach einer Initialisierung und der Herstellung einer Verbindung zum Applikationsserver werden Jobobjekte aufgebaut, denen Eingabeparameter und Eingabedateien übergeben werden. Nach der Ausführung können Ausgabeparameter und Ausgabedateien vom Objekt gelesen werden. Darüber hinaus wird ein Fehlerstack bereitgestellt, der mögliche fachliche und technische Fehlermeldungen aufnehmen kann. Eingabe- und Ausgabelisten werden je nach verwendeter Programmiersprache als Hashlists, Arrays oder sonstige Objekte dargestellt.
Vorrangig sollte die oxsvrspt.dll als Bibliothek verwendet werden. Ausführliche Informationen zur Verwendung der Bibliotheken finden Sie im Abschnitt 'OxSvrSpt'.Ziel einer Archivanbindung für verschiedene Applikationen ist es, Dokumente, die mit Struktur- und Indexmerkmalen versehen sind, im DMS abzulegen, im Datenbestand zu recherchieren, Dokumente zu downloaden und ggf. zu löschen. Diese Szenarien sollen an Hand von nachfolgenden Beispielen demonstriert werden. Wie bereits beschrieben, werden die Funktionen durch den Aufruf von Serverjobs durchgeführt, die in der DMS-Engine und der Standard-DMS-Engine implementiert wurden.
Zunächst eine kurze Einführung zur Struktur des Systems. Weitergehende Informationen sind den Administrationshandbüchern von enaio zu entnehmen. enaio verwendet folgende DMS-Objekte für die Abbildung von Informationsstrukturen:
Schrank:
Der Begriff Schrank wurde als Analogie zu einem Aktenschrank gewählt. Ein Aktenschrank enthält Ordner, Register und Dokumente. Er stellt die oberste Verwaltungsebene im DMS dar. Alle weiteren DMS-Objekte können nur als Subobjekt eines Schrankes existieren. Ein Schrank erhält als einziges Attribut einen Namen.
Ordner:
Ordner werden durch Indexdaten beschrieben und sind Container für darunter liegende Objekte. Sie sind vergleichbar mit Ordnern im Dateisystem auf Wurzelebene. Pro Schrank existiert immer nur ein Ordnertyp.
Register:
Register dienen der weiteren Feingliederung der Informationsstruktur. Pro Schrank kann es mehrere Registertypen geben, die sich nach der Struktur der Indexdaten unterscheiden.
Dokumente:
Dokumente zeichnen sich neben den Indexdaten zusätzlich dadurch aus, dass mit ihnen Dokumentdateien assoziiert sind. Jeder Dokumenttyp besitzt die Eigenschaft eines Haupttyps, wodurch gekennzeichnet ist, ob es sich bei den assoziierten Dateien um Images, Windows-Quelldokumente oder andere, von ihrem Wesen nach unterschiedlichen Dateitypen handelt. Der enaio® client verhält sich je nach Haupttyp beim Erfassen und Ausgeben der Dokumente unterschiedlich.
Die Klassen von Ordnern, Registern und Dokumenten heißen Objekttypen. So ist beispielsweise ein Kundenordner oder eine Rechnungsart ein Objekttyp. Alle Instanzen der Klasse, also die einzelnen Ordner oder Belege selbst verfügen über die gleichen Felder zur Indexierung. Bei Dokumenten wird über den Objekttypen auch der Haupttyp festgelegt. Die Struktur der Indexdaten wird durch das Objektmodell vorgegeben. So kann für jeden Objekttypen eine eigene Menge von Feldern definiert werden, die zur Verschlagwortung und zur Recherche dienen.
Nachfolgend werden Dokumente, Register und Ordner als Objekte bezeichnet, sofern eine genauere Spezifikation unerheblich ist. Jedes Objekt ist durch Indexdaten und so genannte Basisparameter gekennzeichnet. Basisparameter werden automatisch vom System vergeben und sind zur internen Verwaltung der Objekte vorgesehen. Sie beinhalten Informationen über den Anleger eines Objektes, seine ObjektID, Änderungsdaten usw.
Jedes Objekt im DMS wird durch seinen Objekttypen und seine ObjektID eindeutig beschrieben. Für die meisten Jobs werden die Objekttypen und ObjektIDs als Eingabeparameter erwartet.
Bei einer Recherche sollen anhand von Suchparametern, Indexdaten und Basisparameter von Objekten zur weiteren Verarbeitung, ermittelt werden. Über die ermittelten ObjektIDs und Objekttypen können dann weitere Recherchen durchgeführt werden oder etwa die Dokumentdateien selbst gedownloadet werden.
Bei einem Import werden durch die aufrufende Applikation Indexdaten und ggf. Dokumentdateien vorgegeben und daraufhin im System neue Objekte angelegt.
Nachfolgend eine kurze Zusammenstellung der Jobs, die für eine Archivanbindung benötigt werden.
Für Tests einzelner Jobs des enaio-Servers und seiner Engines stellt OPTIMAL SYSTEMS das Programm axlabjobs.exe zur Verfügung. Die Jobs können mit beliebigen Parametern und beliebig oft ausgeführt werden. Über einen Connect-String kann angegeben werden, an welchem Server sich das TestLab anmelden soll. Es ist möglich, mit vielen TestLabs an einem Server zu arbeiten, um somit Belastungstests durchzuführen. Das Programm wird standardmäßig im Serververzeichnis installiert. Der Referenz zu den einzelnen Jobs kann jeweils entnommen werden, welche Parameter für das Testprogramm anzugeben sind.
Zur Überwachung von Jobaufrufen steht der enaio® enterprise-manager zur Verfügung. Dort können sowohl Rechner wie auch Jobs spezifiziert werden, die überwacht werden sollen. Zu Jobs, zu denen Dateien mitgeschickt werden, können auch diese Dateien über ein temporäres Verzeichnis zugänglich gemacht werden.
Auf die Funktionen zur Jobüberwachung wird im enaio® enterprise-manager über den Bereich 'Erweiterte Administration / Überwachung / Jobaufrufe' zugriffen.
Dieser Abschnitt soll zur Erklärung einiger Begriffe dienen, die in der Dokumentation der Serverjobs auftauchen.
Cache-Verzeichnis – ist ein Verzeichnis unterhalb des Serverpfades (..\server\CACHE), welches dazu benutzt wird archivierte Dokumente, die aus Archivierungsmedien gelesen wurden für weitere Zugriffe bereit zu haben, damit der nächste Benutzer nicht auch zeitaufwendig auf das Archivierungsmedium zugreifen muss.
Flag - ist ein Parameter, der eine bestimme Eigenschaft aktivieren bzw. markieren soll.
OSTEMP-Verzeichnis – ist ein Verzeichnis, deklariert in der Umgebungsvariable OSTEMP, dass von einigen Jobs zur Zwischenlagerung oder Erzeugung für temporäre Dateien benutzt wird.
Work-Verzeichnis – ist ein Verzeichnis unterhalb des Serverpfades (..\server\WORK), welches als Ablageort für alle nicht archivierten Dokumente genutzt wird. Aus Gründen der Performance erfolgt die Ablage in diesem Verzeichnis und nicht in der Datenbank.
Parameter und Rückgabewerte, die in eckige Klammern '[Parameter]' eingeschlossen sind, sind optionale Parameter. Diese Parameter müssen, wenn sie nicht benötigt werden, beim Jobaufruf nicht angegeben werden.
PDF Guides
Tutorial Videos
Downloads
Popular Topics
User Forum