Frage: Fehler bei Indexierung wo soll wie Benachrichtigt werden?

Moin,

ich stelle mir gerade eine Frage, bei der ich gerne ein Feedback von Euch aus der Community hätte. Es geht darum, das wenn bei der Indexierung eines Datensatzes ein Fehler auftritt, wie dann am besten darüber informiert wird.

Der Goobi viewer Indexer hat die Funktion um in dem Fall eines Fehlers eine E-Mail zu versenden. Die ist aber bei fast keiner Einrichtung konfiguriert. In der E-Mail ist die komplette Logausgabe zu sehen, zum Beispiel so etwas:

INFO  2021-04-05 21:13:37.469 [main] (Hotfolder.java:scan:534)
        Found file 'parziv_823714454.xml' (hotfolder).
INFO  2021-04-05 21:13:37.497 [main] (MetsIndexer.java:index:182)
        Record PI: 1255519150
INFO  2021-04-05 21:13:37.497 [main] (RemainingSpaceStrategy.java:selectDataRepository:120)
        Total record size is 710704 Bytes.
INFO  2021-04-05 21:13:37.501 [main] (RemainingSpaceStrategy.java:selectDataRepository:161)
        Using previous data repository for '1255519150': /opt/digiverso/viewer/data/2
INFO  2021-04-05 21:13:37.511 [main] (Indexer.java:checkOldDataFolder:1085)
        Using old 'mediaFolder' data folder '/opt/digiverso/viewer/data/2/media/1255519150'.
INFO  2021-04-05 21:13:37.514 [main] (Indexer.java:deleteWithPI:212)
        Removing previous instance of this volume from the index...
INFO  2021-04-05 21:13:37.618 [main] (Indexer.java:deleteWithPI:266)
        869 docs deleted.
ERROR 2021-04-05 21:13:37.861 [main] (MetadataHelper.java:retrieveElementMetadata:461)
        CURRENTNOSORT cannot be written because it's not an integer value: 18871/20
INFO  2021-04-05 21:13:37.862 [main] (MetadataHelper.java:retrieveAuthorityData:541)
        retrieveAuthorityData: http://d-nb.info/gnd/133501221
INFO  2021-04-05 21:13:38.358 [main] (MetadataHelper.java:retrieveAuthorityData:541)
        retrieveAuthorityData: http://d-nb.info/gnd/133501221
INFO  2021-04-05 21:13:38.585 [main] (MetsIndexer.java:generatePageDocuments:820)
        Generating 817 page documents (count starts at 1)...
WARN  2021-04-05 21:13:48.975 [ForkJoinPool-6988-worker-1] (MetsIndexer.java:generatePageDocument:897)
        Page 1 is not mapped to a structure element, skipping...
WARN  2021-04-05 21:13:48.977 [ForkJoinPool-6988-worker-1] (MetsIndexer.java:generatePageDocument:897)
        Page 2 is not mapped to a structure element, skipping...
WARN  2021-04-05 21:13:48.978 [ForkJoinPool-6988-worker-1] (MetsIndexer.java:generatePageDocument:897)
        Page 3 is not mapped to a structure element, skipping...
INFO  2021-04-05 21:13:51.078 [main] (MetsIndexer.java:generatePageDocuments:853)
        Generated 814 page documents.
INFO  2021-04-05 21:13:51.386 [main] (MetsIndexer.java:index:526)
        Successfully finished indexing 'parziv_823714454.xml'.

In diesem Fall sollte man dem Metadatum CurrentNoSorting im Regelsatz eine validationExpression konfigurieren damit keine für den Goobi viewer invaliden Werte erfasst werden können, aber das ist ja nur ein Beispiel. Es gibt noch viel mehr Fehler die auftreten können… Und damit komme ich zu meiner eigentlichen Frage:

