CPB wird nicht abgearbeitet. Was tun?

1. enaio Enterprisemanager starten

2. auf "erweiterte Einstellungen, Überwachung, CP-Warteschlange" gehen.
   Bei Mehrserversystemen: Egal welcher Server. Es gibt nur 1 Datenbank und damit nur 1 CPB-Queue.

3. Sofern, wie im Screenshot zu sehen, "beim Verbinden aktualisieren" nicht aktiviert ist, einmal auf "Aktualisieren" klicken

   Open

   

4. Dann die Spalte Dienstname prüfen.

   1. Wenn hier nichts steht und bei Aktualisierung auch keine Daten verarbeitet werden, laufen die zugehörigen Dienste nicht. Alle Dienste holen sich periodisch Jobs ab und markieren sie mit ihrem Namen.

   2. Sofern hier Sperren stehen (Spalte Dienstname ist gefüllt), sind sie entweder gerade in Bearbeitung oder es gab Fehler bei der Verarbeitung oder die Dienste sind nicht erreichbar. 

5. Als nächstes ermitteln, welche Objekte sind es und von wann sind die Jobs - Typname, "Min Zeit" und "Max Zeit". Die ID der Dokumente sieht man nur in der Datenbank.

   1. "Min Zeit" = ist das Datum des ältesten Jobs in der CPQueue.

   2. "Max Zeit" = ist das Datum des jüngsten Jobs in der CPQueue. 

6. Dann die jeweiligen Services auf Fehler prüfen. Sind keine vorhanden, den betreffenden Servive neu laden, siehe nachfolgende Fehlerfälle und prüfen, welche Meldungen kommen. 

7. Laufen danach wieder Jobs auf Fehler, sollten diese genauer geprüft werden. 

Beispiel:

Hier sieht man (nach ein paar Mal Aktualisieren), dass:

• neue Pagecount-Jobs generell abgearbeitet sind bzw. werden, aber gesperrte Pagecounts vorhanden sind 

• sehr viele Fulltext-Jobs gesperrt sind (Standardwert sind 10 Jobs parallel, d.h. es sollten maximal 10 Jobs gesperrt sein )

• Es gibt abweichende Queuenamen (*WAIT). Diese können entweder bei einem Server konfiguriert worden sein oder manuell geändert worden sein. Scheinbar gibt es aber keinen Service, der diese abholt. 

Open

1. Die Pagecounts werden von den enaio Servern verarbeitet. Konkret wird der periodische Serverjob "ProcessPageCountCPMessages" alle 60 Sekunden (Standardeinstellung) ausgeführt. Der jeweilige Server geht zum Documentviewer und fragt die Pagecounts für die Objekte ab. Dazu sperrt er die Jobs, für die er das macht.
   Technisch wird per CURL.EXE die URL aufgerufen:
   http://<osrenditioncache-Eintrag aus dem enaio enterprisemanager>:8070/osrenditioncache/app/trusted/document/<DocID>/rendition/pagecount?timeout=120000&size=96&digest=<Hashwert des Dokumentes>
   
   Können die Pagecount per einfachem URL-Aufruf nicht geliefert werden, wird ein Convert-Pagecount ausgeführt per REN-BAT. Gibt es auch hier Fehler, bleichen die Jobs gesperrt und das Server-Err-Log füllt sich. 

   Open

   

2. Lösung ab enaio 9.10:

   1. im enaio Enterprisemanager mit dem Server verbinden, der die Jobs gesperrt hat

   2. die Pagecount-Jobs mit dem gleichen Dienstnamen markieren

   3. Den Reset-Button rechts oben drücken.
      Achtung: Der Button wird nur verfügbar, wenn man beim richtigen Server ist und Pagecount-Jobs markiert ist. 
      
      Im Screenshot ist der Enterprisemanager mit Server3 verbunden. D.h. es können alle Pagecount, die am Ende eine 3 haben entsperrt werden. 

      Open

      

3. Bei Mehrserver: Der Reihe nach im enaio Enterprisemanager mit allen anderen Servern verbinden und dort ebenfalls "Reset" drücken analog Punkt 2.

4. Nach spätestens 60 Sekunden sollten die Jobs abgearbeitet werden. Für kurze Zeit kann der periodische Server-Job auch angepasst werden. Ich würde ihn nicht unter 10 Sekunden stellen. 

5. Alternativen zum Zurücksetzen:

   1. alle enaio Dienste neu starten. 

   2. Script implementieren, dass die Sperre zurücksetzt. 

6. Laufen die Jobs danach wieder auf Fehler, dann ist der Documentviewer, der bei diesem Server hinterlegt ist, nicht erreichbar. Bitte diesen prüfen.

