Die Arbeit mit der Beispielanwendung

Die Beispielanwendung bringt zur Demonstration bereits eine Reihe von Benutzern und Gruppen mit. Einer Gruppe können dabei mehrere Benutzer angehören. Die Vergabe von Rechten auf Objekte kann dann sowohl für einen einzelnen Benutzer als auch für eine ganze Gruppe erfolgen. Im Abschnitt "Zugriffsrechte auf Daten" wird dieses Zugriffssystem (ACL-System) näher erläutert.

Tabelle 6.1: Beispielgruppen in DocPortal

Tabelle 6.2: Beispielbenutzer in DocPortal

Alle in MyCoRe gespeicherten Objekte besitzen einen Zugriffsschutz über Access Control Lists (ACL). Dieser Schutzmechanismus ordnet jedem Objekt eine Reihe von Attributen zu, welche als Bedingung erfüllt sein müssen, damit der Zugriff auf das Objekt gewährt wird. Der Vergleich der in den ACL's gespeicherten Voraussetzungen gegen den aktuellen Zustand des Zugriffs erfolgt mittels der Sitzung (Session). In ihr werden alle Umgebungsinformationen wie zugreifende IP, Benutzer, usw. gespeichert. Das für MyCoRe implementierte ACL-System kennt drei Attribute für die Auswertung.

• Benutzer
• Gruppen
• Netzadressen in Form von IP's bzw. IP-Blöcken

Bei der interaktiven Eingabe neuer Daten werden standardmäßig im Projekt festgelegte Zugriffsregeln vorgegeben. Diese trennen sich in die Bereiche Lesen und Bearbeiten. Im Bereich des Bearbeitens wird wiederum in die Arbeit im Workflow und im Server-System unterschieden. Hier können jeweils die Arbeitsgänge Editieren und Löschen getrennt voneinander festgelegt werden. Für DocPortal sind folgende Berechtigungen (Permissions) definiert:

• read – gestattet den lesenden Zugriff
• writewf – gestattet das Schreiben bzw. Ändern, solange das Objekt im Simple Workflow (SWF) ist
• deletewf – gestattet das Löschen, solange das Objekt im Simple Workflow (SWF) ist
• writedb – gestattet das Schreiben bzw. Ändern, wenn das Objekt im Server ist
• deletedb - gestattet das Löschen, wenn das Objekt im Server ist

Die Permissions werden in der Editor-Verarbeitung des Neuanlegens eines Datensatzes aus einem Standard-ACL-Datensatz erzeugt. Hierzu kommt die Berechtigung des aktuellen Autors zu allen Bearbeitungsfunktionen. Die Leserechte sind für alle Benutzer zugelassen. Diese Einstellung gilt konkret für die Docportal-Anwendung. Für eigene Projekte kann dies ganz anders definiert werden. Die Permissions werden im Workflow-Prozess direkt im Datensatz gespeichert. Die Notation der Zugriffsregeln im Datenabschnitt services ist als Datentyp MCRMetaAccessRule im Abschnitt "Syntax des XML-Knotens service" näher beschrieben. Beim Einstellen (Hochladen) der Objekte in den Server werden die Regeln writewf und deletewf vollständig entfernt, da sie nicht mehr benötigt werden. Alle anderen Zugriffsregeln werden im MyCoRe-ACL-System in die Datenbank eingetragen und anschließend aus dem Originaldatensatz gelöscht. Damit ist das Objekt gesichert, ein Zugriff darauf benötigt nun immer die Zustimmung der ACL-Komponente. Eine Änderung der Permissions kann nun nur noch bei einer Schreibberechtigung erfolgen. Die interaktiven Komponenten von DocPortal bieten hier ein Aktionsfeld mit einem Editor-Formular an. Nutzer der Gruppe admingroup sind immer für den Zugriff berechtigt, auch wenn dies nicht explizit angegeben ist.

Um den einzelnen digitalen Objekten ggf. eine höhere Sicherheit zu geben, können ergänzende Permissions in den Derivate-XML-Daten angegeben werden. Bei einem Zugriff wird zuerst geprüft, ob Zugriffsrechte für den Metadatensatz bestehen, anschließend wird geprüft ob es zusätzliche Einschränkungen aus dem Derivate gibt. Standardmäßig ist im Derivate immer die Permission 'true' gesetzt, was keinen weiteren Einschränkungen entspricht.

Das ACL-System gestattet prinzipiell eine beliebige Sicherung mit anwendungsspezifischen Kriterien. Im Programmer Guide finden Sie detaillierte Informationen zur Weiterentwicklung Ihrer eigenen Applikationen.

