10. Ereignissse

Kapitel hinzufügen

10.1 Einführung

Abschnitt hinzufügen

Viele Aktionen eines Workflows laufen beim Einsatz von MyBib eDoc vollautomatisch und damit unsichtbar („im Hintergrund“) ab. Das ist praktisch, schafft Luft für andere Aufgaben und erhöht Zuverlässigkeit und Durchsatz etwa im Bereich der Dokumentenlieferung. Allerdings stellt sich auch die Frage, wie letztlich der Überblick behalten und zeitnah und konsequent auf eventuelle Fehler oder Probleme reagiert werden kann. Bei interaktiver Arbeit stellt sich diese Frage weniger. Wie auch bei anderen Systemen erhält der Nutzer in diesem Fall direkt Fehlermeldungen mit Hinweisen auf Ursache und mögliche Reaktionen. Bei vollautomatischen Prozessen ist dies jedoch anders: Da es keinen Nutzer gibt, der die Aktionen direkt angestoßen hat, sieht niemand eine eventuelle Fehlermeldung. Der Nachweis in einer Logdatei hilft nur bedingt, sie erzwingt eine konsequente Überwachung des Status aller Aufträge bzw. eine Analyse der Logdateien, um Fehler überhaupt erst zu bemerken. Hier setzt das Konstrukt der „Ereignisse“ an: Jede Aktivität in MyBib eDoc bewirkt die Generierung eines oder mehrerer „Ereignisse“. Ereignisse beschreiben Vorgänge samt Ihrer Ergebnisse.

• Gewichtungen: Hinweise, Warnungen, Fehler, …
• Arten/Aspekte: Erfassungen, Änderungen, Löschungen, …
• Umfänge: Einzel- oder Sammelereignisse

10.2 Funktion

Abschnitt hinzufügen

Generell erzeugt das System unabhängig von Konfiguration oder Nutzung Ereignisse zunächst intern. Die so erzeugten Ereignisse werden stets persistent in einer Datenbank gespeichert und sind später unverändert einsehbar. Aufgrund des dokumentierenden Charakters erlaubt das System keine Manipulation zuvor gespeicherter Ereignisse. Wohl aber ist die Visualisierung von Listen von Ereignissen kontrollierbar. Das System erlaubt Filterung und Sortierung, um einen effektiven Zugriff auf die Menge an Ereignissen zu ermöglichen.
Aufbauend auf diesen persistent gespeicherten Einträgen kann MyBib eDoc Ereignisse auch zusätzlich aktiv publizieren. Hierzu gibt es mehrere Varianten:

• Newsfeeds: Abonnierbare Feeds mit der Möglichkeit der Filterung nach Typ, Gewichtung und Auslöser durch jeden Nutzer selbst und damit effizienter & ressourcenschonender Zugriff.
• Email-Gateway: Einzelversand der Ereignisse als Email-Nachricht, zentral konfigurierbare Filter- und Verteilregeln.
• Email-Dump: Direkte, ungefilterte Übergabe aller Ereignisse an eine zentral konfigurierte Emailadresse, spätere Filterung über Headereinträge machbar.
• passive Queries: Die persistente Speicherung der Ereignisse in der Datenbank erlaubt eine Abfrage der Ereignisse in Queries, abrufbar etwa per XML-RPC-API.

Jedes einmal generierte Ereignis hat eine eindeutige Kennung, anhand derer es jederzeit identifiziert werden kann. Diese Kennung ist entsprechend auch bei der Veröffentlichung eines Ereignisses über Newsfeeds oder das Email-Gateway angegeben. Im Falle der Newsfeeds erlaubt es einen direkten Zugriff auf das Ereignis über einen eingebetteten Link (Zugriff auf das System vorausgesetzt). Der dokumentierende Charakter der gespeicherten Ereignisse ist auch der Grund, warum der textuelle Inhalt einzelner Ereignisse nicht entsprechend den Nutzereinstellungen übersetzt wird. Eine automatische Übersetzung von Prosatext zur Laufzeit kann nicht funktionieren, da für das tatsächlich gespeicherte Ereignis eine Sprache für die Formulierung eindeutig gewählt sein muss.
Zusätzlich werden in einem Ereignis zwei weitere technische Angaben abgelegt:

• Eine „Referenz“ auf das Objekt, auf dem das Ereignis basiert, etwa ein existierender Auftrag, eine Charge oder Selektion. Diese „Referenz“ dient dem direkten Ansprung des Objektes in der Oberfläche. Entsprechend wird sie unterdrückt, falls das Objekt nicht (mehr) existiert, beispielweise für das Ereignis des Löschens einer Systemeinstellung.
• Die Angabe eines „Kontextes“, falls das Ereignis etwa im Zuge einer Gesamtaktion generiert wurde. Ein Beispiel hierfür wäre etwa die Erfassung eines Auftrags im „Kontext“ der Verarbeitung einer Importliste; der Kontext erlaubt dann den Zugriff auf die Menge aller Ereignisse, die während dieser Aktion generiert wurden.

