Ereignisse und Ereignis-Handler

Ereignisse sind eine einfache Datenstruktur, welche entweder über docuteam feeder Event API eingereicht oder intern in feeder generiert werden. Mittels Ereignis-Handler kann angegeben werden, aufgrund welcher Eigenschaften eines Ereignisses welche(r) Workflow(s) gestartet werden.

Ereignisse werden im Bereich "Ereignisse" angezeigt. Die genauen Eigenschaften eines Ereignisses werden mit Klick auf anzeigen angezeigt.

Ereignis-Handler können im Admin-Bereich unter "Ereignis-Handler" verwaltet werden.

Struktur eines Ereignis

Ein Ereignis hat immer mindestens die folgenden zwei Eigenschaften:

• source: Die Herkunft des Ereignisses. Bei Ereignissen, welche feeder selbst generiert, ist dies immer internal.
• event_type: Der Typ des Ereignisses. Hierbei kann ein beliebiger Wert angegeben werden. Die Ereignis-Typen, welche feeder selbst generiert, sind weiter unten angegeben.

Konfiguration eines Ereignis-Handler

Bei der Erstellung eines Ereignis-Handlers muss im Minimum ein Name und ein zu startender Workflow angegeben werden. Eine solch minimale Regel würde dann bei jedem erstellten Ereignis den gewählten Workflow starten.

Die Anzahl Felder beim Abschnitt Attribute, welche weitergegeben werden sind abhängig vom gewählten Workflow und dessen Parameter. Für jeden Parameter des gewählten Workflows muss der Name einer Eigenschaft aus dem Ereignis angegeben werden, dessen Wert als Parameter an den Workflow weitergegeben werden soll. Falls die Eigenschaft im Ereignis nicht vorhanden ist, wird der Workflow nicht gestartet.

Ersteller des Ereignis erlaubt die Auswahl einer Autorisierung, von welcher das Ereignis erstellt werden muss (nur relevant für Ereignisse die über das Event API von docuteam feeder erstellt wurden).

Mit Workflow, der das Ereignis ausgelöst hat kann gewählt werden, welcher Workflow das Ereignis ausgelöst haben muss. Dies ist hilfreich, wenn man einen Cleanup-Workflow laufen lassen möchte nach der Ausführung eines bestimmten Workflows.

Beim Klick auf Neue Regel hinzufügen können zusätzliche Eigenschaften aus dem Ereignis geprüft werden.

Es gilt zu beachten, dass die einzelnen Regeln alle mit dem logischen UND verknüpft werden und immer exakt vergleichen. Das heisst wenn man auf einen Ereignistyp Test Typ eine Regel erstellen möchte, das Ereignis dann aber mit dem Typ Test-Typ erstellt wird, wird der definierte Workflow der Ereignisregel nicht gestartet.

Anwendungsfälle

Fedora 3 zu Fedora 6 Migration

Für die Migration der Daten von Fedora 3 zu Fedora 6 muss feeder wissen, welche PIDs in Fedora 3 vorhanden sind und welche PIDs bereits in Fedora 6. Anschliessend wird für alle PIDs, welche noch nicht in Fedora 6 sind, ein DIP generiert und damit die Migration vorgenommen.

actions.js spricht dazu mit den beiden Fedora-Instanzen und sendet anschliessend pro migrierbare PID ein Ereignis an das docuteam feeder API mit der PID sowie dem Typ MigratablePID. In feeder ist dazu ein Ereignis-Handler konfiguriert, welche auf den Typ MigratablePID wartet und bei einer Übereinstimmung den Migrationsworkflow mit der PID als SIP-Parameter startet. Dies stellt sicher, dass nur von den Daten, welche in diesem Moment verarbeitet werden, ein DIP angefordert wird, anstatt alles auf einmal zu laden.

{
  "PID": "CH-002003-9:1553",
  "source": "actions.js",
  "event_type": "MigratablePID"
}

Ablieferung verschiedener Paket-Formate über docuteam feeder Deposition API

Bei Verwendung der Deposition API konnten bisher nicht Pakete in unterschiedlichen Formaten abgeliefert werden, da nur ein Workflow zur Verarbeitung ausgewählt werden konnte.

Bei der Erstellung einer Ablieferung wird intern ein Ereignis generiert, unter anderem mit dem Paket-Format. Nun kann pro Paket-Format ein Ereignis-Handler definiert werden, welche auf den Typ Deposition Creation wartet und das gewünschte Paket-Format. Als zu startender Workflow kann dann für ein Matterhorn METS-Paket ein Workflow ausgewählt werden, welcher Matterhorn METS auch verarbeiten kann.

Von feeder generierte Ereignisse

Wie eingangs erwähnt, erzeugt feeder selbst Ereignisse, welche für das Workflow-Management genutzt werden können.

Status der Workflow-Ausführung geändert

Ändert sich der Status einer Workflow-Ausführung, wird ein Ereignis mit Event Type WorkflowExecution Status Change erstellt.

Dieses besteht aus den folgenden Attributen:

{
  "event_type": "WorkflowExecution Status Change",
  "new_status": "failed",
  "source": "internal",
  "workflow_execution_id": 7,
  "workflow_id": 1,
  "sip": 4,
  "sip_type": "deposition"
}

Erklärung der Attribute:

• source: Immer internal, da das Ereignis von feeder erstellt wurde.
• new_status: Entweder failed oder finished.
• resource_type "sip" für SIPs in der Workbench, "depositions" für Ablieferungen über das Deposition API.
• resource_value: Name des SIP oder ID der Deposition.
• workflow_execution_id: ID der Workflow-Verarbeitung, welche das Ereignis ausgelöst hat.
• workflow_id: ID des Workflows, welcher in der Workflow-Verarbeitung verwendet wurde, welche das Ereignis ausgelöst hat.

Alle weiteren Eigenschaften im Ereignis sind abhängig von den Parameter des verwendeten Workflow. feeder fügt für jeden Parameter eine Eigenschaft zum Ereignis hinzu. Falls ein Parameter vom Typ file or folder ist, fügt feeder eine zusätzliche Eigenschaft namens type hinzu, welche entweder deposition oder other ist.

Ablieferung erstellt

Wenn eine Ablieferung in feeder erstellt wird (entweder im Webinterface unter Ablieferungen oder über das Depositions API wird ein Ereignis mit Ereignis-Typ "Deposition Creation" erstellt.

Dieses besteht aus den folgenden Attributen:

{
  "source": "internal",
  "event_type": "Deposition Creation",
  "resource_type": "deposition",
  "package_format": "MatterhornMETSv1.0",
  "resource_value": 12
}

Erklärung der Attribute:

• source: Immer internal, da das Ereignis von feeder erstellt wurde.
• resource_type: Immer deposition.
• resource_value: ID der Deposition.
• package_format: Angegeber Paket-Typ der Ablieferung.