Mit Hilfe der Kommandozeilenschnittstelle können Sie administrative Aufgaben für ihre MyCoRe-Anwendung auf Kommandozeilenebene durchführen. Dies ermöglicht auch die Abarbeitung von Scripts zu Massenverwaltung der eingestellten Daten. So können Sie etwa Objekte (Dokumente, Derivate, Personen, usw.) oder Klassifikationen in das Repository einlesen, aktualisieren und löschen, Suchen durchführen und Objekte in Dateien exportieren. Diese Funktionalitäten sind insbesondere bei einer Migration eines bestehenden Systems zur Sicherung der Daten sehr sinnvoll.

Die nachfolgenden Abschnitte sollen Ihnen eine Übersicht der möglichen Kommandos geben. Die einzelnen Kommandogruppen werden dabei intern in den Kommandokern importiert und stehen dem Benutzer zur Verfügung. Die mit dem MyCoRe-System ausgelieferten Kommandos können beliebig erweitert werden. Konsultieren Sie hierzu den MyCoRe Programmer Guide.

Basiskommandos des Kommandozeilensystems

Das Kommandozeilensystem enthält eine kleine Zahl an Basiskommandos. Diese sollen im folgenden Abschnitt beschrieben werden. Sie werden ergänzt durch weitere Kommandos für die einzelnen Bereiche der Arbeit mit MyCoRe. Es besteht auch die Möglichkeit, eigene Anwendungskommandos als Java-Klassen zu entwickeln und zu integrieren. Das Kommandozeilen-Tool ist mycore.sh bzw. mycore.cmd steht nach dem Erzeugen mittels ant create.scripts im bin-Verzeichnis der Anwendung bereit. In den unten stehenden Beschreibungen sind alle erforderlichen Parameter in der Form {n} notiert. n gibt dabei die Nummer des Parameters an. Die Zählung beginnt bei 0.

help

Zeigt alle möglichen Kommandos, auch die von der Anwendung hinzugefügten.

help {0}

Zeigt alle Kommandos, die mit {0} als Text beginnen

process {0}

Führt das im Parameter 0 angegebene System-Shell-Kommando aus.

! {0}

Führt das im Parameter 0 angegebene System-Shell-Kommando aus.

whoami

Zeigt den aktuellen Benutzer an.

login {0}

Startet einen Benutzerwechsel-Dialog für den Benutzer {0}.

change to user {0} with {1}

Wechselt den Benutzer {0} mit dem Passwort {1}.

show file {0}

Zeigt den Inhalt der Datei {0} an. Eine absolute Pfadangabe für {0} ist erforderlich.

show command statistics

Zeigt eine Statistik der ausgeführten Kommandos und der Laufzeiten an.

cancel on error

Beendet die Ausführung folgender Kommandos im Fehlerfall.

skip on error

Übergeht Kommandos, welche bei der Ausführung fehl schlagen.

exit

Beendet das Kommandozeilensystem.

quit

Beendet das Kommandozeilensystem.

Kommandos zur Arbeit mit der Benutzerverwaltung

Eine Gruppe der verfügbaren Kommandos der Kommandozeilenschnittstelle ermöglicht die Verwaltung von Benutzern und Gruppen. Diese Kommandos werden im folgenden vorgestellt. Oft werden bei den Kommandos XML-Dateien mit Definitionen von Benutzern oder Gruppen erwartet. Die Syntax dieser XML-Beschreibungen finden Sie im Programmer Guide. Es werden derzeit nur die wichtigsten Geschäftsprozesse der Benutzerverwaltung in den folgenden Kommandos abgebildet. Der Schwerpunkt liegt auf einem Management-Interface für administrativen Zugriff. Die vollständige GUI der Benutzerverwaltung (geplant für eine spätere Version) wird die Möglichkeit einer Bearbeitung aller Geschäftsprozesse bieten.

Allgemeine Verwaltungskommandos

init superuser

Dieses Kommando wird einmalig bei der Installation und Konfiguration des MyCoRe-Systems verwendet. Dabei werden Daten über den zu verwendenden Administrations-Account und den Gast-Account aus den Konfigurationsdateien gelesen, sowie das Benutzersystem initialisiert.

check user data consistency

Dieses Kommando dient zur Kontrolle der Konsistenz des Benutzersystems. Alle Verbindungen zwischen Benutzern und Gruppen werden kontrolliert und Unregelmäßigkeiten, die eventuell durch den Import von Daten ( siehe weiter unten) entstanden sind, werden ausgegeben.

set user management to ro mode

set user management to rw mode