An welcher Stelle, und auf welche Weise, würden sich eigentlich die Community eine Rückmeldung wünschen, dass bei der Indexierung eines Datensatzes ein Fehler aufgetreten ist?

  • Reicht eine E-Mailbenachrichtigung mit der Ausgabe wie oben gezeigt und die muss nur konfiguriert werden?
  • Wird das im Goobi viewer Backend erwartet? Auf einer eigenen Seite in der alle aufgetretenen Fehler aufgelistet werden? Das würde zum Beispiel Sinn ergeben weil ja auch oft Datensätze indexiert werden die nicht aus Goobi workflow stammen.
  • Oder wird das eigentlich in Goobi #workflow erwartet? Ein Eintrag im Vorgangslog und dazu eine Anzeige auf dem Dashboard? Oder eine eigene Übersicht der Vorgänge bei denen ein Fehler aufgetreten ist, gruppiert nach Fehlertyp?

Ich bin an der Stelle ein wenig ratlos. Einerseits denke ich mir: “Es gibt nur sehr wenige die sich in den letzten Jahren mit so einem Problem bei uns gemeldet haben.” Andererseits weiß ich auch, dass viele über eventuelle Exportprobleme gar nicht Bescheid wissen, weil Goobi workflow ja einen erfolgreichen Export meldet und das Problem dann erst bei der Indexierung auftritt. Es ist ein typisches Problem an einer Schnittstelle.

Was meint Ihr dazu? Fändet Ihr so etwas hilfreich, und wenn ja, wo würdet Ihr es erwarten?

Ich würde mich über eine Rückmeldung freuen, viele Grüße und bleibt Gesund!

Jan :slight_smile:

2 „Gefällt mir“

Hallo @jan,

ganz abseits der Fehlermeldungen fände ich es hilfreich, wenn ich direkt im Backend des Viewers sehen könnte, ob sich noch Vorgänge in der laufenden Indexierung/ im Hotfolder des Viewers befinden. Während des Indexierungsprozesses kommt es ja immer mal zur Verlangsamung des Viewers bzw. zu Fehlermeldungen.

Beste Grüße, Andreas

1 „Gefällt mir“

Hallo @jan,

eigentlich sollten invalide Werte dort gemeldet werden, wo sie das erste Mal auftreten. Jetzt ist es ja generell so, dass Goobi workflow an einigen Stellen Werte zuläßt, die der Goobi viewer nicht in der erwarteten Form verarbeiten kann.

Aus Nutzersicht halte ich eine Fehleranzeige auf dem Dashboard von Goobi workflow für sinnvoll. Die Begründung ist einfach. Als Projektverwalter, der solche Fehler potenziell beheben kann, habe ich dieses Dashboard eher im Blick als das Dashboard des viewers. Dadurch wird meiner Meinung nach auch eine Benachrichtigung per e-mail obsolet.

Beste Grüße, Andreas

Hallo Jan,
die E-Mail-Benachrichtigung ist für mich gut und die Möglichkeit sollte erhalten bleiben, auch wenn andere Benachrichtigungsmöglichkeiten dazu kämen. Wie Andreas anmerkt, habe auch ich eher das workflow-Dashboard im Blick wie jenes vom viewer.

Beste Grüsse, Meinrad

Das sollten wir auf jeden Fall ändern. Kannst Du - abgesehen von dem oben genannten CurrentNoSorting- noch weitere Beispiele geben die wir mit einer Validierung im Regelsatz abfangen könnten?

Wir werden das Feature nicht zurückbauen! :slight_smile:

ref Goobi Goobi workflow Dashboard: Ich kann mir auch gut vorstellen, dass die Fehler dort angezeigt werden, aber der Platz ist dort ja begrenzt. In meinen Augen müsste man schon eine dedizierte Seite haben die die Vorgänge auflistet bei denen ein Fehler aufgetreten ist. Eigentlich auch gruppiert nach Schritten, also zum Beispiel

  • OCR: 1 Fehler
  • Derivate generieren: 7 Fehler
  • Export: 3 Fehler

Auf dem Dashboard könnte man dann je nachdem was sinnvoll ist verschiedene Informationen anzeigen, zum Beispiel:

  • Datum, Titel und Schritt der fünf Vorgänge in denen zuletzte ein Fehler aufgetreten ist
  • Anzahl der Vorgänge insgesamt die in einem Fehlerschritt sind
  • Anzahl der Fehler pro Schritt

