Komponenten

Allgemeines

Die Komponente Session Listing ist relativ klein und einfach. Sie stellt lediglich die Möglichkeit bereit, in der interaktiven Sitzung angezeigt zu bekommen, welche Sitzungen für die MyCoRe-Anwendung aktiv sind. Die Anfrage an das Servlet liefert eine XML-Datei zurück, welche über das mitgelieferte Stylesheet angezeigt wird. Ggf. kann dieses Stylesheet durch eine eigene Variante überschrieben werden.

Installation

Der MyCoRe-Kern enthält schon alle Dateien für die Integration der Komponente. Sie muss lediglich noch aufgerufen werden, z. B. in der navigation.xml mit href="/servlets/MCRSessionListingServlet".

Allgemeines

Abbildung 3.1: Grundübersicht des SimpleWorkflow

Für die Erstellung einfacher Anwendungen, welche nur einen relativ primitiven Arbeitsablauf bedingen, war es notwendig ein Werkzeug zur Gestaltung dieser Abläufe anzubieten. So entstand die Idee des SimpleWorkflow. Eigentlich handelt es sich dabei gar nicht um einen Workflow, sondern eher um eine Menge von kleinen Werkzeugen, die über HTTP-Requests zu einem interaktiven Arbeitsablauf zusammengefügt werden können. Der Begriff Workflow soll dabei die Bearbeitungsebene zwischen dem ersten Erstellen eines Objektes, seiner Bearbeitung und der Ablage im Server sowie die dabei vor sich gehenden Arbeitsschritte beschreiben. Physisch handelt es sich um ein Verzeichnis workflow, unter welchem für jeden Objekttyp Unterverzeichnisse angelegt sind, in welchen die Daten zwischengespeichert werden. Konsultieren Sie zum besseren Verständnis auch die Beschreibung im MyCoRe-User Guide.

Der SimpleWorkflow besteht im wesentlichen aus einer Sammlung von Servlets, die über HTTP-Requests angesprochen, verschiedene Bearbeitungsprozesse initiieren. Dabei wird gleichzeitig eine Berechtigungsprüfung für den Zugriff auf einzelne Aktionen durchgeführt. Für das Neuanlegen von Objekten ist die Permission 'create-'ObjectTyp bzw. für mandantenfähige Systeme 'create-'ObjectBase erforderlich. Ist das Objekt schon vorhanden, so entscheiden die ACL's des jeweiligen Objektes selbst über die Möglichkeit der Bearbeitung.

Tabelle 3.1: Permissionliste für den SimpleWorkflow

Bestandteile und Funktionen

Der SimpleWorkflow besteht aus einer Reihe von Servlets. Die folgende Tabelle listet die Servlets auf.

Tabelle 3.2: Übersicht der SimpleWorkflow-Servlets

Die folgende Abbildung soll noch einmal die Beziehungen der einzelnen Teile verdeutlichen. Hier gibt es zwei Komplexe. Der erste arbeitet mit dem Plattenzwischenspeicher und stellt einen simplen Workbasket dar. In diesen Korb können Objekte neu eingestellt, bearbeitet, ergänzt, geprüft oder wieder gelöscht werden. Ist dieser Arbeitsschritt fertig, so kann das Objekt in den Server hoch geladen werden. Hier gibt es wieder die Möglichkeit, so der Nutzer die Berechtigung dazu hat, Objekte zu bearbeiten, zu verändern oder zu löschen. Diese Schritte arbeiten direkt gegen den Server. Ausgangspunkt aller Aktivitäten ist dabei das MCRStartEditorServlet. Hier wird beim Aufruf eine Aktion mitgegeben, welche den weiteren Ablauf bestimmt. Entweder werden jetzt die ToDo's direkt ausgeführt (Löschen) oder es wird z.B. eine Web-Seite mit einer Editor-Maske aufgerufen. Diese wiederum beinhaltet im <target>-Tag das zu nutzende Verarbeitungs-Servlet, welches dann je nach Aufgabe wieder zu einer Web-Seite oder der Workflow-Ansicht verzweigt. Um weitere Aktionen in eigene Anwendungen zu integrieren, muss nur eine Servlet erstellt werden, welches eine Ableitung vom MCRStartEditorServlet ist und die neuen Aktionen implementiert. Mit MyCoRe 2.0 besteht die Möglichkeit, statt der Angabe des Types nun den Base-Bestandteil der MCRObjectID, also projectid_type anzugeben. Damit können Permissions für gleiche Datenmodelltypen bei unterschiedlicher Projekt-ID einzeln abgesichert werden.