Mit diesen Kommandos können die Daten der Benutzerverwaltung eingefroren werden. Dies sollte vor dem Exportieren von Daten in XML-Dateien geschehen, damit sich nicht während des Exports Daten geändert oder Objekte angelegt werden.

Kommandos zum Anlegen und Ändern von Gruppen und Benutzern aus XML-Dateien

create user data from file {0}

create group data from file {0}

Diese Kommandos erwarten eine XML-Datei als Parameter. In der Datei müssen ein oder mehrere Definitionen von Benutzern oder Gruppen existieren, die dann in das System übernommen werden. Ein Benutzerpasswort muss im Klartext in der definierenden XML-Datei vorliegen (für die Syntax siehe den Programmer Guide). Ist die Passwortverschlüsselung eingeschaltet (siehe mycore.private.properties), so wird das Passwort bei der Ablage in der Datenbank verschlüsselt. Bei der Erzeugung der Objekte wird die Korrektheit der Eingaben bezüglich vorhandener Regeln überprüft. So wird z.B. getestet, ob IDs doppelt vergeben wurden.

import user system from files {0} {1}

Dieses Kommando dient der Rekonstruktion des User Systems aus den abgesicherten Daten der Benutzer und Gruppen. Da eine direkte Abhängigkeit zwischen beiden Teilen besteht werden alle Daten mittels eines gemeinsamen Kommandos verarbeitet. Dabei ist {0} die Guppen- und {1} die Benutzerdatei der Sicherung.

update user data from file {0}

Mit diesen Befehlen werden bereits vorhandene Benutzer aktualisiert. Dabei ist zu bedenken, dass „update“ im Sinne von „festsetzen auf neue Werte“ zu verstehen ist, die Objekte also nach dem update genau die Definitionen haben, die in den XML-Dateien festgelegt werden. Einige der Attribute können allerdings nicht verändert werden, z.B. die Erzeuger-Accounts oder das Datum der Erzeugung. Sollen diese Daten unbedingt verändert werden, dann müssen die Objekte vorher gelöscht und neu angelegt werden.

export all users to file {0}

export all groups to file {0}

export user {0} to file {1}

export group {0} to file {1}

Mit diesen Kommandos werden alle oder einzelne Objekte der Benutzerverwaltung in XML-Dateien gespeichert. Passwörter von Benutzern werden bei eingeschalteter Verschlüsselung verschlüsselt abgelegt. Die so entstandenen Dateien können beispielsweise mit den import-Kommandos wieder geladen werden.

encrypt passwords in user xml file {0} to file {1}

Passwortverschlüsselung kann durch einen Konfigurationsparameter in der Datei mycore.properties.user aktiviert oder deaktiviert werden. Dieses Kommando wird benötigt, wenn man ein bestehendes System mit nicht eingeschalteter Verschlüsselung auf ein System mit Verschlüsselung migrieren will. Dabei verfährt man folgendermaßen: Zunächst werden alle Benutzer des alten Systems mit dem Kommando (siehe oben) export all users to file in eine XML-Datei exportiert. Daraufhin wendet man encrypt passwords in user xml file {0} to file {1} auf diese Datei an und erhält damit verschlüsselte Passwörter in den XML-Dateien. Mit dem Kommando (siehe oben) update user data from file können diese Daten in das System reintegriert werden. Danach muss die Kommandozeilenschnittstelle geschlossen und die Verschlüsselung in mycore.properties.user eingeschaltet werden.

Kommandos zum direkten Arbeiten mit Objekten der Benutzerverwaltung

delete user {0}

delete group {0}

Durch Angabe des Benutzer- oder Gruppennamens werden die Objekte mit diesen Kommandos aus dem System entfernt (und abhängige Objekte aktualisiert).

list all users

list user {0}

list all groups

list group {0}

Die Kommandos dienen dem Auflisten der Objekte der Benutzerverwaltung und sind selbsterklärend.

set password for user {0} to {1}

Mit Hilfe dieses Befehls kann das Passwort eines Benutzers direkt über die Kommandozeile gesetzt werden. Voraussetzung ist, dass die notwendigen Privilegien vorliegen.

enable user {0}

disable user {0}

Mit Hilfe dieser Kommandos können einzelne Benutzer temporär deaktiviert und wieder aktiviert werden. Ist ein Benutzer disabled, so kann er oder sie sich nicht mehr am System anmelden.

add user {0} as member to group {1}

remove user {0} as member from group {1}

Mit diesen Kommandos kann direkt auf die Mitgliederlisten von Gruppen zugegriffen werden, indem Mitglieder (sowohl Gruppen als auch Benutzer) hinzugefügt oder gelöscht werden können.

