/
Wie arbeitet der Documentviewer die Jobs ab?

Wie arbeitet der Documentviewer die Jobs ab?

Es gibt mehrere Wege, wie Daten zum Documentviewer kommen. Ab enaio 7.10 beinhaltet der Documentviewer auch die Volltextdaten.

So bekommt der Documentviewer Jobs:

 

Wer erstellt diese Jobs?

zu 1) der enaio Server oder Indexmanager oder per Server-API
zu 2) Der Documentviewer selbst beim Entpacken von Daten, z. Bsp. E-Mail-Anhänge oder ZIP-Dateien oder PDFs mit Bildern. Es kann aber auch per Erstellung von Job-Dateien durch Indexmanager oder per Skript gefüllt werden.
zu 3) Vorschau Client, Webclient, Desktop-App, Schnittstellen, Server mit Pagecount und Slide sowie Volltext-Daten-Abfrage des Indexservice

 

1. über CPQueue-Einträge

(DV = Documentviewer)

  1. Proaktiv geht der Documentviewer zum Server und holt die Jobs aus der  CPQueue ab, die beim Documentviewer konfiguriert sind. Es gilt Last-In, First-Out. 
    Der Documentviewer markiert die Daten, die er abholt und in Bearbeitung hat mit Setzen des Dienstnamens in der Tabelle OSCPMQUEUE. Es werden alle Einträge mit identischen ID markiert. 
    Beispiel: Wenn ein Dokument mehrfach in der CPQueue steht, markiert sich der Dokumentviewer alle Rendition-Einträge für dieses Dokument mit created (OSCPMQUEUE-Feld) kleiner dem Wert, den er sich zuerst geholt hat. 

  2. Die Konfiguration befindet sich in der config.properties (RenditionCache).
    Standard CP-Queue-Eintrag = Rendition.
    Soll der Documentviewer andere Daten abholen, dann an dieser Stelle den neuen Namen (beliebig wählbar, Empfehlung: keine Sonderzeichen) eintragen, z. Bsp. RENDITIONEMAIL oder RENDITIONPRIO1. 

  3. Beim Server werden nun die Daten zum Objekt abgeholt per API-Job dms.getobjectdetails (es kann ein Ordner, Register oder Dokument sein) inkl. Hashwert. Der Hashwert ist die Basis für die Ablage im DV-Cache. Bei Ordner und Register wird ein fiktiver Hashwert erstellt. 
    Es erfolgt eine Analyse des Rückgabewertes (z. Bsp. Pagecount erstellen ja/nein, Volltext erstellen ja/nein, Slide erstellen ja/nein …).

  4. Prüfen, welchen Job der Documentviewer bekommen hat:

    • Wenn es ein RENDITION-Job ist, werden diese Schritte ausgeführt: 

      • bis einschl. enaio 8.50 (ab 9.0 gibt es die Mapper-Datenbank nicht mehr. Dieser Schritt wird übersprungen)
        Prüfen, ob in der DV-Datenbank etwas zum Objekt steht.

        1. Falls ja:

          • steht dort, dass es einen Fehler gab, dann nichts tun. Unnötige Arbeit soll vermieden werden. 

          • steht dort, dass das Dokument schon erstellt wurde, dann den DV-Cache prüfen, ob hier etwas liegt. 

            • Falls ja: Eintrag in DV-Datenbank aktualisieren

            • Falls nein: Wie ein neues Dokument behandeln und Rendern starten.

        2. Falls nein: Eintrag in der DV-Datenbank ergänzen.

      • prüfen, ob das Objekt im DV-Cache-Verzeichnis liegt

        1. Falls ja: nichts tun

        2. Falls nein: Das Objekt rendern und alle Daten erstellen nach ermittelter Objektinfo und Konfiguration des Documentviewers.

    • Es ist ein RenReset-Job: 

      • Daten im DV-Cache ignorieren bzw. verwerfen und wie ein neues Dokument behandeln, dass es noch nie gab.

      • D.h. das Objekt rendern und alle Daten erstellen nach ermittelter Objektinfo und Konfiguration des Documentviewers.

  5. Bei Dokumenten mit Volltext wird zusätzlich der Status der Verarbeitung in der Tabelle OSFTSLOG protokolliert. Dazu gehört: Ist es an die OCR gegangen, gab es Fehler beim Rendern ... 

2. über das JOBS-Verzeichnis

  1. Der Documentviewer prüft das Verzeichnis periodisch bzw. benutzt es selbst. 

  2. Falls es Jobs gibt: 

    1. Was sind das für Jobs? 
      Falls es ein Rendition-Job ist: siehe Abschnitt "CPQueue-Einträge” ab Punkt 4. 
      Falls es ein RenReset-Job ist: siehe Abschnitt "CPQueue-Einträge” ab Punkt 4. 
      Falls es ein Delete-Job ist: Eintrag im DV-Cache löschen und in der DV-Datenbank.
      Falls etwas anderes übergeben wird, dann dies ausführen.