Abbildung 3.2: Ablaufschema im SimpleWorkflow

Installation

In DocPortal sind die Funktionen bereits standardmäßig integriert. Bei der Verwendung in anderen Applikationen sind die nacholgenden Schritte auszuführen:

1. die folgende Zeile ist in das XSL-Stylesheet zu kopieren, welches die Auswertung Ihrer XML-Webseiten realisiert (z.B. MyCoReWebPage.xsl).
   <xsl:include href="workflow.xsl" />
2. Weiterhin finden Sie im Kern unter components/swf/xsl das Stylesheet mycoreobject-to-workflow.xsl. Dieses ist eine Transformationsvorlage für die Transformation von den XML-Objekt-Metadaten in eine SimpleWorkflow-interne XML Struktur. Für jeden Ihrer Metadaten-Typen muss eine solche Konverter-Datei mit Namen mycoreobject-<type>-to-workflow.xsl in Ihrer Anwendung vorhanden sein.
3. Als letztes muss der Workflow in eine XML-Webseite integriert und diese entsprechend über Menüpunkte aufgerufen werden. Aufgerufen wird ein Workbasket mit der eingebetteten Zeile
   <workflow base="MCRObjectID.Base" step="editor" /> oder
   <workflow type="MCRObjectID.Type" step="editor" />

Die Integration des SimpleWorkflow in die Präsentationsseiten erfolgt unter Einbeziehung der bereitgestellten Icons und eines dahinter liegenden Links. Dieses kann an beliebiger Stelle in der Präsentation platziert werden. Da die einzelnen Aktionsaufrufe sich in ihren Parametern doch erheblich unterscheiden sollten bei Bedarf die relevanten die entsprechenden Aufrufe im DocPortal-Beispiel zu Rate gezogen werden.

 
    <a href="{$ServletsBaseURL}MCRStartEditorServlet{$HttpSession}?
       tf_mcrid={$mcrid}&amp;       - MCRObjectID
       se_mcrid={$mcrid}&amp;       - MCRObjectID
       re_mcrid={$mcrid}&amp;       - Return MCRObjectID, nur für Derivate-ToDo, optional
       type={$type}&amp;            - MCRObjectID Typ, alte Variante, ggf. optional
       project={$project}&amp;      - MCRObjectID Base, neu, überschreibt type
       step=commit&amp;             - Arbeitsschritt
       todo=seditobj&amp;           - ToDo
       layout={$layout}"            - optional
    >
    <img
       src="{$WebApplicationBaseURL}images/static/workflow_objedit.gif" 
       title="{$OMD.EditorEdit}"/>
    </a>
    
    

Die Einbindung in den Editor erfolgt mit den folgenden Zeilen.

 
    <target type="servlet" name="MCRCheckNewDataServlet" method="post" format="xml" />
    oder
    <target type="servlet" name="MCRCheckEditDataServlet" method="post" format="xml" />
    oder
    <target type="servlet" name="MCRCheckCommitDataServlet" method="post" format="xml" />
    
    

Konfiguration

Die Konfiguration des SimpleWorkflow beschränkt sich auf einige wenige Dinge. Für MyCoRe 2.0 kann alternativ entweder auf den MCRObjectID.Type (alt) oder MCRObjectID.Base (neu) referenziert werden. Für jede Installation können einige Werte different sein, so dass es sich empfiehlt, diese in der mycore.private.properties abzulegen. Ein großer Teil der vom MCRStartEditorServlet veranlassten Aktionen ist so implementiert, dass Sie auf Wunsch eine E-Mail an eine oder mehrere E-Mail-Adressen schicken können. Wenn Sie für den Konfigurationswert, welcher durch das Paar [MCRObjectID.Base|MCRObjectID.Type].[todo] beschrieben wird, nichts angeben, so wird die E-Mail unterdrückt. Alle Angaben in diesem Konfigurationsabschnitt sind selbsterklärend. Anzugeben sind:

• allgemeine Angaben zur Mailverteilung
• die Verzeichnisnamen des Plattenspeichers,
• die Mail-Verteilung

 
    ##################################################################
    #  SimpleWorkflow                                                #
    ##################################################################
        
    # Generic mail configuration for MCRMailer
    # The server for outgoing mails
    MCR.Mail.Server=mail.mycore.de
    # The mail protocol
    MCR.Mail.Protocol=smtp
    # The debug option
    MCR.Mail.Debug=false
    # Encoding for the mail
    MCR.Mail.Encoding=UTF-8
    # Number of send tries to send the mail : 0 – off or n tries
    MCR.Mail.NumTries=1
    # Editor Mail adresses for Messages add1@serv1,add2,@serv2,...
    MCR.Mail.Address=mycore@mail.mycore.de

    # Editor path for directories
    MCR.SWF.Directory.base=%MCR.basedir%/data/workflow
    MCR.SWF.Directory.[MCRObjectID.Base|MCRObjectID.Type]=%MCR.basedir%
        /data/workflow/[MCRObjectID.Base|MCRObjectID.Type]
    ...

    # Editor flags for base/type and todo
    MCR.SWF.Mail.[MCRObjectID.Base|MCRObjectID.Type].
        [todo]=%MCR.Mail.Address%
    ...

    
    

Ergänzung eigener ToDo's

Das MCRStartEditorServlet gestattet eine Erweiterung mit eigenen Funktionen durch einfache Vererbung. Erstellen Sie eine Klasse MCRStartEditorServletMyToDo als Ableitung des MCRStartEditorServlet. Hierin können Sie nun Methoden definieren, welche als ToDo direkt aufgerufen werden können. Entsprechend der Konfiguration können dann auch Mails versendet werden.

 
package org.mycore.frontend.servlets;

import java.io.IOException;

/**
 * The class extends the MCRStartEditorServlet with a new method
 * 
 * @author Jens Kupferschmidt
 */
public class MCRStartEditorServletMyToDo extends MCRStartEditorServlet {

    private static final long serialVersionUID = 1L;

    /**
     * A new method. The access right is writedb.
     * 
     * @param job
     *            the MCRServletJob instance
     * @param cd
     *            the common data part
     */
    public void mytodo(MCRServletJob job, CommonData cd) throws IOException {
        // access right
        if (!MCRAccessManager.checkPermission(cd.mysemcrid, "writedb")) {
            job.getResponse().sendRedirect(job.getResponse().encodeRedirectURL(getBaseURL() + usererrorpage));
            return;
        }
        
        /** ToDo code */
        
        // back to the metadata view
        StringBuffer sb = new StringBuffer();
        sb.append(getBaseURL()).append("receive/").append(cd.mysemcrid);
        job.getResponse().sendRedirect(job.getResponse().encodeRedirectURL(sb.toString()));
    }

}
    
    

Ergänzung eigener Datenmodell-Datentypen

Werden dem bereits vorhandenen allgemeinen Datenmodell neue bzw. ergänzende Typen hinzugefügt, so muss die Prüfung und Vervollständigung des Output Validators für den Editor erweitert werden. Dazu muss in der Klasse MCREditorOutValidator eine Methode für die Klasse eingefügt werden. Die Klasse prüft den Output des Editor Framework und ergänzt fehlende Namespaces (z. B. für xml:lang).

 
    /**
     * @param datasubtag
     */
    boolean checkMCRMetaXYZ(Element datasubtag) {
        return checkMetaObject...(datasubtag, MCRMetaXYZ.class);
    }
    
    

Allgemeines