7. Funktioniert es dann immer noch nicht, dann zuerst prüfen, ob die CURL.EXE im enaio Server-Verzeichnis vorhanden ist. 

   1. Falls nein:
      Die curl.exe aus einem anderen Verzeichnis kopieren. Die EXE allein genügt, es sind keine weiteren DLLs nötig. 

   2. Falls ja:

      • Die URL prüfen. Dazu im enaio Enterprisemanager des enaio Servers den Eintrag "Renditioncache" ermitteln.
        Außerdem ein Beispieldokument ermitteln, z. Bsp. per Datenbank: 

        -- MSSQL: SELECT TOP 10 * FROM OSCPMQUEUE WHERE QUEUENAME='PAGECOUNT';  -- ORACLE: SELECT * FROM OSCPMQUEUE WHERE ROWNUM<11; -- Die ID notieren und den Hashwert ermitteln, -- z. Bsp, so (MSSQL- und ORACLE-STATEMENT identisch):  SELECT OSHASH FROM OSDOCHASH WHERE OBJECT_ID=<docid>; 

        Dann die URL zusammenbauen. 
        <http://<osrenditioncache-Eintrag> aus dem enaio Enterprisemanager>:8070/osrenditioncache/app/trusted/document/<DocID>/rendition/pagecount?timeout=120000&size=96&digest=<Hashwert des Dokumentes>
        
        Beispiel: http://127.0.0.1:8070/osrenditioncache/app/trusted/document/123/rendition/pagecount?timeout=120000&size=96&digest='ABC123000EEE111';
        
        erwartetes Ergebnis:
        Die Zahl für Pagecount. Sollte die Zahl nicht kommen, muss beim Documentviewer weitergesucht werden. Der liefert dann offensichtlich nicht die Daten, die er haben sollte.  

      • aus dem enaio Server-Err-Log einen Convert-Bat-Eintrag kopieren und in Commandline kopieren:

        "E:\OSECM\server/___ren.bat" -id "14301731" -targetFile "e:\osecm\server\ostemp\cnv_322337E6F524478DBBB49E585F84A137.txt" -rendition "pagecount" -url "http://127.0.0.1:8070/osrenditioncache" -digest "BB0884C5D767A5D1C3D82B26CCF6700D0B3F4FE7943FA04F462E959B42BB07BF" -timeout 120000 

        Falls Fehler erscheinen wegen Timeout:
        Testen, ob es funktioniert, wenn ab "-timeout" entfernt wird. Eventuell dauert die Konvertierung nur einfach länger und der Standard-Timeout muss erhöht werden (enaio Enterprisemanager bei Servereigenschaften, Kategorie "Allgemein" Sektion "Conversion"). 

siehe vorheriger Punkt Pagecount. Einziger Unterschied: Der periodische Serverjob "ProcessSlideCPMessage" führt die Aktion aus. Die Slides (= Quicklooks im enaio Client oder auch DIA genannt) werden vom Documentviewer abgeholt und parallel zum Verzeichnis WORK im Verzeichnis SLIDE abgelegt. 

1. Rendition-Jobs werden vom Documentviewer aktiv abgeholt. Standardmäßig sind es 3 Jobs parallel. Es kann sein, dass ein Job kurzzeitig in der CPQueue gesperrt bleibt, solange die OCR-Erkennung läuft. 

2. Da es 1-n Documentviewer geben kann, sollten auch die Namen der Instanzen entsprechend konfiguriert/gewählt sein, damit man erkennen kann, welcher Documentviewer die Jobs gesperrt hat.
   Hier ein Beispiel: Es gibt KDS01 und KDS03 für die Verarbeitung der Jobs. Das zeigt deutlich, dass es bei KDS01 Probleme zu geben scheint: 

   Open

   

3. Zu den betroffenen Documentviewer gehen und den Documentviewer prüfen.

   1. läuft der Dienst noch?

   2. Was meinen die Logs?

      • Gibt es evtl. Exceptions?

      • oder ist der Plattenplatz voll? 

      • oder werden Daten geblockt vom Virenscanner?

      • Wurden dem technischen Benutzer Rechte entzogen?

      • Werden die OCR nicht abgearbeitet? 

      • ...

4. Rücksetzen der Jobs ist nur mit dem Neustart des Documentviewers möglich. Danach in jedem Fall prüfen, ob der Indexservice auf einen dieser Services umgeleitet ist und diesen neu laden, siehe Punkt "Fehlerfall 'Fulltext*' sind gesperrt oder liegen geblieben". 

1. Da diese Jobs aktiv vom Indexservice (im enaio Servicemanager) abgeholt werden, sollte der Indexservice geprüft werden bzw. das services.log. 

2. Wurde ein Update auf enaio 10.x oder höher vorgenommen? 

   1. Falls ja: Der Servicename hat sich geändert von IDXSERVICE auf INDEX:8045. Diese Jobs können nur über die Datenbank zurückgesetzt werden. 

3. Läuft der Dienst noch (enaio Servicemanager)? 

   1. Falls nein: Was findet man in den Logs dazu?

      • Ist der ElasticSearch nicht erreichbar?

      • Oder ist der ElasticSearch Readonly?

      • Oder ist der Documentviewer nicht erreichbar? 

4. Es empfiehlt sich den Documentviewer zu prüfen, mit dem sich der Indexservice verbinden soll.

   1. das wird konfiguriert in der index-prod.yml bei "alternative.rendition.endpoint"

      Open

      

   2. Sofern es diese Datei nicht gibt, holt sich der Indexservice von dem enaio Server, mit dem der Servicemanager verbunden ist, die URL des Renditioncache. 

      Open

      

5. Einfach den Indexservice im Servicemanager neu laden. 

6. Sofern die gleichen Object-IDs wieder auf Fehler laufen: Bitte die Objecte prüfen.

   1. Was sind es für Objekte?

   2. Welche Fehler treten auf?

7. Bitte auch Tabelle OSFTSLOG prüfen. 
   Ist ein eindeutiger / Primary Index für Feld osid gesetzt? Falls nicht, kann es passieren, dass Objekte mehrfach in der Tabelle sind. Eine Verarbeitung ist dann nicht möglich. Die Tabelle muss mit dem Support Berlin repariert werden.