2020.06 2021.06

Das EventHandler-Modell

Funktionsprinzipien und Implementierungen der EventHandler

Allgemein

Das EventHandler-Basispaket realisiert eine bessere Trennung der Code-Schichten des Datenmodells und der Backends. Im Datenmodell werden nur Ereignisse ausgelöst werden (z.B. create, delete usw.), welche dann bestimmt durch die Konfiguration in den Property-Dateien verarbeitet werden. Es existiert ein allgemein gültiges Template-Modell, welches für die erforderlichen Anwendungsfälle ausgebaut wird. Ein singleton-Manager-Prozess nimmt nur ein Ereignis entgegen, wählt die dafür bestimmte Konfiguration aus und startet die Methode doHandleEvent(MCREvent evt). Dies geschieht in der Reihenfolge, welche in der Konfiguration angegeben ist und stellt ein Pipeline-Verfahren dar. Das Event-Objekt wird dabei nacheinander an die Handler durchgereicht. Änderungen an den im Event-Objekt gespeicherten Daten werden also für alle folgenden Handler wirksam. Kommt es bei einem Handler zu einer Ausnahme, so wird diese vom Manager aufgefangen und es wird für alle in der Pipeline davor liegenden Handler die Methode undoHandleEvent(MCREvent evt) initiiert. Somit ist ein Rollback möglich. Je nach Anwendung ist es möglich, verschiedene Pipelines für unterschiedliche Abläufe unabhängig voneinander zu implementieren, z.B. eine Pipeline für die Verarbeitung der Metadaten und eine andere für die Volltextindizierung der Dokumente. Die Pipelines und die damit verbundenen Ereignisse unterscheiden sich am Namen der jeweiligen Pipeline.

Das EventHandler-Modell (Bsp. Metadaten-Objekte)

Das EventHandler-Modell wird beispielsweise eingesetzt, um Objekte vom Typ MCRObject persistent zu speichern. Das Klassendiagramm (Abbildung 1.6) verdeutlicht die Zusammenhänge.

  1. Das MCRObject erzeugt ein neues Ereignis, welches in diesem Fall die vordefinierte Pipeline OBJECT_TYPE und das vordefinierte Ereignis CREATE_EVENT nutzt. Es können aber auch beliebige Strings eingetragen werden. Dabei ist aber auf die Konsistenz zu achten.
    MCREvent evt = new MCREvent(MCREvent.OBJECT_TYPE, MCREvent.CREATE_EVENT);
  2. Nun wird dem neuen Ereignis das Datum übergeben, welches an die Handler weitergereicht werden soll. Ein Ereignis kann auch mehrere Daten beinhalten.
    evt.put("object",this);
    Klassendiagramm

    Abbildung: Klassendiagramm des EventHandler-Modells

  3. Die folgende Zeile ruft abschließend den MCREventManager auf und stößt die Handler für die Pipeline an.
    MCREventManager.instance().handleEvent(evt);

Die Konfiguration des EventHandler-Managers

Für die Nutzung des EventHandler-Konzeptes gib es in der vom Kern mitgelieferten Konfiguration mycore.properties eine Reihe von Voreinstellungen, welche im Standardfall vollständig funktionieren. Sollen davon abweichende Implementierungen zum Einsatz kommen, so sind die entsprechenden Properies in den lokalen Property-Dateien zu überschreiben. Sollen Schritte zwischen zwei Handlern durch eigene Handler durchgeführt werden, können diese über das Nummernschema an die entsprechende Stelle eingefügt werden.

Für jeden Event-Typ (in diesem Fall ist es MCRObject = MCREvent.OBJECT_TYPE) ist eine Kette von Handlern in der folgenden Form definiert. Jeder Standard-Handler bekommt dabei eine aufsteigende Nummer in Zehnerschritten. Einige EventHandler enthalten die Implementation sowohl für MCRObjecte wie auch MCRDerivate.

1
MCR.EventHandler.MCRObject.010.class=org.mycore.access.MCRAccessEventHandler

Wollen Sie eigene EventHandler schreiben und diese einbinden, so ist es ratsam diese direkt von MCREventHandler abzuleiten und analog zu den bestehenden Handlern einzubinden. Sie können dafür auch neue Pipelines und Ereignisse definieren. Den MCREventManager können Sie nun an beliebiger Code-Stelle einbauen und ihm ein von Ihnen definiertes Ereignis übergeben. Diese Komponente ist allgemein verwendbar und nicht auf das MyCoRe-Datenmodell festgelegt.

Liste der verfügbaren EventHandler

EventHandler für MCRClassification