10.3 Konfiguration

Abschnitt hinzufügen

10.3.1 Grundlegende technische Konfiguration

Optionen zur grundlegenden technischen Konfiguration finden sich im Menü zentral unter >> „Verwaltung“ >> „Einstellungen“ >> „Ereignisse“. Die Bedeutung der einzelnen Optionen wird einer technisch versierten Person einfach ersichtlich sein, zusätzlich wird zu jeder Option eine knappe Erläuterung angeboten.

10.3.2 Inhaltliche Formulierung von Ereignisvorlagen

Die Vorgaben zur inhaltlichen Formulierung von Texten, mit denen Ereignisse veröffentlicht werden, finden sich in einer zentralen Verwaltung der „Ereignis-Vorlagen“ (Templates). Diese ist schon aufgrund der Menge der Kombinationen aus Arten von Ereignissen wesentlich umfangreicher. Das System enthält zum Zeitpunkt der Installation eine komplette Sammlung an Vorlagen, die sofort einsatzbereit sind. Sinnvolle Änderungen an der lokalen Sammlung der Vorlagen beschränken sich daher normalerweise auf diese Punkte:

• Unterdrückung einzelner, nicht erwünschter Ereignisvorlagen
• Anpassung der vordefinierten Formulierung der Beschreibung einzelner Ereignisse
• Mehrsprachigkeit der Vorlagen

Die Verwaltung der Vorlagen ist auch direkt aus der Liste der bereits generierten Ereignisse aufrufbar.

10.3.2.1 Konkreter Zugriff auf die Ereignisse

Zur Laufzeit werden die generierten Ereignisse intern gespeichert. Als solche sind sie anschließend direkt einsehbar. Dieser Punkt findet sich im Menü unter „Service“ >> „Ereignisse“. Weiter bietet das System die aktive Veröffentlichung von Ereignisse an. Diese Möglichkeiten werden in den folgenden Abschnitten näher erläutert:

10.3.3 Prosa- oder Rohform von Ereignissen

Ereignisse werden generell in einer von zwei Ausprägungen generiert:

• Prosaform: Die sauber ausformulierte Darstellung eins Ereignisses.
• Rohform: Eine generische Auflistung der zugrunde liegenden Informationen eines Ereignisses.

Die „Prosaform“ ist der Normalfall bei der Generierung eins Ereignisses. Sie basiert auf einer hinterlegten Ereignisvorlage und formuliert einen sprachlich sauberen Text, der das Ereignis basierend auf den zum Zeitpunkt der Generierung vorliegenden Informationen anpasst. Da die Ereignisvorlage lokal konfiguriert werden kann, ist es möglich, in dieser Form auf Wünsche bezüglich Sprache, Formulierung und Detailreichtum in der Darstellung von Ereignissen Einfluss zu nehmen.
Die „Rohform“ eines Ereignisses verzichtet dagegen bewusst auf die Nutzung einer hinterlegten Vorlage. Vielmehr werden die ungefilterten technischen Aspekte und inhaltlichen Details des Ereignisses in ihrer Gesamtheit erfasst. Ein solches Ereignis trägt unter Umständen eine große Menge von Informationen. Insbesondere direkt auftragsbezogene Ereignisse beinhalten sämtliche den Auftrag charakterisierende Attribute. Der Sinn der Generierung dieser „Rohform“ liegt in der Übersicht über die Gesamtheit der verfügbaren Informationen. Diese Übersicht ist wichtig für die Formulierung konkreter Ereignisvorlagen. Es gibt drei mögliche Situationen, in denen ein Ereignis in „Rohform“ generiert wird:

10.3.3.1 Löschen oder Fehlen einer Ereignisvorlage

Fehlt in der Sammlung der Ereignisvorlagen eine konkrete Ausprägung, so veröffentlicht MyBib eDoc ein zur Laufzeit generiertes Ereignis in seiner „Rohform“. Dieses Verhalten dient zwei wichtigen Punkten:

1. Direkte Definition von Vorlagen basierend auf einem so generierten Ereignis.
2. Sicherheit gegen (versehentliches) Unterdrücken von Ereignissen, aufgrund einer fehlenden Vorlage.

10.3.3.2 Deaktivieren einer Ereignisvorlage

