Ereignisse und Ereignis-Handler

Ereignisse sind eine einfache Datenstruktur, welche entweder über docuteam feeder 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.

Beim Feld Attribut aus dem Inhalt des Ereignis, dessen Wert als SIP an den Workflow weitergegeben werden soll kann angeben werden, welche Eigenschaft aus dem Ereignis als "SIP"-Parameter an den Workflow weitergegeben soll. Falls die Eigenschaft im Ereignis nicht vorhanden ist, wird kein Workflow gestartet. Falls entweder SIP oder Ablieferung an den Workflow weitergegeben werden soll, kann hier resource angegeben werden.

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 API 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 bridge 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 bei der bridge API

Nutzer der bridge API konnten bisher nicht Pakete in unterschiedlichen Formaten abliefern, 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:

{
  "source": "internal",
  "event_type": "WorkflowExecution Status Change",
  "new_status": "failed",
  "resource_type": "deposition",
  "resource_value": 1,
  "workflow_execution_id": 2
}

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 die bridge API.
• resource_value: Name des SIP oder ID der Deposition.
• workflow_execution_id: ID der Workflow-Verarbeitung, welche das Ereignis ausgelöst hat.

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": "MatterhornMets",
  "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.