Für das Webservice-Module wird das Axis-Framework verwendet (http://ws.apache.org/axis/). Über den Webservice können MyCoRe-Objekte geholt und Queries in der neuen Abfragesprache ausgeführt werden. In dem Modul ist auch ein Beispiel eines Clients enthalten, der den installierten Webservice von MyCoRe nutzt.

Installation des Webservices

Hierzu müssen in der mycore.private.properties die Properties für den Axis-Administrator gesetzt werden:

MCR.ws_admin =Kennung des Axis-Administrators

MCR.ws_adminpasswd =und zugehöriges Passwort

Von ant webapps werden Kennung und Passwort in die Datei webapps/WEB-INF/users.lst eingetragen. Docportal wird wie gewohnt gestartet und durch Eingabe der Url

http://localhost:8080/servlets/AxisServlet

wird geprüft, ob Axis richtig konfiguriert ist. Danach wird das Deployment des Webservice mit ant webservice.deploy (docportal/modules/module-webservices/build.xml) durchgeführt. Ein erneuter Aufruf des AxisServlets zeigt den MyCoRe-Webservice mit dem Namen MCRWebService und den Methoden MCRDoRetrieveObject und MCRDoQuery an. Ein Klick auf die WSDL (Web Service Description Language) von MCRWebService zeigt die Parameter und Datentypen der Rückgabewerte an.

Mit ant webservice.undeploy wird das Undeployment des Webservice MCRWebService durchgeführt.

Mit folgendem Aufruf kann überprüft werden, ob der MCRWebService Ergebnisse liefert:

  
    http://localhost:8080/services/MCRWebService?method=MCRDoRetrieveObject&id=<mcrid>
    
    

Sollten Sie beim Deploy/Undeploy die Meldung „Exception in axis-admin“ oder „axis-admin failed with {http://xml.apache.org/axis/}HTTP (401)Unauthorized“ erhalten, setzen Sie wie am Anfang dieses Abschnittes beschrieben, Kennung und Passwort des Axis-Administrators. Nach einem erneuten ant webapps führen Sie ant webservice.deploy aus. Die Konfigurationsdatei für Axis ist docportal/config/server-config.wsdd.

Client für den Webservice erzeugen

Mit 'ant client.cmd' wird ein Webservice-Client erstellt, der den Webservice MCRWebService nutzt. Hierzu werden WSDL-Informationen vom Server geholt und mittels Axis die Stubs generiert und im Verzeichnis module-webservices/build/src gespeichert. Anschließend werden alle Daten kompiliert und module-webservices/build/bin/wsclient.cmd (Windows) gebaut.

[ToDo]: sh für Linux bauen]

Allgemeines

MyCoRe bietet einen Bildbetrachter, „Image-Viewer“ genannt, für das komfortable Betrachten von Bilddaten an. Dieser eignet sich sehr gut für Bildarchive oder jegliche Content-Repositories in denen Bilddaten verwaltet und angezeigt werden müssen. Der Bildbetrachter basiert (wie MyCoRe) auf Java und XML/XSL. Die Benutzerschnittstelle ist mit Javascript unter Verwendung der Frameworks PanoJS und jQuery realisiert.

Komponente IView2 – API zur Bildbearbeitung

Die IView2-Komponente befindet sich im MyCoRe-Kern und bietet eine API um Bilddaten in MyCoRe abzuspeichern, performant zu laden und gegebenenfalls zu verändern (Skalierung).

Bilder speichern

Für jedes (unterstützte) Bildformat wird beim Einstellen der Datei in MyCoRe ein asynchroner Kachelvorgang gestartet. Dabei wird das Bild in Kacheln à 256x256 Pixel zerlegt und so lange herunterskaliert und erneut gekachelt, bis das Thumbnail (x<=256 und y<=256) erstellt ist. Alle so entstanden Kacheln und Auflösungen werden für die spätere Verwendung gespeichert. Durch diese redundante Speicherung der Bilddaten verdreifacht sich schlimmsten Falls (wenn original JPEG ist) die Datenmenge. Bei unkomprimierten TIFF-Bildern liegt der Overhead bei ca. 10-15 Prozent.

Bilder ausgeben

Bilder können über den Image-Viewer angezeigt werden oder in festen Auflösungsstufen ausgegeben werden. Beim Image-Viewer wird entsprechend der Ausgabegröße wird entschieden, welche Kacheln für die Darstellung verwendet werden.

Schnittstellen

Hier nun eine Übersicht der Möglichkeiten die verschiedenen Kacheln/Darstellungen in die eigene Anwendung einzubinden. Der jeweilige Pfad muss dann im Zuge der Anwendungsentwicklung im gewünschten Stylesheet an der richtigen Stelle platziert werden.

Thumbnails (immer PNG 256x256 mit transparenten Rahmen):

/servlets/MCRThumbnailServlet/{derivateID}/{pfadZumBild}

Thumbnails original (immer JPEG und mit Kantenlänge <=256):

/servlets/MCRTileServlet/{derivateID}/{pfadZumBild}/0/0/0.jpg

Zusammengefügte Bilder in verschieden Auflösungen (immer JPEG):

/servlets/MCRTileCombineServlet/{Auflösung}/{derivateID}/{pfadZumBild}

Auflösung:

• "MIN" - 256 < Kantenlänge <=512
• "MID" - 512 < Kantenlänge <= 1024
• "MAX" - 1024 < Kantenlänge <= 2048

pfadZumBild: relativer Pfad innerhalb des Derivats inklusive der original Endung (z.B.: .tiff)

Einbinden des Bildbetrachters mittels XSLT (kompatibel mit IView1):

    	<xsl:call-template name="derivateView">
          <xsl:with-param name="derivateID" select="{derivateID}" />
        </xsl:call-template>

IView2-Metadaten eines Bildes:

/servlets/MCRTileServlet/{derivateID}/{pfadZumBild}/imageinfo.xml

ergibt:

    	<imageinfo  derivate="{derivateID}"path="/{pfadZumBild}"tiles="{AnzahlAllerKacheln}"
               width="{BreiteInPixeln}"height="{HöheInPixel}"zoomLevel="{maximalerZoomlevel}"//>

Allgemein

Die Firma Zoomify Inc. bietet einen Web-basierten Bildbetrachter an, der auf der Grundlage von gekachelten Bilder basiert und diese "on-demand" nachlädt. Innerhalb des Bildausschnitt kann stufenlos gezoomt werden.

Grundlagen

Um ein Bild über den Zoomify-Viewer anzeigen zu können, muss dieses zunächst aufbereitet werden. In Windows existiert dafür ein Midlet, in Linux kann ein Phyton-Skript genutzt werden. Bei der Datenaufbereitung werden Ausschnittbilder in verschiedenen Auflösungen erzeugt und in Ordnern abgelegt. Für das Zoomify-Servlet in MyCoRe kann der so entstandene Datenbestand in Zip-Archive verpackt werden (jedoch ohne Archiv-Kompression!). Somit wird das Handling extrem vereinfacht. Die Zip-Dateien werden dann als Derivat hochgeladen.

Bilder anzeigen

Für die Bildanzeige wird das Zoomify-Express-Plugin erwartet. Über das MCRStartZoomifyServlet wird die Anzeige der Bilder gesteuert. Zur Zeit findet sich eine adäquate Navigation wie beim IView zur Bildsteuerung im Servlet-Menü. Die Bilder werden über das MCRZipFileNodeServlet automatisch an das Plugin übergeben. Die Anzeigereihenfolge wird über die Mets/Mods-Datei definiert und ist zwingend erforderlich (siehe dazu den Abschnitt über das Mets/Mods-Modul).

Konfiguration

In der mycore.properties-Datei kann über die folgende Variable der Titel des Bildes in Abhängigkeit des zugrunde gelegten Objektes angezeigt werden:

MCR.Component.Zoomify.[type].identifier=[field of datamodel]

Hierbei steht [type] für den Objekttyp und [field of datamodel] für ein verknüpftes Feld aus dem Datenmodell.

Allgemein

Das Mets-Format ist ein Austauschformat in XML für mediale Inhalte. Besonders für die Darstellung von Bildern im DFG-Viewer wird das Format benötigt. Daneben nutzt der Zoomify-Bildbetrachter das Format als Reihenfolgenvorgabe bei Bilderserien.

Mets-Dateien erzeugen

Die Mets-Datei kann vom Derivat-Menü aus erzeugt werden und lässt sich via Java-Applet konfigurieren.

Konfiguration

Die Komponente kann über folgende Properties konfiguriert werden:

CommandLine-Befehle

Allgemeines

Dieses Modul ergänzt die Anwendung um die Funktionalität einer Runtime-Anwenderinformation. Als berechtigter Nutzer oder Administrator können Sie Nachrichten online generieren und versenden.

Konfiguration

In der konkreten Anwendung muss im Verzeichnis modules ein Unterverzeichnis module-broadcasting angelegt werden. Hier muss sich eine build.xml-Datei mit folgenden Targets befinden:

• create.default-rules – Es werden die erforderlichen Rechteeinträge erzeugt.
• webapps – Der Modul wird in die Web-Applikation integriert.

Die Nutzung des Modules in mehreren Anwendungen macht weiterhin die Existenz eines config-Verzeichnisses erforderlich. Darin sind die Dateien grant-broadcastinggroup.xml und mcr-module-broadcasting.xml abzulegen. Die Datei grant-broadcastinggroup.xml beschreibt die Gruppen und Nutzer, welche Nachrichten an die Anwendung versenden dürfen. Im Beispiel sind das alle Mitglieder der Gruppe admingroup.

 
    <?xml version="1.0" encoding="utf-8"?>
    <!-- this rule allways returns true -->
    <condition format="xml"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"    
       xsi:noNamespaceSchemaLocation="MCRCondition.xsd">
       <boolean operator="or">
         <condition value="admingroup" operator="=" field="group" />
       </boolean>
    </condition>
    
    

Mit den folgenden MyCoRe-Kommandos werden die Rechte für die Nutzung des Modules eingetragen. Bei Nutzung des ANT-Tagets create.default-rules erfolgt dies automatisch.

    mcrcmd> update permission manage for id module-broadcasting with rulefile grant-broadcastinggroup.xml
    
    mcrcmd> update permission read for id webpage:/servlets/MCRBroadcastingServlet?mode=getReceiverList with rulefile grant-broadcastinggroup.xml
      
    

Die Grundkonfiguration zum Versenden der Nachrichten ist in der Datei mcr-module-broadcasting.xml gespeichert. Sie stellt eine Voreinstellung dar, welche zum Ausführungszeitpunkt interaktiv verändert werden kann.

 
    <?xml version="1.0" encoding="ISO-8859-1"?>
    <mcr-module-broadcasting>
       <!-- on | off -->
       <!-- on = client will autmatically listen for new messages by AJAX -->
       <!-- off client won't listen for new messages -->
       <power>on</power>
   
       <!-- Seconds, in which intervall the client will ask for new messages -->
       <refreshRate>60</refreshRate>
    
       <!-- true | false -->
       <!-- true = User will get the same message again, if a new session is opened, even though the user already received 
            the message. This should be used, if a user login will be used by more than one person -->
       <!-- false = Each user will get a message only on times, indepently on the session. -->
       <sessionSensitive>false</sessionSensitive>
    
       <message.header>Sehr geehrte Mitarbeiter</message.header>
       <message.tail>Ihr Administrator</message.tail>
       <!-- <group/> &| <user> -->
    
       <!-- allowGuestGroup ("true|false")  if set to true all "gast" users are listen on the channel, if "false" only 
            user != "gast" are listen -->
       <receivers allowGuestGroup="false"/>
    
       <!-- <from> & <to> (ISO 8601) are NOT supported yet, -> use @send -->
       <!-- @send = ever | never --><!-- ever = send continuasly -->
       <!-- never = do NOT send -->
       <onAirTime send="ever">
          <from>2006-10-20T10:17:42.920Z</from>
          <to>2006-10-20T10:17:42.920Z</to>
       </onAirTime>
    
    </mcr-module-broadcasting>
    
    

Einbinden in die Anwendung

Der Aufruf des Broadcasting-Modules sollte aus der Navigation der Anwendung heraus erfolgen. Hierfür ist in der navigation.xml folgender Eintrag zu tätigen.

 
    <item 
       href="/servlets/MCRBroadcastingServlet?mode=getReceiverList"
       type="extern"
       target="_self"
       style="normal"
       replaceMenu="false"
       constrainPopUp="false">
         <label xml:lang="de">Nachrichten</label>
         <label xml:lang="en">Broadcasting</label>
    </item>
    
    

Der Include der benötigten XSLT-Stylesheets erfolgt in der Datei generatePage.xsl.

<xsl:include href="mcr-module-broadcasting.xsl" />

Als letztes ist dafür zu sorgen, dass der Listener in alle Webseiten im HEAD-Bereich eingetragen wird. Dazu ist das head-HTML-Tag um diese Zeile zu ergänzen.

<xsl:call-template name="module-broadcasting.getHeader"/>

Informationen zu Benutzung des Modules finden Sie im MyCoRe User Guide.