CM-Repository-Manager
Verwendung
Ein CM-Repository wird als Haupt-Repository für das Speichern von Dokumenten und Ordnern verwendet, die vom CM verwaltet werden.
Voraussetzungen
● Eine Datenbank für die Speicherung von Inhalten oder Metadaten ist installiert.
Eine Übersicht der unterstützten Datenbanken finden Sie auf dem SAP Service Marketplace unter der Internetadresse service.sap.com/platforms → Product Availability Matrix.
● Die vom Repository-Manager zu verwendenden Memory-Caches sind definiert (siehe auch weiter unten).
Funktionsumfang
Der CM-Repository-Manager unterstützt alle CM-Funktionen.
Persistenzmodi
CM-Repository-Manager können in verschiedenen Modi eingerichtet werden:
● DB-Modus
● DBFS-Modus
● FSDB-Modus
DB-Modus
Alle Daten (Dokumente, Ordner und Metadaten) werden in der Datenbank gespeichert.
Richten Sie das CM-Repository im Datenbankmodus ein, wenn es viele Schreibanforderungen in Ihrem CM-Verwendungsszenario gibt. Da sämtliche Dokumente in der Datenbank abgelegt sind, werden unbeabsichtigte Manipulationen an den Daten von außen vermieden.
Ein weiterer Vorteil der Ablage aller Daten in der Datenbank ist das einfache Vorgehen bei der Datensicherung und Wiederherstellung, da nur die Datenbank gesichert werden muss.
DBFS-Modus
Metadaten und Ordner werden in der Datenbank, Dokumente aber im Dateisystem gespeichert.
Dieser Modus ist bei großen Dokumenten etwas schneller als der Datenbankmodus, da das Streaming der Daten aus der DB wegfällt. Der Modus erlaubt auch eine einfachere Kontrolle über die Größe der Datenbank, da Dokumente im Dateisystem abgelegt werden.
Nehmen Sie im DBFS-Modus keine Änderungen oder Manipulationen an Dateien über das Dateisystem vor.
Da Dokumente
und Metadaten in unterschiedlichen Ablagen liegen, müssen bei der
Datensicherung und Wiederherstellung Datenbank und Dateisystem
berücksichtigt und entsprechend synchronisiert werden (siehe
Sicherung und
Wiederherstellung von CM-Repositorys im DBFS-Modus).
FSDB-Modus
Ordner und Dokumente werden im Dateisystem, Metadaten in der Datenbank gespeichert.
In diesem Modus ist das Dateisystem maßgebend. Da Dateisysteme nicht transaktional sind, bringt der Modus Restriktionen und Performance-Auswirkungen mit sich. Kommt es bei einem Dokument im Dateisystem gleichzeitig zu Lese- und Schreiboperationen, müssen diese Operationen vom Repository-Manager koordiniert werden. Dies geschieht, indem neben den Schreibzugriffen auch die Lesezugriffe in der Datenbank verzeichnet werden. Dies hat Auswirkungen auf die Performance.
Die Datenbank wird auch automatisch aktualisiert, wenn Dateien im Dateisystem entfernt oder hinzugefügt werden. Die automatische Aktualisierung kann in der Konfiguration des Repository-Managers über den Parameter Disable Automatic FSDB Synchronization abgeschaltet werden.
Beachten Sie,
dass es zu Metadatenverlusten (z.B. Verlust von Sperren oder
Zusatzeigenschaften) kommen kann, wenn Dokumente und Ordner direkt auf dem
Dateisystem bearbeitet oder manipuliert werden. Falls die Änderungen direkt im
Dateisystem vorgenommen werden, können die Metadaten teilweise oder ganz
verloren gehen. Wenn Sie beispielsweise den Content direkt im Dateisystem
ändern, geht der letzte bekannte Wert der Systemeigenschaft Geändert von
nach der Synchronisation
verloren. Wenn Sie Namensraumoperationen wie Umbenennen oder Verschiebenausführen, gehen nach der Synchronisation alle
Metadaten der Ressource verloren. Arbeiten im Dateisystem sollten nur von
Administratoren zur einfacheren Durchführung von Massenoperationen (Kopieren,
Löschen) vorgenommen werden.
Die Metadatenverluste können, falls der Parameter Disable Automatic FSDB
Synchronization aktiv ist,
durch Verwendung des Synchronisierungsreports (siehe Reports) vermieden
werden.
Ist der Parameter aktiviert, so kann es beim Lesen eines Dokuments zu korrupten Daten kommen, wenn während der Lese-Operation gleichzeitig Schreib-Operationen auf dem Dokument stattfinden.
Bei einem Szenario mit Schreibzugriff kann dieser Modus keine konsistente Datensicherung und -wiederherstellung gewährleisten. Dies liegt daran, dass Änderungen der Ordnerstruktur im Dateisystem zwischen diesen zwei Aktionen vorgenommen werden können. Bei der Wiederherstellung der gesicherten Daten käme es zu einem inkonsistenten Datenbestand. Eine konsistente Datensicherung und Wiederherstellung ist nur dann gewährleistet, wenn nur Lesezugriffe erfolgen.
Der Persistenzmodus FSDB basiert auf einer 1:1-Beziehung. Z.B. repräsentiert einen Eintrag in der Datenbank – DB – eine Ressource im Dateisystem – FS (file system). Der Modus funktioniert nur mit gemeinsam genutzten Ordnern, bei denen diese Beziehung erhalten bleibt (gemeinsame Ordner, bei denen die Groß-/Kleinschreibung berücksichtigt wird, oder solche, die sich so verhalten). In anderen Szenarios, in denen diese Beziehung nicht zutrifft, funktioniert der Persistenzmodus FSDB nicht; z.B. wenn eine N:1-Beziehung vorliegt (DB:FS; gemeinsam genutzten Ordner, bei denen die Groß-/Kleinschreibung nicht berücksichtigt wird)
Auswahl des passenden Modus
Wenn es hauptsächlich Leseanforderungen gibt, sollten Sie einen Modus wählen, bei dem Inhalte im Dateisystem gespeichert werden. Stellen Sie in diesem Fall sicher, dass der Zugriff auf den betreffenden Teil des Dateisystems durch andere Komponenten verweigert wird oder eingeschränkt ist.
Wenn Sie große Datenmengen verwalten möchten, empfehlen wir den DBFS-Modus.
Nachträglicher Wechsel des Persistenzmodus
Ein nachträglicher Wechsel des Persistenzmodus ist nur vom Modus DB in den Modus DBFS möglich. Ein Wechsel von DB nach FSDB, FSDB nach DB/DBFS oder DBFS nach DB/FSDB ist nicht möglich.
Um den Wechsel durchzuführen, sind folgende Schritte notwendig:
...
1. Stellen Sie sicher, dass genügend freier Festplattenspeicher für die Migration der Inhalte aus der Datenbank in das Dateisystem zur Verfügung steht.
2. Passen Sie die Konfiguration des CM-Repository-Managers an. Geben Sie im Parameter Root Directory den Pfad zum Dateisystem an, in dem die Dokumente aus der Datenbank abgelegt werden sollen. Ändern Sie die Angabe im Parameter Persistence Mode von DB in DBFS.
3. Starten Sie den Application Server neu.
4. Führen Sie den Report CM-Speicher: Content-Crawler aus.
Versionierungsmodi
Das CM-Repository kann in einem der folgenden Versionierungsmodi eingerichtet werden:
● Standardmodus
Wenn das CM-Repository im Standardmodus eingerichtet wurde, legt das System für die versionierte Ressource und die aktuelle Version immer verschiedene Kopien des Contents an. Abhängig vom Persistence Mode des CM-Repository werden die Kopien entweder im Dateisystem oder in der Datenbank abgelegt. Deshalb zeigen die aktuelle Version und die versionierte Ressource immer auf verschiedene Kopien des Contents. Dieser Modus ist standardmäßig für alle CM-Repositories eingestellt.
● Speicheroptimierter Modus
Wenn das CM-Repository im speicheroptimierten Modus eingerichtet wurde, legt das System für die aktuelle Version der versionierten Ressource keinen Content an. Die aktuelle Version und die versionierte Ressource teilen sich denselben Content.
Wenn Sie die versionierte Ressource auschecken, wird der Content dupliziert, der von der versionierten Ressource und der aktuellen Version geteilt wird. Die aktuelle Version zeigt nun zum neu kopierten Content. Somit zeigen die aktuelle Version und die versionierte Ressource auf verschiedene Kopien des Contents. Obwohl der speicheroptimierte Modus also die Auslastung des Speicherplatzes reduziert, benötigen Sie trotzdem ausreichend Speicherplatz für eine Content-Kopie der aktuellen Version beim Auschecken der Ressource.
Wenn Sie die Änderungen an der versionierten Ressource verwerfen, veranlasst das System, dass die Ressource wieder auf den Content der aktuellen Version verweist. Somit teilen sich sowohl die versionierte Ressource als auch die aktuelle Version denselben Content. Der alte Content der versionierten Ressource wird gelöscht.
Wir empfehlen, dass Sie wegen der Spezifika des Persistenzmodus den Standardversionierungsmodus für CM-Repositories im FSDB-Persistenzmodus verwenden. Wenn Sie zum speicheroptimierten Versionierungsmodus wechseln, während Sie im FSDB-Persistenzmodus arbeiten, wird für die aktuelle Version eine Datei mit 0 KB angelegt, die für die Bindung zwischen dem Content der versionierten Ressource und der aktuellen Version zuständig ist. Jede Operation auf den Dateien, die nicht von den Standard-KM-APIs abgedeckt wird, wie das direkte Ersetzen einer Datei auf dem Dateisystem, ohne die Standardmechanismen zum Aus- und Einchecken zu verwenden, führt zu einem Verlust des Content der aktuellen Version.
Ressourceneigenschaften, die vom CM-Repository-Manager unterstützt werden
Der CM-Repository-Manager ist der einzige Repository-Manager, der das gesamte Spektrum der Standardressourceneigenschaften unterstützt, einschließlich der Eigenschaften Description, Read-only und Hidden. Der Standardwert der Eigenschaften Description ist leer, der Standardwert für Read-only und Hidden ist 'false'. Der Dateisystem-Repository-Manager unterstützt diese drei Eigenschaften z.B. nicht.
Namensraumeinschränkungen für Ressourcennamen
·
Maximale Länge für Ressourcennamen:
FSDB: es gelten die Einschränkungen des Dateisystems (Windows-Dateisystem: 255
Zeichen)
DBFS und DB: 448 Zeichen
·
Maximale Pfadlänge (URI ohne Präfix):
FSDB: es gelten die Einschränkungen des Dateisystems (Windows-Dateisystem: 255
Zeichen)
DBFS und DB: unbegrenzt
·
Zulässige Zeichen in Ressourcennamen
FSDB: es gelten die Einschränkungen des Dateisystems (Unicode nur unter
Windows)
DBFS und DB: alle Unicode-Zeichen, Restriktionen jedoch bei manchen
Komponenten des Repository-Framework möglich
Am Ende eines Ressourcennamens darf kein Punkt gesetzt werden.
Datenbankeinschränkungen
Da Knowledge Management selbst keine Größenbeschränkung besitzt, hängt die Maximalgröße eines Repositorys von der darunter liegenden Ablage ab (die technische Maximalgröße einer Datenbank oder eines Dateisystems) ab.
Für eine Datenbank berechnet sich die Maximalgröße aus der Summe aller CM-Repositories, die in derselben Datenbank liegen.
Beachten Sie, dass extreme Datenmengen in Repositories einen größeren Aufwand bei der Datensicherung und Wiederherstellung erzeugen.
Für die Datenbank gelten folgende Einschränkungen:
●
Maximale
Anzahl der Ressourcen (Ordner, Dokumente) in einer Repository-Instanz:
FSDB: keine Einschränkung (begrenzt durch mögliche Einschränkungen des
Dateisystems)
DBFS und DB: 2.147.483.648
●
Maximale
Größe einer einzelnen Ressource:
FSDB: keine Einschränkung (begrenzt durch mögliche Einschränkungen des
Dateisystems)
DBFS: 8 Exabytes (MS SQL Server 2000), 2 GB (Oracle)
DB: 2 GB
● Maximale Länge großer Eigenschaftswerte (vom Typ String): 2.147.583.647 Bytes (2 GB)
Persistentes Caching im Dateisystem
Für CM-Repositories, die in den Persistenzmodi DB oder DBFS betrieben werden, können Sie persistentes Caching aktivieren. Ein automatisch generierter Cache sichert den Content eines Dokuments lokal im Dateisystem des Portalservers unter Verwendung der Dokumenten-ID. Sie können diesen Cache verwenden, um Datenbank-Traffic, Datenbankzugriffe und Netzwerklast zu reduzieren.
In der Konfiguration eines CM-Repository-Managers steht hierzu der Parameter File System Content Cache Directory zur Verfügung. Den Umfang des Caches können Sie durch die Parameter Max. Size of File System Cache und Maximum Number of Cache Files einschränken. Hierbei beschränkt das Kriterium, das zuerst erreicht wird, den Umfang des Caches.
Wenn Sie für einen CM-Repository-Manager das persistente Caching konfiguriert haben, wird bei jedem Aufruf eines Dokuments zuerst im Cache nachgesehen, ob bereits ein Eintrag für das Dokument verfügbar ist. Sollte der Eintrag noch nicht im Cache verfügbar sein, wird der zugehörige Content aus der Datenbank geholt, in eine temporäre Datei geschrieben und GZIP komprimiert.
Wird bei einem Request das Dokument bereits im Cache gefunden, wird der zugehörige Eintrag entpackt und an den Client geschickt. Der Cache-Eintrag wird danach mit einem neuen Zeitstempel versehen und somit in der Cache-Statistik korrekt berücksichtigt.
Dokumente, die geändert wurden, werden mit einer neuen ID versehen und im Cache durch einen neuen Eintrag ersetzt.
Für die Einträge im Cache werden die ACLs der Originaldokumente aus der Datenbank übernommen.
Beim Start von Knowledge Management bzw. beim Reaktivieren eines CM-Repositorys wird der Inhalt des persistenten Caches komplett gelesen, intern sortiert und aufbereitet. Dieser Vorgang kann abhängig von der Anzahl der Einträge einige Zeit dauern.
Sie finden den persistenten Cache eines CM-Repositorys, der automatisch angelegt wird, im Cache-Monitor unter dem Namen <Repository-Präfix>_fsContentCache. Wenn Sie den Cache leeren, werden alle Einträge im Dateisystem gelöscht. In einer Cluster-Umgebung zeigt der Cache-Monitor die „lokale“ Auslastung des Caches auf dem spezifischen Portal-Server an. Wenn Sie den Cache leeren, werden nur die Einträge im Dateisystem dieses Portal-Servers gelöscht.
Parameter eines CM-Repository-Managers
Parameter |
Obligatorisch |
Beschreibung |
Name |
ja |
Name des Repository-Managers |
Description |
nein |
nähere Beschreibung des Repository-Managers |
Prefix |
ja |
URI-Präfix, für das der Manager registriert ist Unter dieser Angabe wird das Repository im Stammverzeichnis aufgelistet. Die URIs aller von diesem Repository-Manager verwalteten Ressourcen haben diesen Präfix gemeinsam. Das Präfix wird dazu verwendet, den Repository-Manager zu identifizieren, der für eine Ressource mit einem bestimmten URI zuständig ist. Beachten Sie, dass das Präfix mit einem Schrägstrich anzugeben ist, z.B. /documents. |
Repository ID in Database |
nein |
Identifikation des Repository in der Datenbank Die Angabe ist erforderlich, da in der Regel eine Datenbank für die Speicherung der Daten mehrerer Repositories verwendet wird. Der Wert muss eine alphanumerische Zeichenfolge sein, die unter den IDs aller Repositories, die die Datenbank verwenden, eindeutig ist. Wird die ID nicht angegeben, wird der Name des Repositorys als ID verwendet. Durch die Verwendung einer ID kann das Präfix geändert werden, ohne die Datenbank abgleichen zu müssen. Verwenden Sie für die Angabe der ID keine Sonderzeichen. |
Root Directory
|
nein |
Dieser Parameter wird nur dann benötigt, wenn der Parameter Persistence Mode auf FSDB oder auf DBFS gesetzt ist. Er gibt den Pfad zum Stammverzeichnis im Dateisystem an, dem der Repository-Manager zugeordnet ist. Dies kann ein Verzeichnis auf dem lokalen Server (z.B. /usr/myshare/somedir) oder auf einem freigegebenen Remote-Server sein. Um auf ein Dateisystem eines anderen UNIX-Rechners zugreifen zu können, muss das Verzeichnis zum Portalserver gemountet sein. Der Repository-Manager ist für dieses Verzeichnis und all seine Unterverzeichnisse zuständig. Beachten Sie, dass es nicht zulässig ist, dass mehrere Repository-Manager denselben Unterpfad in ihrem Parameter Root Directory verwenden.
Schränken Sie die Berechtigungen auf diese Pfadangabe im Dateisystem aus Sicherheitsgründen ein. |
Root Directory for Versions |
nein |
Pfad zum Stammverzeichnis im Dateisystem, das zum Speichern von Versionen verwendet wird Dieser Parameter wird nur dann benötigt, wenn der Parameter Persistence Mode auf FSDB gesetzt ist. Der Pfad darf nicht der unter Root Directory angegebene Pfad oder eines seiner Unterverzeichnisse sein. Sind für die aktuelle Version eines Dokuments Berechtigungen vergeben, werden diese auf frühere Versionen des Dokuments vererbt. |
Windows Landscape System |
nein |
nicht erforderlich für CM-Repository-Manager unter Unix |
Active |
nein |
Sie können den Repository-Manager durch Setzen des Parameters (de)aktivieren. |
Auto Check-In/Check-Out |
nein |
Wenn dieser Parameter aktiviert ist, können versionierte Dokumente geändert werden, ohne dass diese vorher ausgecheckt und zum Abschluss wieder eingecheckt werden müssen. Dabei wird von solchen Dokumenten beim Speichern automatisch eine neue Version angelegt. Wenn der Parameter deaktiviert ist, müssen Sie versionierte Dokumente erst auschecken, bevor Sie Änderungen vornehmen können. Nach der Änderung müssen Sie das geänderte Dokument wieder einchecken. |
Hide in Root Folder |
nein |
gibt an, ob das Repository im Stammverzeichnis aufgelistet wird Wenn Sie den Parameter aktivieren, wird das Repository nicht im Stammverzeichnis aufgelistet. |
Internal Links Default To Dynamic |
nein |
Wenn aktiviert, zeigen neu angelegte interne Verweise immer auf das jeweilige Objekt, auch wenn dieses im zugehörigen Repository verschoben wird. Wird das Objekt gelöscht, werden auch die zugehörigen Verweise gelöscht. |
Preserve Version Histories |
nein |
gibt an, ob Versionen beim Löschen des zugehörigen Dokuments gelöscht werden oder erhalten bleiben Aktiviert: Versionen bleiben erhalten Deaktiviert: Versionen werden gelöscht Versionen finden Sie im Verzeichnis /.~system~ des jeweiligen Repositorys. Dieses Verzeichnis können Sie nur mit dem Admin-Explorer aufrufen. Wenn Sie den Parameter aktivieren, sollten Sie die Berechtigungen für das Verzeichnis /.~system~ des jeweiligen Repositorys einschränken. Gewähren Sie nur Systemadministratoren Zugriff auf dieses Verzeichnis. Der Parameter kann nicht genutzt werden, wenn das CM-Repository im Persistenzmodus FSDB betrieben wird und der W2K-Sicherheitsmanager eingesetzt wird. |
Send Events |
nein |
gibt an, ob das Repository Ereignisse sendet, wenn Operationen wie „Löschen“, „Inhalt aktualisieren“ usw. durchgeführt werden Damit das Repository Ereignisse sendet, muss der Parameter aktiviert sein. Das ist z.B. für die Verwendung von Services wie dem Subskriptionsservice erforderlich. |
Persistence Mode |
ja |
Auswahl des Persistenzmodus des CM-Repository-Managers Er legt fest, wo Namensraum, Inhalte und Metadaten gespeichert werden. Wenn Sie den Datenbankmodus (DB) verwenden, dürfen die Parameter Root Directory und Root Directory for Versions nicht angegeben werden, da sie nur für Repositories gelten, die das Dateisystem verwenden. Siehe auch nachfolgende Tabelle.
Der Persistenzmodus eines bestehenden Repositorys darf nie geändert werden. Bei kundeneigenen Repository-Managern ist ein nachträglicher Wechsel vom Modus DB in den Modus DBFS möglich. |
Property Search Manager |
nein |
Auswahl des Managers für die Suche nach Eigenschaften Wählen Sie CM Property Search Manager. |
Compress content greater than |
nein |
Inhalte, die größer sind als der angegebene Wert, werden komprimiert abgespeichert. |
Repository services |
nein |
Angabe der Repository-Services, die Sie für ein Repository verwenden möchten |
ACL Manager Cache |
nein |
Angabe eines Memory-Caches für Ressourcen-ACLs: ca_rsrc_acl Dieser Parameter wird benötigt, wenn ein ACL-Sicherheitsmanager im Parameter Security Manager angegeben ist. Der Cache ist in der Standardauslieferung bereits angelegt (siehe Caches). |
Memory Cache |
nein |
Angabe eines Memory-Caches, der für diesen CM-Repository-Manager genutzt wird Im Cache werden u. a. Namen von Ressourcen, Eigenschaften und Sperren abgelegt. Es wird jedoch kein Content im Cache abgelegt. |
Memory Cache for small Content (<32KB) |
nein |
Angabe eines Memory-Caches, der für Inhalte genutzt wird, die kleiner als 32 KB sind |
Security Manager |
nein |
Auswahl eines Sicherheitsmanagers, der den Zugriff auf die Repository-Inhalte steuert Wenn Sie möchten, dass das CM beim Zugriff auf Ressourcen eine Berechtigungsprüfung durchführt, müssen Sie einen Sicherheitsmanager angeben. Im Allgemeinen sollte der AclSecurityManager für CM-Repositories verwendet werden. Nur das CM-Repository /collaboration sollte den CollaborationSecurityManager verwenden. Wenn Sie ein CM-Repository im Persistenzmodus FSDB unter WINDOWS→ betreiben, können Sie den W2K-Sicherheitsmanager benutzen. |
File System Content Cache Directory |
nein |
gibt einen Ordner im lokalen Dateisystem des Portal-Servers an, in dem Cache-Einträge persistent abgelegt werden Beispiel: /tmp/cmcontentcache Siehe dazu den oben aufgeführten Abschnitt Persistentes Caching im Dateisystem. Stellen Sie in einer Cluster-Umgebung sicher, dass auf jedem Rechner des Clusters ein Ordner mit diesem Namen angelegt ist. Der Ordnername bzw. der Pfad muss auf jedem Rechner gleich sein. Die Nutzung des gleichen Ordners für unterschiedliche CM-Repositories wird nicht empfohlen. Geben Sie ebenfalls keinen Ordner eines Remote-Servers an, da es ansonsten zu Einbußen bei der Performance kommen kann.
Schränken Sie die Berechtigungen auf diesen Ordner im Dateisystem aus Sicherheitsgründen ein. |
Max. Size of File System Cache |
nein |
Größe in Megabyte, die der persistente Cache im Dateisystem maximal annehmen kann Die Größenbeschränkung bezieht sich auf die komprimierten Cache-Einträge. Die Angabe -1 bedeutet keine Beschränkung. Diese Angabe wird jedoch nicht empfohlen. |
Maximum Number of Cache Files |
nein |
maximale Anzahl der Einträge, die der persistente Cache im Dateisystem aufnehmen kann Die Angabe -1 bedeutet keine Beschränkung. Diese Angabe wird jedoch nicht empfohlen. Die Einträge werden nach dem letzten Zugriff sortiert. Alte Einträge, die nur selten abgerufen werden, werden aus dem Cache entfernt und durch neue Einträge ersetzt. |
Disable Automatic FSDB Synchronization |
nein |
steuert die Synchronisation von CM-Repositories, die im Persistenzmodus FSDB betrieben werden wenn aktiviert, wird für dieses Repository die automatische Dateisystem-Synchronisation nicht durchgeführt Änderungen, die direkt im Dateisystem durchgeführt werden (Änderungen an Eigenschaften, Einfügen, Umbenennen/Verschieben, Löschen von Ordnern oder Dokumenten), werden nicht automatisch in der Datenbank nachgezogen. Diese Änderungen sind im Portal nicht sichtbar – Zugriffe auf nicht mehr existierende Objekte führen ggf. zu einem Fehler. Damit diese Änderungen im Portal sichtbar werden, kann die Dateisystem-Synchronisation bei Bedarf manuell mittels eines Reports gestartet werden (siehe CM-Repository: FS-DB-Datenbank-Synchronisierung). Ist der Parameter aktiviert, so kann es beim Lesen eines Dokuments zu korrupten Daten kommen, wenn während der Lese-Operation gleichzeitig Schreib-Operationen auf dem Dokument stattfinden. |
Enable Disk Optimized Mode |
nein |
steuert das Umschalten zwischen den beiden Versionierungsmodi Standardmodus und speicheroptimierter Modus. Um Rückwärtskompatibilität sicherzustellen, wird der Standardwert des Parameters Enable Disk Optimized Mode auf Standardversionierungsmodus gesetzt. Sie können den Versioned Content Converter Report verwenden, um die versionierten Ressourcen vom Standardmodus in den speicheroptimierten Modus und umgekehrt umzuwandeln. Weitere Informationen: Konvertierungsreport für versionierten Content |
Enable FSDB Content Tracking |
nein |
regelt das Tracking von Content für Repositories, die im Persistenzmodus FSDB betrieben werden Wenn dieser Parameter aktiv ist, verwendet der CM-Repository-Manager die Datenbank zum Koordinieren des Lese- und Schreibzugriffs im Dateisystem, indem beide Zugriffsarten in der Datenbank dokumentiert werden. Dies stellt die Konsistenz des zurückgegebenen Contents sicher, wenn z.B. mehrere Threads lesend auf Daten zugreifen, die gleichzeitig von anderen Threads geändert werden.
Die Datenbanksynchronisation des Content-Zugriffs kann eine negative Auswirkung auf die Performance haben. Jeder Content-Request mit Lese- oder Schreibzugriff an eine Ressource wartet auf das Setzen einer Schreibsperre im Sperrenverzeichnis der Datenbank. Deshalb kann die Wartezeit für die Vergabe der Schreibsperre in der Datenbank möglicherweise länger dauern, und die wartenden Threads können einen erheblichen Anteil der im Thread-Pool verfügbaren Threads beanspruchen. Wenn der Parameter nicht aktiv ist, wird kein Tracking des Content durchgeführt und der Content-Zugriff nicht synchronisiert. Hierdurch kann eine bessere Performance erzielt werden, da die Wartezeit für die Schreibsperren reduziert wird und weniger Datenzugriffe und Datenbanksperren benötigt werden.
Die Deaktivierung des Parameters Enable FSDB Content Tracking kann jedoch zu Inkonsistenzen im zurückgegebenen Content führen. Da der Content-Zugriff nicht synchronisiert wird, können sich mehrere Threads gegenseitig stören und der zurückgegebene Content kann somit Fehler enthalten.
|
Read-only Content Expiry Delay |
nein |
gibt an, wie lange Clients den Inhalt von schreibgeschützten Ressourcen zwischenspeichern sollen Innerhalb dieses Zeitraums werden schreibgeschützte Ressourcen vom Client nicht erneut vom Server geladen. Die Angabe erfolgt in Sekunden. Die Funktion kann nur genutzt werden, wenn der Persistenzmodus DB oder DBFS eingestellt ist. Die Cache-Optionen bzw. die Einstellungen der temporären Internet-Dateien des genutzten Browsers sollten dabei auf „automatisch“ eingestellt sein. |
Abhängig vom gewählten Persistenzmodus müssen sie bestimmte Parameter angeben:
Persistenzmodi und Root-Parameter
Persistenzmodus |
erforderliche Parameter |
nicht erforderliche Parameter |
DB |
|
Root
Directory |
DBFS |
Root Directory |
Root Directory for Versions |
FSDB |
Root
Directory Root Directory for Versions und Root Directory dürfen keine Unterordner voneinander und nicht identisch sein. |
|
Aktivitäten
Mehrere CM-Repositories sind in der KM-Standardkonfiguration vorkonfiguriert (siehe Interne Repositories). Sie werden als Daten- und System-Repositories verwendet.
Um einen neuen CM-Repository-Manager für eigene Daten anzulegen und zu konfigurieren oder die Konfiguration eines vorhandenen CM-Repository-Manager zu ändern, wählen Sie im Portal Systemadministration → Systemkonfiguration → Knowledge Management → Content Management → Repository Managers → CM Repository.
Konfiguration der benötigten Memory-Caches
In der CM-Repository-Manager-Definition können Sie drei Caches angeben:
● ACL Manager Cache (ca_rsrc_acl)
● Memory Cache (ca_cm)
● Memory Cache for small Content (ca_cm_content)
Die Caches sind bereits vorkonfiguriert. Sie können deren Konfiguration jedoch nachträglich an Ihre Erfordernisse anpassen.
Weitere Informationen zur Konfiguration von Caches finden Sie unter Komponenten und zugehörige Caches.
Beispiel
Konfiguration eines CM-Repository-Managers
Name =
documents
Description =
Standard repository for content
Prefix =
/documents
Repository-ID in DB = documents
Send
Events =
true
Persistence Mode = DB
Property Search Manager = CMPropertySearchManager
Repository Services = properties, feedback,
comment, rating,
accessstatistic,
personalnote, discussion,
tbp,
statemngt, subscription, svc_acl
ACL Manager Cache = ca_rsrc_acl
Memory
Cache =
ca_cm
Memory Cache for small Content = ca_cm_content
Security Manager =
AclSecurityManager
File System Content Cache
Directory = /tmp/cmdocumentscontentcache
Max. Size of File System
Cache = 100
Maximum Number of Cache
Files = 10000
Das obige Beispiel zeigt Parametereinstellungen für den Repository-Manager documents, der in der KM-Standardkonfiguration enthalten ist. Der Manager speichert sowohl Inhalte als auch Metadaten in der Datenbank. Das persistente Caching ist eingerichtet.
Weitere Informationen
CM-Repository-Dateisystemprüfung
CM-Repository-Datenbankprüfung
Unkonfigurierte CM-Repositories
CM-Repository-FS-DB-Datenbank-Synchronisierung