Das Sichern und Restaurieren der Benutzerverwaltungsdaten

Während der Initialisierung eines MyCoRe-Systems werden ein Administrations-Account und ein Gastzugang eingerichtet zusammen mit den zugehörigen primären Gruppen (siehe Kommando init superuser). Dadurch ist das Sichern und Reimportieren der gesamten Daten der Benutzerverwaltung mit etwas mehr Handarbeit verbunden, weil der Administrations-Account und Gastzugang zwar mit gesichert werden, aber vor einer Restauration der Daten z.B. nach einem Crash der SQL-Datenbank neu initialisiert werden müssen. Das bedeutet, dass sie bereits vorhanden sind und ein import user data from file deswegen nicht geht. Andererseits können sich die Daten dieser beiden Benutzer natürlich auch verändert haben, so dass die alten Daten wieder hergestellt werden müssen. Der folgende Ablauf führt zum Ziel. Dabei stehen <superuser> und <superuser-group> bzw. <guest> und <guest-group> für die in mycore.private.properties eingetragenen Parameter für den Administrations- und Gastzugang. In der MyCoRe-Kommandozeile werden die folgenden Befehle durchgeführt:

MyCoRe:> export user <superuser> to file <superuser.xml>
MyCoRe:> export user <guest> to file <guest.xml>
MyCoRe:> export group <superuser-group> to file 
         <superuser-group.xml>
MyCoRe:> export group <guest-group> to file <guest-group.xml>
MyCoRe:> export all users to file <all-users.xml>
MyCoRe:> export all groups to file <all-groups.xml>

Die Benutzer <superuser> und <guest> sowie die zugehörigen Gruppen müssen aus den Dateien <all-users.xml> bzw. <all-groups.xml> manuell entfernt werden. Dann können alle Daten in einer neu erstellten SQL-Datenbank folgendermaßen importiert werden:

MyCoRe:> init superuser
MyCoRe:> import user data from file <all-users.xml>
MyCoRe:> import group data from file <all-groups.xml>
MyCoRe:> update user data from file <superuser.xml>
MyCoRe:> update user data from file <guest.xml>
MyCoRe:> update group data from file <superuser-group.xml>
MyCoRe:> update group data from file <guest-group.xml>
MyCoRe:> check user data consistency

Kommandos zur Administration des ACL-Systems

load permissions data from file {0}

Das Kommando lädt statische Permissions aus der Datei {0}.

update permission {0} for id {1} with rulefile {2}

update permission {0} for id {1} with rulefile {2} described by {3}

update permission {0} for selected with rulefile {2}

update permission {0} for selected with rulefile {2} described by {3}

list all permissions

Das Kommando listet alle statischen Permissions.

delete permissions {0}

Das Kommando löscht die in {0} angegebene Permission.

delete all permissions

Das Kommando löscht alle statischen Permissions.

export all permissions to file {0}

Das Kommando sichert alle statischen Permissions in die unter {0} angegebene Datei.

Kommandos zum Verwalten von Klassifikationen

load classification from file {0}

Es wird eine Klassifikation in Form einer XML-Definition aus der Datei {0} gelesen und in das System geladen.

load all classifications from directory {0}

Es werden alle XML-Definitionen von Klassifikationen aus einem Verzeichnis {0} gelesen und in das System geladen.

update classification from file {0}

Es wird eine Klassifikation in Form einer XML-Definition aus der Datei {0} gelesen. Diese überschreibt die im System bereits geladene Klassifikation. Achtung, lassen Sie keine Kategorien einer bestehenden Klassifikation weg, da sonst Ihr System ggf. in einen inkonsistenten Zustand kommen kann! Referenzierte Kategoien werden nicht beseitigt.

update all classifications from directory {0}

es werden alle XML-Definitionen von Klassifikationen aus einem Verzeichnis {0} gelesen. Diese überschreiben die im System bereits geladenen Klassifikationen. Achtung, lassen Sie keine Kategorien einer bestehenden Klassifikation weg, da sonst Ihr System ggf. in einen inkonsistenten Zustand kommen kann! Referenzierte Kategoien werden nicht beseitigt.

delete classification {0}

Es wird eine Klassifikation mit der im Parameter {0} angegebenen MCRObjectID gelöscht. Sollten noch Referenzen existieren, wird das Löschen abgebrochen.

export classification {0} to {1} with {2}

Es wird eine Klassifikation mit der im Parameter {0} angegebenen MCRObjectID in eine Datei mit dem im Parameter {1} angegeben Namen gespeichert. Es wird zur Transformation der zu speichernden Daten das Stylesheet {2}-classification.xsl unter $DOCPORTAL_HOME/build/xsl verwendet.