Ebenfalls zum Zweck der Definition von Ereignisvorlagen dient die Möglichkeit, existierende Ereignisvorlagen zu deaktivieren. Eine solche Vorlage wird vom System nicht berücksichtigt. So lassen sich beispielsweise mehrere Vorlagen zur gleichen Art von Ereignis definieren, wobei nur jeweils eine dieser gleichartigen Vorlagen aktiviert sein kann. Es können also neue Formulierungen angelegt und getestet werden. Weit wichtiger aber ist die Möglichkeit, eine existierende Vorlage zeitlich begrenzt zu deaktivieren, mit dem Ziel einen ungefilterten Blick auf die „Rohform“ des generierten Ereignisses zu erhalten. Motivation ist der Wunsch, weitere inhaltliche Details oder technische Aspekte in die Formulierung der Ereignisvorlage aufzunehmen. Hierzu leistet die „Rohform“ eines Ereignisses gute Hilfe, da aus ihr die Bezeichnung von Details und Aspekten entnommen werden kann.
Generell gilt, dass in ihrer „Rohform“ generierte Ereignisse auch in dieser Form persistent gespeichert sind. Dies entspricht konsequent dem dokumentierenden Charakter der Ereignisse in MyBib eDoc. Eine nachfolgende Definition einer Ereignisvorlage wird in keinem Fall Einfluss auf die Formulierung bereits zuvor generierter Ereignisse haben. Sie hat prinzipiell nur Auswirkung auf nachfolgend generierte Ereignisse.

10.3.3.3 Manuelles Auslösen einer Ereignisvorlage

In diesem Fall stehen zwar keine zur Laufzeit vorliegenden Informationen bereit, dennoch eignet sich diese Art der Generierung gut, um die grundlegenden Aspekte einer Vorlage einzusehen und etwa die Veröffentlichung bzw. deren Filterregeln zu testen. Jede Ereignisvorlage bietet hierzu in der Verwaltung die entsprechende Aktion „Auslösen“. Ein derart generiertes Ereignis wird exakt wie jedes andere, normale Ereignis persistent gespeichert und veröffentlicht.

10.4 Veröffentlichung

Abschnitt hinzufügen

10.4.1 Newsfeeds

Das System veröffentlicht (vorausgesetzt diese Option ist freigegeben) alle generierten Ereignisse in Form von Newsfeeds. Newsfeeds sind eine etablierte und standardisierte Technik, die vielfach im Internet zur Publizierung von Nachrichten an ein breites Publikum eingesetzt wird. Derartige Feeds können einfach von interessierten Nutzern abonniert werden. Sie werden in Form einer speziellen URL angeboten. Diese kann vom Nutzer in eine lokale Lese-Applikation übernommen werden  – einen sogenannten (News-) Aggregator. Es gibt eine große Vielfalt solcher Applikationen, freie wie auch proprietäre. Die am weitesten verbreiteten Aggregatoren sind derzeit die Firefox-Extensions, Plugins, in die gängigen PIM-Suiten, also etwa KDE-Kontact, Gnome-Evolution oder MS-Outlook, um nur ein paar Beispiele zu nennen. Die Feeds lassen sich entweder explizit durch Kopieren der angebotenen URL als solche angeben, oder es reicht ein einfaches Anklicken der URL. Die korrekte Konfiguration des lokalen Systems ist die Voraussetzung dafür. Ein abonnierter Feed wird durch den Aggregator periodisch nach neuen Einträgen abgefragt. Die Häufigkeit der Abfrage ist konfigurierbar, ein sinnvoller Kompromiss aus Last und Aktualität wird üblicherweise bei einer Aktualisierung zwischen 5 und 60 Minuten liegen. Viele dieser Aggregatoren bieten neben dem reinen Lesen der veröffentlichten Ereignisse weitere Fähigkeiten wie lokale Archivierung, Ablage, Kategorisierung oder auch Wiederveröffentlichung etwa in Form von Email-Nachrichten. Hierbei handelt es sich aber um applikationsspezifische Fähigkeiten, die hier nicht weiter vertieft werden können.

10.4.1.1 Abonnements

Die veröffentlichten Feeds werden an zentraler Stelle als Abonnements angeboten: „Service“ > „Ereignisse“ listet in der Vergangenheit generierte Ereignisse auf. Links oben findet sich bei den „Aktionen“ die Stelle zum Abonnieren der dazu gehörigen Feeds. Es bestehen Einstellmöglichkeiten nach „Protokoll“ („Atom“ oder „RSS-2.0“) und „Schwellwert“ zur Gewichtung („ab welcher Wichtigkeit“). Darunter werden die verfügbaren Feeds einzeln zum Abonnieren angeboten. Die Aufteilung in eine größere Menge von Feeds wurde bewusst im Hinblick darauf getroffen, dass Nutzer an unterschiedlichen Arten von Ereignissen interessiert sind. Die große Menge der erzeugten Ereignisse würde andernfalls schnell dazu führen, dass einzelne, wichtige Ereignisse in der großen Menge untergehen. Als weitere Option wird der Export aller Feed-URLs in Form einer OPML-Ressource angeboten. Dies ist ein Standardformat, mit dem mehrere Feeds gemeinsam definiert und als solche gebündelt abonniert werden können. Es handelt sich um eine Textdatei; entsprechend kann sie lokalen Bedürfnissen angepasst werden, etwa zur Bereitstellung vordefinierter Auswahlen an Feeds für bestimmte Nutzergruppen.

