Content-Modelle 
Die einzelnen SAP-Anwendungen erstellen Meta-Datenmodelle für die verschiedenen Typen von Dokumenten, die sie benutzen und die in Beziehungen zueinander stehen. Diese Modelle werden als Content-Modelle bezeichnet.
In einem Content-Modell werden auf einer abstrakten Ebene die Charakteristika der einzelnen Content-Entitäten im Knowledge Provider beschrieben. Die verschiedenen Arten von Content werden auf die Dokumente im Content-Modell abgebildet und verwaltet. Mögliche Arten von Content sind Endbenutzer-Dokumentation, eingescannte Dokumente etc.
KPro-Content-Modell
Das KPro-Content-Modell beinhaltet drei Ebenen für Verwaltungsdaten. Daher wird das KPro- Content-Modell auch als dreistufiges Content-Modell bezeichnet:
Komponenten verwalten Content
physische Dokumente verwalten Dokumente
logische Dokumente verwalten Collections von Dokumenten
Mehrere physische Dokumente werden einem logischen Dokument zugeordnet. Ein physisches Dokument repräsentiert ein individuelles Dokument, während ein logisches Dokument eine Collection von Dokumenten repräsentiert.
Ein Dokument kann aus unterschiedlichen Dateien bestehen, d. h. zu jedem physischen Dokument kann es eine oder mehrere Komponenten geben. Jede Komponente wiederum wird mit genau einer Content-Einheit assoziiert.
KPro-Content-Modell
Hinweis
Der Knowledge Provider erlaubt ebenfalls die Modellierung von zweistufigen Content-Modellen. In diesem Fall benötigt eine den Knowledge Provider nutzende Anwendung keinerlei logische Dokumente. Es werden lediglich physische Dokumente und Komponenten eingesetzt.
Anwendungsspezifisches Content-Modell
Um die Dokumenteninfrastruktur des Knowledge Provider zu nutzen, können Anwendungen ihre eigenen Content-Modelle entwickeln. Während der Laufzeit greift der Knowledge Provider auf diese anwendungsspezifischen Content-Modelle zu und verwendet die darin enthaltenen Meta-Informationen, um die benötigten Services auszuführen. Somit können Anwendungen beispielsweise ihre eigenen Attribute oder bestimmte Arten der Versionierung definieren.
Als erstes entscheidet sich die Anwendung, ob ein zwei- oder dreistufiges Content-Modell für ihre Belange einzusetzen ist. Wenn erwartet werden kann, dass die Dokumente im Laufe der Zeit einem Änderungs- oder Versionierungsprozess unterworfen sein werden, wird das dreistufige Content-Modell eingesetzt. Mögliche Änderungen sind Änderungen des Inhalts, der Sprache und des Formats. Das zweistufige Content-Modell ist nur für Dokumente sinnvoll, die während ihres Lebenszyklus keinerlei Änderungen oder Versionierungen unterworfen sein werden.
Das dreistufige Content-Modell wird auch für Szenarios empfohlen, in denen mehr als eine kontextabhängige Instanz eines bestimmten physischen Dokuments gleichzeitig existiert.
Sobald eine Entscheidung für das zwei- oder dreistufige Content-Modell gefällt wurde, kann das Content-Modell selbst in den folgenden Schritten modelliert werden:
Definition von anwendungsspezifischen Attributen
Definition von Klassen für physische Dokumente
Definition von Klassen für logische Dokumente
Definition von Klassen von Beziehungen
Definition der erlaubten Beziehungen
Im letzten Schritt werden Regeln für das Anlegen von Beziehungen bestimmter Klassen zwischen Instanzen logischer und physischer Dokumente festgelegt. Während der Laufzeit greift der Knowledge Provider auf diese Informationen innerhalb des anwendungsspezifischen Content-Modells zu, um zu klären, ob die geforderte Aktivität zulässig ist. Diese Regeln können beispielsweise eingesetzt werden, um unerlaubte Beziehungen zwischen Inhaltsversionen physischer Dokumente abzufangen.
Hinweis
Sie können Ihr eigenes Content-Modell über die Document Modeling Workbench (Transaktion DMWB) anlegen. Informationen über die DMWB erhalten Sie in der Dokumentation Document Modeling Workbench.