Wie ist der Documentviewer-Cache aufgebaut?

Wie ist der Documentviewer-Cache aufgebaut?

Der Aufbau des DV-Cache hat sich im Laufe der Zeit geändert:

  • In den erste Versionen hieß der Documentviewer noch Contentviewer. Der Standort wurde aus der ID des Dokumentes gebildet und zwar:
    ID des Dokumentes auf 10 Stellen auffüllen und dann teilen. Je 2 Ziffern bilden das Verzeichnis im Cache.

  • Seit die Komponente Documentviewer heißt und bis enaio Version 7.00: 
    Die Struktur ist anders als in den vorherigen Versionen, siehe auch KB-036/12 und KB-104/12. Der Standort wird aus dem Hashwert des Dokumentes gebildet. Je 2 Ziffern bilden das Verzeichnis im Cache - bis zu 6 Ebenen.

  • bis enaio 7.00:
    Das Verzeichnis MAPCACHE darf - nach Möglichkeit - nicht gelöscht werden. Gesteuert und überwacht wird die Verarbeitung mit MARKER-Dateien. Diese liegen im Hashwert-Verzeichnis. 
    Beispiel: 

  • Ab 7.10 hat sich die Struktur des Cache-Verzeichnisses noch einmal geändert und die Ansteuerung. Bitte beachten beim Bereinigen per Hand!

  • Es wird weiterhin der Hashwert verwendet. Je 2 Ziffern bilden das Verzeichnis im Cache - bis zu 4 Ebenen.

  • Das unterste Verzeichnis (5. Ebene) ist der Hashwert. In diesem Pfad liegen die Daten in weiteren Unterverzeichnisse. 0 bis 10 sind möglich, je nachdem wer bzw. welche Komponenten gerade die Erstellung aufgerufen haben bzw. parallel aufrufen. Das kann z. Bsp. sein durch Anklicken des Buttons "Vorschau neu erstellen" im Client durch  mehrere Benutzer, Importe, Skripte, Events ... 
    Ist die Konvertierung erledigt, wird aufgeräumt. Übrig bleibt im Standardfall das Verzeichnis 0 mit allen Informationen.

    In diesem Beispiel sieht man, dass es 3 parallele Jobs gab: 2 wird aktuell ausgeliefert. 0 und 1 werden in Kürze aufgeräumt (das sieht man anhand der DEL-Dateien). 2 wird später umbenannt in 0.

  • Das nächste Unterverzeichnis teilt sich auf in alle Komponenten, die beliefert werden müssen. Je nach Konfiguration sind diese Verzeichnisse vorhanden: 

    Wenn die Pre-Seiten-Generierung auf 0 gestellt wird (route.properties im RenditionCache-Verzeichnis), dann kann es sein, dass diese Verzeichnisse nicht vorhanden sind. 
    Funktion/Bedeutung der Unterverzeichnisse:

    • PDF: Für den Client (Vorschau einfaches PDF)

    • PDFA: Für den Client (Vorschau im PDF/A-Format). Dies ist nur vorhanden, wenn PDF/A konfiguriert ist.

    • Thumbnail: Vorschaudateien für alle Komponenten, die Thumbnails verwenden, wie Outlook, Quicklook …

    • Web: Für andere Tools/Komponenten sowie interne Verwaltung zum Dokument 
      Das Web-Verzeichnis unterteilt sich weiter. In der Info.xml steht der Status der Konvertierung aller Versionen für das Dokument bzw. des Verzeichnisses. Im Idealfall steht überall successfull. 
      Beispiel:

    • hocr: beinhaltet die Positionsdaten der Volltext/Text-daten. Das ist die Markierung im Client nach der Volltextsuche. 

    • search: Ist eine Mini-Datenbank zur Verwaltung des Dokumentes.

    • 96 + 1200: Slides bzw. Quicklooks im Client  

    • Text: Volltextdaten 

  • Hinzu kommen separate Verzeichnisse für Migration (= FTS-ARCHIVE) und Sicherung Volltextdaten (BACKUP).

  • Pro Dokument-Verzeichnis gibt es eine Mini-Datenbank mit allen Infos und Stand der Konvertierung aller konfigurierten Features (also: Volltext, Slide, Quicklook ...) sowie eine info.xml. 

  • Im Documentviewer kann zudem eingestellt werden, ob die Daten im BACKUP-Verzeichnis gezippt/gepackt werden.

    • Falls ja, wird es eine Archive-Datei geben mit allen Dokumenten, dessen erste 4 Hashwert-Einträge identisch sind. 
      Beispiel gezippt: d:\enaiodata\dv\cache\backup\text\00\0000.archive

    • Wird nicht gepackt, liegen die Dateien als Text in Unterverzeichnissen. 
      Beispiel nicht gezippt: d:\enaiodata\dv\cache\backup\text\00\00\0000AB1100F44448...86600.TXT

 

Tipp: Wie kann man den Hashwert ermitteln (gültig ab enaio 7.10): 

Es gibt diese Möglichkeiten:

  • über die Protokolle, z. Bsp. Renditioncache-Log oder Client-Log oder Server-Log 

  • oder über die Datenbank:
    SELECT OSHASH FROM OSDOCHASH WHERE OBJECT_ID=<dokumentid>;
    Beispiel:
    select oshash from osdochash where object_id=124;
    (siehe auch KB-Eintrag KB-061/13) 

  • per Documentviewer-URL:
    http://<documentviewerserver>:8070/osrenditioncache/app/management/info/<documentid>
    Beispiel: http://10.10.77.148:8070/osrenditioncache/app/management/info/124
    Rot markiert ist der Pfad im Documentviewer-Cache:

 

Besonderheit:

Im Documentviewer-Cache-Verzeichnis liegen standardmäßig auch BACKUP und FTS-ARCHIVE!!

Verzeichnis

Inhalt

Verzeichnis

Inhalt

BACKUP

Das sind die Volltextdaten !! Diese sollte nie gelöscht werden. Es ist wichtig für Nachindizierung oder Neuaufbau des Volltextes. Auch bei Volltext-Migration hilft es (in Abhängigkeit, wie die Migration ausgeführt wird). 

FTS-ARCHIVE

Volltextdaten aus alten Versionen für Migration. Sollen diese weiterhin verwendet werden, dann nicht löschen! Hier können ZIP-Dateien mit Volltext-Daten eingefügt werden. Beim Start des Documentviewers werden diese eingelesen und erfolgreich verarbeitete ZIP-Dateien werden in ARCHIVE umbenannt. 

 

Die Struktur ab 7.10 ist weiterhin gültig. Das Verzeichnis BACKUP sollte nie gelöscht werden. Hier liegen die Sicherungen alle extrahierte Texte für den Volltextes. 

Verwandte Artikel