export all classifications to directory {0} with {1}

Es werden alle im System befindlichen Klassifikationen in Dateien des Verzeichnisses mit dem im Parameter {0} angegeben Namen gespeichert. Es wird zur Transformation der zu speichernden Daten das Stylesheet {1}-classification.xsl unter $DOCPORTAL_HOME/build/xsl verwendet.

count classification children of {0}

Es werden die Referenzen zu den Kategorien der im Parameter {0} angegebenen Klassifikation mit der MCRObjectID gezählt.

list all classifications

Das Kommando listet alle in der Datenbasis gespeicherten Klassifikationen aus.

list classification {0}

Das Kommando listet die unter der MCRObjectID in der Datenbasis gespeicherte Klassifikation mit alle Kategorien aus.

Kommandos zur Verwaltung der Objekte

load object from file {0}

load all objects from directory {0}

load derivate from file {0}

load all derivates from directory {0}

die Kommandos laden die Metadaten-Objekte oder die Derivate inklusive ihrer Bilder und Dokumente von einer Quelldatei oder einem Quellverzeichnis in das System.

update object from file {0}

update all objects from directory {0}

update derivate from file {0}

update all derivates from directory {0}

die Kommandos laden die Metadaten-Objekte oder die Derivate inklusive ihrer Bilder und Dokumente von einer Quelldatei oder einem Quellverzeichnis in das System. Dabei werden die bestehenden Daten bis auf Strukturinformationen überschrieben. Strukturinformationen sind ggf. Daten über Vater-Kind- oder Objekt-Derivate-Beziehungen.

export object {0} to directory {1} with {2}

export object from {0} to {1} to directory {2} with {3}

export all objects of type {0} to directory {1} with {2}

export derivate of {0} to directory {1}

export derivate from {0} to {1} to directory {2}

export all derivates to directory {0} with {1}

die Kommandos speichern ein oder mehrere Metadaten-Objekte oder Derivate in ein Verzeichnis ab. Für die Parameter {0} und {1} bzw. {0} sind MCRObjectIDs anzugeben. Es werden zur Transformation der zu speichernden Daten die Stylesheets {3}-object.xsl und {3}-derivate.xsl unter $DOCPORTAL_HOME/stylesheets verwendet. Standard ist save-object.xsl bzw. save-derivate.xsl.

delete object {0}

delete object from {0} to {1}

delete derivate {0}

delete derivate from {0} to {1}

die Kommandos löschen einzelnen Metadaten-Objekte oder Derivate oder ganze Gruppen von selbigen. Alle Parameter müssen dabei MCRObjectID's sein.

delete all objects of type {0}

das Kommando löscht alle eingestellten Objekte eines bestimmten Datentypes.

delete all derivates

das Kommando löscht alle eingestellten Derivate.

show loadable derivate of {0} to directory {1}

das Kommando speichert den Content des Derivates vom Objekt mit der MCRObjectID {0} in das Verzeichnis {1}.

Kommandos zur Arbeit mit dem ImageViewer

tile images of all derivates

das Kommando erzeugt Kacheln für alle Bilddateien (deren Formate unterstützt werden).

tile images of derivate {0}

das Kommando erzeugt Kacheln für alle Bilddateien im angegebenen Derivat {0}.

tile image {0} {1}

das Kommando generiert die Kacheln für die angegebenen Datei aus dem Derivate {0} entsprechend des absoluten Pfades {1}.

check tiles of image {0} {1}

das Kommando prüft alle Kacheln der angegebenen Datei aus dem Derivate {0} entsprechend des absoluten Pfades {1} und generiert bei Bedarf neue Kacheln.

delete tiles of image {0} {1}

das Kommando löscht alle Kacheln der angegebenen Datei aus dem Derivate {0} entsprechend des absoluten Pfades {1}.

Anfragen an das System per Kommandozeile

run query from file {0}

das Kommando startet eine Anfrage mit einer Query, welche im File {0} steht.

run local query {0}

das Kommando startet eine Anfrage gegen das lokale System mit einer Query, welche im String {0} steht.

run distributed query {0}

das Kommando startet eine Anfrage gegen alle bekannten Systeme mit einer Query, welche im String {0} steht.

Sonstige Kommandos

repair metadata search of type {0}

repair metadata search of ID {0}

die Kommandos lesen die XML-SQL-Tabellen und reparieren zerstörte Metadaten-Suchindizes. Das Kommando kann auch beim Wechsel eines SearchStore angewendet werden.