Auf dem Weg dahin wären noch verschiedene andere Fragen zu klären, aber erst einmal ist meine Frage ja:

Gibt es dazu noch weitere Meinungen?

Dazu melde ich mich noch einmal separat :slight_smile:

2 „Gefällt mir“

@jan, dazu eine Rückfrage von mir:

Könntet Ihr im Falle einer fehlerhaften/ nicht möglichen Verarbeitung/ Indexierung eines Vorganges im Goobi viewer diese Information in das Vorgangslog des betroffenen Vorganges in Goobi Workflow zurückspielen?

Das wird ja bis jetzt nur dann gemacht, wenn der Export des Vorganges von workflow zu viewer gänzlich scheitert?

Das wäre der Plan… Aber es ist nur ein kleines Teilstück in der Gesamtproblematik.

Der Goobi viewer Indexer kann aus den METS-Dateien ja die Goobi workflow Vorgangs-ID ermitteln und mit der Kenntnis der REST API URL + Token damit auch etwas zum entsprechenden Vorgangslog hinzufügen. Aber damit ist es ja nicht getan. Ihr müsst in Goobi workflow ja die Möglichkeit haben die entsprechenden Vorgänge auch zu identifizieren.

Am einfachsten ginge das mit dem ERROR Status für einen Schritt, aber es kann ja nicht einfach der letzte offene Schritt genommen werden, denn nach dem Export können ja auch weitere automatische Schritte kommen… Es müsste also immer der letzte Export-Schritt sein, aber da es ja auch mehrere automatische Exportschritte hintereinander geben kann verbliebe ein Restrisiko. Das ließe sich nur verhindern in dem auch die Schritte-ID mit übermittelt werden würde. Dann könnte der Indexer nicht nur den Vorgang, sondern auch genau den Schritt identifizieren der jetzt fehlgeschlagen ist.

Was ist dann aber wenn der Export via GoobiScript oder aus als Administrator aus der Vorgangsübersicht heraus ausgelöst wurde? Dann gibt es ja keinen Schritt zum Schließen. Eine Übersicht braucht es ja aber trotzdem.

Hier müsste man jetzt kreativ werden und sich überlegen, ob nicht ein Schritt, sondern ein ganzer Vorgang in den ERROR Status versetzt werden können müsste. Das ließe sich auch abwärtskompatibel implementieren (Ein Vorgang ist automatisch im ERROR Status, wenn entweder ein Schritt im ERROR Status ist, oder der gesamte Vorgang dort hinein versetzt wurde).
Dann bedarf es einer Übersicht aller Vorgänge die im ERROR Status sind. Darin könnte man dann Suchen, Sortieren, Filtern etc. Vielleicht auch GoobiScript ausführen um die Fehler zu korrigieren.
Wie würde dann ein Vorgang wieder aus dem ERROR Status herauskommen? Welche Logik sollte dann greifen?

Ihr merkt schon, es startete mit einer Frage zum Goobi viewer Indexer, aber es mündet dann vielleicht an ganz anderer Stelle wo man etwas verändern sollte.
Andersherum wäre eine solche Übersicht nicht nur für Indexierfehler hilfreich, sondern vermutlich im Sinne eines Workflow-Management-Tools ein guter Ort, an dem man sich konzentriert den Fehlern im Arbeitsablauf zuwenden kann…

@jan

Was den Regelsatz betrifft, fällt mir akut nichts ein, was dann im Goobi viewer als Fehler aufschlägt. Die Probleme Goobi workflow vs. Goobi viewer liegen für mich eher auf anderer Ebene.

Zum Beispiel kann ich ja in Goobi workflow im Metadateneditor das Feld “Anmerkung intranda viewer” mehrmals anlegen:
grafik

Im viewer wird aber nur der erste Eintrag angezeigt:

Die METS/MODS als solche ist valide und enthält beide Einträge. Hier handelt es sich vermutlich um eine Konfiguration im viewer, die eine Wiederholung des Feldes in der Anzeige erlaubt.