optional
010
Enthalten in mycore-base
org.mycore.access.MCRAccessEventHandler
Der MCRAccessEventHandler liest die Sektion /mycore.../services/servacls des eingehenden Objektes und trägt die gelesenen ACL-Informationen in die ACL-Komponente von MyCoRe ein. Anschließend wird diese Datensektion aus dem in der pipeline weiterzurechenden Datensatz entfernt.
Alternative
zu 010
Enthalten in mycore-base
org.mycore.access.MCRRemoveAclEventHandler
Der MCRRemoveAclEventHandler entfernt alle ACL-Informationen aus dem Objekt. Er ist für Access-Strategien gedacht, welche von globalen Zugriffsrechten für Objektgruppen von MCR-Projekten oder MCR-Typen implementieren. Dieser Handler sollte in dem Fall den MCRAccessEventHandler überlagern.

EventHandler für MCRObject

optional
010
Enthalten in mycore-base
org.mycore.access.MCRAccessEventHandler
Der MCRAccessEventHandler liest die Sektion /mycore.../services/servacls des eingehenden Objektes und trägt die gelesenen ACL-Informationen in die ACL-Komponente von MyCoRe ein. Anschließend wird diese Datensektion aus dem in der pipeline weiterzurechenden Datensatz entfernt.
Alternative
zu 010
Enthalten in mycore-base
org.mycore.access.MCRRemoveAclEventHandler
Der MCRRemoveAclEventHandler entfernt alle ACL-Informationen aus dem Objekt. Er ist für Access-Strategien gedacht, welche von globalen Zugriffsrechten für Objektgruppen von MCR-Projekten oder MCR-Typen implementieren. Dieser Handler sollte in dem Fall den MCRAccessEventHandler überlagern.
optional
011
Enthalten in mycore-acl
org.mycore.mcr.acl.accesskey.MCRAccessKeyEventHandler
Der MCRAccessKeyEventHandler importiert Zugriffsschlüssel beim Import/Erstellung eines MyCoRe Objekts aus dem accesskey Servflag und löscht das Servflag anschließend. Beim Löschen eines Objekts werden alle Zugriffsschlüssel gelöscht. Beim Updaten eines Objekts wird der Servflag gelöscht und somit nicht verarbeitet bzw. ignoriert.
012 Enthalten in mycore-base
org.mycore.access.MCRAccessCacheEventHandler
Beim Update oder Löschen eines MyCoRe Objekts löscht der Eventhandler alle Einträge für das Objekt, seine Derivate und seine Kinder im AccessCache aller aktiven MCRUserSessions.
optional
013
Enthalten in mycore-mods
org.mycore.mods.MCRExtractRelatedItemsEventHandler
Nur relevant für die MODS Unterstützung. Der MCRExtractRelatedItemsEventHandler extrahiert mods:relatedItem Elemente und speichert sie als separate MyCoRe Objekte, die dann miteinander verlinkt werden.
optional
015
Enthalten in mycore-base
org.mycore.oai.classmapping.MCRClassificationMappingEventHandler
Der MCRClassificationMappingEventHandler setzt MyCoRe-Klassifikationen in spezielle Klassifikationen für z.B. für DINI um.
optional
016
Enthalten in mycore-mods
org.mycore.mods.classification.MCRClassificationMappingEventHandler
Der MCRClassificationMappingEventHandler für MODS setzt MyCoRe-Klassifikationen in spezielle Klassifikationen im MODS-Datenmodell für z.B. für DINI um.
optional
017
Enthalten in mycore-base
org.mycore.datamodel.common.MCRServiceFlagEventHandler
Der MCRServiceFlagEventHandler setzt im Service-Bereich /mycore.../services/servflags je ein Flag mit dem aktuellen Nutzer und den Typen createdby und/oder modifiedby an und leitet das modifizierte Objekt in der Pipeline weiter. Die geschieht nur, wenn der ImportMode des Objektes false ist.
020 Enthalten in mycore-base
org.mycore.datamodel.common.MCRXMLMetadataEventHandler
Der MCRXMLMetadataEventHandler speichert das XML des Objektes gemäß dem IFS2 Speicherkonzept für Metadaten ab.
030 Enthalten in mycore-base
org.mycore.datamodel.common.MCRLinkTableEventHandler
Der MCRLinkTableEventHandler speichert alle Referenzen des Objektes zu anderen MyCoRe-Objekten in die SQL-MCRLINKTABLE. Grundlage dafür sind Datenelemente vom Datenmodelltyp MCRMetaLinkID. Dies betrifft auch Verweise aus dem /mycore.../structure-Bereich. Weiterhin werden die Referenzen auf Klassifikationen gespeichert.
optional
040
Enthalten in mycore-mods
org.mycore.mods.MCRMODSLinksEventHandler
Nur relevant für die MODS Unterstützung. Speichert verwendete Klassifikationskategorien von MODS-Dokumenten.
060 Enthalten in mycore-base
org.mycore.datamodel.metadata.history.MCRMetadataHistoryManager
Der MCRMetadataHistoryManager ersetzt den MCRDeleteObjectEventHandler und führt eine History über den Stand der vorhandenen Objekte und ggf. deren Löschung.
optional
071
Enthalten in mycore-pi
org.mycore.pi.MCRPersistentIdentifierEventHandler
Die Beschreibung zum MCRPersistentIdentifierEventHandler folgt.
100 Enthalten in mycore-solr; erforderlich bei Nutzung von SOLR
org.mycore.solr.index.MCRSolrIndexEventHandler
Der MCRSolrIndexEventHandler indexiert die Metadatenobjekte für Solr, sofern diese von einem passenden Datentyp sind.
optional
900
Enthalten in mycore-wfc; erforderlich bei Nutzung der MyCoRe-Workflow-Komponente
org.mycore.wfc.mail.MCRMailEventHandler
Wenn die MyCoRe-Workflow-Komponente (wfc) genutzt wird, sorgt dieser EventHandler dafür, dass entsprechende Mails an Bearbeiter etc. gesendet werden. Dazu wird die Konfiguration in e-mail-events.xsl herangezogen.