repair derivate search of type derivate

repair derivate search of ID {0}

die Kommandos lesen die gespeicherten Datenobjekte und reparieren zerstörte Volltext-Suchindizes. Das Kommando kann auch beim Wechsel eines SearchStore angewendet werden.

get last ID for base {0}

get next ID for base {0}

show last object ID for base {0}

show next object ID for base {0}

die Kommandos liefern die nächste freie oder die letzte MCRObjectID für eine vorgegeben MCRObjectID-Basis zurück. Die Basis besteht aus Projekt- und Type-String in der Form project_type. (Siehe Abschnitt zur MCRObjectID)

check file {0}

prüft eine im Parameter {0} angegebene Datei mittels XML-Parser.

init hibernate

das Kommando initialisiert den Hibernate-SQL-Store. Das Kommando ist nur einmal erforderlich!

Das SimpleWorkflow-System wurde entwickelt, um mit einem einfachen Werkzeug die interaktive Autoren- und Editorenarbeit zu ermöglichen und damit eine sinnvolle Arbeit mit einer MyCoRe-Applikation zu ermöglichen. Es ist jedoch so konzipiert, dass es auch über eine Servlet-Schnittstelle in größere Workflow-Engines eingebunden werden kann. Einen Workflow im eigentlichen Sinne gibt es nur sehr eingeschränkt und in einfachem Ablauf. Weiterführende organisatorische Maßnahmen waren auch nicht Ziel dieser Entwicklung.

Die Komponente wurde in ein Modul verlagert und ist somit durch andere Komponenten ersetzbar. Eine genaue Beschreibung der Details zur Integration finden Sie im Programmer Guide. Die wichtigsten Merkmale dieses Moduls sind:

• Mit dem System kann ein einfacher Eingabe- und Bearbeitungs-Dialog realisiert werden.
• Eingabe und Bearbeitung werden durch eine Rechtekontrolle mittels des ACL-System realisiert. Nur berechtigte Benutzer dürfen die Daten verändern.
• Die Zwischenspeicherung aller eingehenden Daten erfolgt zuerst auf einem Plattenbereich, so dass bei Fehlern ggf. auch der Administrator direkt eingreifen kann. Daten die erfolgreich in den Server geladen wurden, werden aus diesem Plattenbereich gelöscht.
• Das System benutzt die MyCoRe-interne Editor-Komponente.
• Das System basiert auf einer Reihe von Servlets, XML-Seiten und Stylesheets, sowie der Einbindung in die Editor-Formulare.
• Alle Funktionen werden über ein einheitliches Servlet initiiert (MCRStartEditorServlet). Die möglichen Aufrufe sind weiter unten notiert.

Abbildung 6.1: Funktionsschema des SimpleWorkflow

Das MCRStartEditorServlet

Dieses Servlet ist der Einstiegspunkt für die Nutzung des SimpleWorkflow-Systems. Von ihm aus werden alle Verarbeitungsprozesse angestoßen. Das Servlet seinerseits startet dann wieder Web-Dialoge oder führt selbstständig Aktionen aus. Dabei sind die folgenden Startparameter von Interesse:

Tabelle 6.3: Parameter des MCRStartEditorServlets

Die nächsten Tabellen sollen eine Übersicht der möglichen Aktionen geben. Jede Aktion ist dabei an eine entsprechende Berechtigung gebunden, welche der aktuelle Benutzer gerade haben muss. Hat er sie nicht, so wird seine Aktion abgewiesen und nicht ausgeführt. Dabei wird noch nach dem Datenmodell-type unterschieden, d.h. ein Benutzer muss für genau diesen type auch die Berechtigung haben. Die Aktionen unterscheiden sich in dem Ziel-Store, todo=w... steht für den Plattenbereich; todo=s... arbeitet mit den bereits eingestellten Server-Daten. Der Parameter layout ist optional und dient der Verfeinerung der möglichen Arbeitsschritte. Während alle Aktionen, die mit einem w beginnen auf dem Plattenbereich (workflow) arbeiten, veranlassen alle Aktionen mit s einen Zugriff und Änderungen im Server-System.

Tabelle 6.4: Mögliche Aktionen mit dem MCRStartEditorServlet auf dem Plattenbereich

Tabelle 6.5: Mögliche Aktionen mit dem MCRStartEditorServlet im Server

Abläufe für neue Datenobjekte

