2015.05

Simple Workflow

Die SimpleWorkflow-Komponente (swf)

Allgemeines

SimpleWorkflow allgemein

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.

ACL-Permission Bedeutung
writewf Gestattet das Bearbeiten der Objekte im Workflow (d. h. auf dem Plattenbereich).
deletewf Gestattet das Löschen von Objekten im Workflow (d. h. auf dem Plattenbereich).
writedb Gestattet das Bearbeiten von Objekten im Server.
deletedb Gestattet das Löschen der Objekte aus dem Server.

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.

Servlet Funktion
MCRStartEditorServlet Das Servlet dient als Startpunkt für alle Arbeiten mit dem SimpleWorkflow.
MCRCheckCommitDataServlet Wird vom Editor über ein <target>-Tag aufgerufen und schreibt die Metadaten nach Bearbeitung in den Server.
MCRCheckEditDataServlet Wird vom Editor über ein <target>-Tag aufgerufen und schreibt die Metadaten nach deren Bearbeitung auf die Platte.
MCRCheckNewDataServlet Wird vom Editor über ein <target>-Tag aufgerufen und schreibt die neuen Metadaten auf die Platte.
MCRCheckCommitFileServlet Wird vom Editor über ein <target>-Tag aufgerufen und schreibt die Derivate-Daten nach Bearbeitung in den Server.
MCRCheckNewFileServlet Wird vom Editor über ein <target>-Tag aufgerufen und schreibt die neuen Derivate-Daten auf die Platte.
MCRFileListWorkflowServlet Listet die auf der Platte befindlichen Dateien in den Derivaten auf.
MCRFileViewWorkflowServlet Gestattet den Zugriff auf eine Derivate-Datei auf der Platte.
MCRListDerivateServlet Listet alle auf der Platte befindlichen Derivate auf.
MCRListWorkflowServlet Erzeugt einen XML-Baum, welcher zur Darstellung des Workflow (Platteninhaltes) benötigt wird.

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.

SimpleWorkflow

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);
    }
    
    

Das SimpleWorkflow-System zur interaktiven Autorenarbeit

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.
Funktionsschema SimpleWorkflow

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:

Parameter Bedeutung
todo Zeigt an, welche Aktion auszuführen ist.
type Gibt den Datenmodell-Typ des Metadaten-Objektes an.
step Gibt den Verarbeitungsschritt an (z. B. author, editor, commit).
layout Gestattet eine verfeinerte Angabe des Verarbeitungsschrittes (ist optional).
tf_mcrid Enthält eine MCRObjektID, welche neu hinzugekommen und/oder dem System noch nicht bekannt ist. Die Gültigkeit wird geprüft.
se_mcrid Enthält eine MCRObjectID, welche aus einem Datensatz oder ähnlichen Quellen extrahiert wurde und gültig sein sollte.
re_mcrid Enthält eine weitere MCRObjectID, welche aus einem Datensatz oder ähnlichen Quellen extrahiert wurde und gültig sein sollte (z.B. zugehöriger Metdatensatz).
extparm Erweiterungsparameter, wie in einigen wenigen Fällen benutzt.

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.

Aktion todo ID Permission ruft
Anlegen neuer Metadaten wnewobj tf_mcrid create-type editor_form_author-type[-layout].xml
Anlegen eines Neuen Derivates wnewderse_mcrid create-type MCRStartEditorServlet?todo=waddfile
Hinzufügen neuer Dateien aus dem Upload waddfile se_mcrid re_mcrid writewf fileupload_new.xml
Bearbeiten von Metadaten weditobjse_mcrid writewf editor_form_type_[layout_]editor.xml
Bearbeiten des Label eines Derivate-Metadaten-Satzes weditderse_mcrid re_mcrid writewf editor_form_derivate_editor.xml
Löschen aller Daten eines Objektes wdelobj se_mcrid deletewf editor_type_editor.xml
Löschen eines Derivates wdelder se_mcrid deletewf editor_type_editor.xml
Löschen einer Datei aus einem Derivate wdelfile se_mcrid writewf editor_type_editor.xml
Setzen der Hauptdatei in einem Derivate wsetfilese_mcridwritewf editor_type_editor.xml
Hochladen eines Datensatzes vom Plattenbereich zum Server wcommit se_mcrid writedb MCRQueryServlet mit der ID mit mode=ObjectMetadata

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

Aktion todo ID Permission ruft
Bearbeiten der Metadaten seditobj se_mcrid writedb MCRQueryServlet mit der ID mit mode=ObjectMetadata
Bearbeiten des Label der Derivate-Metadaten seditder se_mcrid re_mcrid writedb editor_form_commit_derivate.xml
Löschen eines Datenobjekts sdelobj se_mcrid deletedb editor_deleted.xml
Löschen eines Derivates von einem Datenobjekt sdelder se_mcrid re_mcrid deletedb MCRQueryServlet mit der ID mit mode=ObjectMetadata
Hinzufügen eines neuen Derivates zu einem Datenobjekt des Servers; Zwischenablage der Daten auf dem Plattenbereich snewder re_mcrid writedb MCRStartEditorServlet?todo=saddfile
Hinzufügen von Daten zu einem Derivate aus dem Server; Zwischenablage der Daten auf dem Plattenbereich snewfile se_mcrid re_mcrid writedb MCRStartEditorServlet?todo=saddfile
Upload von Datenobjekten in die Zwischenablage saddfile se_mcrid re_mcrid writedb MCRStartEditorServlet?todo=scommitder
Setzen Des Label in einem Derivate ssetlabel se_mcrid re_mcrid writedb MCRQueryServlet mit der ID mit mode=ObjectMetadata
Setzen der Main File Markierung im Derivate ssetfile se_mcrid re_mcrid writedb MCRFileNodeServlet mit der ID des Derivates
löschen einer Datei aus einem Derivate sdelfile se_mcrid re_mcrid writedb MCRFileNodeServlet mit der ID des Derivates

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.

 Jens Kupferschmidt