EventHandler für MCRDerivate

optional
010
Enthalten in mycore-base
org.mycore.access.MCRAccessEventHandler
Der MCRAccessEventHandler liest die Sektion /mycore.../services/servacls des eingehenden Derivates und trägt die gelesenen ACL-Informationen in die ACL-Komponente von MyCoRe ein. Anschließend wird diese Datensektion aus dem in der pipeline weiterzurechenden Datensatz entfernt.
Alternative
zu 010
Enthalten in mycore-base
org.mycore.access.MCRRemoveAclEventHandler
Der MCRRemoveAclEventHandler entfernt alle ACL-Informationen aus dem Objekt. Er ist für Access-Strategien gedacht, welche von globalen Zugriffsrechten für Objektgruppen von MCR-Projekten oder MCR-Typen implementieren. Dieser Handler sollte in dem Fall den MCRAccessEventHandler überlagern.
optional
011
Enthalten in mycore-acl
org.mycore.mcr.acl.accesskey.MCRAccessKeyEventHandler
Der MCRAccessKeyEventHandler importiert Zugriffsschlüssel beim Import/Erstellung eines MyCoRe Derivats aus dem accesskey Servflag und löscht das Servflag anschließend. Beim Löschen eines Derivats werden alle Zugriffsschlüssel gelöscht. Beim Updaten eines Derivats wird der Servflag gelöscht und somit nicht verarbeitet bzw. ignoriert.
012 Enthalten in mycore-base
org.mycore.access.MCRAccessCacheEventHandler
Beim Update oder Löschen eines Derivates löscht der Eventhandler alle Einträge für das Derivate im AccessCache aller aktiven MCRUserSessions.
020 Enthalten in mycore-base
org.mycore.datamodel.common.MCRXMLMetadataEventHandler
Der MCRXMLMetadataEventHandler speichert das XML des Objektes gemäß dem IFS2-Speicherkonzept für Metadaten ab.
optional
050
Enthalten in mycore-mets
org.mycore.mets.events.MCRUpdateMetsOnDerivateChangeEventHandler
Der MCRUpdateMetsOnDerivateChangeEventHandler aktualisiert die bereits bestehende mets.xml-Datei nach Update eines Derivates.
070 Enthalten in mycore-base
org.mycore.datamodel.metadata.history.MCRMetadataHistoryManager
Der MCRMetadataHistoryManager ersetzt den MCRDeleteObjectEventHandler und führt eine History über den Stand der vorhandenen Objekte und ggf. deren Löschung.
optional
100
Enthalten in mycore-solr; erforderlich bei Nutzung von SOLR
org.mycore.solr.index.MCRSolrIndexEventHandler
Der MCRSolrIndexEventHandler indexiert die Metadatenobjekte für Solr, sofern diese von einem passenden Datentyp sind.

EventHandler für MCRPath

optional
020
Enthalten in mycore-iview2; erforderlich bei Nutzung von IView2
org.mycore.iview2.events.MCRImageTileEventHandler
Der MCRImageTileEventHandler initialisiert das Kacheln der Datenobjekte, sofern diese von einem passenden Bildtyp sind.
optional
060
Enthalten in mycore-mets; erforderlich bei Nutzung von mets
org.mycore.mets.events.MCRUpdateMetsOnDerivateChangeEventHandler
Der MCRUpdateMetsOnDerivateChangeEventHandler aktualisiert die bereits bestehende mets.xml-Datei nach Update eines Derivates.
optional
100
Enthalten in mycore-solr; erforderlich bei Nutzung von SOLR
org.mycore.solr.index.MCRSolrIndexEventHandler
Der MCRSolrIndexEventHandler indexiert die Volltexte für Solr, sofern diese von einem passenden MimeType sind.