10.4.1.2 Optionen

MyBib eDoc unterstützt neben der freien Veröffentlichung der Feeds auch den Zwang zu einer expliziten „Authentifizierung“ des Aggregators vor dem Abruf. Dies kann bei Systemen, in denen sensitive Daten (Kundenadressen etc.) gespeichert oder die frei in größeren Netzwerken zugreifbar sind, Sinn machen. Diese Option muss explizit in den zentralen Einstellungen aktiviert werden. Anschließend können Feeds nur noch nach Authentifizierung mit einer berechtigten ME-Login-Kennung abgerufen werden. Diese Art des Abonnierens eines Feed wird leider nicht von allen verbreiteten Aggregatoren unterstützt.
MyBib eDoc unterstützt Newsfeeds in den beiden derzeit aktuellen Protokollen Atom und RSS-2.0. Es bietet Feeds mit korrekt spezifiziertem Mimetype an; die Angabe einer nicht-standard-konformen //Pseudo//-URL-Notation (feed:///) wird nicht unterstützt.

10.4.2 Email-Gateway

Zusätzlich zur Möglichkeit sich über generierte Ereignisse per Newsfeed informieren zu lassen, bietet das System die Möglichkeit, diese Ereignisse auch aktiv über ein sogenanntes Email-Gateway zu veröffentlichen. Dabei wird prinzipiell jedes generierte Ereignis einzeln in einer Email-Nachricht an einen oder mehrere Empfänger verschickt. Im Gegensatz zu den angebotenen Feeds wird also die Menge der Information vervielfacht, es entsteht höhere Last.

10.4.2.1 Zentrale Filterregeln

Entsprechend bietet das Email-Gateway die Möglichkeit zentrale Filterregeln zu definieren. Diese Regeln können einschränken, welche Menge an Ereignissen an welchen Nutzer verschickt wird. Typische Beispiele an Filterungen sind etwa die Reduktion ausschließlich auf Fehlermeldungen und Warnungen, also die Unterdrückung von Ereignissen positiven Charakters oder die Unterscheidung nach der Aufgabe von Nutzern, etwa eine Unterscheidung nach administrativen Vorfällen oder Ereignissen im täglichen Workflow.
Das Email-Gateway ist eine separate Instanz, mit der MyBib eDoc im Hintergrund kommuniziert. Die Konfiguration des Gateways ist entsprechend nicht in die Oberfläche des Systems integriert. Vielmehr müssen die Regeln direkt in kodierter Form im Gateway hinterlegt werden. Diese Aufgabe kann IWC nach Vorgaben eines Kunden übernehmen.

10.4.2.2 Dezentrale Filterung

Zusätzlich ist es natürlich jedem Empfänger solcher per Email verschickter Nachrichten möglich, mit seinen eigenen vorhandenen Werkzeugen eine Filterung eingehender Nachrichten zu realisieren. Je nach verwendeter Software zum Empfang der Emails werden hier server- und clientseitig Filteroptionen angeboten. Diese sind jeweils spezifisch für die verwendeten Applikationen und werden entsprechend nicht weiter im Einzelnen vertieft. Generell lässt sich aber festhalten, dass neben den offensichtlichen Angaben wie Betreff und Absender insbesondere die zusätzlich enthaltenen Headereinträge in den Nachrichten sich als Aspekte für Filterregeln anbieten. Diese Header sind in normaler Ansicht der Nachrichten nicht sichtbar, aufgrund ihres Aufbaus aber prädestiniert zur Auswertung durch Filterregeln.

10.4.3 Email-Dump

Zur Erleichterung von Konfiguration und Systemüberwachung lassen sich zusätzlich zur Nutzung des Email-Gateways auch direkt alle generierten Ereignisse in Form einzelner Emails an eine zentral konfigurierte Adresse exportieren. Die entsprechende Option findet sich unter den zentralen „Einstellungen“ im Menu unter >> „Verwaltung“ >> „Einstellungen“ >> „Ereignisse“: Eine hier hinterlegte Adresse erhält eine direkte Kopie jedes generierten Ereignisses. Bedenken Sie, dass es sich hierbei um eine unter Umständen sehr große Menge an Nachrichten handelt, insbesondere bei Systemen, die große Mengen an Aufträgen automatisiert bearbeiten, etwa im Kontext der Massendigitalisierung.