/
Wie wird ein Dokument verarbeitet (CPQueue-Fluss)

Wie wird ein Dokument verarbeitet (CPQueue-Fluss)

Owned by Former user (Deleted)

Datenfluss:

Das passiert, wenn ein Dokument erstellt wird:


CPQueue - Verarbeitungskette:

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 Servicemanagerprüfen, ob Jobs verarbeitet werden.

Wer die IDs wissen möchte, muss in die Datenbank schauen. Wichtig: Nur Selects ausführen. Bei allen anderen Eingriffen den Support hinzuziehen, sonst kann der Support-Anspruch erlöschen.

ID der gesperrten Volltext-Jobs ermitteln:
SELECT * FROM OSCPMQUEUE WHERE LOCK_SERVICE LIKE 'IDX%'; 

Gesamtmenge ausgeben und nach Dokumenttyp und Queue sortieren:
select queuename,ostype,count(ostype) as AnzahlJobs from oscpmqueue group by queuename,ostype;

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 Server holt sich die Infos vom Documentviewer (periodischer Server Job, Standardwer = alle 60 Sek.). Verwendet wird der Documentviewer, der im enaio Enterprisemanager bei diesem Server hinterlegt ist.
  2. Rendition Jobs
    • Der Documentviewer holt die Rendition-Jobs (RENDITION und RENRESET) ab.
    • Dann holt er sich vom enaio Server die Dokumenteigenschaften (dms.GetObjectDetails).
    • Anhand dessen weiß er, ob Volltext und Slides 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
    • 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 ist bei Renditioncache, mit dem sich der Servicemanager verbindet. 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 mittel 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: 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:


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.

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. Sind hier mehr als die konfigurierten Werte vorhanden, 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