Die Abläufe für die Eingabe neuer Datensätze sind praktisch für alle Datenmodelle gleich. Lediglich die Anbindung der Derivate an die Metadaten-Objekte ist nicht immer gegeben. Das hängt allein an der Gestaltung des jeweiligen Datenmodell-Konzeptes für ein Projekt (z.B. haben Personendaten im DocPortal-Projekt keine eigenen Derivate). Wird beim SimpleWorkflow ein neues Objekt eingestellt, so befinden sich alle relevanten Daten vorerst auf einem Plattenbereich, der über die Konfiguration festgelegt wird. Erst wenn das Commit (Laden) zum Server-System ausgeführt wurde, werden die Daten von diesem Zwischenspeicher wieder gelöscht. Jeder Datenmodell-type hat dabei in der Regel ein eigenes Verzeichnis innerhalb des Workflow-Plattenbereiches.

Abläufe für Datenobjekte aus dem Server

Wurden Datenobjekte in den Server eingebracht, so steht Benutzern, welche berechtigt sind, die Möglichkeit einer Änderung der Daten und/oder das Löschen der selben frei. Für das Bearbeiten der Daten werden diese zwischenzeitlich auf dem Plattenbereich gespeichert. Bei erfolgreicher Beendigung einer Aktion werden die temporären Daten wieder vom Plattenbereich gelöscht. Im Falle eines Fehlers kann über den Zugriff auf den Plattenbereich (Workflow) und entsprechender Aktionen der Fehler behoben werden. Alle Commits sind als Update ausgelegt, so dass ältere Versionen im Server auch bei einem Commit vom Workflow als Folge eines Fehlers überschrieben werden. Einzelheiten zu den Abläufen finden Sie im Programmer Guide.

Einbindung in das Access Control List - System

In den Bearbeitungsstufen gibt es jeweils einen Button, welcher es gestattet, die ACL's (Access Control Lists – Zugriffslisten) zu ändern. Dies geschieht über zusätzliche Eingabemasken. Alle Änderungen wirken direkt und sofort.

In Bibliotheken spielen Klassifikationen eine große Rolle. Eine Klassifikation in MyCoRe ist eine hierarchische festgeschriebene Darstellung von Kategorien, welche nach bestimmten Ordnungsprinzipien und Eigenschaften gestaltet ist. Die Menge der Klassen/Kategorienamen bilden ein kontrolliertes Vokabular, das es ermöglicht, Dokumente nach den Kriterien der Klassifikation zu ordnen. In den Metadaten der Dokumente können beliebige Klassifikationen und Kategorien dem Dokument zugeordnet werden. Typische Klassifikationen wie Dokumentformate, Dokumententyp, Herkunft für die formale Zuordnung von Dokumenten aber auch Sachgruppen der DNB und Pacs für die inhaltliche Klassifizierung werden von MyCoRe im Content-Zweig bereits mitgeliefert.

Mit dem Klassifikationsbrowser bietet MyCoRe die Möglichkeit über Klassifikationen zu navigieren und so zu den zugehörigen Dokumenten zu gelangen. Syntax und Beschreibung von Klassifikationen wurden bereits in Kapitel 6 dargestellt.

Abbildung 6.2: Auswahl der zu bearbeitenden Klassifikation

Start des Klassifikationseditors

Der Editor wird über den Klassifikationsbrowser mit dem Parameter mode=edit gestartet.

Beispiel:
http://localhost:8291/browse?mode=edit

Erfüllen die Privilegien des Nutzers die Anforderungen, erhält man zunächst eine Liste aller im System installierten Klassifikationen, also auch die, die nicht über den Klassifikationsbrowser eingebunden sind. Die nicht eingebundenen Klassifikationen werden mit den Parametern aus dem Default-Block gesteuert!

Operationen des Klassifikationseditors

Klassifikationen

Neue Klassifikation erstellen

Über den Button [neue Klassifikation erstellen] kann eine Klassifikation angelegt werden. Dazu ist es notwendig mindestens ein Label für die Klassifikation anzugeben. Es können Label und zugehörige Beschreibungen in verschiedenen Sprachen angelegt werden, sowie eine URL.
Die ID der Klassifikation wird vom System vergeben.

Klassifikation importieren

Über den Button [Klassifikation importieren] kann eine neue Klassifikation vom Dateisystem in MyCoRe importiert werden, oder eine bereits im System vorhandene Klassifikation aktualisiert werden. Ist der Import der Klassifikation nicht erfolgreich (z.B. XML ist nicht valide, oder die zu aktualisierende Klassifikation existiert nicht im System) erfolgt eine Fehlermeldung und die Klassifikation wird nicht importiert.
Bei Erfolg wird automatisch wieder auf die Liste aller im System vorhandenen Klassifikationen zurückgesprungen.

