/
Wie ist der Documentviewer-Cache aufgebaut?

Wie ist der Documentviewer-Cache aufgebaut?

Owned by Former user (Deleted)

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

Generell:

  • In den erste Versionen hieß der Documentviewer noch Contenviewer. Der Standort wurde aus der ID des Dokumentes gebildet und zwar: ID des Dokumentes auf 10 Stellen auffüllen 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.
      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. 
      Wird nicht gepackt, liegen die Dateien als Text in Unterverzeichnissen. 
      Beispiel gezippt: d:\enaiodata\dv\cache\backup\text\00\0000.archive
      Beispiel nicht gezippt: d:\enaiodata\dv\cache\backup\text\00\00\0000AB1100F44448...86600.TXT


Wie kann man den Hashwert ermitteln und Ablagestruktur ab 7.10: 

Ermitteln des Hashwertes ist ab enaio 7.10 möglich entweder:

  • ü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
    (siehe auch KB-Eintrag KB-061/13) 
  • Ab 7.10: einfach diesen Link eingeben, der Pfad wird angezeigt: http://documentviewerserver:8070/osrenditioncache/app/management/info/documentid
    Beispiel: 
    • In diesem Pfad liegen die Daten in 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 


Besonderheit:

Im Documentviewer-Cache-Verzeichnis liegen standardmäßig auch BACKUP und FTS-ARCHIVE!!
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. 


Für alle enaio Versionen ab 7.10: 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



Related content