Wie wird ein Dokument verarbeitet (CPQueue-Fluss)

Wie wird ein Dokument verarbeitet (CPQueue-Fluss)

Datenfluss:

Das passiert, wenn ein Dokument erstellt wird:

 

CPQueue - Verarbeitungskette / Weiterverarbeitung:

Zuerst wird bei Neuanlage ein RENDITION-Job erstellt. Wenn dieser verarbeitet ist, werden Pagecount, Slide und (sofern konfiguriert) Fulltext erstellt. Prinzipiell gilt: Last In – First out. 

Die CPQueue kann nur über den enaio Enterprisemanager eingesehen werden bzw. per Datenbank. 

  • Die Spalte Dienstname (= lock_service) zeigt an, welcher Dokumenttyp in Arbeit ist. Wenn in der Spalte nichts steht, wartet der Job darauf, dass ihn jemand abholt/bearbeitet.

  • Bei Documentviewer sollten pro Documentviewer maximal die Anzahl geblockt sein, die im Documentviewer konfiguriert ist (Standardwert 3 pro verarbeitender Documentviewer). Es ist möglich, dass hier mehr steht, wenn die Jobs auf OCR-Ergebnisse warten. Daher ist es ratsam die Documentviewer/Logs zu prüfen.

  • Der Volltext ist standardmäßig auf 10 parallele Jobs gestellt. Wenn OCR-Jobs ausstehen, dann können mehr als 20 Jobs gesperrt sein (10x FULLTEXTIDX + 10x FULLTEXTDOC). Diese werden dann aufgelöst, wenn das OCR-Ergebnis vorliegt. Am besten über den Servicemanager prüfen, ob Jobs verarbeitet werden.

  • Pagecount-Jobs können im enaio Enterprisemanager freigegeben bzw. zurückgesetzt werden. Bei Mehrserversystem: Das geht allerdings nur für die Jobs des Servers, von dem sie gesperrt wurden, siehe auch https://enaiodevelop.atlassian.net/wiki/spaces/PS/pages/21424785 .

  • Wer die IDs wissen möchte, muss in die Datenbank schauen.

 

Wichtig: Nur Selects in der Datenbank ausführen. Bei allen anderen Eingriffen den Support hinzuziehen, sonst kann der Support-Anspruch erlöschen.

 

IDs der gesperrten Jobs ermitteln und nützliche Infos:

Dies gilt für MSSQL-Server und Oracle.

  • ein geeignetes Datenbank-Tool benutzen. Notfalls enaio Enterprisemanager über “Datenbank”.

  • Gewünschtes nachfolgende Statement ausführen. Der Name des Lock_Service wird in der jeweiligen Komponenten konfiguriert.
    Volltext = in der index-prod.yml
    Documentviewer = in der config.properties des osrenditioncache

  • Alle gesperrten Jobs ausgeben:

    SELECT * FROM OSCPMQUEUE WHERE LOCK_SERVICE LIKE 'betroffener Service';  -- Beispiel: SELECT * FROM OSCPMQUEUE WHERE LOCK_SERVICE LIKE 'OSRENDITION*'; 
  • Bei Volltext gab es eine Änderung.
    Alle Volltext-Jobs ausgeben bis enaio 9.10:

    SELECT * FROM OSCPMQUEUE WHERE LOCK_SERVICE LIKE 'IDX%'; 

    ab enaio 10.00:

    SELECT * FROM OSCPMQUEUE WHERE LOCK_SERVICE LIKE 'INDEX%'; 
  • Gesamtmenge ausgeben und nach Dokumenttyp und Queue sortieren:

    select queuename,ostype,count(ostype) as AnzahlJobs from oscpmqueue group by queuename,ostype;
  • Menge/Summen pro Queue ausgeben:

    select queuename,count(queuename) from oscpmqueue group by queuename;

 