Export der Klassifikation

Mit dieser Funktion kann die ausgewählte Klassifikation in einem Extra-Browserfenster im XML-Format angezeigt werden oder auch über die rechte Maustaste auf dem lokalen Dateisystem gespeichert werden.

Editieren der Klassifikation

Die Beschreibungsdaten der ausgewählten Klassifikation können über ein Editorformular geändert werden. Es können weitere Label in anderen Sprachen hinzugefügt werden. Die ID kann nicht verändert werden. Ein Label muss für die Klassifikation mindestens belegt sein.

Löschen der Klassifikation

Die ausgewählte Klassifikation wird, inklusive der eventuell vorhandenen Kind-Kategorien gelöscht, nachdem geprüft wurde ob es keine Referenzen zu Objekten gibt. Im Browser ist das durch die Anzeige der Dokumentanzahl bereits sichtbar. Klassifikationen, bei denen eine Anzahl>0 gezählt wurde besitzen daher keinen [Delete] Button.
Im Erfolgsfall wird wieder die aktuelle Klassifikationsliste ohne das gelöschte Klassifikations-Item angezeigt.

Kategorien

Beim Klick auf eine der aufgelisteten Klassifikationen wird die erste Ebene der Klassifikation mit den zugehörigen Kategorien geöffnet.

Abbildung 6.3: Einzelne Kategorien einer Klassifikation bearbeiten

Die aktuell manipulierte Kategorie wird zur besseren Übersicht farblich hervorgehoben.

Für Kategorien gibt es folgende Aktionsmöglichkeiten:

Neue Kategorie anlegen

Unter der ausgewählten Kategorie wird eine neue Kategorie angelegt. Dazu wird ein Editorformular für die Angaben von ID, Label und Beschreibung geöffnet. Die Felder sind zunächst mit den Werten der Vorgängerkategorie (also der Ausgewählten unter der die neue Kategorie angelegt werden soll.) belegt.
Beim Abspeichern wird die Eindeutigkeit einer Kategorie-ID für die Klassifikation geprüft. Ist sie nicht eindeutig erfolgt einen Fehlermeldung. Im Erfolgsfall wird wieder die aktuelle Klassifikationsebene mit dem neuen Kategorie-Item angezeigt.

Editieren der Kategorie

Die ausgewählte Kategorie wird im das Editorformular geladen. Die Angaben von ID, Label und Beschreibung können manipuliert werden.
Beim Abspeichern wird die Eindeutigkeit einer Kategorie-ID für die Klassifikation geprüft. Ist sie nicht eindeutig erfolgt einen Fehlermeldung. Im Erfolgsfall wird wieder die aktuelle Klassifikationsebene mit dem modifizierten Kategorie-Item angezeigt.
Die Kind-Knoten, die an der Kategorie möglicherweise hängen werden nicht geändert.

Löschen der Kategorie

Die ausgewählte Kategorie wird, inklusive der eventuell vorhandenen Kind-Kategorien gelöscht, nachdem geprüft wurde ob es keine Referenzen zu Objekten gibt. Im Browser ist das durch die Anzeige der Dokumentanzahl bereits sichtbar. Kategorien, bei denen eine Anzahl >0 gezählt wurde besitzen daher keinen Delete–Button.
Im Erfolgsfall wird wieder die aktuelle Klassifikationsebene ohne das gelöschte Kategorie-Item angezeigt.

Verschieben der Kategorie

Eine Kategorie kann in der Hierarchie im Baum verschoben werden. Je nach Position im Baum sind die Verschiebemöglichkeiten Aufwärts, Abwärts, nach Links und Rechts möglich.
Auf- und Abwärts-Verschieben verändert die Position der jeweils gewählten Kategorie um 1 Stelle in der aktuellen Ebene.
Die Rechts-Verschiebung bewirkt, dass die Kategorie zur Kind-Kategorie der darüber positionierten Kategorie wird. Dabei werden auch alle in der ausgewählten Kategorie eventuell vorhandenen Kindelemente mit verschoben. Die Kategorie wird quasi in die darüber positionierte Kategorie hinein geschoben und dort an das Ende dieser Ebene angehangen, also eine Ebene tiefer angelegt.
Die Links-Verschiebung bewirkt das Gegenteil der Rechts-Verschiebung, dass die Kategorie aus der Ebene in die darüber liegende Ebene geschoben wird. Dabei werden auch alle in der ausgewählten Kategorie eventuell vorhandenen Kindelemente mit verschoben. Die Kategorie wird quasi in die darüber liegende Ebene geschoben und dort an das Ende der Ebene angehangen.