Kurz gefasst: Ist eine Wiederholbarkeit eines Feldes in goobi workflow möglich, sollte die Anzeige der sich wiederholenden Felder auch im goobi viewer standardmäßig gewährleistet sein.

Ein weiteres Beispiel ist die Seitenzuweisung im Metadateneditor.

Ich kann einem Werk alle Images von 1 bis 51 zuweisen. Ich kann aber auch die Seiten 2 bis 6 und 11 bis 51 zuweisen:

Auswirkungen hat die Auswahl mit der Lücke zwischen Image 6 und Image 11 allerdings nicht. Schon goobi workflow ignoriert diese Auswahl:
grafik

Im Viewer werden dementsprechend auch alle Seiten angezeigt.

ja auch:

  • im viewer backend
  • ebenso die angesprochene liste der noch zu indexierenden vorgänge.
  • wenn möglich eine rückmeldung an den vorgang

ich finde alles toll :smiley:

1 „Gefällt mir“

zur Info:

Ich habe gerade einmal in der Updateanleitung für die kommende Version eine Notiz eingefügt, dass die E-Mailbenachrichtigung bei Indexierfehlern geprüft und gegebenenfalls korrigiert wird. Das finde ich einen sinnvollen ersten Schritt:

Danke für die Rückmeldung @bbfks :slight_smile:

1 „Gefällt mir“

Das kann viele Ursachen haben. Die Felder sind in der Regel wiederholbar, wenn das nicht der Fall sein soll muss es im Regelsatz oder im Goobi viewer Indexer explizit konfiguriert sein. Das Beispiel ist anscheinend schon zurückgebaut, ich habe aber die Kette gerade einmal geprüft und kann keine Einschränkungen feststellen.

Zu dem Thema sind wir ja bereits separat in Kontakt :wink:

Ich habe den Vorgang mit dem sich wiederholenden Feld “Anmerkungen Viewer” erneut angelegt und exportiert:


https://haab-digital.klassik-stiftung.de/viewer/metsresolver?id=1867822032
grafik

Hilft das weiter?

Klaro. Da ist der Fehler ja auch schon zu sehen: Das MODS Mapping ist falsch, hier liegt also ein Fehler im Regelsatz von Goobi workflow vor. Der Goobi viewer Indexer und Goobi viewer Core interpretieren das alles richtig.

Im Regelsatz steht:

      <Metadata>
        <InternalName>ViewerNote</InternalName>
        <WriteXPath>./mods:mods/mods:note[@type='viewer']</WriteXPath>
      </Metadata>

Ich habe da jetzt noch eine Raute “#” ergänzt:

      <Metadata>
        <InternalName>ViewerNote</InternalName>
        <WriteXPath>./mods:mods/#mods:note[@type='viewer']</WriteXPath>
      </Metadata>

Jetzt ist das MODS Mapping korrekt und auch die Anzeige im Goobi viewer ist richtig.

mods

1 „Gefällt mir“

Hallo @jan ,
auch wenn die Indexierung ja genau genommen ein Schritt nach erfolgtem Export ist, der dadurch ja praktisch zum Viewer gehört, finde ich, dass eine Benachrichtigung auf der goobi-Seite erfolgen sollte. Ich halte es auf jeden Fall für sehr sinnvoll, wenn im goobi-Vorgangslog der Hinweis auf den Fehler stehen sollte. Eigentlich müsste doch sogar der eigentliche Schritt “Export” auf Fehler gesetzt werden, damit es dem Bearbeiter direkt auffällt.
LG
Holger :slight_smile:

Hallo @Holger,

danke für Dein Feedback! Ja, eigentlich sollte der Export-Schritt auf “Fehler” gesetzt werden, aber da ist ja noch das Problem:

Ich sehe, das ist etwas, was ich einmal mit den Kollegen von Goobi Goobi workflow besprechen muss :wink:

Beste Grüße von

Jan :slight_smile:

Moin @jan,
also aus Anwendersicht würde ich sagen, dass sich goobi sowohl beim normalen Weg, den Export auszulösen als auch bei deinen beiden alternativen Varianten gleich verhalten müsste wenn möglich.
LG
Holger

1 „Gefällt mir“