Das passiert mit dem Inhalt der CPQueue:

  1. Pagecount Jobs und Slide Jobs

    • jeder enaio Server holt sich die Infos vom Documentviewer

    • Der Zeitraum wird über den periodischer Server Job für Pagecount konfiguriert, Standardwert = alle 60 Sek.

    • Verwendet wird der Documentviewer, der im enaio Enterprisemanager bei diesem Server hinterlegt ist.

  2. Rendition Jobs

    • Jeder Documentviewer, der auf CPB-Verarbeitung gestellt ist, holt die Rendition-Jobs (RENDITION und RENRESET) ab, die noch nicht gesperrt sind.

    • Dann holt sich der Documentviewer vom enaio Server die Dokumenteigenschaften (dms.GetObjectDetails).

    • Anhand dessen weiß er, ob Volltext und Slides etc. erstellt werden müssen. Er führt dementsprechend die Konvertierung aus bzw. das Rendern in PDF. Bei Bedarf (und Konfiguration) werden OCR Job erstellt.

    • Wenn die Konvertierung bzw. das Rendern fertig ist, werden - je nach ermittelter Konfiguration - Volltextjobs in CPQueue gelegt sowie SLIDE Jobs und Pagecount Jobs

  3. Fulltext Jobs

    • Der Indexservice (Bestandteil des Servicemanager) holt alle “Fulltext*” Jobs ab (FULLTEXTIDX, FULLTEXTDOC ...).

    • Er ruft pro Dokument die Texte beim Documentviewer ab und sendet sie an den ElasticSearch. Der ElasticSearch fügt die Daten in seine Datenbank ein.

    • Es wird standardmäßig der Documentviewer verwendet, der bei dem Server hinterlegt, mit dem sich der Servicemanager verbindet. Der Wert steht bei Parameter Renditioncache bei “Servereigenschaften” Kategorie “Services“.
      Achtung: Ist in der Index-prod.yml ein alternativer Link hinterlegt, wird dieser Documentviewer verwendet und nicht der Standard. 

Jeder Job, der gerade in Bearbeitung ist, wird vom jeweiligen Service gesperrt. Im enaio Enterprisemanager sieht man es in der Spalte Dienstname. Treten Fehler auf, dann bleiben die Jobs gesperrt. Im Erfolgsfall wird der Job aus der CPQueue entfernt. 

 

OCR-Jobs:

  • Jeder Documentviewer hat seine eigene OCR-Queue. Sofern beim Documentviewer Finereader aktiviert ist, erstellt er auch Jobs. Diese Jobs holt sich der OCRService (Bestandteil des Servicemanager) proaktiv vom Documentviewer ab.

  • D.h. sind mehrere Documentviewer vorhanden, müssen alle Documentviewer dem OCRService bekanntgegeben werden. Das erfolgt mittels Auflistung in der OCR-PROD.YML. 

  • Die OCR-Jobs werden dann mittels Abbyy Finereader konvertiert in lesbaren Text. Das Ergebnis wird vom OCRService zurück an den Documentviewer gesendet. Dieser fügt sie dann in sein Cache-Verzeichnis ein (und pro Dokument eine Sicherung in Cache\BACKUP sowie BackupIndex Datenbank). Daraufhin gibt es einen Index-Job in der CPQueue. 

 

Einsehen der OCR-Jobs:

  • Dazu diese URL verwenden:

    http://<documentviewerserver>:8070/osrenditioncache/app/management/info/db/ocr

    Da jeder Documentviewer seine eigene Queue hat, muss die Abfrage pro Documentviewer ausgeführt werden. 

    Dies bedeutet, es gibt keine OCR-Jobs. Das ist ok, wenn tatsächlich kein Job vorhanden ist:


    Sind mehr als 100 vorhanden, kann man mit "next" zur nächsten Seite blättern werden. Aktuell gibt es keine Möglichkeit direkt ans Ende zu springen oder nach IDs zu suchen. Man muss 1x "next 0-100" drücken und sich dann bei der Seitenanzahl in der URL annähern. Das Problem ist bereits Thema in unserer Entwicklung.

 

prüfen, ob die Jobs noch abgearbeitet werden:

  • im Services.log sollten Einträge zu finden sein, dass Jobs verarbeitet werden

  • Beim Servicemanager, der den ocrservice hat, sollten auch FREngine.exe im Taskmanager zu finden sein, wenn im Verzeichnis <enaio>\services\servicemanager\data\ocr_data\ocrjob auch Dateien liegen.

  • im OCR-DATA-Verzeichnis:
    Standardpfad = <enaio>\services\servicemanager\data\ocr_data\ocrjob
    Sind hier mehr als die konfigurierten Werte vorhanden oder die Daten sind alt, weist das auf Probleme entweder mit der Abbyy-Instanz hin oder beim Zugriff auf den/die Documentviewer.

Ist "nur" ein Connect verloren gegangen, hilft Neuladen des OCRServices.

 

 

Wer die IDs wissen möchte, muss in die Datenbank schauen. Wichtig: Nur Selects. Bei allen anderen Eingriffen den Support hinzuziehen, sonst kann der Support-Anspruch erlöschen. Bei Fragen oder Unstimmigkeiten, mit dem Support sprechen. 

Verwandte Artikel