3. per URL:

  1. Der Documentviewer prüft, was es für ein Job ist. Standardmäßig steht in der URL, was passieren soll, z. Bsp. PDF liefern, Pagecount liefern, Volltextdaten liefert …. 

  2. Falls es eine Vorschau-Anfrage ist: 
    Im DV-Cache prüfen, ob eine Vorschau verfügbar ist (je nach Anforderung PDF, Thumbnail ... prüfen) 

    1. Ist die Vorschau verfügbar: Daten ausliefern 

    2. fehlt die Vorschau, wie im Abschnitt "CPQueue-Einträge” ab Punkt 4 vorgehen. 

  3. Falls es ein Pagecount-Job ist, den Pagecount-Wert ausliefern. Sofern es keine Daten im DV-Cache, dann wie im Abschnitt "CPQueue-Einträge” ab Punkt 4 vorgehen.

  4. Falls es ein SLIDE-Job ist, die Daten ausliefern. Sofern es keine Daten im DV-Cache, dann wie im Abschnitt "CPQueue-Einträge” ab Punkt 4 vorgehen.

  5. Falls es ein Rendern-Job ist, dann die übergebenen Daten rendern und das Ergebnis ausliefern (das wird z. Bsp. auch vom PDF-Printer aufgerufen)

  6. Falls es ein Volltext-Job ist, dann die Volltext-Daten ausliefern. Dazu wird nach diesem Schema vorgegangen:
    ab enaio 9.00:
    a. Objekt-Infos vom Server holen
    b. prüfen, ob die geforderten Daten im DV-Cache liegen.
    c) falls ja: ausliefern und falls nein: neu rendern, Text extrahieren und dann ausliefern

    bis enaio 8.50:

    1. FTS-Archive (Daten aus Altsystemen) zuerst prüfen, das hat höchste Priorität

    2. nur wenn der Text dort fehlt, dann im im DV-Cache suchen, ob der Text verfügbar ist

    3. fehlt es dort, dann prüfen, ob es in BACKUP\Text liegt.

    4. nur wenn es auch dort fehlt, dann wie im Abschnitt "CPQueue-Einträge” ab Punkt 4 vorgehen. 

4. Abarbeitung speziell bei neuen Dokumenten

  1. Header des Dokumentes analysieren. Das sieht man im RenditionCache-Log. 

  2. Danach entscheiden, welche Route das Dokumente nehmen soll. Es kann OCR aktiv sein. Die genommenen Routen sieht man im RenditionCache-Log und die eigentlichen Convert-Jobs im RenditionPlus-Log, siehe auch
     Wie kann man über die Logs herausbekommen, welcher Converter verwendet wurde?
    Hier findet man auch den Source-Type, um zu sehen, was der Documentviewer aus dem Dokument ausliest. Bsp.: 

  3. Im DV-Cache werden alle Verzeichnisse erstellt, die gefüllt werden sollen. 

  4. Standardmäßig wird eine PreVorschau erstellt, die der Client oder die Komponente, die per URL gerade die Vorschau anfordert, zuerst bekommt, damit so schnell wie möglich etwas geliefert wird. Diese ist nicht durchsuchbar. Im Hintergrund läuft die eigentliche Vorschauerstellung (z. Bsp. mit Hidden-Text). Sobald diese fertig ist, wird das Dokument automatisch ausgetauscht, da der Client permanent die URL aufruft. Es kann vorkommen, dass man das Dokument ein 2. Mal anklicken muss, damit das durchsuchbare Vorschaudokument angezeigt wird.
    Der Documentviewer prüft per eigenem URL-Aufruf, den Stand der PDF-Konvertierung. 
    Bitte beachten: Im Text-Verzeichnis gibt es immer eine ocr-error-Datei, sobald Volltext aktiviert ist. Erst wenn der Text extrahiert ist, wird die Error-Datei ersetzt durch den Text. 
    Bei Finereader speziell: Erst wenn der OCR-Job vom OCRService verarbeitet wurde und an den Documentviewer die Texte geliefert werden, wird die Error-Datei ersetzt. 
    Wichtig auch: Beim erneuten Rendern beachtet der Documentviewer auch den Datenbankeintrag in Tabelle OSFTSLOG. Es wird nicht erneut Volltext extrahiert. Das passiert nur in Kombination Anpassung der Tabelle OSFTSLOG Feld2 und RENRESET-Job.

  5. Nach Fertigstellung aller Routen, werden:

    1. in der CPQueue PAGECOUNT und SLIDE erstellt 

    2. falls Volltext vorhanden ist: Volltext-Jobs werden in die CPQueue gelegt 

 

Sofern Volltext aktiv ist: Während der Verarbeitung wird zusätzlich der Status in die Tabelle OSFTSLOG geschrieben. 

Bei größeren Dokumenten ist es möglich, dass der Timeout nicht reicht. Dann entscheiden, wie verfahren werden soll. Das generelle Erhöhen des Timeouts wirkt sich auf alle Dokumente bzw. Dokumenttypen aus. 

 

Verwandte Artikel