Web-Repository-Manager (SAP-Bibliothek

Web-Repository-Manager

Verwendung

Mit einem Web-Repository (-Manager) ermöglichen Sie den Lesezugriff auf Dokumente, die auf Remote-Web-Servern gespeichert sind. Die Dokumente werden als CM-Ressourcen zur Verfügung gestellt und können so im Content Management indiziert und durchsucht werden.

Voraussetzungen

Die Remote-Web-Server, auf deren Inhalte Sie über einen Web-Repository-Manager zugreifen möchten, sind in der CM-Systemlandschaft in HTTP-Systemen definiert.

Funktionsumfang

In der Regel erfolgt der Zugriff auf ein Web-Repository durch den Crawler-Service, und seine Inhalte werden vom Indexverwaltungs-Service verarbeitet. Wenn die Dokumente indiziert sind, können Benutzer über eine Suchfunktionion oder das Durchsuchen von Taxonomien auf sie zugreifen.

Mit einem Web-Repository-Manager können Sie Inhalte und Eigenschaften von HTML-Dokumenten und anderen Dokumenten abrufen, die von einem Web-Server bereitgestellt werden. Sie können die Inhalte und Eigenschaften dieser Dokumente jedoch nicht ändern. Der Web-Repository-Manager verwendet HTTP/1.1 für den Zugriff auf andere Web-Server. Dieses Protokoll lässt das Ändern von Dokumenten nicht zu. Dagegen greift der WebDAV-Repository-Manager über WebDAV auf andere Web-Server zu, eine Erweiterung des HTTP-Protokolls, die das Ändern von Inhalten und Metadaten zulässt.

Da die Dokument-Collections, auf die über HTTP zugegriffen wird, eine netzartige, keine hierarchische Struktur haben, werden sie nur auf einfache CM-Ressourcen abgebildet, nicht auf CM-Collections. Wenn eine Ressource ein HTML-Dokument mit Hyperlinks darstellt, werden diese Links in einer Eigenschaft der Ressource gespeichert.

Dynamische und statische Web-Repositorys

Web-Repositorys können so konfiguriert werden, dass sie nur die Inhalte einer oder mehrerer vordefinierter Websites enthalten, oder so, dass ihr Namensraum beim Zugriff auf andere Server dynamisch erweitert wird. Es gibt diese Grundkonfigurationstypen für ein Web-Repository: dynamisch und statisch.

Dynamische Repositorys

Das leistungsfähigste Web-Repository ist das dynamische Repository. Es ermöglicht den Zugriff auf beliebige HTML-Dokumente im Internet oder Intranet, vorausgesetzt, die Web-Server sind von dem Server, auf dem das Web-Repository läuft, erreichbar.

Nehmen wir an, ein solches Web-Repository ist mit dem Präfix /web konfiguriert. Man könnte dann über den URI /web/www.example.com/ auf die Homepage http://www.example.com/ zugreifen. Der Zugriff auf einen Web-Server, der unter http://company:81/ erreichbar ist, könnte über /web/company:81/ erfolgen.

Die unter /web erreichbare Ressource ist eine Collection. Sie wird als Stamm-Collection des Repository bezeichnet. Untergeordnet sind alle Ressourcen, auf die bis zu diesem Zeitpunkt zugegriffen wurde. In diesem Beispiel würde /web die Ressourcen /web/www.example.com und /web/company:81 als untergeordnete Ressourcen enthalten.

Bei jedem erfolgreichen erstmaligen Zugriff auf einen neuen Server wird eine andere untergeordnete Ressource zur Stamm-Collection hinzugefügt. So wächst die Liste der untergeordneten Ressourcen dynamisch an.

Wenn Sie ein dynamisches Web-Repository einrichten, können Sie mit einer leeren Stamm-Collection anfangen oder eine Menge vordefinierter Websites als Stamm-Collection für den Einstieg angeben. Eine solche Einstiegs-Collection geben Sie genauso an wie die Stamm-Collection für ein statisches Repository (s. u.).

Empfehlung

Wir empfehlen nur ein einzelnes dynamisches Web-Repository einzurichten. Falls Sie mehrere dynamische Web-Repositorys nutzen, kann es sein, dass Crawler in mehreren Web-Repositorys dieselben Dokumente finden und dadurch den Ort des Dokuments zufällig auswählen. Dies kann die Indizierung und Klassifikation von Dokumenten erschweren.

Statische Repositorys

Statische Web-Repositorys sind auf die Inhalte einer oder mehrerer vordefinierter Websites beschränkt. Sie stellen keine Verbindung zu Servern und Websites her, die nicht in ihren Konfigurationseinstellungen angegeben sind.

Beispiel: Ein statisches Web-Repository mit Präfix /web2 wird für den Zugriff auf http://example.com/ und http://www.sap.com/ konfiguriert. Das Repository /web2 hätte dann ausschließlich /web2/example.com und /web2/www.sap.com als untergeordnete Ressourcen. Ein Versuch eines Service oder Benutzers, auf /web2/www.example.com zuzugreifen, würde scheitern.

Da die untergeordneten Ressourcen der Stamm-Collection statisch sind, können Sie sie anders behandeln als bei der dynamischen Variante:

● Sie können den untergeordneten Ressourcen der Stamm-Collection beliebige Namen zuordnen (über die Eigenschaft „displayname“. Sie könnten z.B. den Anzeigenamen Example! für example.com verwenden.

● Sie können sie direkt auf ein bestimmtes Dokument auf einem Server zeigen lassen. Anstelle eines Link auf http://www.sap.com/ könnten Sie z.B. einen direkten Link auf die FAQ unter http://www.sap.com/contactsap herstellen. Dann könnte /web2/SAP-CONTACT direkt auf dieses HTML-Dokument zeigen.

Sie geben die Website(s) für den Zugriff durch ein statisches Web-Repository an, indem Sie sie aus der Liste Systems in der Konfiguration des Web-Repository-Managers auswählen. Sie müssen diese Websites zuvor definiert haben.

Dazu wählen Sie Content Management → Repository Managers → Web Sites.

Die folgende Tabelle zeigt die Parametereinstellungen für die verschiedenen Web-Repository-Typen, die zuvor beschrieben wurden.

Parameterkombinationen für verschiedene Web-Repository-Typen

	Web Sites	Dynamic
Dynamisch ohne Einstiegs-Stamm-Collection	leer	markiert
Dynamisch mit Einstiegs-Stamm-Collection	eine oder mehrere Web Sites markiert	markiert
Statisch	eine oder mehrere Web Sites markiert	entmarkiert

Zuordnung URI-URL

Die Ressourcen in der Stamm-Collection eines Web-Repository (oder die übergeordnete Ressource eines einfachen Web-Repository) werden URLs auf anderen Servern zugeordnet. Sie definieren diese Zuordnung, indem Sie System-IDs und -pfade auf dem Remote-Server angeben, entweder direkt in der Konfiguration des Web-Repository-Managers oder in der Konfiguration einer Website, auf die der Web-Repository-Manager zugreift. Sie müssen die System-IDs zuvor auch im Systemlandschafts-Service registrieren.

Es wäre natürlich sehr zeitaufwendig, für jedes HTML-Dokument, auf das man zugreifen will, eine Zuordnung zu definieren. Ein Web-Repository ordnet CM-Ressourcen automatisch zu Dokumenten auf dem Remote-Server zu. Es erstellt Zuordnungen bezogen auf die Stammressourcen. Diese Zuordnung wird auch bei Erzeugung der Ressourceneigenschaft embedded-links verwendet (siehe Abschnitt Ressourceneigenschaften).

Wenn ein Repository mit dem Präfix /cnn z.B. so konfiguriert ist, dass es auf http://www.cnn.com/ zeigt, können Sie jedes Dokument auf der CNN-Website erreichen, indem Sie einfach den Pfad anhängen. Der Zugriff auf den Wetterbereich (http://www.cnn.com/WEATHER/) könnte unter /cnn/WEATHER/erfolgen, auf die Weltnachrichten unter /cnn/WORLD/ usw. Das funktioniert auf jeder Ebene, d.h., http://www.cnn.com/2002/TECH/industry/01/29/microsoft.reut/index.html wäre verfügbar unter /cnn/2002/TECH/industry/01/29/microsoft.reut/index.html.

Beispiel für URI-Zuordnung

URI im Knowledge Management	HTTP-URI
/web	http://host/a
/web/index.html	http://host/a/index.html
/web/b/c/	http://host/a/b/c/
/web/search?key=sap	http://host/a/search?key=sap

Um HTTP-URIs, die Parametertrennzeichen enthalten (wie z.B. der letzte Eintrag in der obigen Tabelle), zu Ressourcennamen zuzuordnen, die gültige Dateinamen sind, muss die Eigenschaft Filenames in der Konfiguration des Web-Repository-Managers den Wert true haben (s.u.).

Natürlich gibt es Hyperlinks, die nicht zugeordnet werden können. Wenn beispielsweise index.html einen Link auf http://hostenthalten würde, könnte dieser Link nicht dem Namensraum des Web-Repository zugeordnet werden. Wie solche Links behandelt werden, hängt davon ab, ob der jeweilige HTTP-URI einem anderen Web-Repository zugeordnet ist und welchen Wert die Eigenschaft External Server URI Handling in den Repository-Einstellungen hat (s.u.).

Das veranschaulicht, warum das Spektrum eines Web-Repository eingeschränkt ist, wenn das Repository so konfiguriert ist, dass es auf ein bestimmtes Dokument zeigt (wenn z.B. /web2/SAP-COANTACT auf http://www.sap.com/contact/ zeigt). In diesem Beispiel sind die Dokumente http:// www.sap.com/ und http://www.sap.com/something/else über dieses Web-Repository nicht zugänglich. Sie können keinem Namen im Namensraum des Web-Repository /web2 zugeordnet werden.

Ressourceneigenschaften

Ressourcen, die vom Web-Repository-Manager erzeugt werden, haben Standardeigenschaften wie z.B. contenttype, contentlength, displayname und description.

Die folgenden Daten werden aus Dokumenten auf dem Webserver extrahiert und als Eigenschaften der CM-Ressourcen gespeichert, die diese Dokumente darstellen. Während displayname und description Standardeigenschaften von CM-Ressourcen in allen Repositorys sind, sind die zwei anderen Eigenschaften spezifische Eigenschaften von Web-Repository-Ressourcen.

Eigenschaftsname	Daten
displayname	Inhalt des HTML-Tag <title>
description	Inhalt des HTML-META-Tag „description“
embedded-keywords	Liste der im HTML-META-Tag „keywords“ angegebenen Schlagwörter”
embedded-links	Liste von Hyperlinks, neu erstellt, damit sie bezogen auf die Ressource im Namensraum des Web-Repository gültig sind

Die Eigenschaft embedded-keywords ist nützlich bei der Indizierung eines HTML-Dokuments mit Schlagwörtern, die vom Autor dieses Dokuments angegeben wurden.

Die Eigenschaft embedded-links kann zum Traversieren eines Web-Servers verwendet werden. Die Eigenschaft embedded-links von /web/www.cnn.com enthält Links auf alle Ressourcen, auf die in der HTML-Seite unter http://www.cnn.com verwiesen wird. In diesem Beispiel sind das die Ressourcen /web/www.cnn.com/WEATHER/ und /web/www.cnn.com/WORLD/. Die Eigenschaft embedded-links dieser Ressourcen enthält alle Ressourcen, auf die diese HTML-Seiten verweisen, usw.

Beispiel

Der URI http://host/site wird der Ressource /web zugeordnet. Ein Client fordert die Ressource /web/index.html an. Der Web-Repository-Manager fordert das Dokument http://host/site/index.html vom Remote-Server an.

Angenommen, index.html sieht so aus:

<html>
<head>
<title>Tension Band Wiring</title>
<META NAME="keywords" CONTENT="fracture, fixation technique"> </head>
<body>
<a href="this.html">link one</a>
<a href="./there/another.html">link two</a>
</body>
</html>

In diesem Fall hat die Ressource /web/index.html folgende Eigenschaften:

displayname = Tension Band Wiring
embedded-keywords = fracture, fixation technique
embedded-links = “/web/this.html”, “/web/there/another.html”

Die Eigenschaft description fehlt, da index.html keinen META-Tag „description“ hat.

Ressourceninhalt

Bei allen MIME-Typen außer „text/html“ ist der Ressourceninhalt identisch mit dem Inhalt der HTTP-Ressource auf dem Remote-Server. HTML Seiten, die vom Remote-Server geholt werden, erhalten ein HTML-BASE-Attribut, welches alle Links der Seite auf den Ursprungs-Server zeigen lässt. Beim Aufruf der Seite verhält sich der Browser so, als wenn direkt auf den Remote-Server zugegriffen worden wäre.

Achtung

Links, die in Scripting-Sprachen wie JavaScript eingebettet sind, werden nicht gefunden und funktionieren deshalb nicht richtig.

Authentifizierung

Das Web-Repository kann Benutzer beim Remote-Server authentifizieren. Folgende Authentifizierungsarten werden unterstützt:

● Basic-Authentifizierung

● Digest-Authentifizierung

● NTLM-Authentifizierung

Für die Angabe der Authentifizierungsinformationen (Credentials) stehen zwei Möglichkeiten zur Verfügung: Sie können die Authentifizierungsinformationen in einem HTTP-System mit den Parametern User und Passwordstatisch angeben. Wenn Sie diese Parameter nicht angeben, werden die Credentials dynamisch und personalisiert aus der Benutzerzuordnung des Portals gelesen. Weitere Information finden Sie unter Berechtigungen bei Zugriff auf Web-Repositorys.

Berücksichtigung von ROBOTS-Angaben

Beim Crawlen von Web-Repositorys wird die Datei robots.txt der Webseite ausgewertet.

In HTML-Dokumenten werden folgende ROBOTS-Angaben berücksichtigt:

● <METANAME="ROBOTS" CONTENT="NOFOLLOW">

● <METANAME="ROBOTS" CONTENT="NOINDEX">

● <METANAME="ROBOTS" CONTENT="NOINDEX,NOFOLLOW">

Weitere Information finden Sie unter Crawler und Crawler-Parameter.

Formular-basierte Anmeldung

Der Web-Repository-Manager unterstützt den Zugriff auf Web-Server, die Authentifizierung über HTML-Seiten mit einem Formular-basiertem Anmelde-Dialog nutzen.

Um diese Funktion nutzen zu können, müssen Sie in der Konfiguration von einer Website die Parameter für die Formular-basierte Anmeldung angeben:

● Login Form ID

● Login URI

● Login User Agent

● Login Timeout

Die Beschreibung der Parameter finden Sie unter Websites.

Zur Anmeldung am Remote-Web-Server werden die Benutzer-Informationen standardmäßig ermittelt: Entweder wird der Benutzer, der im HTTP-System angegeben ist, verwendet oder die Benutzerzuordnung im Portal wird abgefragt. Der Web-Repository-Manager holt sich vom Web-Server die HTML-Seite, die den Anmelde-Dialog enthält (angegeben im Paramter Login URI). Der Anmelde-Dialog, normalerweise ein HTML-Formular, wird mit den Benutzerdaten versehen und zum Remote-Web-Server geschickt, der darauf ein HTTP-Cookie zurücksendet. Der HTTP-Cookie identifiziert die Benutzer-Session und wird als Authentifizierung für weitere Zugriffe genutzt.

Einschränkung: Remote-Web-Server, die an Stelle von Cookies URL-Rewriting zur Identifizierung von Sessions benutzen, werden nicht unterstützt. (Bei URL-Rewriting wird die Session-ID in der URL gespeichert.) Da solche URLs nur eine kurze Zeit existieren, sind sie für die Indizierung mittels TREX im Allgemeinen ungeeignet.

HTTP- und HTTPS-Unterstützung

Der Zugriff auf Remote-Web-Server, deren URLs in HTTP-Systemen eingetragen sein müssen, kann über HTTP oder HTTPS erfolgen.

Timeouts

Cache-Timeout

Der Parameter Cache Timeout legt fest, wie lange der Cache-Inhalt als aktuell betrachtet wird. Mit einem Timeout-Wert von 3000 würden die Eigenschaften einer Ressource z.B. für drei Sekunden nach ihrer Ermittlung nicht aktualisiert. Je nach Typ des Inhalts einer Website würde der Wert normalerweise auf mehrere Minuten eingestellt, wenn nicht sogar einen ganzen Tag. Der optimale Wert hängt von der Aktualisierungshäufigkeit des Remote-Standortes ab.

Um die optimale Einstellung für den Timeout-Wert zu vereinfachen, berücksichtigt das Web-Repository auch den Expires-Header von einem Remote-Server. Wenn der Server diesen Header sendet, fügt das Repository den Timeout-Wert zum Ablaufdatum hinzu. Wenn Sie also den Timeout-Wert auf eine Stunde setzen, wird diese Stunde zu allen Ablaufinformationen von Ressourcen hinzugefügt. Der Remote-Server weiß, wie Ablauftermine auf der Basis der individuellen Aktualisierungshäufigkeit einer Ressource zu setzen sind.

Hinweis

Wenn Web-Repositorys periodisch aktualisiert werden, sollte das Indizierungs-Intervall so eingestellt werden, dass die Indizierung kurz nach dem Cache-Timeout stattfindet (siehe:Zuordnen von Datenquellen). Damit wird sichergestellt, dass jeweils die aktuellste Version im Cache vorhanden ist.

HTTP-Timeout

Der HTTP-Timeout definiert die Leerlaufzeit für eine Remote-Server-Operation, d.h., das Intervall, nach dessen Ablauf die Operation abgebrochen wird. Das stellt einen sinnvollen Schutz gegen falsche Verbindungen oder schlecht konfigurierte Web-Server dar.

Die Leerlaufzeit ist die Zeit zwischen erfolgreichen Lese-/Schreiboperationen. Wenn der Remote-Server z.B. einen Request nicht im vorgegebenen Zeitintervall beantwortet, wird der Request als gescheitert betrachtet, und ein Fehler wird gemeldet.

Beachten Sie, dass zu diesem Zeitpunkt nicht die komplette Antwort gelesen wird. Wenn der WebDAV-Repository-Manager ein großes Dokument liest, wird die Leerlaufzeit als die Zeit zwischen erfolgreichen Leseoperationen von Teildaten gezählt, nicht als die Zeit, die für das Abrufen des vollständigen Dokuments benötigt wird. (Erläuterung: HTTP Timeout legt den Wert SOTIMEOUT des Verbindungs-Socket zum Remote-Server fest).

Parameter

In der Konfiguration eines Web-Repository-Managers geben Sie folgende Parameter an:

Parameter eines Web-Repository-Managers

Parameter	Obligat.	Beschreibung
Name	ja	Name des Repository-Managers
Description	nein	Bezeichnung des Repository-Managers
Prefix	ja	URI-Präfix, für das der Manager registriert ist Unter dieser Angabe wird das Repository im Stammverzeichnis aufgelistet. Beachten Sie, dass das Präfix mit einem Schrägstrich anzugeben ist, z. B. /WEB.
Active	nein	Sie können den Repository-Manager durch Setzen des Parameters (de)aktivieren.
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.
Repository Services	nein	Identifikationen der Repository-Services, die Sie für ein Repository verwenden möchten
Security Manager	nein	Auswahl des 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. Falls der Webserver Authentifizierung unterstützt, können Sie den WebSecurityManager verwenden. Zusätzlich muss im Portal die Benutzerzuordnung durchgeführt werden. Weitere Information finden Sie unter Berechtigungen bei Zugriff auf Web-Repositorys.
ACL Manager Cache	nein	Identifikation des Cache für Ressourcen-ACLs Dieser Parameter wird benötigt, wenn ein ACL-Sicherheitsmanager im Parameter Security Manager Class angegeben ist. Der Cache ca_rsrc_acl ist in der KM-Standardkonfiguration, die mit dem CM geliefert wird, voreingestellt (siehe Caches).
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.
Case-Sensitive URI Handling	nein	legt fest, ob der Repository-Manager Klein- und Großschreibung in Ressourcen-URIs beachtet Wenn aktiviert, wird z. B. zwischen INDEX.HTM und index.htm unterschieden.
Dynamic	nein	gibt an, ob das Repository neue Remote-HTTP-Server dynamisch in seinem Namensraum hinzufügen kann Der Standardwert ist false.
Filenames	nein	legt fest, ob das Repository Ressourcennamen erzeugt, die gültige Dateinamen sind Links innerhalb einer HTML-Seite verwenden solche Namen ebenfalls. Der Standardwert ist false.
Persistent Caching	nein	wenn aktiviert, wird die Datenbank zum Caching von Objekten verwendet Der Datenbank-Cache wird genutzt, wenn der Memory-Cache die festgelegte Größe erreicht bzw. die maximale Anzahl von Einträgen erreicht ist. Die maximal möglichen Einträge des Datenbank-Caches sind in der Konfiguration des Web-Garbage-Collector-Scheduler-Tasks festgelegt. Der Cache wird von allen Web-Repository-Managern genutzt, bei denen dieser Parameter aktiviert ist.
Use System Default Proxy Settings	nein	legt fest, ob die Einstellungen des Standard-Proxy-Systems verwendet werden
External Server URI Handling	ja	legt fest, wie URIs (Links) innerhalb von HTML-Seiten behandelt werden, die auf externe Server zeigen (außerhalb des Bereichs dieses Web-Repository) Drei verschiedene Werte sind möglich: none (URIs werden unverändert übergeben) rewrite (URIs werden neu geschrieben, um auf URIs auf diesem Server zu zeigen, sofern möglich) report (wie rewrite, aber die neuen geschriebenen URIs werden auch an die Eigenschaft „embedded-URIs“ der Ressource übergeben). Der Standardwert ist none.
Cache Stale Timeout	nein	bestimmt, falls definiert, den Zeitraum in Millisekunden nach dessen Ablauf "veraltete" Ressourcen aus der Datenbank gelöscht werden Die Lebenszeit einer gecachten Ressource wird durch den Parameter Cache Timeout bestimmt. Nach Ablauf des Timeout gilt sie im Cache als stale (abgestanden). Eine Ressource, die älter als die Angabe im Parameter Cache Stale Timeout ist, wird aus dem Cache entfernt.
Cache Timeout	nein	Timeout in Millisekunden für Ressourcen im Cache Der Timeout-Wert legt fest, wie lange Ressourcen im Cache (Inhalt und Eigenschaften) nicht aktualisiert werden. Der optimale Wert hängt von der Aktualisierungshäufigkeit des Remote-Standortes ab. Der Timeout-Wert sollte jedoch kürzer sein als die Aktualisierungshäufigkeit des Remote-Standortes, damit der Cache mit den neuen Inhalten aktualisiert wird. Bei Ressourcen, die mit einem „Expires“-Header an den Remote-HTTP-Server gesendet werden, wird der Timeout-Wert zum Ablaufdatum hinzugefügt.
HTTP Timeout	nein	Timeout in Millisekunden, nachdem Operationen auf dem Server abgebrochen werden Der Standardwert ist 60000 ms (d.h. eine Minute).
Web Sites	nein	Liste der Websites, die Sie in die Stamm-Collection des Repository-Managers aufnehmen möchten Die hier angebotenen Optionen können Sie über Content Management → Repository Managers → Web Sites im iView Konfiguration einstellen. Diesen Parameter geben Sie nur dann an, wenn das Repository mehrere Websites abbilden soll. In diesem Fall dürfen Sie den Parameter System ID nicht angeben.
HTML Property Extractors	nein	Identifikation eines Web-Eigenschafts-Extraktors, der bei diesem Repository-Manager zum Extrahieren zusätzlicher Ressourceneigenschaften zu verwenden ist (siehe Web-Eigenschafts-Extraktoren) Wenn Sie nachträglich Änderungen an dem genutzten Web-Eigenschafts-Extraktor vornehmen, müssen Sie den zugehörigen Cache manuell leeren (siehe unten).
Memory Cache	ja	Identifikation des Memory-Cache, der vom Web-Repository für das Caching von generierten Ressourcen verwendet werden soll Die Eigenschaft Maximum Entry Size dieses Cache legt fest, ob der Inhalt einer Ressource im Cache gespeichert wird. Nur Ressourceninhalte, die kleiner als die Maximum Entry Size sind, werden im Cache gespeichert. Dagegen werden Ressourceneigenschaften immer gespeichert.

Hinweis

Der Web-Repository-Manager legt automatisch einen virtuellen, persistenten Cache mit dem Namen "WebRepositoryPersistence-/x", wobei "/x" der Präfix des Repositorys ist. Dieser Cache kann nicht konfiguriert werden. Wenn Sie nachträgliche Änderungen an dem genutzten HTML-Eigenschaften-Extraktor vornehmen, müssen Sie den Cache über den Cache-Monitor leeren.

Aktivitäten

Um einen Web-Repository-Manager zu konfigurieren, wählen Sie Content Management → Repository Managers → Web Repository. Bei der Konfiguration ordnen Sie dem Web-Repository-Manager unter anderem Websites zu.

Wenn Sie ein Upgrade oder eine Migration durchgeführt haben, können Sie die Konfiguration Ihrer bisherigen Web-Repository-Manager weiterhin unter Content Management → Repository Managers → [Legacy Web Repository] aufrufen.

Beispiel

Es folgt eine Beispielkonfiguration eines Web-Repository, das mit dem URI-Präfix /web registriert ist. Das Repository kennt zwei Websites namens spiegel und faz. Diese Websites müssen konfiguriert sein. Die Remote-Server müssen in der Systemlandschaft in HTTP-Systemen registriert sein. Das Repository ist statisch. Es kann nur auf die angegebenen Websites zugegriffen werden. Es verwendet einen Memory-Cache mit der ID web_cache. Die angeforderten Ressourcen werden 3600000 ms (eine Stunde) lang im Cache gehalten, bevor sie bei Folge-Requests aktualisiert werden.

Konfiguration des Web-Repository-Managers web

Name          = web
Prefix        = /web
Dynamic       = false
Web Sites     = spiegel, faz
Cache         = web_cache
Cache Timeout = 3600000

Konfiguration der Website spiegel

Name          = spiegel
Display Name = Der Spiegel
System ID     = WEB_SPIEGEL
System Path   = politik

Konfiguration der Website faz

Name          = faz
Display Name = Frankfurter Allgemeine Zeitung
System ID     = WEB_FAZ
System Path   = news

Angabe des Remote-Servers http://www.spiegel.de in einem HTTP-System

System ID = WEB_SPIEGEL

Server-URL = http://www.spiegel.de

Angabe des Remote-Servers http://www.faz.net in einem HTTP-System

System ID = WEB_FAZ

Server-URL = http://www.faz.net