Enaio Dokumente ohne Volltext Index - Identifizierung möglich?

enaio®
1

Hallo zusammen,

wir haben verstärkt das Thema, das vereinzelt (gerne auch mal gehäuft) enaio Dokumente die vom Volltext/OCR verarbeitet werden sollen dies nicht tun :slight_smile:

Um unseren Nutzer zuvor zu kommen, die einen solchen Fehler feststellen und uns mit einem Ticket beglücken, träume ich von einer Möglichkeit jene Dokumente ohne Volltext-Index identifizieren zu können.

Bleibt es bei einem Traum oder habt Ihr eine Idee wie ich zumindest an die ID’s herankommen kann?

Merci vorab und viele Grüße
Flo

1 „Gefällt mir“
2

Hoi @fb, meinst Du etwas in Richtung enaio® index-manager?

Volltextübersicht
Die Aktion zeigt eine Übersicht über die Objekttypen und das enaio®-System an.

[…]

Nachindizieren / PostIndexing
Die Aktion überprüft Volltextdokumente, deren Indexdaten indiziert sind, deren Dateien aber auf Grund von Fehlern in der Kooperation mit der Rendition nicht indiziert werden konnten.

3

Hi @rk ,

ja genau. Dieses Tool arbeitet aber autark und führt alle Arbeiten automatisiert durch.
Ich suche nach einer Möglichkeit an die ID’s der Objekte heranzukommen zu denen kein Volltext existiert um diese z.B. nach “meiner” Priorität dem Tool als ID-Liste (List-Indexing) zuzuführen.

Hilft mir hier die OSFTSLOG Tabelle irgendwie weiter?

Ich habe auch gerade die Herausforderung das die Warteschlange (OSRENDITIONCACHE) extrem lang ist. Da würden sich neue Aufträge ja am Ende einreihen.

Kann ich diese irgendwie beeinflussen? :laughing:

LG Flo

4

Hallo @fb,

das sind zwei relativ komplizierte Themen :slight_smile:

ElasticSearch

Ab hier folgt mein ElasticSearch Halbwissen:

Allgemeine Infromationen zum Index findet sich hier über die URL http://localhost:8041/_stats abfragen. Das Login dazu findet man in der application-es.yml im Service-Manager.

Der Index für die Dateien heisst bei enaio üblicherweise enaioblue_0.
Mit dem Endpunkt http://localhost:8041/enaioblue_0/_stats kann man dann nochmals die Details zu diesem Index erfragen.

Den Dokumentenstatus kann man dann per http://localhost:8041/enaioblue_0/_doc/2691?_source=false erfragen, wobei dir 2691 die OS ID des Dokuments ist.

{
  "_index": "enaioblue_0",
  "_type": "_doc",
  "_id": "2691",
  "_version": 2,
  "_seq_no": 74,
  "_primary_term": 93,
  "found": true
}

Wenn man das ?source=false weglässt, sieht man auch die indizierten Metadaten.

Details zu ElasticSearch API findet man zum Beispiel hier:

DocumentViewer - RenditionCache

Dass die Queue an sich auf Dauer so voll ist, ist prinzipiell nicht so gut. Ist bekannt, warum dies so ist? Falls es sich hierbei um Fehler handelt, müsste man überlegen, ob man die Queue leer und schrittweise die Rendition auf den aktuellen Stand bringt.

Liebe Grüsse
Uli

2 „Gefällt mir“
5

Moin @fb , Gemäß der Doku kann man über die Flags in der osfts Tabelle ermitteln, ob der Volltext (Dokument und/oder Indexdaten) erstellt wurde:

Vielleicht hilft das zusammen mit Ulis Antwort.

Gruß

Alexander

2 „Gefällt mir“
6

Von einem Kollegen aus einem Projekt kommt noch folgender Hinweis. Diesen finde ich auch wichtig, da er komplett per API zu machen ist:

  1. Ermitteln der Dokument-IDs und deren Typen z.B. des gestrigen Tages per SQL-Select
  2. Prüfen pro Objekt-Typ, ob für dieses überhaupt ein Volltext aktiv ist
  3. Check des Volltext-Ergebnisses pro Dokument per http://localhost:8070/osrenditioncache/app/trusted/document//rendition/txt
    1. wenn hier etwas Sinnvolles im Return zurückgegeben wird, kann man von erfolgreicher OCR/Volltext für den Dokumenteninhalt ausgehen
    2. falls nicht, kann man dafür die erneute Indexierung anstoßen