Knowledge Provider (BC SRV KPR)

Knowledge Provider (BC-SRV-KPR)

HE

LP

.BC

SR

VK

PR

Re lease 6 .20

SAP Online Help 22.03.2002

Copyright © Copyright 2001 SAP AG. All rights reserved. No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft®, WINDOWS®, NT®, EXCEL®, Word®, PowerPoint® and SQL Server® are registered trademarks of Microsoft Corporation. IBM®, DB2®, OS/2®, DB2/6000®, Parallel Sysplex®, MVS/ESA®, RS/6000®, AIX®, S/390®, AS/400®, OS/390®, and OS/400® are registered trademarks of IBM Corporation. ORACLE® is a registered trademark of ORACLE Corporation. INFORMIX®-OnLine for SAP and INFORMIX® Dynamic ServerTM are registered trademarks of IBM Corporation. UNIX®, X/Open®, OSF/1®, and Motif® are registered trademarks of the Open Group. Citrix®, the Citrix logo, ICA®, Program Neighborhood®, MetaFrame®, WinFrame®, VideoFrame®, MultiWin® and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA®is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT® is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink, SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI, SAPPHIRE, Management Cockpit, mySAP, mySAP.com, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and in several other countries all over the world. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP Markets and Commerce One. All other product and service names mentioned are the trademarks of their respective owners.

Knowledge Provider (BC-SRV-KPR) 6.20 2


Icons

Icon Meaning

Caution

Example

Note

Recommendation

Syntax

Typographic Conventions

Type Style Description

Example text Words or characters that appear on the screen. These include field names, screen titles, pushbuttons as well as menu names, paths and options.

Cross-references to other documentation Example text Emphasized words or phrases in body text, titles of graphics and tables

EXAMPLE TEXT Names of elements in the system. These include report names, program names, transaction codes, table names, and individual key words of a programming language, when surrounded by body text, for example, SELECT and INCLUDE.

Example text Screen output. This includes file and directory names and their paths, messages, names of variables and parameters, source code as well as names of installation, upgrade and database tools.

Example text Exact user entry. These are words or characters that you enter in the system exactly as they appear in the documentation.

<Example text> Variable user entry. Pointed brackets indicate that you replace these words and characters with appropriate entries.

EXAMPLE TEXT Keys on the keyboard, for example, function keys (such as F2) or the ENTER key



Knowledge Provider (BC-SRV-KPR) ....................................................................................................7

Document Management with the Knowledge Provider......................................................................10 Document Management Service (BC-SRV-KPR)..............................................................................14

Concepts.........................................................................................................................................14 Attributes .....................................................................................................................................16 Relationships...............................................................................................................................17 Versioning ...................................................................................................................................18 Context Resolution......................................................................................................................21 Content Models ...........................................................................................................................23

DMS Programming Interface ..........................................................................................................25 Content Management Service (BC-SRV-KPR)..................................................................................27

Storage Types ................................................................................................................................29 Concepts.........................................................................................................................................29

HTTP Access for Repositories on SAP Web Application Server................................................33 Storing URLs...............................................................................................................................36

SAP Content Server .......................................................................................................................37 Architecture of the SAP Content Server .....................................................................................38 Advantages of the SAP Content Server......................................................................................39 Security Mechanisms of the SAP Content Server ......................................................................40

Secure URLs ...........................................................................................................................40 Protection Against Tapping and Forging of the Data Stream .................................................41 Security Mechanisms Against Data Loss................................................................................41 Creating a System-Specific Certificate for Content Server Access ........................................42 Access Protection for Administration.......................................................................................43

Logical Repository ..........................................................................................................................43 Knowledge Provider and Caching ..................................................................................................46

Cache Servers ............................................................................................................................47 Architecture of the Cache Server ............................................................................................48 Deletion Strategy and Performance ........................................................................................49 Optimal Access Path for Client Requests ...............................................................................50

Customizing for Caching.............................................................................................................50 Cascaded Caching......................................................................................................................51 Content Server Aliases ...............................................................................................................51 Cascaded Caching and Content Server Aliases.........................................................................52 Cache Preload ............................................................................................................................52

Distribution......................................................................................................................................53 Configuring the Distribution Settings...........................................................................................53 Reading via Distributed Cache Servers......................................................................................56 Different Locations with Different Content Servers.....................................................................57



Redirecting the Web Server........................................................................................................57 Overview of Transactions ...........................................................................................................58

Locations .................................................................................................................................58 IP Subnets ...............................................................................................................................59 Hosts .......................................................................................................................................59 Content Server Administration ................................................................................................59 Content Repositories...............................................................................................................60 Content Categories .................................................................................................................62 Caches ....................................................................................................................................63 Distributing Categories ............................................................................................................63 Web Servers for Document Spaces........................................................................................64 Web Servers for Document Classes .......................................................................................64

Content Server and Cache Server Administration .........................................................................65 Choosing a Server ......................................................................................................................66 Functions.....................................................................................................................................67

Overview Information ..............................................................................................................67 Details......................................................................................................................................68 Certificates...............................................................................................................................69 Settings....................................................................................................................................70 Statistics ..................................................................................................................................70 Creating New Content Repositories........................................................................................71

Content Server and Cache Server Monitoring ...............................................................................72 Monitoring for Content Server.....................................................................................................74 Monitoring for Cache Server .......................................................................................................76 Monitoring with KPro Web Server...............................................................................................76

SAP Content Server HTTP 4.5 Interface........................................................................................78 Introduction .................................................................................................................................78

Definition of Terms ..................................................................................................................78 Implementation........................................................................................................................80 Security....................................................................................................................................80

secKey .................................................................................................................................80 Security Level / Access Permissions...................................................................................82

Syntax .........................................................................................................................................83 General....................................................................................................................................83 URL Encoding .........................................................................................................................84 Coding in the Response Body.................................................................................................85 Functions .................................................................................................................................85

Access Functions.................................................................................................................87 Function: info....................................................................................................................87 Function: get.....................................................................................................................90 Function: docGet..............................................................................................................91



Function: create ...............................................................................................................95 Function: HTTP-PUT....................................................................................................96 Function: HTTP-POST multipart/form-data ..................................................................96

Function: mCreate............................................................................................................98 Function: append ...........................................................................................................100 Function: update ............................................................................................................101

HTTP-PUT..................................................................................................................102 HTTP-POST multipart/form-data................................................................................102

Function: delete..............................................................................................................103 Function: search.............................................................................................................104 Function: attrSearch.......................................................................................................106

Administration Functions ...................................................................................................111 Function: putCert............................................................................................................111 Function: serverInfo .......................................................................................................112

Error Codes ...........................................................................................................................114 Cache Server and Interface Version 4.6...................................................................................115 Appendix ...................................................................................................................................116

Parameters and Keywords ....................................................................................................116 Migrating Existing Archives ...................................................................................................120



Knowledge Provider (BC-SRV-KPR) Uses The Knowledge Provider (KPro) is a cross-application and cross-media technical information infrastructure within the framework of SAP Web Application Server. The modularity and openness at the heart of the Knowledge Provider are demonstrated in its modular services and its clearly defined interfaces. Thanks to its considerable flexibility, the Knowledge Provider can handle widely differing information types relating to documents and document-like objects, such as administration data, index data, and pure content.

The fundamental concepts of the Knowledge Provider are protected by United States Patent 6,134,552.

For detailed information on the patent, see the following URL: http://164.195.100.11/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='6,134,552'.WKU.&OS=PN/6,134,552&RS=PN/6,134,552.

The applications that use the Knowledge Provider have different end users, each with their own different requirements. This means that there is no universal interface to the following Knowledge Provider services:

• End-user-specific knowledge management functions

• Application-specific terminology for describing document-like objects

• Specific work process design

• Specific user interface design

Different applications use Knowledge Provider services by implementing their own user interface. In this way, the Knowledge Provider provides the fundamental infrastructure for application-independent information exchange.

The Knowledge Provider is intended for use in the application areas listed below. (For a list of the SAP applications into which the Knowledge Provider is integrated, see the section ‘Client Applications’.)

• Context-specific development and distribution of documentation, online help, and training materials, of both SAP and SAP customers, within SAP Knowledge Warehouse

• Management of multimedia information objects for companies primarily active in the media industry, for example, collation and distribution of information using any media and distribution channel, such as print media, internet, television, and radio

• Development, management, and distribution of software and software components

• Administration of report lists in the Business Information Warehouse environment

• Integration of business transactions with static information objects for e-commerce solutions

• In the framework of SAP Business Workflow, extensive support for document-oriented business processes

• Publishing solutions for both the Internet and intranet. For example, international companies can use the Knowledge Provider to obtain up-to-date information at any time about important issues within the company, for example, quality management.

Although end users’ requirements overlap to a certain extent, there are nonetheless significant differences in the general goals and requirements of the applications that use the Knowledge Provider. For example, one customer may use the Knowledge Provider as a tool for designing a corporate intranet, while another may use it for publishing a magazine or administrating software components. However, the fundamental Knowledge Provider infrastructure is at the basis of all applications, providing version management, context resolution, and integration of various content servers, among others.



Notes on Implementation It may be necessary to implement some Customizing in order to use the Knowledge Provider, regardless of the SAP application in question. See the SAP reference implementation guide (IMG) under SAP Web Application Server → Basis Services → Knowledge Provider. The IMG modules contain further information on each activity.

Scope of Functions Within its information technology infrastructure, the Knowledge Provider provides the following services:

• Integration of KPro client applications

• Integration of Knowledge Provider services: Document Management Framework (DMF), Document Management Service (DMS) and Content Management Service (CMS)

• Integration of content servers and cache servers

myS

APPL

M

Kno w

led g

eW

areh

ouse

Busi

ness

Wor

kflo

w

ADK

CMS

DMS

DMFDMWB

ContentServer

CacheServer

Appl

icat

ion

Prog

ram

min

gIn

terfa

ces

(API

s)

Kn owle dg e P ro vid er

Ap pli cat ion si n S AP W

eb A ppl ica tio n S erv er

Server Components

myS

APC

RM

Oth

ers

SAP

Arch

iveL

ink

Modeling

Knowledge Provider Infrastructure

Knowledge Provider Client Applications Client applications use Knowledge Provider by integrating Knowledge Provider interfaces into their systems. Based on the flexibility and scope of the document management functions you wish to implement, you select the services and interfaces that best meet your requirements.

The following SAP applications use Knowledge Provider functionality:

• SAP Knowledge Warehouse

• Business Document Service (BDS)

• Document Management System (DMS)

• SAP Business Workflow

• SAP Business Workplace



Knowledge Provider Services The Knowledge Provider provides the following services:

• Document Management Service (DMS)

The DMS allows you to process documents and document-like objects on the basis of application-specific content models. It also allows you to modify document administration data and to store document content on content servers.

See Document Management Service

• Content Management Service (CMS)

See Content Management Service

Knowledge Provider Server Integration • Content Server

Allows you to integrate SAP Content Sever or external content servers. See SAP Content Server.

• Cache Server

Allows documents to be cached. See Cache Server.

For information on installing the Content Server and the Cache Server, see the SAP Content Server Installation Guide in the SAP Service Marketplace, under the alias INSTGUIDES. Choose SAP Web Application Server and the relevant release.

You can also integrate search engines using Text Retrieval & Information Extraction. For further information on this, see the implementation guide (IMG), the SAP Content Server Installation Guide, and Text Retrieval & Information Extraction.



Document Management with Knowledge Provider Introduction The knowledge and information contained in documents can have a significant impact on the efficiency and productivity of your company.

The Knowledge Provider (KPro) is a general and comprehensive infrastructure that provides cross-application and cross-media document management technologies. The Knowledge Provider is a component of SAP Web Application Server and can be integrated with any SAP application.

Concepts Various Information Entities When dealing with documents, the Knowledge Provider differentiates between the following information entities:

• Content

• Content index

• Administrative data

• Model data

A text file exists for a section of documentation. This text file contains the content. The file exists independently of whether or not other information about this section exists. Administrative data could be the person responsible, the creation date, and the name of the documentation to which the section in question belongs. The model data defines, among other things, what attributes the document has. The existence of the attribute “author” is therefore part of the model data. The content index is a secondary representation of the content. The content index makes it possible to have content searches (for example, full-text search). You do not always have to define the content index separately. Sometimes it may be more efficient to duplicate parts of the administrative data (for example, author) in the content index or in the content (self-describing documents).

Documents and Document-Like Objects In the context of the Knowledge Provider, the term “document” is used in a broad sense. It can refer to text, video, audio, software programs, websites, and controls. In other words, the Knowledge Provider definition of the term “document” is much wider than the classical sense of the word. In the Knowledge Provider, a document can be any self-contained document-like object.

Application-Specific Content Models In the context of the Knowledge Provider, there is no fixed definition of the term “document”. The Knowledge Provider allows its client applications the freedom to define and create their own specific definitions of document models. An application-specific content model contains in particular the following elements:

• Classes for relationships

• Classes for logical documents

• Classes for physical documents

Content models function as the structure and the architecture of document-like objects within the application-specific context. This means that every client application can use its own specific metadata descriptions, while still being able to exchange information with other applications.



Application-specific content model for a magazine article In this example, there are two classes, one for a logical document, and one for a physical document with specific properties. There are also a number of classes for relationships. The instances of the relationship classes CONTENT VERSION, FORMAT VERSION, and LANGUAGE VERSION make it possible to administrate any number of different versions according to different criteria (modified content, translation, format conversions).

LANGUAGE VERSION

LD_SAPINFO

Person responsibleMagazine issue

PD_SAPINFO_1Creation dateAuthorLanguageFormat

COLLECTION

CONTENT VERSION

1 *

FOR

MAT

VER

SIO

N

Class: logical document

Class: physical document

Class: relationship

HYPERLINK

SCR

DST

DST

DST

SCR

SCR DSTSCR

DST

SCR

** * *

* *

*

*

Application-Specific Content Model

Intension and Extension The Knowledge Provider provides both simplification and automation functions in several areas of document management. A central part of this is a two-level approach to document management, consisting of intension and extension.

The logical properties of a document, including meaning and purpose, are referred to as intension.

The actual physical representation of the document itself is the extension.

Intension and extension are represented in the Knowledge Provider by two administration objects: logical document and physical document.

The intension of this section is the conceptual background of the Knowledge Provider. (However, this statement does not make any assumptions about how this will be achieved.) This section is available both in German and in English. It is also available in electronic form, for example, in the form of HTML Help or plain HTML, and can also be printed. Therefore, the physical representation of the document exists in various forms, that is, extensions.

Relationships Documents in isolation are worthless. Every document-like object has relationships to other objects. These relationships can be either implicit or explicit. The Knowledge Provider administrates not only document-like objects themselves, but also the relationships between objects. The Knowledge Provider also allows relationship classes to be defined, which means you can identify and classify the types of relationships between documents.

Relationships and references between documents are dynamic. If you make a change to a document in the Knowledge Provider, this does not mean that a costly chain reaction of manual changes to other documents has to be made.



If a note is created which relates to a specific document, the link between the note and the document can be made explicit by means of a relationship. In the same way, relationships can be used to display hyperlink paths in documents, thus making explicit the interrelationship between the documents linked by hyperlinks.

Late Binding and Context Resolution If various documents are interconnected by several relationships (for example, hyperlinks), these documents are no longer self-contained. This problem applies to all types of relationships, not just hyperlinks, and can occur between different documents, and between documents and business objects.

The Knowledge Provider provides a solution to this problem by referencing logical documents (for example, logical hyperlink) and by implementing context resolution at runtime. This process is called late binding. This means that the physical document version that best matches the specified context is not selected from the set of physical documents belonging to the specified logical document until runtime. The version is selected on the basis of context information (user context or business context). Late binding, then, is the interface between intension and extension. Both information managed by the Knowledge Provider and other information from the Knowledge Provider client application can be involved in the resolution process. The network of relationships remains intact, even if documents are translated, if document content is edited, or if a document is converted to a different format. This all helps to avoid expensive and time-consuming extra work.

Logical Hyperlink: Context Resolution

For further information see..."href ..ID = LO_1..."

HTML page contains alogical hyperlink that points

to a logical document

Logical Document

German TXT PO2German HTML PO4English HTML PO5Spanish HTML Result is determined

by application-specific rules.

ID = LO_1Person responsible: Seamus O’HaraSAPinfo issue: 61

PhysicaldoccmentID = PO2Author: MüllerLanguage: GermanFormat: TXT

PhysicaldoccmentID = PO4Author: MüllerLanguage: GermanFormat: HTML

PhysicaldoccmentID = PO3Author: O’HaraLanguage: EnglishFormat: TXT

Format version

Languageversion

PhysicaldoccmentID = PO1Author: MüllerLanguage: GermanFormat: TXT

Content version

PhysicaldoccmentID = PO5Author: SmithLanguage: EnglishFormat: HTML

Format version

Context Result

Versioning The Knowledge Provider provides a powerful versioning concept. Knowledge Provider versioning supports multiple versioning based on a number of different criteria. Versioning can control language versions and format versions, among others. For example, a document can exist in German, English, and French, and in both PDF and HTML format.



Equal Access and Retrieval The Knowledge Provider allows equal access to all document-like objects via HTTP, regardless of the underlying medium and the application-specific design of the website. The check-in and check-out mechanism ensures that authors cannot make conflicting changes to the same object at the same time. Text Retrieval & Information Extraction offers a range of retrieval strategies, including integration of search engines to allow full-text searches.

Content Storage Media The Knowledge Provider provides document storage services. This means that SAP-based document management functions can be combined with a wide range of storage media.

See also Content Management Service.



Document Management Service (BC-SRV-KPR) Purpose The Document Management Service (DMS) is a service of the information management infrastructure provided by the Knowledge Provider within the framework of SAP Web Application Server. The central task of the DMS is to process documents and document-like objects on the basis of application-specific content models. Only the DMS can modify document administration data and save this data in a storage medium, such as the SAP database.

Implementation Considerations In order to use the DMS, you need to implement some Customizing steps. For details, see the Implementation Guide (IMG) under the following path: SAP Web Application Server → Basis Services → Knowledge Provider → Document Management Service. The IMG modules contain details on the individual Customizing activities.

Features The DMS provides the following functions:

• Administration of attributes

• Administration of relationships

• Versioning

• Context resolution

• Content models

An important task of the DMS is to shield the SAP applications from the details of administration data storage. In other words, the DMS takes care of the administration and processing of all administration data and the corresponding tables on behalf of the SAP applications.

The DMS also provides a lock mechanism. The lock mechanism guarantees that only one author can work on a document at any one time.

The DMS also has its own programming interface.

Concepts In the context of Knowledge Provider, the term ‘document’ refers to any information entity that can be accessed via document-like objects, in particular:

• Actual content

• Administration data

• Index data

• Metadata

Every application-specific content model represents a document definition.

The logical document “Documentation on Knowledge Provider Data Structures”.

The central components of Knowledge Provider are logical documents, physical documents and components. A logical document is the logical representation of a document in all its forms. A logical document can contain several physical documents. Physical documents therefore consist of meta-descriptions of real documents. Meta-descriptions are implemented using attributes.



Physical documents belonging to the logical document “Documentation on Knowledge Provider Data Structures”: “Documentation on Knowledge Provider Data Structures, in HTML format, in English, third version, 01.10.1999” and “Documentation on Knowledge Provider Data Structures, in WinWord format, in German, second version, 02.10.1999”.

Physical documents contain references to one or more components. Components contain administration data about the document content, for example, the size of the file.

Components of the physical document “Documentation on Knowledge Provider Data Structures, in HTML format, in English, third version, 01.10.1999”, where the physical document consists of a HTML file and a PowerPoint file on the Content Server: administrative counterparts to the HTML and PowerPoint files on the Content Server.

On the physical level, every component is assigned to one file. The file contains the actual content.

Administration Data

Logicaldocument

Content

Physical document Component File1 * 1 * 1 1

See the Implementation Guide (IMG) under SAP Web Application Server → Basis Services → Knowledge Provider for the necessary Customizing steps.



Attributes Attributes are used to create meta-descriptions of physical documents. Attributes can be, for example, format and language.

Attributes can be set either by the SAP application in which the document is being created, or by Knowledge Provider itself. Knowledge Provider provides the following pre-defined attributes:

Relevant for: Attribute Name Description

Logical documents

Physical documents

Relation-ships

CREATED_AT Creation time x x x

CREATED_BY Creator x x x

LAST_CHANGED_AT Last changed at [time]

x x x

LAST_CHANGED_BY Last changed by x x x

EXPIRYTIME Expiry time x x x

ORIGINAL_LANGUAGE Original language x

CHECKED_OUT Flag for checked-out documents

x

CHECKOUT_USER Name of user who has checked out the document

x

DOCUMENT_FORMAT Document format x

LANGUAGE Language x

RESERVED Flag for reserved document

x

STATE Status of document x

STORAGE_CATEGORY Storage category ID x

DESCRIPTION Short description x x



The logical document with the ID LD_1 consists of two physical documents with the Ids PD_1 and PD_2. The first document has the following attributes: ID = PD_1, author = Hans Meier, language = German, format = DOC. The second document has these attributes: ID = PD_2, author = John Smith, language = English, format = DOC.

Logical Document: LD_1

Physical Document

Attributes:

ID = PD_1Author = Hans MeierLanguage = GermanFormat = DOC

Physical Document

Attributes:

ID = PD_2Author = John SmithLanguage = EnglishFormat = DOC

Relationships Knowledge Provider uses relationships to represent interdependencies between documents. Every relationship is an independent object. An internal relationship links two Knowledge Provider documents according to certain criteria. Different classes of relationships exist independently of these criteria. An external relationship links Knowledge Provider administration objects with non-Knowledge Provider documents.

A document that is administrated as a physical document in Knowledge Provider is translated from German into English. The creation of the translated version creates a language relationship between the two documents, and this relationship allows us to conceptually define the English version of the document. The criterion for the creation of the relationship in this case is the language. The creation and administration of a language relationship is called language versioning.

The Knowledge Provider provides the following predefined relationship types or relationship classes:

• Collection relationship

Logical documents contain physical documents. The collection relationship (LOGOBJECT) models this behavior. A particular physical document belongs exclusively to one logical document. This relationship means that the logical document acts as a container for the physical document.

• Template relationship

A template relationship (EXPORT_MODEL) exists between two physical documents. In a template relationship, a particular document serves as the template for the creation of a new



document or several new documents. This relationship is activated when new documents are created.

• Version relationship

The version relationship (VERSIONREF, FORMATREF, TRANSLREF) between document A and document B tells us, for example, that document A was created as a version of document B. This means that document A could be one of the following:

− A translation

− An updated version of the document

− A backup copy in a different format

• Description relationship

The description relationship (DESCOBJECT) tells us that an information object is actually a description of another information object. This type of relationship can be useful if the content in question is an image, for example.

• Structure relationship

A structure relationship (STRUCTLINK) models a hierarchical relationship between the contents of two documents. The relationship could be, for example, that between chapters and paragraphs in a book.

• Hyperlink relationship

A hyperlink relationship (HYPERLINK) is used to represent hyperlinks between documents. If a hyperlink points to a logical document, the Knowledge Provider’s context resolution function is used.

Versioning In Knowledge Provider, the term ‘versioning’ is an umbrella term for various subtypes of versioning. These subtypes are defined by means of various relationship classes. In general, versioning describes the relationship between two documents where one of the documents is derived from the other.

The following versioning relationship classes are predefined in the Knowledge Provider:

• Content versioning

Criterion: content has changed

• Format versioning

Criterion: format has changed

• Language versioning

Criterion: language has changed

Multiple Versioning The Knowledge Provider also supports the principle of multiple versioning, independently of these criteria. If a number of physical documents are derived from one physical document, multiple versioning is required, so that the various versions of the document can be administrated. The document versions vary in terms of format, language, and so on.

Three versions of the content of a physical document exist. These versions are of equal status.

For example, if a German document is translated into English and Spanish, this is multiple versioning.



The following graphic illustrates the principle of multiple versioning based on the versioning criterion “content”:

Multiple Versioning

Logical DocumentID = LO_1

Logical DocumentID = LO_1

ID = PH_1Language = EMat.no. = 100

Phys. document


Phys. document


Phys. document


Phys. document

New versioncreated for

mat. no. = 100

Content version

Content version


Phys. document

Content version

The logical document on the left-hand side contains two washing machine manuals in English, one manual for model 100 and another for model 200. The manual for model 200 was derived from the manual for model 100. However, a technical fault has been identified in model 100, and so the manual has to be modified accordingly. A new content version is created, but the original is retained, not overwritten. This is so that the name of the person who made the changes and the time that changes were made are recorded (for quality assurance purposes, for example). A new physical document for model 100 is therefore created. This is illustrated in the right-hand side of the graphic. Now there are two content versions that were derived from the original content for model 100.

Strict Versioning The principle of strict versioning ensures that the content of physical document components is automatically protected. Every change triggers the creation of a new version of the document with a new ID. In the case of applications that deal with a large number of documents, this procedure can lead to a high versioning overhead. If references to different document versions are being used, every reference has to be updated whenever a new version is created or an existing version is deleted. The three-layer content model (see Content Models), however, solves these problems. The three-layer content model supports both strict versioning and inter-document references. In the model, all references are to logical documents. New versions of individual physical documents with new IDs cause no problems. The three-layer content model therefore avoids unnecessary versioning overhead.

Versioning Type Content Versioning If component content of an existing physical document is changed, and this results in the creation of a new physical document, content versioning is responsible for saving and administrating this information in the Knowledge Provider. Content relationships are used for content versioning.

Format Versioning Format versioning uses format relationships to ensure that physical documents that differ only in terms of format are administrated separately. Format versioning can only be carried out on physical documents that belong to the same logical document.



If a .PDF document is generated from a .DOC document, the Knowledge Provider defines the relationship as a format relationship. Format versioning administrates this relationship and keeps a record of which DOC the PDF was created from. This enables the system to deal with requests along the lines of “Is this physical information object available in a format that my application can understand?”

Language Versioning Language relationships are administrated by a process called language versioning.

A translator wants to translate a Knowledge Provider document from German into English. A copy of the German original can be transferred to the user’s application via the Knowledge Provider interface. The language relationship between the copy and the original is created at this point. Once the translator marks the translation as completed, the translation is transferred back to the Knowledge Provider by means of the check-in function. Language versioning administrates existing language relationships and deals with requests along the lines of “Does physical document 4711 exist in languages x, y, and z?”



Context Resolution The Knowledge Provider contains the concept of logical hyperlinks to logical documents. The ID of the logical document is the most important component of a logical hyperlink to a logical document. At runtime, a context string (attribute name 1 = attribute value 1, attribute name 2 = attribute value 2, and so on) is dynamically added to the logical hyperlink to resolve the hyperlink and to identify the physical document, its components, and its content. This process is called context resolution.

Document--------------

GermanHTMLV 4.6B

Logicaldocument

Physical document

-----------------Language

FormatRelease

Component

0 .. 1

*

1

*

Document--------------

GermanPDF

V 4.6B

Document--------------

GermanDOC

V 4.6B

Document--------------

EnglishHTMLV 4.6B

Document--------------

EnglishPDF

V 4.6B

Document--------------

EnglishDOC

V 4.6B

File--------------GIF graphic

File--------------HTML text

Chapter---------------

KProConcepts

One component represents one file on the content server. Therefore, one document can consist of several files. This is especially true of HTML documents, which often contain GIF graphics.

A physical document, on the other hand, represents an individual document and everything associated with that document, that is, its components. Since physical documents also contain document properties, which determine the version of a document, physical documents are evaluated in the context resolution process.

Logical documents, on the other hand, represent all documents belonging to a collection. This means that they also contain all physical documents. Logical documents do not contain any information relevant to context resolution and are not subject to the versioning process. Logical documents group together the physical documents that logically belong to a group. The definition of a group and its properties depends on the relevant client application. References always refer to logical documents. This makes them independent of the lifecycle of individual documents.



A number of versions of a document can exist simultaneously (see also Versioning).

A user is logged onto the SAP system in English, and is viewing the Knowledge Provider via a Web browser at the front-end. The user wants to view the English HTML version of the documentation “Knowledge Provider Concepts”. A German user who is logged on in German, meanwhile, wants to view the German version of this documentation. Both users also expect to see the correct release of the documentation. The Knowledge Provider now compares the attributes of the user context with the corresponding document properties:

User Context Attributes Document Properties

Logon language Language

Viewer application Format

Current SAP system release SAP system release defined for the document

If there is a document in the collection whose properties all match the context attributes, the Knowledge Provider returns this document. Otherwise, the Knowledge Provider returns the document whose properties match most closely.

A Knowledge Provider client application can define additional context attributes and document properties (see also Attributes).

If there are a number of documents with the same number of matching properties, the Knowledge Provider activates application-specific context resolution in the form of application-specific function modules. These function modules evaluate the additional attributes so that a suitable document is returned, or they prioritize properties in the context of the current application.



Content Models Individual SAP applications create meta-data models for the various types of documents that they use that have relationships to each other. These models are called content models.

A content model describes on an abstract level the characteristics of the individual content entities in the Knowledge Provider. The documents in the content model are classified according to content type. Examples of content type are end-user documentation and scanned documents.

Knowledge Provider Content Model The Knowledge Provider content model is called a three-level content model, as it contains three levels for administration data:

• Components administrate content

• Physical documents administrate documents

• Logical documents administrate collections of documents

A number of physical documents is assigned to a logical document. A physical document represents an individual document, while a logical document represents a collection of documents.

A document can consist of different files, that is, every physical document can have one or more components. Every component, for its part, is associated with one content entity.

Knowledge Provider Content Model

Administration Data

Logicaldocument

Administrated Entities

Physicaldocument

Component

0 .. 1

*

1

*

Collection

Document

Content

0 .. 1

*

1

*KPro representation

1 1

File

Databaseentry

Repositorysystem entry

...

KPro representation

1 1

KPro representation

1 1

With the Knowledge Provider, you can model two-layer content models. In this case, an application using the Knowledge Provider does not need any logical documents, as only physical documents and components are used.

Application-Specific Content Model Applications can use the Knowledge Provider’s document infrastructure to develop their own content models. At runtime, the Knowledge Provider accesses these application-specific content models and



uses the meta-information they contain to execute the required services. This allows applications to define their own attributes or particular types of versioning, for example.

First, the application decides whether it will use a two-level or a three-level model. If it is likely that the documents will be subject to changes or a versioning procedure, the three-level model should be used. Possible changes could be changes to the content, language, and format. The two-level model is only suitable for documents to which no changes will be made and which will not be subject to a versioning procedure.

The three-level model is also recommended in situations where a number of context-dependent instances of a particular physical document coexist.

Once the application decides on the two-level or three-level model, the content model can itself be modeled in the following steps:

• Define application-specific attributes

• Define classes for physical documents

• Define classes for logical documents

• Define relationship classes

• Define allowed relationships

The last step sets rules for creating relationships of particular classes between instances of logical and physical documents. During runtime, the Knowledge Provider accesses this information in the application-specific content model to find out whether a particular activity is allowed. You can use these rules to ensure that only allowed relationships between content versions of physical documents occur.

You can create your own content model using the Document Modeling Workbench (transaction DMWB). See the Document Modeling Workbench documentation for more information.



DMS Programming Interface Use You use this programming interface to integrate the functions of the Document Management Service into your SAP application.

Features The following function modules are available:

Function modules for document classes and relationship classes

SDOK_CLASS_ATTRIBUTES_GET

SDOK_CLASS_FIND_BY_QUERY

SDOK_CLASS_PARTNERS_GET

SDOK_CLASS_PROPERTIES_DELETE

SDOK_CLASS_PROPERTIES_GET

SDOK_CLASS_PROPERTIES_SET

Function modules for logical documents SDOK_LOIO_CREATE

SDOK_LOIO_CREATE_WITH_PHIO

SDOK_LOIO_DELETE

SDOK_LOIO_ATTRIBUTES_GET

SDOK_LOIO_PROPERTIES_SET

SDOK_LOIO_PROPERTIES_GET

SDOK_LOIO_PROPERTIES_DELETE

SDOK_LOIO_DESCRIPTIONS_SET

SDOK_LOIO_DESCRIPTIONS_GET

SDOK_LOIO_DESCRIPTIONS_DELETE

SDOK_LOIO_FROM_RELATIONS_GET

SDOK_LOIO_TO_RELATIONS_GET

SDOK_LOIO_FIND_BY_QUERY

SDOK_LOIO_PHYSICAL_OBJECT_GET

Function modules for physical documents SDOK_PHIO_CREATE

SDOK_PHIO_CREATE_AS_COPY

SDOK_PHIO_CREATE_NEW_VERSION

SDOK_PHIO_CREATE_WITH_MODEL

SDOK_PHIO_DELETE

SDOK_PHIO_ATTRIBUTES_GET

SDOK_PHIO_PROPERTIES_SET

SDOK_PHIO_PROPERTIES_GET

SDOK_PHIO_PROPERTIES_DELETE

SDOK_PHIO_FROM_RELATIONS_GET

SDOK_PHIO_TO_RELATIONS_GET

SDOK_PHIO_FIND_BY_QUERY

SDOK_PHIO_STORE_CONTENT

SDOK_PHIO_STORE_AS_UPDATE



SDOK_PHIO_STORE_NEW_VERSION

SDOK_PHIO_STORE_NEW_CONTENT

SDOK_PHIO_LOAD_CONTENT

SDOK_PHIOS_CHECKIN

SDOK_PHIOS_CHECKIN_AS_UPDATE

SDOK_PHIOS_CHECKIN_NEW_VERSION

SDOK_PHIOS_CHECKOUT

SDOK_PHIOS_CHECKOUT_CANCEL

SDOK_PHIOS_GET_COPY

SDOK_PHIOS_FILE_PROPERTIES_GET

SDOK_PHIO_GET_URL_FOR_GET

SDOK_PHIO_GET_URL_FOR_UPDATE

SDOK_PHIO_GET_URL_FOR_NEW_VERS

SDOK_PHIO_GET_URL_NEW_CONTENT

SDOK_PHIO_GET_URL_FOR_PUT

Function modules for relationships SDOK_RELA_CREATE

SDOK_RELA_DELETE

SDOK_RELA_PROPERTIES_SET

SDOK_RELA_PROPERTIES_GET

SDOK_RELA_PROPERTIES_DELETE

Other function modules SDOK_ATTRS_QUALITIES_GET

SDOK_DOCUSPACE_SEARCH

The function modules listed here are just some of the more important DMS function modules.



Content Management Service (BC-SRV-KPR) Purpose The various storage media that can be used to store document objects all offer different advantages with regard to the storage quality. Quality aspects include security, lower costs, and higher performance.

The Content Management Service (CMS) is a service within the IT infrastructure provided by Knowledge Provider within the framework of SAP Web Application Server One of the main features of the CMS is that it is designed to be compatible with different types of storage media. In other words, the CMS functions as an interface between content servers and the SAP system.

Also, the CMS can be used to cache documents and integrate cache servers.

Implementation Considerations In order to be able to deploy cache servers in a Knowledge Provider environment, you must make certain settings in the SAP system:

• A range of transactions are available to administrators for defining general administrative settings and for monitoring the various content servers, cache servers, and Web servers. For further information, see Content and Cache Server Administration and Content and Cache Server Monitoring.

• The system administrator has to make certain settings when setting up the system. These are known as Customizing settings. In Customizing, you can do the following:

− Implement the SAP functionality in your company quickly, reliably, and economically

− Tailor the global functionality shipped with the system to the specific business requirements of your company

− Document and control the implementation and adaptation phases with an easy-to-use project management tool

Customizing must be carried out before the system goes live and is carried out in the SAP system using the Implementation Guide (IMG). The individual Customizing activities are contained in the SAP Reference IMG, which you can access under SAP Web Application Server → Basis Services → SAP Knowledge Provider. You can call up the relevant transaction from the IMG by simply choosing Execute. To display the online Help, simply choose Documentation. The main IMG activities for content servers and caching are grouped under the headings Content Management Service and Distribution.

Features The CMS provides the following services:

• Integration of various external storage media and decoupling of the application-related layer of the Document Management Service (DMS) from the storage media, that is:

− SAP database (SAP DB)

− Content servers

The static content can be stored either on the SAP Content Server or on external content server to which the CMS has a suitable interface. Different types of external content servers can be integrated.

• Content retrieval via a HTTP interface:

All document access on the client is conducted via HTTP. The CMS supplies the client with the appropriate access URLs that point to the document required. The HTTP Content Server protocol is the only access path to document stored on the Content Server.



The protocol specification (see also SAP Content Server HTTP 4.5 Interface), published by SAP, contains the following information:

− A number of command URLs, which the Knowledge Provider client uses to store documents on a content server and then access them as required

− Security mechanisms to protect documents from being accessed using forged URLs

− The structure of the request body and response body, which are transferred between the client and the server

− The action taken by the server in the case of incorrect client requests

To be Knowledge Provider-compliant, a content server has to support this protocol in its entirety.

Once this prerequisite is fulfilled, the result is a comprehensive and simple infrastructure that is largely independent of content servers and clients. The HTTP Content Server is designed in such a way that the characteristics of the concrete storage medium are completely transparent to the SAP system and to the client. This means that a content server can use, for example, an optical archive or a database as a storage medium.

SAP also provides certification for the HTTP Content Server Interface within the framework of the Software Partner Program.

• Central administration of the SAP Content Server and administration of cache servers

Administration can be carried out directly from the SAP system. Specially tailored monitoring and administration tools are provided for the SAP DB underlying the SAP Content Server.

For further information see SAP Content Server Administration.

• Monitoring in the framework of the Computing Center Management System (CCMS)

For further information see Content and Cache Server Monitoring.

• SAP Content Server

SAP provides a standard content server that can be installed separately on an NT server (see SAP Content Server).

• Cache Servers

Any number of content servers can be installed in different locations. The contents are transferred directly between the client and content server. If the content servers are accessed from different locations that are linked only via a wide area network (WAN), cache servers should be used. Network traffic across the WAN can be reduced to a minimum and performance enhanced by installing at least one cache server at each location.

A client cache is also available on the user's front end computer.

For further information see Knowledge Provider and Caching.

• The other Knowledge Provider services are not affected by the specific features of the various storage system types

• Likewise, the Knowledge Provider client applications are not affected by the specific features of the various storage system types.

Applications The CMS is used internally by Knowledge Provider to separate the SAP applications that use Knowledge Provider document management functionality and the Knowledge Provider itself from the various types of storage media. This ensures that the Knowledge Provider operates independently of the content servers.



Storage Types Purpose There are a number of different storage types. Each one has different advantages over the others. The storage category is selected on the basis of how the document in question is intended to be used:

• HTTP content server Either the SAP Content Server or a third-party content server can be used.

• SAP database If you want to store your documents in the SAP database, you need a content table. All your documents are stored in this table in the SAP database. The content table can be cross-client or client-specific.

• RFC storage system RFC is used for storing documents in the context of SAP ArchiveLink, the Archive Development Kit (ADK), or an application that uses SAP ArchiveLink or the ADK.

• Logical repository This storage type allows access to different physical repositories, independently of the client and the system ID.

• Structure repository The structure repository is only used in the SAP Knowledge Warehouse environment.

Concepts Entities and Relations The following entity relationship diagram illustrates the components and terminology used in CMS:

Entity Relationship Diagram

SAP System

Physicaldocument

ComponentContext

Logicaldocument

Contentcategory

Contentrepository

ContentserverLocation

1 n 1 n

internal

1

n

1 n

n 1

1

n

1externaln

1

1

n

n

Acce

ss k

ey

The individual entities are explained in detail below (see also Document Management with Knowledge Provider):

• The SAP system is the central instance where the Document Management Service (see also Document Management Service (BC-SRV-KPR) and the Content Management Service are implemented.



• Location refers to the location of a host (content server, cache server, application server) or user (client). Locations are used to choose the optimum route when cascaded caching (see also Cascaded Caches) and content server aliases (see also Content Server Alias) are being used.

• A content server is an external storage system. It can be accessed via the HTTP Content Server Interface (see also SAP Content Server HTTP 4.5 Interface).

• A content server administrates content repositories (see also Content Repositories). The Knowledge Provider stores documents only in repositories. The content server hides the technical details of how these repositories are actually implemented.

• Repositories have the following advantages over, for example, file systems: A repository is abstracted from the physical storage location. Repositories can be created in the R/3 database, in SAP Content Servers, or in third-party content servers. This has the effect of decoupling the physical access information (server name, access protocol, TCP port, storage type (file system, table access, Web server)) from the logical data access procedure.

• The equivalent of a repository in R/3 Customizing is the content category (see also Content Categories).

• The Knowledge Provider differentiates between logical documents and physical documents (see also Concepts and Context Resolution).

• Documents often consist of several different elements. For example, a typical HTML page can consist of a frameset, various pictures, stream data, text, and possibly script code. The individual elements represent components. A component ID identifies a component. In the simplest case, the component ID is a file name. Each component is assigned to only one physical document, while each document normally consists of at least one component. You can access whole documents and specific components using HTTP.

You specify in the document model (see also Content Models) what document types are used in an application. The Knowledge Provider provides tools for creating these models.

The necessary Customizing steps are provided in the Implementation Guide (IMG) under SAP Web Application Server → Basis Services → Knowledge Provider → Content Management Service.



Document Classes and Categories Using the basic DMS concepts of logical documents, physical documents, and components (see also DMS Concepts), you can group several physical documents in physical document classes. Each physical document class is assigned a default content category.

Physical Document Class

Physical document 1

Physical document 2

Physical document n

...

Content category

Physical Document Class and Content Category



Repositories and Categories A physical document is identified by the document ID and a content category. The content category only exists at a purely logical level. Each content category, in turn, is assigned a content repository, which represents the physical equivalent of the content category. The content repositories provide the physical storage location. Various repository types can be used here, for example, HTTP or the R/3 database. The repository types, in turn, are assigned concrete content servers, such as an HTTP content server for the storage category HTTP.

Physicaldocument

Document ID

Content cat. Content rep.

HTTP Content ServerHTTP

Structure

R/3 database SAP DB(for example)

Content Category and Content Repository

The structure repository is only of importance when CMS is being used in conjunction with the Knowledge Warehouse.



HTTP Access for Repositories on SAP Web Application Server Use Knowledge Provider’s Content Management Service can use both the HTTP server and the HTTP client interface of SAP Web Application Server (see the documentation on HTTP Communication with the SAP System as a Client and HTTP Communication with the SAP System as a Server).

The test report RSCMST is provided for testing access to the HTTP Content Server and the database repository. The report checks that the repositories are working properly. The report is also used in the certification procedure.

The SAP Content Server Interface (see also SAP Content Server HTTP 4.5 Interface) is implemented in the SAP system as of Release 6.10. This makes the database repository HTTP-compatible. HTTP compatibility contains the functions of the above-mentioned interface.

HTTP compatibility comprises the following functions:

• HTTP access to the database repository

For example, SAP ArchiveLink can use the database repository as a HTTP Content Server repository if the corresponding settings are made in transaction OAC0. Thanks to HTTP compatibility, new features are now available, for example, you can now view documents stored in the database repository in the browser. For example, you can now display documents in the browser when using the database repository.

• HTTP access to the HTTP repository

This allows you to use the SAP system as a gateway.

Use the class CL_HTTP_EXT_CSIF to implement SAP Content Server interface.

This functionality is intended for use in the following situations:

• Another SAP system needs to access your documents. To allow this, set your repository as a HTTP repository on the other SAP system and save the corresponding technical data:

− Enter an application server in your own SAP system as the HTTP server. The Internet Communication Manager must be running on this application server.

− Enter the HTTP port of your own SAP system as the port.

− Enter /sap/bc/contentserver as the path.

• To enable external access to all repositories of the SAP system via this gateway, the gateway simply has to point to the HTTP port of the application server. The gateway can be specified as an alias for any content server.

The gateway must be at a different location from the application server.

Prerequisites • HTTP must be activated in the Internet Communication Manager. For information on the ICM,

which is a component of SAP Web Application Server, see the documentation on SAP Web Application Server Components and the Structure of the ICM.



If an SAP system has more than one application server, HTTP need only be activated on one application server.

• To use this functionality you need to create a user in the HTTP services maintenance screen (see below).

Features HTTP Access to Repositories It is possible to access repositories via HTTP using SAP Web Application Server (see also the documentation on SAP Web Application Server), especially R/3 database repositories. To do this, in your system you need a user for anonymous access, without any permissions (see below). You can create this user in transaction SICF (see below). If you do not create this user, the system outputs a logon screen at the relevant point.

If you want to use cache servers for HTTP access to repositories via SAP Web Application Server, you need a database repository with version 0046. There are no plans to support cache server functionality with version 0045 database repositories.

Certificate Administration Full certificate administration is supported (transaction CSADMIN, tab page Certificates).

In transaction OAC0, set up a repository and choose Environment → CS Admin to go to transaction CSADMIN. You can then administrate certificates in this transaction. A dialog box appears, in which you have to enter your user and password. The client is entered automatically. From release 6.10, you have the option of specifying the client yourself. Once you make these entries, the authorization object S_TABU_DIS is used to carry out an authorization check. Both read and write authorizations are checked:

• Activity 02: change

• Activity 03: display

Note that these authorizations are only valid for administration commands, not for the service user mentioned above.

You can now make settings on the tab page Certificates in CSADMIN:

• If you only use one SAP system, you do not have to do anything on this tab page.

• You only have to send or activate certificates if you want to access database repositories on another system via HTTP. In this case, you have to specify what systems should have access. Then, your own SAP system only has access when its own certificate is active.

You are working in system A. If you want to make your own database repository accessible to another SAP system (system B), system B must send a certificate to system A. You then have to activate this certificate in your SAP system (system A).

CSADMIN supports certificate administration only for the R/3 database. It only supports read access for all other functions. A statistics function is not available.



Activities Creating a User for Anonymous Access 1. Call transaction SU01.

2. Enter a user name, such as CMS_CS, and choose .

3. On the next screen, select the tab page Address and enter this user name in the Last name field.

4. Select the tab page Logon data and enter an initial password.

5. On the tab page Logon data, choose Service.

This user type corresponds to the former CPIC user.

Do not assign any permissions to this user.

6. Choose .

Storing a User in the SICF 1. Call transaction SICF.

2. Expand the services tree.

3. Double-click on the service contentserver, which is located under /default_host/sap/bc.

4. Make sure that the service user you created in transaction SU01 is stored under Anonymous Logon Data on the tab page Service data.

Note that setting under Language here sets the language of the Content Server error messages.

When you create this user, the standard client is also specified.

5. Activate the service contentserver. To do this, choose Execute, click with the right-hand mouse button on the service in question, and choose Activate service from the context menu.

6. Choose .

Note that all services provided by SAP, as well as all newly created services, are initially inactive. Therefore, before you start working with the ICF, you have to activate the services you require. For more information on the Internet Communication Framework (ICF), see the ICF documentation under Creating an ICF Service.



Storing URLs Use The Knowledge Provider can administrate documents that are accessible via external URLs. Instead of storing the actual content of such documents, Knowledge Provider can simply store the corresponding URLs.

Features When a request for read access to such a document is processed, the same results are returned as if the content itself were stored. This is because at runtime, Knowledge Provider gets the current content from the URL.

Read access is carried out more or less transparently, using the same modules as for documents with stored content.

Whether a document is stored by means of its URL or whether its actual content is specified in the sub-type of the repository that is assigned to the document category (see below).

The URL is analyzed only at the time of reading, that is, at check-in the URL is merely stored. If the URL in question links to dynamic pages, Knowledge Provider displays the content that is available and most up-to-date at the time the display request is made.

In the case of read access, note that the Knowledge Provider gets the content itself via the URL. In such cases the Web server may return an error message (for example, if a link is faulty, the Web server returns a message that the page could not be found). The Knowledge Provider interprets this message as document content and displays it accordingly.

If the Web server retrieves the content independently of the browser, the document retrieval process can fail due to the absence of a browser.

Implementation This function can be implemented by means of a sub-type. This sub-type is introduced along with the content repositories (see also Content Repositories) in transaction OAC0 in addition to the already existing repository type (SAP database, HTTP content server). This sub-type defines the difference between the storage location of the content and the storage location of the URL.

Currently, this function is only supported for SAP database repositories.



SAP Content Server Purpose The SAP Content Server is based on the SAP DB and is available on Windows NT Server and Windows 2000 Server from release 4.6.

Therefore, besides the SAP DB, an external content server is always available in every SAP system installation. In this way, the necessary technical infrastructure is provided for all document-centric applications and business scenarios that do not require a long-term archiving solution. Since the SAP Content Server is also integrated via the HTTP interface (see SAP HTTP Content Server 4.5 Interface), the actual storage medium used remains completely transparent to SAP applications. This means that the storage medium can be changed at any time.

For OLTP documentation and information on the SAP DB tools, see the documentation under mySAP Technology Components → SAP DB:

Database Manager GUI: SAP DB 7.3

Database Manager CLI: SAP DB 7.3

SQL Studio: SAP DB 7.3

Reference Manual: SAPDB 7.2 and 7.3

Replication Manager: SAP DB

Applications that can use the technical infrastructure of the SAP Content Server include the SAP Business Workplace, SAP ArchiveLink, the Document Management System (DMS), and the Knowledge Warehouse.

Implementation Considerations The installation procedure for the SAP Content Server is described in the SAP Content Server Installation Guide, which is also available in both English and German as a PDF document on the SAP Server Components2 CD.

Constraints The SAP Content Server is not intended to replace optical storage systems and other storage media for long-term archiving of documents.



Architecture of the SAP Content Server The SAP Content Server consists of the following components:

SAP Content Server – mögliche Rechnergrenzen

SAP DB kernel

DatabaseRep 1 Rep nDatabaseRep 1 Rep nDat

abas

ese

rver

(NT

Serv

er 4

.0)

SAP DB ODBC Driver

Content Storage Layer

Content Server Engine

MS Internet Information Server 4.0 / ISAPISAP Content Server HTTP 4.5 Schnittstelle

Certificate Pool

SAP Security

SAP DB ODBC driver

Content storage layer

Content Server engine

MS Internet Information Server 4.0 / ISAPISAP Content Server HTTP 4.5 interface

Certificate pool

SAP security

Con

tent

Ser

ver

(NT

Serv

er 4

.0)

n|

m

SAP Content Server

The basis of the SAP Content Server is the Content Server Engine. The engine is implemented as an ISAPI extension in Microsoft Internet Information Server.

The engine receives all URLs, checks their validity, and triggers the processing of requests.

The SAP Content Server saves data to the SAP database (SAP DB). However, the Content Server engine does not communicate directly with the SAP DB. It uses an adapter known as the content storage layer. The storage layer hides the specific access mechanisms of the storage medium behind a consistent, bytestream-oriented interface. This means that one server engine can support several storage media. Only the storage layer has to be implemented every time.

In the case of the SAP Content Server, the storage layer uses the SAP DB client driver to access the database server. The SAP DB administrates the individual repository tables in which the documents are stored.



Advantages of the SAP Content Server • The SAP Content Server provides a flexible and scalable architecture. You can enhance the

capacity and performance of the SAP Content Server even further by using a number of servers and by decoupling the database server from the HTTP server.

• The database is much better suited than a file system to the administration of large amounts of data. Internally at SAP, the SAP Content Server has been used for several release cycles to administrate all documentation and training content.

• The SAP DB version is independent of the SAP release. SAP DB version 7.2 is included in the SAP release 4.6C package. This version of the SAP DB has a capacity of 64 terabytes (maximum). In the unlikely event of this space being used up, another database can be installed.

• Easy-to-use and stable SAP DB administration tools are shipped with the SAP Content Server. These can be used to make automatic backups, for example.

• The interface, which is based on the HTTP protocol, decouples the storage systems involved. Several well-known providers of storage systems have successfully implemented the certification procedure.



Security Mechanisms of the SAP Content Server Internet security mechanisms are intended to prevent data from being intercepted during transfer by unauthorized persons, and from being used for purposes for which it was not intended. In the Knowledge Provider, there are two potential security risks:

• URLs may be forged, allowing the forger unauthorized access to data

• The data stream may be “tapped” or forged

The following security mechanisms counteract these risks:

• Secure URLs

• URL Encoding

• Security Mechanisms Against Data Loss

• Access Protection for Administration

Secure URLs Protection Against Unauthorized Access to Stored Content To prevent unauthorized access to stored content on the SAP Content Server, the SAP system carries out an authorization check. However, the SAP Content Server is accessed by means of the open SAP Content Server interface (see also SAP Content Server HTTP 4.5 Interface). URLs must be secure so that they allow only authorized access to stored content and, correspondingly, so that forged requests are rejected. To make a URL secure, it is given a characteristic (like a watermark on a banknote) which allows the receiver to detect whether or not the URL has been tampered with (like if the watermark is missing from a banknote).

In the case of a Content Server URL, the characteristic in question is the signature. The signature is an encoded copy of the URL itself and is transferred to the content server as part of the URL. A signed URL contains the additional parameters expiration (see also Parameters and Keywords) and secKey (digital signature). A signed URL is only valid if the expiration time has not been exceeded and if it contains a valid signature.

The content server decodes the signature and compares it with the URL it received. The content server only executes the request if the URL and the signature match. If an intruder changes the plaintext in the URL, the signature will not match the URL. The content server will accordingly reject the request.

The signature is based on the RSA procedure and MD5 hashing. The RSA procedure is also known as the public key procedure. This procedure is based on a private and a public key. You need the private key to create the signature. You need the public key to check the validity of the signature. For a description of the technical details of this procedure, see the documentation on Secure Store & Forward / Digital Signatures (BC-SEC-SSF).

As the main partner in the three-way relationship of client – SAP system – content server, the SAP system is the only partner that may send request URLs to the client. Because of this, the SAP system has to create the URL signature using a private key.

The public key of the SAP system must be stored on the content server, and the relevant repository must have access to it (see also Content Repositories). Transactions OAHT, OAC0 (from release 4.6C) and CSADMIN (from release 4.6C for SAP Content Server, see also Content Server and Cache Server Administration) are used to transfer the certificate. The certificate has to be activated on the content server for the repository in question. This is done using transaction CSADMIN (for SAP Content Server).

Every SAP system must have its own unique certificate, so that the SAP system’s digital signature can be used properly.

See the section Creating a System-Specific Certificate for Content Server Access.



Protection Against Tapping and Forging of the Data Stream Data transfer must also be encoded, so that a potential intruder cannot access the data while it is in transit between client and server. Standard procedures exist for this, such as secure HTTP (HTTPS). HTTPS encoding is usually implemented between the client and the server and is not part of the SAP HTTP Content Server interface.

Signed URLs can slow down performance, as it takes increased processing power to create the signature.

Security Mechanisms Against Data Loss SAP Content Server is based on the SAP DB (see also SAP Content Server). To avoid data loss, take the usual measures against data loss in databases. These measures could include the following:

• Redundant hardware

Mirror disks, RAID systems, and so on

• Regular standard security measures

Log files, backups

Note when making a backup that in addition to the database, the file ContentServer.ini and the directory Security must also be backed up. See also note 319332 (Content Server Backup Strategies).



Creating a System-Specific Certificate for Content Server Access Use To ensure that every SAP system has its own certificate (system-specific certificate), a Personal Security Environment (PSE) (see also the documentation on Personal Security Environment) must be created on every SAP system when it is installed. This only needs to be done once for every system. You set up the PSE in the Trust Manager (transaction STRUST, see also the documentation on the Trust Manager).

As a rule, the SAP system PSE is used to create and verify signed URLs in the SAP system. From SAP Web Application Server release 6.10, you can also use your own PSE.

Two different scenarios are possible here:

• If the SAP system is functioning as a client and is using an external content server as a repository, once you create your own PSE, URLs are from then on signed with your PSE and not with the system PSE. In this case, only private and public key are relevant; the certificate list is irrelevant.

• If the SAP system is functioning as a Content Server and is using HTTP via SAP Web Application Server, the PSE then also has the effect that all public keys needed for checking signatures are stored in the certificate list.

Content Server Administration is used for the checking process itself (see also Content Server and Cache Server Administration). This takes place in transaction CSADMIN, on the tab page Certificates.

Carry out the procedure described below for creating a certificate for Content Server access before creating repositories.

If you do this after you create repositories, you will have to re-send the certificates to all HTTP repositories and reactivate all the certificates. This is because the certificate changes when you create a new PSE.

If you are accessing the database via HTTP (see also HTTP Access for Repositories on the SAP Web Application Server), you also have to redistribute and reactivate the certificates.

Procedure Take the following steps to create your own PSE:

1. Call transaction STRUST.

The Trust Manager opens.

2. Choose Applications.

3. Choose New Entries.

4. Use F4 Help to select HTTP Content Server and confirm this by choosing Enter.

Additional fields for application-specific Secure Store & Forward (SSF) parameters and standard values for empty fields are grayed out.

5. Make the following entries:

a. In the field Security/Product, enter SAPSECULIB.

b. In the field SSF Format, choose International standard PKCS#7.

c. In the field Priv. add. book, enter SAPHTTPCS.pse.

d. In the field SSF profile, also enter SAPHTTPCS.pse.



e. In the field SSF ProfileID, enter CN=<Common name>,OU=<OrganizationUnit>,O=<Organization>,C=<Country>.

For example: CN=BCECS,OU=DEV,O=SAP-AG,C=DE

f. Check Distribute PSE (Only SAPSECULIB).

6. Save your entries.

7. Call transaction STRUST again.

8. Select HTTP Content Server.

9. Choose Replace from the context menu.

10. Confirm this at the confirmation prompt.

11. Confirm your entries by choosing in the next popup (Replace PSE).

Example The HTTP Content Server PSE links to a system-specific PSE. This means that you can specify that you no longer want to use a specific certificate, for example. In this case, you have to open Content Server Administration and delete the certificate in all repositories. You also have to delete it from the certificate list.

Access Protection for Administration Administration for the SAP Content Server is carried out partly inside the SAP system (see Content Server and Cache Server Administration), and partly outside (see the Reference Manual: SAPDB 7.2 and 7.3). Note the following security considerations in relation to administration on the Content Server:

• Make sure that only authorized persons have (administrative) access to the computer on which the SAP Content Server is running.

• Make sure that (administrative) access to the database is appropriately restricted.

To ensure that only authorized persons have administrative access to the SAP Content Server from the SAP system, you need to set the parameter AdminSecurity in the file ContentServer.ini on the SAP Content Server to 1: AdminSecurity=1. For more information, see the section CSADMIN, and the installation documentation SAP Content Server Installation Guide.

Logical Repository Purpose In the Knowledge Provider, different repositories can be used to store document content, depending on the client in question. This type of repository is known as a client-specific repository. Client-specific repositories allow content to be separated according to client, including when external content servers are used.

The benefits of client-specific HTTP repositories are as follows:

• Client-specific repositories allow content to be separated according to client, including in cases where external content servers are used. This is particularly useful for application service provider enterprises, and in cases where live and test clients and running in parallel.

• Client-specific repositories also greatly simplify the administration of your system landscape.

Features Previously, client-specific content storage was only possible in the Online Transaction Processing (OLTP) database. The functionality has been introduced to Knowledge Provider in response to customer demand, especially from Application Service Providers.



The concept of the logical repository is central to implementing client-specific repositories. It is the logical repository that makes it possible to access different physical repositories by means of the client and the system ID.

Logical repositories are maintained in transaction OAC0.

You define the logical repository along with the content repository in the SAP system. A definition template is used to map the logical repository to a physical repository.

The definition template can contain the following values:

<CLIENT> Client

<SYSID> System ID

<CLIENT>Variable 2:

Contentrepositories

<SYSID>_<CLIENT>

Definition template: <SYSID>_<CLIENT>

Logicalrepository

<SYSID>Variable 1:

Dn

D01 D01_<CLIENT>

Dn_<CLIENT>

Contentrepositories D01_001

001

n

001

n

Dn_001

Dn_n

D01_n

These variables are replaced by concrete values during the actual mapping process.

Example • In client 001 of the SAP system ABC, the definition template <SYSID>_CONTENT_<CLIENT> is

mapped to the physical repository ABC_CONTENT_001.

• In client 002 of the same system (ABC), the definition template is mapped to the physical repository ABC_CONTENT_002.

• In client 001 of the SAP system DEF, the same definition template is mapped to DEF_CONTENT_001.

• In client 003 of system DEF, the same definition template is mapped to DEF_CONTENT_003.



Physical repository

ABC_CONTENT_001

Client 001Physical repository

ABC_CONTENT_002

Client 002

Logical Repository

Physical repository

DEF_CONTENT_001

Client 001

SYSID: ABCCLIENT: 001

SYSID: DEFCLIENT: 001

Physical repository

DEF_CONTENT_003

Client 003

Definition template <SYSID>_CONTENT_<CLIENT>

SYSID: ABCCLIENT: 002

SYSID: DEFCLIENT: 003

You can now use the SYSID to centrally administrate the assignment of repositories in several SAP systems and to distribute the assignments to other systems. The various systems can then use different repositories.

Other Notes Ideally, you need an SAP system of release 6.10, or at least 4.6C. Any required modifications are provided by means of Support Packages.



Knowledge Provider and Caching A cache is used to store copies of documents when they are accessed for the first time. As a result, the documents can be accessed again more quickly, since the contents are taken directly from the cache. Caching, however, must not be confused with replication (see below). With caching, the original documents are stored in one location, namely on the content server. The copies in the cache can be replaced with newer content at any time.

Documents are checked in in Walldorf. An employee in South Africa wants to access and display these documents. The transmission time, however, is extremely long and the intercontinental network connections would be overloaded. By using cache servers, the documents are only copied over the connection once.

The Knowledge Provider’s Content Management Service provides two types of caching:

• Cache Servers

Caching on special servers

• Client cache

Caching at the user's front end

Caching is not the same as replication. - The original document is still located on the content server.

- The content server can retrieve the cache content at any time.

- Only documents that are specifically requested (and therefore genuinely needed) are transferred.

Front-End Cache in the SAPGUI The client cache is used by the data provider to cache documents that are read from an HTTP content server or from the SAP system.

This type of caching is extremely fast. However, each user must fill his or her own cache and resources are used at each front end.

The caching settings can be defined in the GUI options. Choose the Local Data tab and specify the directory to be used for caching as well as the maximum size of the cache files.

Cache Servers The cache server is used to cache special content server requests. Remote accesses are cached and executed locally.

This type of caching is ideal for scenarios in which many different users have joint access to the cache. The documents only have to be sent once across the wide area network.

See also: Cache Server



Cache Server Purpose The purpose of the Cache Server is to provide the following benefits:

• Seamless, transparent integration into existing content server landscapes

• Significant reduction in client response times

• As little administration work as possible

Cache servers are used to speed up access to document content. This is particularly useful if the content is required for display in a Web browser, for example. Cache servers can also reduce the network load and thereby enhance performance. It is therefore also a task of the cache to provide the client with documents from a physically close location, even if the content server is located on a different continent.

Caches are used in many areas. For example, MS Internet Explorer uses a local cache on the user's hard disk.

Cache servers are similar to content servers, but require less administration with the same level of access protection.

The Cache Server only uses HTTP. To make this possible, SAP Content Server HTTP Interface has been extended (see SAP Content Server HTTP 4.5 Interface). By using cache servers, you are simply extending your existing infrastructure in a transparent way. There is no need to re-structure the existing content server landscape.

Implementation Considerations The cache server is installed from the SAP Server Components2 CD-ROM as part of the installation of the SAP Content Server. Installation instructions in PDF format are provided in both English and German on this CD-ROM, in the directory \CONTSERV\DOCU.



Architecture of the Cache Server Despite their similar architecture, the Cache Server and the Content Server have some basic differences. The cache server can set up its own HTTP connections to other servers and can forward incoming client requests. The “other servers” can be content servers or other cache servers. If the server in question is another cache server, this architecture is known as cascaded or multi-layer caching (see also Cascaded Caching).

Cache Server Architektur II

Cac

he S

erve

r

... ... ... ... ...

Client Client

... ... ... ... ...

Client Client

Persistenzschicht

SAP DB ODBC Driver


Cache Server Engine

MS Internet Information Server 4.0 / ISAPI

SAP Content Server HTTP 4.5 Schnittstelle

SAP DB Kernel

Certificate Pool

SAP Security

HTTP-Client

Persistence layer

SAP DB ODBC Driver


Cache Server Engine

MS Internet Information Server 4.0 / ISAPI

SAP Content Server HTTP 4.5 Interface

SAP DB Kernel

Certificate Pool

SAP Security

HTTP-client

Content Server

Content Server

...

Content Server

Content Server

CacheServerCacheServerCache

ServerCacheServerCache

ServerCacheServer

SAP Cache Server

A notable feature of the cache is its almost complete freedom in terms of administration. As soon as the cache is integrated into the server topology, it can start performing its services without the need for log monitoring or backups.

Caches are always used for read access to documents. “Lazy write” is not supported. In other words, a client that wants to store documents must always be directly connected to the corresponding cache server.

As already described (see Content Management Service), SAP HTTP Content Server interface supports signed URLs. Cache URLs can of course alse be signed. However, it would be very inconvenient if the cache had to rely on the Content Server to carry out signature checks every time. It therefore makes sense for the cache to check the signatures itself. To this end, the cache contains all the necessary SAP certificates, or else it gets them from the appropriate content server.

The Cache Server has the same security mechanisms as the Content Server.



Deletion Strategy and Performance Deletion A characteristic of cache servers is the pre-set limit on the amount of memory available for storing objects. Unlike the content server, this memory space does not “grow” (but the size of the cache can of course be increased at any time).

If the cache server fills up to the level where it does not have enough space to store the next object, it starts deleting “old” objects from the memory. To facilitate this, the cache carries out a statistical analysis of accesses to cached objects. It then deletes the documents that have been unaccessed the longest, until there is enough space in the memory to store the current document. This method is also called the least recently used (LRU) mechanism.

Performance Considerations SAP’s own analyses have shown that the cache provides a consistent, significant advantage in terms of speed, taking into account both the frequency and size of requests. In the diagram below, this is shown in the comparison of the response times of the cache server and the content server. From the diagram, it is clear that both curves run parallel, regardless of the request size, and that the response times of the content server exceed those of the cache server by a factor of 10. This result is, of course, independent of the bandwidth available to the content server. For example, SAP has a high-bandwidth connection between Walldorf and Palo Alto. In a customer environment, much higher improvements on speed can be expected.

The relationship between cache hits and cache misses is an essential criteria in cache efficiency. When the hit rate is near 100%, cache performance is at optimum level. If the misses are in the majority, or if misses make up 20-30% of the total number of requests, you should consider taking performance optimization measures.



What causes a sharp increase in cache misses?

• An almost full cache

• A large number of widely dispersed requests; that is, documents that are not located in the cache are being constantly requested

Both factors cause the cache to behave in the following ways.

Stored documents are deleted to make way for new objects. The lack of space in the cache and the non-homogenous nature of the requests means that deletion continually takes place. In extreme cases, the cache content is in a constant state of flux (also known as “thrashing”). This greatly degrades cache performance.

The only solution to this problem is to extend the cache space, so that the maximum occupancy of the cache can be maintained at 75%. Backbone caches are particularly susceptible to thrashing, as these serve as concentrators for other caches.

Optimal Access Path for Client Requests The SAP system knows the locations of the content server, cache server, and client attached to it. This knowledge enables it to establish an optimal content access path.

The cache is selected as follows:

1. The SAP system establishes the location of the client.

2. The SAP system then establishes the location of the content server.

3. If the client and the content server are at the same location, no caching is necessary and the requested URL can be retrieved directly from the content server. In other words, the content is displayed directly from the content server. If the client and content server are not at the same location, the SAP system finds out the identity of the cache server at the client location.

4. If no cache server is available, the URLs are displayed on the client directly from the content server. If one or more cache servers are available, one of these is selected to display the content.

Customizing for Caching In order to use caching, you need to take the following basic Customizing steps:

• Define the caches

− Host name and locations (transaction SCMSHO)

− Define the cache (transaction SCMSCA)

• Define locations for the following:

− Users (clients), using the following:

• Set/get parameter LCA

• Host name (transaction SCMSHO)

• Subnet (transaction SCMSIP)

SAP recommends that you use sub-nets when defining locations for users.



− Content server, using the following:

• Host name (transaction SCMSHO)

SAP recommends that you use use host names when defining locations for Content Server.

• Subnet (transaction SCMSIP)

Information on these activities is provided in the Implementation Guide (IMG) under SAP Web Application Server → Basis Services → Knowledge Provider → Distribution.

Cascaded Caching Cascaded caching can be used from release 4.6B and from Knowledge Warehouse release 451A. Cascaded caching is also known as multi-layer caching.

Previously, Knowledge Provider’s Content Management Service provided a simple caching concept. With this system, once content was accessed, it was stored in a cache in the same location as the content server. In other words, the Cache Server retrieved the content directly from the Content Server.

The development of the caching concept to include cascaded caching is of most benefit in large, distributed systems. In such scenarios, a cache server can also get content from another cache server.

When multi-layer caching is used, the path from the location of the client to the location of the content server is established. There can be cache servers both at the client location and the content server location. This allows a cache server at the client location to get a requested document from the cache server at the content server location.

Multi-layer caching is intended to optimize access times. This has the added advantage that URLs can be processed by the content server aliases, so that requests coming in via firewall proxies can be forwarded to their destinations as directly as possible.

The Customizing steps you need to implement are explained in the Implementation Guide (IMG) under SAP Web Application Server → Knowledge Provider → Distribution → Define Location Path for Multi-Layer Caching.

See also: Distribution

Content Server Alias

Constraints Cache server and content server aliases are only used if the client location is known when the URL is being contructed. The client location is known if the Knowledge Provider itself requested the URL. If, on the other hand, the URL was requested by another application, and the Knowledge Provider does not know where the URL is going to be used, the system cannot find out the location of the client. In this case, the URL that points directly to the content server is always returned. The cache server and content server alias are not taken into account.

Content Server Aliases Content server aliases can be used from release 4.6B and from Knowledge Warehouse 4.5.

Before release 6.10, the URL for accessing a content server is set independently of the client location. However, in complex environments, especially in connection with firewalls, it may be necessary to involve the client when accessing various servers. For example, a content server can be accessed from several different locations via the same firewall.



A similar situation occurs when a distributed repository system, such as an archive, consists of a number of servers all at different locations, all of which can facilitate access to the entire repository system.

Therefore, when the URL is retrieved, it is possible to change the entries for server, port, and script, independently of the location. For example, the entry for the original server could be replaced by an entry for the content server alias.

A content server alias can be an IP filter on a firewall that forwards the requests unchanged to the content server.

Cascaded Caching and Content Server Aliases You can use caches and content server aliases (see also Content Server Alias) in combination with each other. If you are using a combination, the system first looks for an alias. If the system finds an alias, the technical data of the cache server is used instead of the technical data of the content server. This means that the location of the server has changed. This information is then taken into account when the cache server is being located.

For details of the required Customizing steps and a description of the individual activities, see the Implementation Guide (IMG) under the following path:

• SAP Web Application Server → Basis Services → Knowledge Provider → Content Management Service → Distribution → Define Content Server Alias

and

• Define Location Path for Multi-Layer Caching

See also: Distribution

Cascaded Caching

Cascaded Caching and Content Server Aliases It is possible to a combination of caches and content server aliases (see also Content Server Alias). If you are using a combination, the system first looks for an alias. If the system finds an alias, the technical data of the cache server is used instead of the technical data of the content server. This means that the location of the server has changed. This information is then taken into account when the cache server is being located.

Constraints Cache server and content server aliases are only used if the client location is known when the URL is being contructed. The client location is known if the Knowledge Provider itself requested the URL. If, on the other hand, the URL was requested by another application, and the Knowledge Provider does not know where the URL is going to be used, the system cannot find out the location of the client. In this case, the URL that points directly to the content server is always returned. The cache server and content server alias are not taken into account.

Cache Preload Use Content that is shipped by SAP in the form of I-files can be imported into a Cache Server or a Content Server.

This function is only useful for applications that support cache preload.



Prerequisites • Your cache server must support preload. This is automatically the case from build 162.

You can find out the build of your Cache Server in transaction CSADMIN (see also Content Server and Cache Server Administration), on the tab page Detail.

• The SAP Gateway and the program SAPKPROTP are available on your Cache Server.

• Your SAP system also contains an RFC destination that links to program SAPKPROTP via the SAP Gateway.

Features For information on features and procedures, see the documentation on the corresponding IMG activity in the Knowledge Provider Implementation Guide (IMG) under SAP Web Application Server → Basis Services → Knowlege Provider → Distribution → Define Cache Preload.

Activities The Customizing steps you need to implement are also detailed in the Knowledge Provider IMG.

Distribution The distribution function defines which content sever is to be used to store the content, whether cache servers are to be used, and where the content and cache servers are located.

Distribution is essentially based on locations. These locations describe the possible locations of a computer (content server, cache server, application server) or user. Locations can be defined for:

• Users

• Content servers

• Cache Servers

• Web servers

In conjunction with author scenarios, locations can also be used to distribute categories.

Distribution is intended for the following situations:

• Reading via distributed cache servers (see Distributed Cache Servers)

• Different locations with different content servers (see Different Content Servers)

A Web server redirect can also be implemented (see Redirecting the Web Server).

You can also use Multi-Layer Caching and Content Server Aliases.

Configuring the Distribution Settings Prerequisites Installing the individual components

The procedures for installing the content server and the cache server are described in the document entitled SAP Content Server Installation Guide on the SAP Server Components CD.



Process Flow The individual steps that are required to implement distributed scenarios in the SAP system and their sequence are shown in the graphic below.

DistributionInstallation

Content server administration / Archive administration

Content repositories

Content categories

IP sub-nets Host

Distribution ofcategories

Web server redirect

Web server fordocument spaces

Web server fordocument classes

Locations

Caches

9 b)

6)

7)

9 a)

1)

9)

2)

8)

3)

5)

4)

The procedure comprises the following steps:

1. Call up the Content Server Administration screen (see the section on Content Server Administration for general information and the section on Content and Cache Server Administration for detailed information). Alternatively, call the appropriate program provided by your archive provider. Specify your content server and its port number. On the Create tab page (see also Creating New Content Repositories), create a new content repository on your content server.

2. You now need to make your new repository known to the SAP system. To do so, choose the icon in the Content Server Administration screen for the repository you have just created. This opens the maintenance screen for repositories (see Content Repositories). The system automatically enters the correct values in all of the required fields and copies over the description. Save the data for your new content repository by choosing .

3. Use transaction OACT to maintain the associated category for your repository (see Content Categories).

4. Create a location (see Locations).

5. Maintain the location for IP subnets (see IP Subnets).

6. If necessary, maintain the location for hosts (see Hosts).

7. Maintain the data for the cache servers you want to use (see Caches).



8. If you are using an authoring scenario, you can also define settings for distributing categories (see Distributing Categories).

9. If you want to use different Web servers to display content at different locations, maintain the Web servers for document spaces (see Web Servers for Document Spaces) and for logical document classes (see Web Servers for Document Classes).



Reading via Distributed Cache Servers Purpose The contents on the SAP Content Server can be cached.

To be able to use cache servers, you must define the following Customizing settings:

• Locations must be defined (see Locations)

• The hosts must be defined (see Hosts)

• The caches must be defined (see Caches)

• Set/get parameter LCA (transaction SU3)

If possible, use the other transactions to choose the procedure. Do not choose the procedure using the set/get parameters.

• IP subnets must be defined (see IP Subnets)

Prerequisites A cache server is installaed on your computer (see SAP Content Server Installation Guide).

Process Flow The content server is accessed as follows:

1. The access location (LU = location of user) is determined.

If access is made via the front end, the parameter LCA is evaluated. If no values have been specified for the LCA parameter, the host table is evaluated. If the host table has not been maintained, the IP subnets are evaluated.

With access via the back end, the location of the application server is determined. First, the host table is evaluated. If the host table has not been maintained, the IP subnets are evaluated. If no value is found, the "empty" location is used.

2. The location of the content server (LC) is determined.

First, the host table is evaluated. If the host table has not been maintained, the IP subnets are evaluated.

3. If LU = LC, access is provided directly.

Caching is not carried out.

4. The caches at the location LU are determined from the host table.

5. If one cache is found, access takes place via this cache.

6. If more than one cache is found, the load is automatically distributed among them.



Different Locations with Different Content Servers In the author scenario, for example, the employees in Philadelphia (location PHILADELPH) store their documents on the content servers in Philadelphia, while their colleagues in Tokyo (location TOKYO) store theirs on the content servers in Tokyo.

The locations can be determined from their IP address; that is, they are defined on the basis of subnet masks.

A subnet mask has the following format: XXX.XXX.XXX.XXX/YY

• XXX defines one byte of the IP address in each case (permissible values: 0 to 255).

• YY defines the number of valid bits (permissible values: 0 to 32)

The subnets can be entered in simple notation, for example, the input 155.5 is mapped to 155.5.0.0/16, which contains the IP addresses 155.5.0.0 to 155.5.255.255.

Different locations, therefore, can be defined for different submasks.

In the case of ambiguous definitions (for example, 155.5/16 and 155.5.17/8), the most restrictive definition (here 155.5.17/8) applies to a given IP address (for example, 155.5.17.3).

Redirecting the Web Server Purpose

This function is only relevant when used in conjunction with Knowledge Warehouse systems.

It is possible to redirect the task of displaying content to different locations via a Web server.

The Web server can be specified via the document space or by means of the logical document class. In this case, the logical document class has a higher priority, that is, the Web server defined for the logical document class is used to display the content. If, on the other hand, no Web server is defined for the logical document class, the Web server defined for the document space is used.

To enhance performance, accesses to a Web server can be redirected to a Web server near the client. In order to do so, however, you must define locations (see Locations).

The following are required to redirect the Web sever:

• Locations must be defined (see Locations)

• The subnets must be defined (see IP Subnets)

• The host locations must be defined (see Hosts)

• The Web server must be defined for logical document classes (see Web Servers for Document Classes)

• The Web server must be defined for document spaces (see Web Servers for Document Spaces)



Process Flow On the original Web server, the IP address and logical document class are mapped to the new Web server in two steps:

1. The IP address is mapped to the location

This is carried out by means of the subnet definition for locations (see IP Subnets).

2. The location and logical document class are mapped to the Web server

Use the following rules to determine the Web server (the first one with a successful result applies):

a. Is there a special Web server for the given combination of location and logical document class?

b. If this is not the case, is there a standard Web server for the logical document class?

c. If this is not the case, is there a Web server for the logical document class?

d. If this is not the case, is there a special Web server for the relevant combination of location and document space?

e. If this is not the case, is there a standard Web server for the document space?

f. If this is not the case, is there a Web server for the document space?

If points c) or f) apply, the original Web server is used as the redirect Web server, since the original Web server is stored here. If the display request was not sent to the original Web server, the request can thus be redirected to the original Web server.

The system first attempts to determine the Web server using the logical document class before it evaluates the document space. This method is used because the logical document class is more specific. It is usually sufficient to store the Web server with the document space. For this reason, the document class is only evaluated if no values have been specified for the document space.

Overview of Transactions The following sections provide an overview of the most important maintenance transactions in the SAP system for maintaining the Content Management Service and distribution functions.

Locations

Transaction Code Name in the SAP System IMG Activity

OALO Locations as a distribution criterion

Defining Locations

You use the location concept in the Knowledge Provider to define the general locations in your network. You can use the default content server for checking in content if you like. Alternatively, the system can be set up in such a way that the content server that is most convenient for the location in question is automatically used.

If you do not define any locations, the default content server is used.



IP Subnets


SCMSIP Locations of IP subnets Defining Locations of IP Subnets

You also define general locations for IP sub-nets. All content in the respective sub-net is mapped to a location. A sub-net comprises the IP address and the number of valid bits.

This transaction can be used as an alternative to maintaining the hosts (see Hosts).

155.56.72.62/32

Hosts


SCMSHO Hosts and properties Defining Hosts and Properties

IP subnet locations (see IP Subnets) can be specified using the maintenance functions for hosts and properties.

If you are using cache servers and Web servers, you must maintain the relevant hosts.

If you are using content servers, SAP recommends that you define the hosts using the above transaction. However, this is not mandatory.

Content Server Administration


CSADMIN Content Server Administration Content Server Administration

The Content Server Administration screen contains both general and detailed information on all the repositories that have been defined for a specific content server. You can administrate and configure your content servers and the associated content repositories. At present, Content Server Administration is only provided for the Content Server and Cache Server provided by SAP.

In change mode, you can create new content repositories using the Create tab.

For further information see Content and Cache Server Administration.



Content Repositories


OAC0 Content Repositories Defining Content Repositories

In this transaction you define the content repositories in the SAP system, and thus the storage systems (the content servers) on which documents can be stored.

The fields on the Details and Create tab pages differ, depending on what storage type you choose for your repository. In the field for storage type, you set what kind of physical storage medium you want for your repository:

• Storage type HTTP Content Server

Choose this setting if you want to store your content on a HTTP content server, for example, the SAP Content Server, or third-party HTTP content servers.

• SAP database

Choose this setting if you want to store your content directly into the SAP database. See below for more information.

• RFC archive

Choose this setting if you want to store documents in an SAP ArchiveLink or Archive Development Kit (ADK) environment, or in an application that uses SAP ArchiveLink (see also the documentation on SAP ArchiveLink – Application Scenarios) or ADK (see also the documentation on Archiving Application Data).

• Structure storage system

Usually, you do not need to make any settings here. The structure repository is only used in the SAP Knowledge Warehouse environment.

You can opt for simple or full administration. The number of fields displayed depends on your selection.

After you have saved your content repository, the time of creation, the creator’s user name, and the creator’s real name are automatically inserted. If you have made changes to an existing repository, details about the changes are also inserted. The time is set in accordance with the time zone specified in the user settings.

HTTP Content Server To store content in a content server, choose HTTP Content Server in transaction OAC0 for your content repository. A prerequisite for this is that you have defined your content repository using CSADMIN (see also Content Server and Cache Server Administration). You can go directly from OAC0

to CSADMIN by choosing .

You can also send certificates here. To do this, choose . You need to send certificates to be able to work with signed URLs. After the certificate has been sent to the content server, it must be activated on the content server before you can work with the server and store documents.

You can also carry out a connection test ( ) and call status information ( ). The status information then appears on the lower half of the screen.

Besides the version number, you also need to know the host name of the HTTP server where your repository is. You also need the port number, the SSL port number if applicable, and the HTTP script.



You specify all this information in the simple administration function for HTTP content server repositories in transaction OAC0.

Example of a HTTP content server repository in OAC0:

HTTP Content Server Repository

Simple Administration

Repository name: myCSRepository

Description: Test repository

Document space:

Storage medium: HTTP content server

SSL port number:

Version number: 0046

HTTP script: ContentServer/ContentServer.dll

Port number: 1090

Usually, the simple administration function is sufficient.

However, you may need the full administration function in the following situations:

• You want to switch off the signature for test purposes.

• You want to make different entries for the basic path and the archive path.

The flag no signature is deactivated by default; in other words, the signature is activated by default. This option controls the availability of the functions for checking and creating signatures.

R/3 Database Repositories To store content in an R/3 database, choose R/3 Database in transaction OAC0 for your content repository. When selecting this storage medium, you can specify for the sub-storage medium whether you want to store the actual document content or URLs. After specifying the version number, you also need a content table (client-specific or cross-client), that is, a table in which your documents are stored in the database. The structure of the content table should correspond to the table SDOKCONT1. The field CLUSTID, however, can be larger than the corresponding CLUSTID field in SDOKCONT1. Also, the client may be available (for example, in table BDS_CONT1). This is all the information you need to set in the simple administration function for R/3 database repositories in transaction OAC0.



Example of an R/3 database in OAC0:

R/3 Database Repository

Simple Administration

Repository name: myRepository

Description: Test repository

Document space:

Storage medium: R/3 database Sub-storage medium: R/3 database

Version number: 0046

Content table: test_cont1

As before, simple administration is usually sufficient here.

You only need to use full administration in special cases, such as the following:

• You want to switch off the signature for test purposes.

• You want to make different entries for the basic path and the archive path.

The flag no signature is deactivated by default; in other words, the signature is activated by default. This option controls the availability of the functions for checking and creating signatures.

Content Categories


OACT Maintain categories Defining Content Categories

This transaction allows you to change content categories for physical documents, and to create new ones.

Content categories identify logical storage locations. On the physical level, each content category is assigned to a content repository (see also Content Repositories). You specify the physical storage location for documents by specifying content repositories.

SAP provides at least one content category for individual applications. You can also create your own additional content categories.



Once your system has gone live, you should generally not make any changes to existing entries. This is because a document is identified by its ID and the category. Categories are mapped to the corresponding content repositories at runtime. If any changes are made after this point, the mapping is no longer valid and existing documents may no longer be accessible.

However, changes may sometimes be necessary; for example, if a repository or a content server is transferred in its entirety to a different computer.

When a document is created, the system always evaluates the category that is initially specified. If no category is specified when a document is created, the class default is used. If no class default is available, the previous version is used.

When the document is checked in, the data defined as part of the distribution is evaluated.

Caches Transaction Code Name in the SAP System IMG Activity

SCMSCA Caches Defining Caches

You use this transaction to announce the existence of caches to the SAP system.

You can temporarily remove components from service by setting the Inactive flag in the detailed view.

Distributing Categories


OADI Distributing Categories Defining the Distribution of Categories

In this step, you specify that when documents are checked in from the front end, a category other than the standard category is used as a repository. This process is location-dependent (see Locations).

Specify both the original category (logical category) and the new category (derived category) for your location.

If a derived category occurs more than once, the associated logical category must always have the same name. This enables you to group the derived category with the original category when they are transported (for example, to the consolidation system).

A category must only ever be used either as a logical category or as a derived category, not as both at the same time.



Web Servers for Document Spaces


Transaction Code Name in the SAP System

SKPR14 Web Servers for Document Spaces

You can use this transaction to define one or more Web servers for a document space. A certain location is specified for each host (see Locations).

Specify the name of the Web server by entering the associated HTTP port and (if necessary) the HTTPS port. Specify the HTTPS port if the Web server will be accessed via HTTPS.

The Web server to be used for displaying content is usually selected via the location defined for the Web server. If there is no Web server at the required location, however, the Web server designated as the default Web server is used.

You can create several entries with different host names for the same document management area. This ensures that the load is distributed.

Web Servers for Document Classes


Transaction Code Name in the SAP System

SKPR15 Web Servers for Document Classes

You can use this transaction to define one or more Web servers for a logical document class. A certain location is specified for each host (see Locations).

Specify the name of the Web server by entering the associated HTTP port and (if necessary) the HTTPS port. Specify the HTTPS port if the Web server will be accessed via HTTPS.

The Web server to be used for displaying content is usually selected via the location defined for the Web server. If there is no Web server at the required location, however, the Web server designated as the default Web server is used.

You can create several entries with different host names for the same document class. This ensures that the load is distributed.



Content Server and Cache Server Administration Use SAP provides a standard content server, the SAP Content Server. This SAP Content Server can be administrated directly from the SAP system.

Special tools tailored to the SAP DB are provided for monitoring and administrating the underlying SAP DB.

Use transaction CSADMIN to go to the Content Server and Cache Server Administration screen.

Access restrictions or permissions for the ini file of the Content Server can be set during the installation routine (see installation instructions in SAP Content Server Installation Guide on the SAP Server Components2 CD). The AdminSecurity=1 variable must be set in the ini file. In this case, a password is requested when the user branches to the Content Server Administration screen, as well as in individual areas of the CSADMIN transaction. You do not have to repeat the password until you launch Content Server Administration again.

Features You can display the following information in the Administration screen:

• General information on the Content Server and Cache Server

• Detailed information on the individual content repositories and cache servers

• Certificates of the individual content repositories

• Settings of the individual content repositories

• Content server and cache server statistics

• Create individual content repositories

The Create tab is only visible if you are in change mode.

As of Release 4.6C, you can also go to the Customizing from every screen concerned with a particular content repository. If you do this from change mode, the current values (HTTP server, port number, HTTP script, version number, and description) are copied automatically.

To display this information and use these functions, you must first select a content server.



Choosing a Server Use In the Content Server Administration screens, you select a content server in order to obtain information on this content server or the associated content repositories, and to use the Content Server Administration functions. You can also call up information on a cache server.

You can administrate a different server in Content Server Administration by choosing the

icon.

Prerequisites • Content Server Administration is open.

Or:

• Go to Content Server Administration using transaction CSADMIN.

Procedure 1. Choose a content server or a cache server.

a. The first time you call up Content Server Administration, the content server selection screen is displayed automatically.

b. If you are already in Content Server Administration, you can choose a server by choosing .

2. The following options are available for calling up the administration functions for a content server:

a. On the Repository tab, enter the name of the content repository that you defined under Maintain Content Repositories.

Choose F4 to display a list of options.

b. Alternatively, make the appropriate entries in the HTTP Server, Port number, HTTP script, and Versions no. fields on the Server tab.

Choose F4 to display a list of options.

If you do not make an entry in the field HTTP script, the default setting ContentServer/ContentServer.dll is used.

3. Choose Enter to confirm your entries.

Result The details of the HTTP server, port number, HTTP script, and version appear in the header of the Content Server Administration screen.



Functions

Overview Information Use The Overview tab contains general information on your content server or cache server.

Prerequisites The Content Server Administration screen is open.

Features The Overview tab page contains the following information:

• Information on the content server or cache server itself

− Status

Possible statuses: running, defined, stopped, error

− Status description

Explanation of the status

− Manufacturer

Manufacturer of the content server or cache server

− Version

Version of content server or cache server

− Build

Build of storage system

− pVersion

Version of the SAP HTTP Content Server Interface

− Server date

Current date

− Server time

Current time on content server or cache server

− Start date

Date on which the content server or cache server was started

− Start time

Time at which the content server or cache server was started

All times are specified in UTC.

• Information on the content repositories of the content server

− Repository name

− Customizing

Information on whether the repository is known to the SAP system in the Customizing and whether the Customizing is consistent. Here, the system checks whether the HTTP server,



port number, HTTP script, and version number match and whether the data entered manually or with the F4 Help matches the Customizing data.

The following options are available:

Icon Description Explanation

Customizing ok Customizing is consistent

Customizing partially ok There are minor differences between the data in the Administration screen and Customizing, such as upper-case and lower-case letters.

Customizing missing No Customizing settings have been maintained for the repository

Customizing differences The data in the Administration screen differs from the Customizing data.

The Customizing information is shown on all the screens that refer to repositories.

− Description

Description of the content repository

− Status

Possible statuses: running, defined, stopped, error

− Status description

− pVersion

Version of the SAP HTTP Content Server Interface

− Further content server-specific settings

In addition to the information described here, other content server-specific values can be output.

Double-click on a Content Repository to see detailed information.

Activities You can update the information on the respective server by clicking the Refresh icon.

Details Use The Details tab contains detailed information on the content repositories of the content server.


Features The following functions are available:

• You can switch to the detailed information screen of a different content repository



• You can go to the Customizing (transaction OAC0) of every repository simply by choosing .

If you are currently in change mode, the change mode of OAC0 opens. Similarly, if you are currently in display mode, the display mode of OAC0 opens.

• You can refresh the detailed information screen

• In change mode, you can do the following:

− Change the description of the content repository

− Go directly to the maintenance screen for the Customizing settings for a repository

The current values for HTTP server - port number, HTTP script, version number, and description (if any) - are copied over automatically.

− Activate/deactivate the digital signature check

− Start the content repository, that is, change its status from defined to running

− Stop the content repository, that is, change its status from running to defined

− Delete the content repository

Activities You can execute the above functions by choosing the relevant icons.

Certificates Use The Certificates tab page contains information on the certificates sent to the Content Server.



• You can display information on the certificates of a different content repository.

• You can go to the Customizing (transaction OAC0) of every repository simply by choosing (see below).

• You can update (refresh) the certificate information.

• You can send certificates.


− Activate the certificates

− Deactivate the certificates

− Delete a sent certificate

− Go directly to the definition screen for the Customizing settings for a repository





Settings Use The Settings tab contains information on the settings for your content repositories.



• You can display information on the settings of a different content repository

• To go to the Customizing, choose .

• You can refresh the settings information

• You can display and edit the settings that apply to all content repositories.

To do so, choose the All repositories entry in the F4 Help for the Content Rep. field.

This function is available as of SAP system release 4.6D.


− Change and save the settings for the content repository, or delete individual settings

These entries are content-server specific.

Changes to the settings might not take effect until you restart the content repository.

− Go directly to the maintenance screen for the Customizing settings for a repository.


Activities

Generally, you should not make any changes here. The options provided in the Details tab are sufficient for any changes that are required in standard operation.

You can execute the above functions by choosing the relevant icons.

Statistics Use The Statistics tab provides statistical information from the content server on the individual HTTP commands.



• You can update the information read from the content server by choosing Refresh.



• You can delete the information in change mode.

In this case, a request to reset the statistics is sent to the content server.


Creating New Content Repositories Use On the tab page Create, you can create new content repositories.

Prerequisites You are in change mode in Content Server Administration.

Features When creating a new content repository, you can use an already existing one as a model.

When carrying out a standard installation of SAP Content Server, you can transfer the values from the Table control.

Activities 1. Enter a name for the new content repository.

If you are using an existing repository as a model, choose and the system automatically fills in the subsequent fields.

2. Enter a short description.

3. Set whether or not digital signatures should be checked.

4. Change the entries for content storage host, and so on, as required.

5. Save your entries.

6. You now have two options:

a. If the creation process is successful, the detailed view (tab page Detail) opens automatically. The content repository should have the status Running.

b. If the creation process is unsuccessful, check the settings and correct them if required (tab page Settings). Then try to create the repository again.

7. Make your content repository known to the SAP system. To do this, go to the Customizing by choosing . For further information on Customizing, see Content Repositories.



Content Server and Cache Server Monitoring Use The HTTP Content Server is monitored automatically as part of the Computer Center Management System (CCMS). For further information on the CCMS, see the documentation on Monitoring in the CCMS and Alert Monitor.

All repositories defined in Customizing are monitored, along with their associated content servers. A monitoring function for Web servers and cache servers recognized by Customizing is also provided.

The Knowledge Provider Web Server is only used within the framework of SAP Knowledge Warehouse. It is used for displaying content on the client. For example, a client wants to display a specific instance of a logical document. To do so, it sends the information on the logical document and its attributes (for example, logon language, release) via RFC to an SAP system. The SAP system returns the corresponding physical document via RFC to the client, which then displays it using the Knowledge Provider Web Server.

To go from the CCMS (transaction RZ20) to the monitoring screen for the Content Server and Cache Server, choose SAP CCMS Monitors for Optional Components. Then choose the monitor for Knowledge Provider.

Alternatively, call up transaction SCMSMO directly.

Features You can call up the following information in the monitoring function:

• Information on the SAP Content Server and HTTP Content Server and their repositories.

Prerequisite: the repositories are defined in Customizing (see OAC0).

• Information on the Cache Server.

Prerequisite: the Cache Servers are defined in Customizing (see SCMSCA).

• Information on the Knowledge Provider Web Server.

Prerequisite: Customizing recognizes the Web servers. The Web servers are stored either with the classes (see Web Servers for Document Classes) or with the document spaces (see Web Servers for Document Spaces).



Content Server

Cache Server

Knowledge Provider Web Server

Server 1

Server 2

Server n

Statistical information

Content repository A

Content repository B

Content repository X

Knowledge Provider Monitoring

...

...

...

...

General information

Monitoring has the following functions:

• Troubleshooting

• Configuration overview

This function provides information on, for example, which SAP system the Web server is connected to, which message server is being used, details of the last access attempt on the server, and so on.

You can switch between Open Alerts and Current Status modes. If you are in Open Alerts mode, you can display and complete (that is, process) alerts.

If you are in Current Status mode, you can also go directly from the monitoring function for Content and Cache Servers to the administration function for Content and Cache Servers (see Administration). To do so, double-click on the name of the required server or repository.

Information on monitoring in the CCMS is available in English only.



Monitoring for Content Server Use SAP Content Server and HTTP Content Server have an automatic monitoring function. The monitoring function (usually simply referred to as “monitoring”) provides information on all defined content repositories.

Prerequisites • The Knowledge Provider monitoring function is currently open on your computer.

• The Customizing recognizes the content server repositories (see also OAC0).

Features The following graphic shows an overview of the information provided by the monitoring function:

Content Server

Server 1

Server 2

Server n


Content repository A

Content repository B

Content repository X

...

...

...

...

Number of requestsNumber of program errorsNumber of internal errors...Number of imported bytesNumber of exported bytes

Performance valuesRequests with errors

General information

ManufacturerStatus...

The monitor also outputs data for content servers of SAP partners, although this data is usually less comprehensive than that provided for the SAP Content Server.



Activities For information on the activities of the CCMS monitor, see the documentation Alert Monitor.

You can get detailed information on a particular repository, or an overview of the content server. To do this, double-click on the name of the content server or the repository in Current Status mode. This takes you to the administration screen (see also Content and Cache Server Administration) , which displays the required information.

Note that this only works for the SAP Content Server and its content repositories.



Monitoring for Cache Server Use The cache server has an automatic monitoring function.


• The Customizing recognizes the cache server (see also SCMSCA).


Cache Server

Server 1

Server 2

Server n


......

...

Number of requestsNumber of program errorsNumber of internal errorsAverage number of responses per millisecondNumber of imported bytesNumber of exported bytes...

General information

ManufacturerStatusTypeRequests with errors,

e.g. connection errorsBuildTime last accessedDate last accessedLocation...

Activities For information on the activities of the CCMS monitor, see the documentation on the Alert Monitor.

To go directly to the Administration screen, double-click on the server name (see also Content and Cache Server Administration).

Monitoring with KPro Web Server Use The Knowledge Provider Web Server has an automatic monitoring function.



The Knowledge Provider Web Server is only used within the framework of SAP Knowledge Warehouse.


• The Web servers are stored either with the classes (see Web Servers for Document Classes) or with the document spaces (see Web Servers for Document Spaces).


Knowledge Provider Web Server

Server 1

Server 2

Server n


...

...

...

Server statusServer versionBuildSAP systemAuthorization checks...

General information

ManufacturerStatusTypeRequests with errors,

e.g. connection errorsPerformanceCPU usage...

Activities For information on the activities of the CCMS monitor, see the documentation on the Alert Monitor.



SAP Content Server HTTP 4.5 Interface This section describes the new SAP Content Server HTTP înterface.

Points relevant to the changeover from SAP ArchiveLink to the HTTP Content Server Interface are explained in this documentation as they become relevant.

The aim of the new interface is that only general industry standards, such as HTTP and BAPIs, should be used in communication with external storage systems (content servers).

The HTTP Content Server Interface can be certified.

Also note the references to the cache server (see Cache Server).

Introduction

Definition of Terms For the purposes of this section, a document comprises administrative data and content.

• Administrative data identifies and describes a document.

• The content of a document refers to closed datasets. The administrative data identifies and describes the content. A single closed dataset is known as a content unit.

In SAP terminology, a content server is any server that manages content. A content server may be a database, a file server, an SAP system, or an external archive.

The data administration terms content repository, document header, and component are of particular importance in identifying documents.

• A content repository is the administrative entity that accesses the logical storage space for documents on a content server. Several content repositories can exist on one content server. A content repository is identified by the parameter contRep.

• The document header is an administrative entity comprising several components. It is identified by the parameter docId. A document header is assigned to one particular content repository.

• A component represents, on the administrative level, one particular content unit. It is assigned to one particular document header and is identified by the parameter compId.



The relationship between content repository, document header, component, and content is illustrated in the diagram below:

Document

Content Repository

Document Header

docIddateC

docStatus...

Component

compIdContent-TypecompStatus

...

ContentUnit1 * 1 0..n 1 1

Administration Data Content

It can happen that a document with only one component is created, and this component is later deleted. This results in an ‘empty’ document, that is, a document with no components. In order to avoid possible contradictions in this documentation, we will assume that empty documents and empty components can exist. This may be the case if, for example, a file with the file size 0 bytes is stored.

The combination contRep/docId is the unique address of a document header.

The combination contRep/docId/compId is the unique address of a component.

In certain circumstances, documents have a security level. This means that functions executed on the document must be authenticated. For each document header, you can define whether authorization is necessary for particular functions. However, this information is not defined in the document header for each function of the HTTP Content Server Interface, but via access modes. Access modes are discrete groups of SAP Content Server HTTP interface functions.

The Hypertext Transfer Protocol (HTTP) is the communication protocol typically used to access objects on the Internet. The W3C (World Wide Web Consortium, http://www.w3c.org) is currently further developing this protocol. There are two versions of the HTTP protocol, HTTP/1.1 and HTTP/1.0, and either can be used for the communication process. Request for Comment (RFC) 2068 specifies the protocol HTTP/1.1. HTTP/1.1 contains more specific regulations than HTTP/1.0 (RFC 1945), with the intention of making implementations of the protocol more reliable.

The new HTTP Content Server Interface is designed in such a way that the client SAP system always initiates communication. The content server being addressed by the SAP system is always a server and never a client, which means that it never instigates communication with the SAP system.

Hypertext Markup Language (HTML) is a standard format and description language for Internet pages.

Uniform Resource Locators (URLs, see RFC 2396) are a standardized mechanism used to address uniquely defined objects on the WWW. As well as serving as addresses, URLs can also contain functions and parameters that are interpreted by the object being addressed.

UTC (the common abbreviation for Coordinated Universal Time) is used for all expressions of time in this specification.



The following rules apply to the spelling of functions, parameters and key words in this section:

All terms defined in the Hypertext Transfer Protocol HTTP/1.1 (RFC 2068) are used here (for example, Content-Type). The terminology of the HTTP/1.0 (RFC 1945) protocol is also used. Terms specific to this interface are not capitalized if they consist of one syntactical term (for example, info). A combination of lowercase and uppercase is used if a term consists of more than one syntactical term (for example, contRep).

Implementation The HTTP protocol is used for communication with content servers. Servers and documents are addressed using URLs, and data is transferred in the request body or in the response body.

The URL specifies which function is executed with a document, that is, whether the document is to be transferred from the server to the client (get), whether information about the document is to be included (info), and whether a new document is to be created (create). The necessary parameters for these functions are also part of the URL.

This documentation describes the URL syntax and the semantics for the various functions.

Security General security and secure data transfer are central aspects of the Content Server Interface. It is important to note the following points in relation to the Content Server Interface:

• It is assumed that all required authorization checks in the SAP system have been carried out.

• To ensure that users cannot circumvent these authorization checks when accessing the Content Server, a public/private key procedure (see also the documentation on Public Key Technology) is used.

• Public and private keys are SAP-specific, not user-specific.

The security concept of the Content Server Interface is based around the fact that the SAP system public key is stored on the Content Server. putCert is the command used to put the key onto the server. The Content Server uses the public key to check URLs and signatures (see also putCert).

For further information, see the documentation on Secure Store & Forward / Digital Signatures.

secKey secKey ensures that a URL cannot be changed after it has been generated by the SAP system. This ensures that access to the document is protected and that access protection is managed in the SAP system. The secKey does not protect the document content. The following parameters are always signed (that is, authenticated by means of a digital signature) in secKey:

• contRep Content repository

• accessMode Access Mode

• authId Client ID

• expiration Expiry time (UTC)



authId must be a unique identification of the client (such as the SAP system). The UTC expiry time is written in the format yyyymmddhhmmss. If the expiry time is exceeded, the content server must report HTTP status code 401 to the client.

If a secKey is transferred with the URL, the parameters accessMode, authId and expiration must also be transferred. These parameters need not be transferred if secKey is not transferred.

Also, other parameters have to be signed. These additional parameters depend on the particular function and are specified in the function description. The name of the function itself is not signed. The parameters to be signed can appear in the URL in any order. However, the order in which the parameters are transferred to the signing module must be the same as the order in the URL, so that the signature can be authenticated properly.

The secKey for the chosen procedure is about 500 bytes long.

The parameters to be signed for a particular function are specified in the function definition. They are specified in the last column of the parameter table. Optional parameters can clearly only be signed if they are used. s-mandatory parameters must appear in the URL if a signature is used. They are always signed. If no signature is used, these parameters are not evaluated.

The URL parameters to be signed are referred to in this section as the message. The message is used to determine a hash value. The parameters must be kept in the same order so that the hash value can be calculated. The hash or message digest is a one-way function, that is, it cannot be reversed. Using the sender’s private key, the SAP Secure Store & Forward (SSF) module uses the Digital Signature Standard (DSS) to digitally sign the hash value according to PKCS#. The digital signature is transferred in the URL in the parameter secKey, as described above.

Once the digital signature has been created, the URL parameters are protected and cannot be tampered with. They are not encoded and so any receiver can check them using the sender’s public key. Any changes would therefore be detected. This ensures that an action on the content server can only be started if the URL transferred has not been tampered with.

Using the sender public key, the content server generates the Message Digest again from the transferred URL. Likewise, it then forms a hash from the message (the order of the parameters in the URL is important here) and compares the two hashes (the message hash and the hash generated by the sender). If the two hashes match, the URL has been transferred intact between the SAP system and the content server.

The library for checking signatures can be obtained from SAP AG. Because the standard format PKCS#7 was used for the signature, other products can also be used for decoding.

Summary of Technical Information

• Format of digital signature: PKCS#7 “signed data”

• Public key procedure: DSS

• Key length: 512 – 1024 bits

• Public exponent: 216 + 1

• Public key format: X.509 v3 certificate

• MD (message digest) algorithm: MD5 or RIPEMD-160



Security Level and Access Permissions The security level of a document is specified when the document is created and stored. When a document is accessed, the server establishes what functions a user may execute on this document. Similar functions are grouped together. The groups are called access modes. They are listed in the following table:

Access Mode Abbreviation

Read r

Create c

Change u

Delete d

The security level applies to all components of the document. If the access mode is “change”, any component of a document may be deleted.

The access mode must be specified in the HTTP request as a parameter (accessMode). A combination of access modes can be specified, for example, ud. A secKey confirms the right of access. In the descriptions of individual functions, the corresponding access mode is specified. When a document is accessed, the content server checks whether the secKey should be checked, that is, whether a function of the document is protected, and if so, what security level it has. It therefore makes sense that any user may read documents, while only certain users may change them. In this case, read protection is deactivated (no secKey is required). For write and delete access, however, asecKey must be transferred. The fact that the secKey can only be generated by the SAP system ensures that an access protection check based on the SAP authorization concept is carried out.

The security level of a document is defined when the document is created. To do this, use the parameter docProt.

security level Description docProt= No access restrictions docProt=du Only signed (that is, authenticated) URLs may delete or update

documents. The accessMode must have at least a d for delete operations, and at least a u for update operations. Read operations do not require any signature.

You may transfer a number of access types, for example, accessMode=rd in a read operation. This can be useful in certain situations. For example, if a get URL with accessMode=rd and a corresponding signature is transferred to a client program, the client has not only read permission but also delete permission for the document. To use the URL for deleting, simply replace the get command with the delete command, and do not transfer the compId. The same parameters are signed for both get and delete, so the signature remains valid. Because the accessMode contains a d, then, in this example it is possible to read and delete the document using the same signature.

Based on the access type of an operation and the security level a document has, the Content Server decides whether it has to check the secKey. If the Content Server decides that no check is necessary, all s-mandatory parameters become obsolete. Therefore, it is not necessary to check these parameters.



However, these parameters can be checked, if they are transferred accidentally, for example. However, this does not provide any extra security and is therefore superfluous, especially in the case of operations with no security level, as the absence of an authorization check enhances system performance.

The parameter docProt is optional, but is usually transferred if the URL is not signed. If neither the Content Server nor the SAP system uses a signature, this has no effect on the security level, which is set for documents when they are created. If the parameter docProt is not transferred, the default setting on the server is used. The content server default is set when the system is being implemented, and its value is entirely at the discretion of the system administrator. If the SAP system does transfer the docProt parameter, the system assumes that the maximum security level applies for all access attempts on the relevant documents, and uses corresponding signed URLs.

The signature can be deactivated in the SAP system only if it is also deactivated on the Content Server.

In live systems, however, you should use signatures.

For all access modes, the Content Server must allow the system administrator to set as default whether a secKey must be specified or not. This server default can, however, be overwritten in the URL for the functions create and mCreate. If no security level is specified, the server default is used.

Old data and documents that were stored in the Content Server without the use of the HTTP interface have the highest security level; that is, all access attempts must be authenticated.

Syntax

General The URL syntax is: http://servername:port/script?command&parameters

servername is the name of the server that is accessed, and port (optional) is a TCP/IP port that can be used to address the server. script is the name of the program used to access the content server. This program could be a DLL, a CGI script or an Active Server Page (ASP). The content server provider creates the object. A command must be included in the URL, followed by one or more parameters.

The URL cannot contain any blank spaces.



Server name:port

ScriptCommand

http:// ContentServer/ContentServer.dll?get&

pswdf009:1080/

Parameters

pVersion=0046&contRep=K1&docId=361A524A3ECB5459E0000800099245EC

URL Encoding The structure of URLs is described in RFC 2396. RFC 1738 also specifies which character set may be used for a URL and how characters not in this set should be encoded.

Only characters from an ASCII character set may be used in a URL (0x00 - 0x7F). The characters 0x00 – 0x1F and 0x7F must be encoded. (The characters 0x00 - 0x1F and 0x7F.) If they must appear in the URL, a ‘%’ (percentage sign) followed by the hexadecimal representation of the character should be used.

A line feed (0x0A) is represented as %0A in a URL.

Unsafe Characters ‘Unsafe’ characters must also be encoded in the way described above. These characters are: space, <, >, “, #, %, {, }, |, \, ^, ~, [, ], ` . These characters are considered unsafe either because they execute special functions in the URL, or because they could be interpreted as special characters during transfer.

Reserved Characters There are also ‘reserved’ characters: ;, /, ?, :, @, =, &.

Reserved characters must also be encoded.

Transferring Binary Data Problems can occur if binary data is to be transferred in a URL. This is the case when using the Content Server Interface, since the secKey consists of binary data. The ASCII character set must first be encoded, and Base64 coding is used for this (RFC 1521).

Example 1. Compiling the URL

http://pswdf009:1080/ContentServer/ContentServer.dll?get&pVersion=0046&contRep=K1&docId=361A524A3ECB5459E0000800099245EC&accessMode=r&authId=pawdf054_BCE_26&expiration=19981104091537

2. Generating the secKey

The secKey is made up of the encoded parameters. The parameters to be signed are specified in the function definition.

In this example (get function) the parameters are:



ContRep = K1 DocId = 361A524A3ECB5459E0000800099245EC AccessMode = r AuthId = pawdf054_BCE_26 Expiration = 19981104091537

In the next step, the parameter values are summarized to form a message (without separators), in accordance with the sequence in the URL: K1361A524A3ECB5459E0000800099245ECrpawdf054_BCE_2619981104091537

The message is used to form the hash from which the SecKey is calculated. In this example, arbitrary values are chosen for the secKey, for the sake of clarity.

The secKey has the following values: 0x83, 0x70, 0x21, 0x42.

3. Encoding the secKey in the ASCII character set Base64 must always be used to encode the secKey.

0x83, 0x70, 0x21, 0x42 -> g3AhQg==

4. Encoding the URL in accordance with URL character set limitations

Characters may need to be encoded, as in this example: That is the case in this example:

g3AhQg== -> g3AhQg%3D%3D

The following URL is generated: http://pswdf009:1080/ContentServer/ContentServer.dll?get&pVersion=0045&contRep=K1&docId=361A524A3ECB5459E0000800099245EC&accessMode=r&authId=pawdf054_BCE_26&expiration=19981104091537&secKey=g3AhQg%3D%3D

Code in the Response Body Many of the functions described in this section return information within the response body. If the information is returned in ASCII format, the lines always consist of key/value pairs separated by a semicolon, as follows:

key1="value1";key2="value2";...keyn="value2";CRLF Only printable ASCII characters may be used. If a value contains an inverted comma, this must be entered in addition to the inverted commas already inserted around the value.

Functions This section describes the available functions and their parameters. The effect of each function, its parameters, and an example are given.

• Effect ‘Effect’ describes the executed function. The individual parameters are also explained.

• Default ‘Default’ describes the effect of transferring only the mandatory parameters of a multi-parameter function.

• Access Mode ‘Access mode’ specifies the access mode for the function.

• Client → Server

‘Client → Server’ lists and specifies as optional or mandatory the parameters that are transferred from the client to the server. It is specified whether the parameters are optional or mandatory. ‘s-mandatory’ means that the relevant parameter must only be specified if a secKey is transferred. ‘Client → Server’ also defines the HTTP request type, and the way in which the parameters are to be coded in the URL or the body.

• Example



‘Example’ gives an example of the executed function, using example parameters. Line breaks are included in the examples purely as an aid to legibility. The actual URLs do not contain any line breaks.

• Server → Client

‘Server → Client’ defines the structure of the HTML response. HTML responses are generated by the server and are then sent to the client.

The HTTP status codes specific to the content server are also listed in this section. If no security key is entered, this may cause errors, for example, error 401 (‘unauthorized’). A wrongly addressed document can cause error 404 (‘not found’). If an error occurs, the content server must deliver an ASCII string describing the error. The error must be entered in the header field X-ErrorDescription.

Function Overview

Command Effect Access Mode info Retrieve information about the

document r

get Fetch (within a range) a content unit of a component

r

docGet Fetch the entire content of a document

r

create Create a new document c mCreate Creates a number of new

documents c

append Append data to a content unit u update Modify an existing document u delete Delete a document or a

component d

search Search for a text pattern within a content unit

r

attrSearch Search for one or more attributes within a document (search within a print list)

r

putCert Transfer client (for example, the SAP system) certificate

-

serverInfo Retrieve information about the content server and the corresponding content repositories

-



Access Functions

Function: info • Effect The function info retrieves document information. In response to info, the server sends the document header information and information on all components. If you require information on only one component, specify a compId. If you do so, the command info has the same effect as the command docGet, except that no component data is transferred with info.

resultAs is used to set the format of the information display. Return values can be provided in ASCII format (which means they can be easily parsed), or in an HTML file. The use of resultAs is optional. ascii is the default. The format is explained in more detail below.

If resultAs=ascii, and if the function is executed successfully, the data is transferred as an entity body in multipart/form-data format (see RFC 1867) as a response to an HTTP GET-Request.

• Default Standard information about the document header and the components of the addressed document is returned. The results are given in ASCII format.

• Access Mode Read (r)

• Client → Server The client sends an HTTP-GET-Request. The URL contains the following parameters:

Parameter Optional/Mandatory Default Sign contRep mandatory X docId mandatory X compId optional pVersion mandatory resultAs optional ascii accessMode s-mandatory X authId s-mandatory X expiration s-mandatory X secKey optional

s-mandatory means that this parameter need only be specified if the URL is signed.

• Example http://pswdf009:1080/ContentServer/ContentServer.dll?info&pVersion=0046&contRep=K1&docId=361A524A3ECB5459E0000800099245EC

The example is a request for information about the document. Information about the document header and all its components is requested.



• Server → Client The server answers the request with a response. The response status code indicates the outcome of the call.

HTTP Status Code Meaning

200 (OK) OK, information sent

400 (bad request) Unknown function or unknown parameter

401 (unauthorized) Security breach

404 (not found) Document or component not found

409 (conflict) Administrative data inaccessible

500 (Internal Server Error) Internal error on Content Server

The response header contains the following information about the document:

Keyword Format Meaning Content-Type String Content type (if known) boundary String Separator between individual

components Content-Length Integer string Entire length of the body

actually transferred X-dateC YYYY-MM-DD Creation date (UTC) X-timeC HH:MM:SS Creation time X-dateM YYYY-MM-DD Last changed on [date] (UTC) X-timeM HH:MM:SS Last changed at [time] (UTC) X-numberComps Integer string Number of components X-contentRep String Content repository X-docId String Document ID X-docStatus String Status X-pVersion String Version

Each time the function is called, all document header information is displayed. If no specific component is addressed, information on all components is made provided. If you require information on only one component, you can restrict the output to this component by specifying the compId. The following combinations are possible:

• docId=ID, compId=ID:

Provides information about the document header and one component.

• docId=ID:

Provides information about the document header and all components of the document.

The component header contains the following information about the component:

Keyword Format Meaning Content-Type String Content-Type (if known) charset String Character set (if known) version String Application version used to

create the content of the component



Content-Length Integer string Actual body size in the response, always 0

X-Content-Length Integer string Size of the component in bytes X-compId String Component ID X-compDateC YYYY-MM-DD Creation date (UTC) X-compTimeC HH:MM:SS Creation time X-compDateM YYYY-MM-DD Last changed on [date] (UTC) X-compTimeM HH:MM:SS Last changed at [time] (UTC) X-compStatus String Component status X-pVersion String Interface version

There are two methods of coding the results in the response body. These methods are explained below. The parameter resultAs controls coding.

1. resultAs=ascii (default)

The server sends a response in multipart/form-data format (see RFC 1867). The total length of the body is specified by the parameter Content-Length in the response header. The individual parts of the response body are separated by a boundary specified in the response header. Each part represents one component. Each component has a component header and a component body. These have the length 0 because no component data is transferred (unlike the docGet command). Therefore, the component parameter Content-Length is always set to 0. If you want to set the component length, you can do so using the parameter X-Content-Length.

If the charset of a component is known, it must be transferred as a Content-Type parameter. Likewise, the parameter version (that is, the version number of the application used to create the component content (see Parameters and Keywords) for a component, if known, must be transferred as a Content-Type parameter.

HTTP/1.1 200 (OK)Server: Microsoft-IIS/4.0Date: Wed, 04 Nov 1998 07:41:03 GMTContent-Type: multipart/form-data; boundary=A495ukjfasdfddrg4hztzu...Content-Length: 32413X-dateC: 1998-10-07X-timeC: 07:55:57X-dateM: 1998-10-07X-timeM: 07:55:57X-contRep: K1X-numComps: 2X-docId: IDX-docStatus: onlineX-pVersion: 0045

--A495ukjfasdfddrg4hztzu898aA0jklmAxcvla12319981147528895Content-Type: application/x-alf; charset=

Content-Length: 0X-compId: descrX-Content-Length: 2591X-compDateC: 1998-10-07X-compTimeC: 07:55:57X-compDateM: 1998-10-07X-compTimeM: 07:55:57X-compStatus: onlineX-pVersion: 0045



--A495ukjfasdfddrg4hztzu898aA0jklmAxcvla12319981147528895

Content-Type: application/x-alf; charset=Content-Length: 0X-compId: dataX-Content-Length: 29213X-compDateC: 1998-10-07X-compTimeC: 07:55:57X-compDateM: 1998-10-07X-compTimeM: 07:55:57X-compStatus: onlineX-pVersion: 0045

--A495ukjfasdfddrg4hztzu898aA0jklmAxcvla12319981147528895--

If the info command is executed on an empty document, the response body will contain something like the following: --A495ukjfasdfddrg4hztzu898aA0jklmAxcvla1231999102562159269


2. resultAs=html

If resultAs=html is set, the server sends an HTML page. The structure of the HTML page is not specified, which means that graphical elements can be used as much as required.

Function: get • Effect

A content unit of a component or a range within a content unit is retrieved from the content repository. The parameters ContRep, docId and compId describe the component. fromOffset and toOffset describe the range of the content unit.

If the function is executed successfully, the content unit is transferred from the server to the client as an entity body in the response to an HTTP GET request.

• Default If no compId is specified, the following conditions are tested in the appropriate order:

1. If the component “data” exists, this component is returned.

2. If the component “data1” exists, this component is returned.

If an incorrect compId, or no compId, was specified, and if neither of the conditions above is fulfilled, the function returns Error 404 (not found).



Parameter Optional/Mandatory Default Sign contRep mandatory X docId mandatory X compId optional see above pVersion mandatory fromOffset optional 0



toOffset optional -1 accessMode s-mandatory X authId s-mandatory X expiration s-mandatory X secKey optional


• Example http://pswdf009:1080/ContentServer/ContentServer.dll?get&pVersion=0045&contRep=K1&docId=361A524A3ECB5459E0000800099245EC&compId=data

This requests the document component “data”.



200 (OK) OK, content unit of component is transferred




409 (conflict) Document or component inaccessible


The response header contains the following standard information about the document:

Keyword Meaning

Content-Type Content-Type

charset The character set of the component (as a content type parameter)

version The version of the component (as a contenttype parameter).

Content-Length Length of document

The response ‘content type’ depends on the content type of the component requested. If the charset of a component is known, it must be transferred as a Content-Type parameter.

Likewise, the parameter version (that is, the version number of the application used to create the component content (see Parameters and Keywords) for a component, if known, must be transferred as a Content-Type parameter.

The content unit (or range within the content unit) of the component is transferred in the response body.

Function: docGet • Effect

The entire content of a document is retrieved from the content repository.



If an incorrect docId was specified, error 404 (not found) occurs.

If the function is executed successfully, the data is transferred as an entity body in multipart/form-data format (see RFC 1867) as a response to an HTTP GET-Request.

• Default -



Parameter Optional/Mandatory Default Sign contRep mandatory X

docId mandatory X

pVersion mandatory

accessMode s-mandatory X

authId s-mandatory X

expiration s-mandatory X

secKey optional


• Example http://pswdf009:1080/ContentServer/ContentServer.dll?docGet&pVersion=0046&contRep=K1&docId=361A524A3ECB5459E0000800099245EC

This transfers the entire content of a document to the client.





200 (OK) OK, document is transferred


401 (unauthorized)




Security breach

The server sends a response in multipart/form-data format (see RFC 1867). The individual parts of the response body are separated by a boundary specified in the response header. In contrast to the info command, when docGet is used, components are actually transferred and the length of the transferred components is specified in the field Content-Length of the relevant component, that is, Content-Length and X-Content-Length have identical values. The response header contains the following information about the document:

Keyword Format Meaning Content-Type String Content type, always

multipart/form-data boundary String Separator between individual

components Content-Length Integer string Entire length of the body

actually transferred X-dateC YYYY-MM-DD Creation date (UTC) X-timeC HH:MM:SS Creation time X-dateM YYYY-MM-DD Last changed on [date] (UTC) X-timeM HH:MM:SS Last changed at [time] (UTC) X-numComps Integer string Number of components X-contRep String Content repository X-docId String Document ID X-docStatus String Status X-pVersion String Version



The component header contains the following information about the component:

Keyword Format Meaning Content-Type String Content type (if known) charset String Character set (if known) version String Content-Length Integer string Size of the component in bytes X-Content-Length Integer string Size of the component in bytes X-compId String Component ID X-compdateC YYYY-MM-DD Creation date (UTC) X-compTimeC HH:MM:SS Creation time X-compDateM YYYY-MM-DD Last changed on [date] (UTC) X-compTimeM HH:MM:SS Last changed at [time] (UTC) X-compStatus String Component status X-pVersion String Interface version

If the charset of a component is known, it must be transferred as a Content-Type parameter. Likewise, the parameter version (that is, the version number of the application used to create the component content (see Parameters and Keywords) for a component, if known, must be transferred as a Content-Type parameter.

• Example HTTP/1.1 200 (OK)Server: Microsoft-IIS/4.0Date: Wed, 04 Nov 1998 07:41:03 GMTContent-Type: multipart/form-data; boundary=A495ukjfasdfddrg4hztzu......some more header information...Content-Length: 32413

X-dateC: 1998-10-07X-timeC: 07:55:57X-dateM: 1998-10-07X-timeM: 07:55:57X-contRep: K1X-numComps: 2X-docId: IDX-docStatus: onlineX-pVersion: 0045

--A495ukjfasdfddrg4hztzu898aA0jklmAxcvla12319981147528895Content-Type: application/x-alf; charset=

Content-Length: 2591X-compId: descrX-Content-Length: 2591X-compDateC: 1998-10-07X-compTimeC: 07:55:57X-compDateM: 1998-10-07X-compTimeM: 07:55:57X-compStatus: onlineX-pVersion: 0045

...component data ...--A495ukjfasdfddrg4hztzu898aA0jklmAxcvla12319981147528895

Content-Type: application/x-alf; charset=Content-Length: 29313X-compId: dataX-Content-Length: 29213X-compDateC: 1998-10-07X-compTimeC: 07:55:57X-compDateM: 1998-10-07



X-compTimeM: 07:55:57X-compStatus: onlineX-compStatus: onlineX-pVersion: 0045

...component data ...--A495ukjfasdfddrg4hztzu898aA0jklmAxcvla12319981147528895--

If the docGet command is executed on an empty document, the response body could contain the following, for example: --A495ukjfasdfddrg4hztzu898aA0jklmAxcvla1231999102562159269


Function: create • Effect

This function creates new documents with one or more components in the content repository. The parameters contRep, docId and compId describe the component (see Definition of Terms). The function is used to create new documents. If you try to create a document that already exists in the content repository, the function returns an error. (If you want to modify existing documents, use the functions update and append.) The create function always creates an entire document.

The function can be called once with an HTTP PUT or POST (for further information, see HTTP-PUT and HTTP-POST multipart/form-data).

• Default A new document with the specified docId is created. One or more components are stored in the content repository. The security level is set according to the standard specified on the content server.

• Access Mode create (c)

• Client → Server The following parameters exist:

Parameter Optional/Mandatory

Default Position (POST/PUT)

Sign (POST/PUT)

contRep mandatory URL/URL X/X

compId mandatory body/URL -/X

docId mandatory URL/URL X/X

pVersion mandatory URL/URL

Content-Type optional body/body

charset optional body/body

version optional body/body

Content-Length mandatory Header-body/ Header-body

docProt optional server setting URL/URL X/X

accessMode s-mandatory URL/URL X/X



authId s-mandatory URL/URL X/X

expiration s-mandatory URL/URL X/X

secKey optional URL/URL

For an HTTP POST, the Content-Length in the request header is the total length of the body and the Content-Length in each part header is the length of the individual content units. For an HTTP PUT, the Content-Length is always the total length of the body.

Note the difference between when the parameter docProt is not transferred at all, and when it is transferred, but with no value (docProt=). In the first case, the content server default for ‘protection required’ is used. The second case specifies explicitly that the security level has not been set.


There are two ways of executing this function. A single component can be transferred using an HTTP-PUT. Alternatively, a HTTP-POST in the format multipart/form-data is used. In the case of the former, only a single component can be loaded onto the server. In the case of the latter, between 0 and n components can be transferred.

Function: HTTP-PUT With HTTP PUT, all parameters are entered in accordance with the table in the section create.

http://pswdf009:1080/ContentServer/ContentServer.dll?create&pVersion=0046&contRep=K1&docId=4B7689654E73D21197E70060B0672A3C&compId=data&Content-Length=300

The document component “data” is stored. The component data is transferred as an entity body.

Function: HTTP-POST multipart/form-data The data is transferred as HTTP-POST and as multipart/form-data. The document header information is transferred in the URL. One or more components are transferred in the body. This version of the function is particularly suitable for transferring documents consisting of several components into the content repository as a whole. The component information is specified in the header of each part; the data in the body.

In practice, this means that the URL contains the parameters contRep, docId, pVersion, docProt, accessMode, authId, expiration and secKey. All the other parameters are in the body.

The request body is in multipart/form-data format. With this format, it is possible to transfer several independent parts to an HTTP content server. The individual parts have a header and a body and are in MIME format (RFC 2045, 2046). The MIME format enables several components to be transferred to the content server simultaneously. If an error occurs when storing a component, the entire action is canceled.

The parameters compId and Content-Type are contained in the header of each part. The CompId is transferred in field X-compId. The component length is in the field Content-Length. The parameters charset and version can be appended to the Content-Type.

• Example 1 http://pswdf009:1080/ContentServer/ContentServer.dll?create&pVersion=0046&contRep=K1&docId=4B7689654E73D21197E70060B0672A3C



A document consisting of one or more components is transferred in multipart/form-data format.

Document header Content-Type: multipart/form-data; boundary=A495ukjfasdfddrg4hztzu898aA0jklm...some more header information...Content length: 32413

Content part --A495ukjfasdfddrg4hztzu898aA0jklm

X-compId: dataContent-Type: application/msword; charset=ISO-8859-1; version=6Content-Length: 4242

... 4242 bytes data ...--A495ukjfasdfddrg4hztzu898aA0jklm--

• Example 2 (create with 0 Components) http://pswdf009:1080/ContentServer/ContentServer.dll?create&pVersion=0046&contRep=M1&docId=3810FF00804C257DE10000009B38FA09&docProt=ud&accessMode=c&authId=CN%3DKPR&expiration=19991025080635&secKey=MIIBlQYJKoZIhvcNA …

A document consisting of one or more components is transferred in multipart/form-data format.

Document header Content-Type: multipart/form-data; boundary=KoZIhvcNAQcB...some more header information...Content length: 38

Content part --KoZIhvcNAQcB

--KoZIhvcNAQcB--



201(created) OK, document(s) created



403 (forbidden) Document already exists


The content server must set the dates (dateC and compDateC) and the times (timeC and compTimeC) for creating the components and the document.



Function: mCreate • Effect

One or more documents, each with one or more components, are stored in the content repository. This function has a similar effect to that of several sequential create functions, but is significantly more efficient at storing many new documents at once in the case of signed URLs.

Within an mCreate call, objects can only be stored in one and the same content repository. The content repository is described by the URL parameter contRep.

The individual components of the documents are transferred in a multipart/form-data entity body. Components of the same document must be transferred one after the other so that transfer of a document can be assumed to be complete as soon as a component from a different document begins.

The parameter docId is mandatory for all components (each multipart-part) and is entered as the header field “X-docId”.

A document is stored by means of a single transaction, but this is not the case for all documents transferred in one mCreate call.

• Access Mode create (c)

• Client ! Server The client sends an HTTP-POST-Request. The following parameters exist:

Parameter Header Field in Body

Optional/Mandatory

Default Position Sign

contRep mandatory URL X compId “X-compId” mandatory body docId “X-docId” mandatory body (1.

docId also in URL)

X (1. docId)

pVersion mandatory URL

Content-Type

optional body

charset optional body

version optional body

Content-Length

mandatory body

docProt optional server setting URL X

accessMode s-mandatory URL X

authId s-mandatory URL X

expiration s-mandatory URL X

secKey optional URL




The parameters for which the request body is specified as position are transferred in the header field of the multipart part of the corresponding components. For special parameters in this interface, the name of the header field is in column 2 of the table.

• Server ! Client The server answers the request with a response. The response status code indicates the outcome of the call. A distinction is made between general status codes, which describe the success of the call as a whole and specific status codes, which document the creation of individual documents.

General HTTP Status Codes Meaning

201(created) OK, all documents were created

250 (missing documents created) OK, all missing documents were created

This status can occur only in the case of repeated mcreate calls.




Specific HTTP Status Codes Meaning

201(created) OK, document created

403 (forbidden) Document already exists


An ASCII text must be returned whether the function is executed successfully or not. The documents stored (HTTP status code 201) and/or not stored (HTTP status code 403) are specified in this text. The following format is used: docId="string";retCode="integerstring";errorDescription="string";CRLF

The value of the parameter retCode is the corresponding specific HTTP status code.

As a summary, the response body contains the following standard information about each document:

Keyword Format Meaning docId string Document ID retCode Integer string HTTP status code

errorDescription string Text explaining the error (optional)



Function: append • Effect

Data is appended to a content unit of a component in the content repository. The parameters ContRep, docId and compId describe the component (see Definition of Terms). The document addressed and the corresponding component must exist.

• Default Data is appended to the content unit of the addressed component.

• Access Mode change (u)

• Client → Server The client sends an HTTP-PUT-Request. The URL or the body contains the following parameters:

Parameter Optional/Mandatory Default Position Sign contRep mandatory URL X docId mandatory URL X compId mandatory URL X pVersion mandatory URL accessMode s-mandatory URL X authId s-mandatory URL X expiration s-mandatory URL X secKey optional URL Content-Length mandatory body

s-mandatory means that this parameter must only be specified if the URL is signed.

The data to be appended is transferred as an entity body.

• Example http://pswdf009:1080/ContentServer/ContentServer.dll?append&pVersion=0046&contRep=K1&docId=4B7689654E73D21197E70060B0672A3C&compId=data&Content-Length=980

Data transferred in the request body is appended to the content unit of the component “data” in the specified document.





200 (OK) OK, data appended






The content server must set the dates (dateM or compDateM) and the times (timeM or compTimeM) for changing the components and the document.

Function: update • Effect

One or more components of a document in the content repository are overwritten. The parameters contRep, docId and compId describe the component (see Definition of Terms). This function is used to modify existing documents and components. The function can be called using HTTP-PUT or HTTP-POST.

The variant HTTP-PUT is used to create or overwrite a component of an existing document.

The variant HTTP-POST (multipart/form_data) is used to bring an entire document up to date. When this variant is used, the entire document, and not only individual components, is overwritten.

• Default One or more components are stored in the content repository. The security level is set according to the standard specified on the server.

• Access Mode change (u)



• Client → Server The following parameters exist:

Parameter Optional/Mandatory Default Position (POST/PUT)

Sign (POST/PUT)

contRep mandatory URL/URL X/X

compId mandatory body/URL -/X

docId mandatory URL/URL X/X

pVersion mandatory URL/URL

Content-Type

optional body/body

charset optional body/body

version optional body/body

Content-Length

mandatory body/body

accessMode s-mandatory URL/URL X/X

authId s-mandatory URL/URL X/X

expiration s-mandatory URL/URL X/X

secKey optional URL/URL


There are two ways of executing this function. A single component can be transferred using HTTP-PUT. Alternatively, a HTTP-POST in the format multipart/form-data can be used. If the former version (HTTP-PUT) is used, only one component at a time can be loaded onto the content server. There is no such restriction if the latter version (HTTP-POST) is used.

HTTP-PUT This variant of the function is used to recreate or overwrite an individual component of a document.

For further details, see the command create.

HTTP-POST multipart/form-data Similarly to the create function, this variant of the function is used to replace a complete document with all its components in the content repository at once. Document components not already in the content repository are created if necessary. Components in the content repository that are not transferred when the update function is executed are considered obsolete and deleted. The structure details of the request is the same as for the function create.





200 (OK) OK, document(s)/component(s) changed






The content server must set the dates (dateM, compDateM and compDateC) and the times (timeM, compTimeM and compTimeC)) for changing components and the document.

Function: delete • Effect

A component or an entire document is deleted. A document to be deleted is addressed via contRep and docId. The parameters contRep, docId and compId identify the component to be deleted.

• Default The document, including all administrative data (document header and components) and the content, is deleted completely.

• Access Mode delete (d)


Parameter Optional/Mandatory Default Sign

contRep mandatory X

docId mandatory X

compId optional all components X

pVersion mandatory




secKey optional




• Example http://pswdf009:1080/ContentServer/ContentServer.dll?delete&pVersion=0046&contRep=K1&docId=4B7689654E73D21197E70060B0672A3C&compId=data

Component “data” is deleted in the named document.



200 (OK) OK, document/component(s) deleted






Function: search • Effect

This function searches for a text pattern in the content unit of a component. The range of the search can be restricted. The search begins at the point specified by fromOffset and continues until the toOffset point. If fromOffset is greater than toOffset, the function searches the component backwards.

A text pattern is found if the following conditions are met:

• if fromOffset <= toOffset

• The location of the first character of the text found is greater than or equal to fromOffset.

• The location of the last character of the text found is smaller than or equal to toOffset.

• if fromOffset >= toOffset

• The location of the last character of the text found is less than or equal to fromOffset.

• The location of the first character of the text found is greater than or equal to toOffset.

The pattern contains the search string. The string can contain blank characters.

The number of “hits” (text found by the search function) and the hits themselves (up to numResults) are returned as the result. A hit consists of information on the character position. The character position is the position of the hit in relation to the start of the document. The position of the hit location is defined as the position of the first character of the search text, regardless of the direction of the search.

• Default The pattern is searched for in the whole addressed component.






contRep mandatory X

docId mandatory X

pattern mandatory

compId mandatory

pVersion mandatory

caseSensitive optional n

fromOffset optional 0

toOffset optional -1

numResults optional 1




secKey optional


• Example http://pswdf009:1080/ContentServer/ContentServer.dll?search&pVersion=0046&contRep=K1&docId=4B7689654E73D21197E70060B0672A3C&compId=data&pattern=Manfred%20M%FCller&fromOffset=80

A search for “Manfred Müller” is carried out in the component “data” of the named object from offset 80 to the end.



200 (OK) OK, component was searched








The result of the search is the number of hits and the offset for each hit. An ASCII string with the following structure is returned: number;offset;length;...

There are no blank spaces between the individual characters. There is a semicolon between the values and at the end.

2;122;222

Function: attrSearch This function is used for attribute-based searches in print lists (attribute search). It is a prerequisite of this search that a print list has a description file (compId=descr) as well as a data file (compId=data). Unlike search this is a specific search, which is carried out in the description file of a print list (compId=descr). Only the description file is relevant for the implementation of an attribute search.

• Basic Principles The structure of the description file is explained below with the aid of an example.

Content of a description file (extract; the periods stand for blank characters):

0 72 DPRL

73 0 DKEYclient………………………………0 3

73 0 DKEYcompany_code………………………...3 5

73 0 DKEYaccount_number………………………….8 7

73 0 DKEYcustomer_name………………………….15 25

73 138 DAIN00100010147119Bröselplc.

211 120 DAIN001000020147129Obelixplc.

…

1147 1 DEPL

The description file consists of a sequence of lines (index lines). These index lines describe attributes of a range of the relevant data file.

An index line consists of the following:

• Offset and Length in the data file:

Specification of the Offset and the Length of the range described (in bytes) relative to the start of the data file.

• Record type

Type of line. The record type consists of four bytes. The following record types are used:

DPRL Prologue

DKEY Description of attributes

DAIN Value of attributes

DEPL Epilogue

The various record types occur in the description file in the order specified here. The fact that the DAIN lines come after the DKEY lines is of particular importance.

Only DKEY and DAIN lines are decisive for the attribute search. The DKEY lines specify the attributes and how they are stored. The DAIN lines specify the attribute values.



• Parameter

Remaining content of the index line dependent on the record type.

The individual index lines are closed with linefeed (0x0A). The value for the “Offset in the data file” increases steadily within the description file.

Interpreted content of the description file (extract):

Offset and length in the data file

Record type Parameter

0 72 DPRL

73 0 DKEY Client 0 3

73 0 DKEY Company code 3 5

73 0 DKEY Accountnumber

8 7

73 0 DKEY Customer name 15 25

73 138 DAIN 001 0001 0147119

Bröselplc

211 120 DAIN 001 0002 0147129

Obelixplc

…

1147 1 DEPL

The structure of the DKEY and DAIN lines is described in detail below.

DKEY lines (description of attributes)

Content Length (in bytes)

Offset in data file Variable

Separator (space) 1

Length in data file Variable

Separator (space) 1

Record type ("DKEY") 4

Attribute names 40

Offset in the DAIN line parameter 3

Length in the DAIN line parameter 3

The DKEY lines specify the names (attribute names) and the structure (offset and length in the DAIN line parameter) of the attributes that occur in the DAIN lines. The offset position is counted starting with 0. Each DKEY line describes one particular attribute.

The values “offset and length in data file” are not relevant here.

DAIN lines (values of attributes)

Content Length (in bytes)

Offset in Data File Variable

Separator (space) 1

Length in Data File Variable

Separator (space) 1



Record type ("DAIN") 4

Parameter Variable

Each DAIN line specifies the attribute value for a specific range of the data file. The DAIN line parameter consists of the attribute values corresponding to the standards in the DKEY lines. Blank characters at the end of the DAIN lines are irrelevant. If the DAIN line contains less data than is specified in the DKEY lines, the attributes must be filled with blank characters.

Here, the specifications “Offset and Length in data file” are relevant. They relate to the data file and specify the range for which the given attribute values are valid.

The content of the above example is as follows:

Description of attributes

Attribute Name Offset in the DAIN Line Parameter

Length in the DAIN Line Parameter

Client 0 3

Company code 3 5

Account number 8 7

Customer name 15 25

Attribute Values

Offset in Data File

Length in Data File Attribute Name Attribute Value

Client "001"

Company code "00001"

Account number "0147119"

73 138

Customer name "Bröselplc"

Client "001"

Company code "00002"

Account number "0147129"

211 120

Customer name “Obelixplc”… … … …

• Effect This function is used for attribute-based searches in print lists. The parameters ContRep and docId describe the component. The parameter pattern specifies the attribute to be searched for, as well as the pattern. The attribute is described in terms of its offset and its length. The pattern is made up of the offset, followed by the character "+", followed by the length, followed by the character "+", followed by the attribute value. If several attributes are to be searched for, the individual patterns should be separated by a #.

The patterns can contain any characters. Unsafe and reserved characters are coded as normal here. This is also true for the separator "#" if this occurs in the pattern (see URL Encoding).

The results of the attribute search are the values for “offset and length in the data file” that match the pattern and are in the search range in the DAIN lines.

For a pattern to be found, the following conditions must be fulfilled:



• The value for the “offset in the data file” in the DAIN line is within the search range.

• The attribute values specified in pattern match those in the DAIN line. In other words, each attribute value specified by pattern must be contained fully in the matching attribute value in the DAIN line.

The number of result entries (number of appropriate DAIN lines), and the result entries themselves (values for “offset and length in the data file” in the DAIN line), are returned as the result. A semicolon separates the values. The result entries are sorted according to the search direction. Control of the search direction is as for the search function. The number of results can be restricted by the parameter numResults.

• Default The pattern is searched for in the document addressed by the parameters contRep and docId. The CompId is not specified in the call. The function always searches in the description file (compId=descr).




contRep mandatory X

docId mandatory X

pattern mandatory

pVersion mandatory

caseSensitive optional n

fromOffset optional 0

toOffset optional - 1

numResults optional 1




secKey optional

s-mandatory means that this parameter must only be specified if the URL is signed.

• Example http://pswdf009:1080/ContentServer/ContentServer.dll?attrSearch&pVersion=0046&contRep=K1&docId=361A524A3ECB5459E0000800099245EC&pattern=3+5+12345#15+25+GmbH&numResults=5



In a component, the search function searches the attribute with offset 3 and length 5 for 12345 (this is the company code in the example), and searches the attribute with offset 15 and length 25 for plc (this is the customer name in the example). Up to 5 hits are returned.

As you can see in the example, # is not encoded as a separator.



200 (OK) OK, component was searched






The result of the search is the number of hits and the offset and length for each hit:

number;offset;length;...

2;73;138;211;120;

If an attribute search cannot be carried out properly because the values in the attribute do not match the standards in the DKEY lines (for example, attribute names wrong or attribute value too long in the pattern), status code 400 (bad request) is returned.

If, however, nothing is found, the status code is set to 200 (OK) and 0 is returned as the result.



Administration Functions In the current HTTP Content Server Interface, only two administrative functions are defined: putCert and serverInfo. Further administration functions will be defined in later versions of the interface.

Function: putCert• Effect

The client certificate and a client identification (authId) are transferred.

The client certificate (see secKey) is decoded in the message body and transferred in binary format.

For reasons of security, it is recommended that it be made mandatory for an administrator to perform some kind of manual action after the certificate has been transferred, before access is actually allowed. This could be a public key fingerprint check or any other plausibility check.

The logon procedure therefore consists of two steps:

• The certificate is transferred and entered in a central location.

• An administrator uses a tool to grant access.

After the first step of this procedure, the certificate is created, but access has not yet been granted. The client only gains access after the second step of the procedure.

• Access Mode -

• Client → Server The client sends an HTTP-PUT-Request.

Parameter Optional/Mandatory Sign authId mandatory

pVersion mandatory

contRep mandatory

The certificate is transferred in the request body. All the other parameters are transferred in the URL. The URL does not contain a secKey.



200 (OK) OK


406 (not acceptable) Certificate not recognized




Function: serverInfo • Effect

This function supplies information about the status of the Content Server and the content repositories that the Content Server administrates.

• Default The standard information is returned to the content server and the content repositories that it manages. The results are given in ASCII format.

• Access Mode -

• Client → Server The client sends an HTTP-GET-Request. The following parameters exist:

Parameter Optional/Mandatory Default Sign contRep optional All repositories

pVersion mandatory

resultAs optional ascii

• Example http://pswdf009:1080/ContentServer/ContentServer.dll?serverInfo&pVersion=0046

In the example, information about the content server and all the content repositories it manages is requested.



200 (OK) OK



The following information about the content server status is displayed:

Keyword Format Meaning

serverStatus Status of content server (running/ stopped/ error)

serverVendorId Manufacturer and software version

serverVersion Version of server

serverBuild Build of server

serverTime HH:MM:SS Content server time (UTC)

serverDate YYYY-MM-DD Content server date (UTC)

serverStatusDescription Text describing server status



pVersion Content server interface version

The following information about the status of each content repository is displayed:

Keyword Format Meaning

contRep Content repository

contRepDescription Text describing content of the repository content

contRepStatus Status of content repository (running/ stopped/ error)

contRepStatusDescription Text describing content repository status

These parameters are mandatory. The parameter list is designed so that it can be extended, if required.

For each function call, all information about the content server is provided. If no content repository is addressed, information on all content repositories is provided. ContRep can be used to limit the content repository information to a single content repository.

There are two methods of coding the results in the response body. These methods are explained below. The parameter resultAs controls coding.

1. resultAs=ascii (default)

A pure ASCII text is returned. The information about the content server is at the start of the string, followed by the information about the content repositories. The following format is used:

• For the content server: serverStatus="string";serverVendorId="string";serverTime="string";serverDate="string";serverErrorDescription="string";pVersion="0046";CRLF

• For each content repository: contRep="string";contRepDescription="string";contRepStatus="string";pVersion="0046";CRLF

If no value is entered, the value remains free. contRepDescription="";contRepStatus="string";...

The order of the key words does not matter, but there must not be any blank characters. The key words (together with their values) are separated from each other by a semicolon. The corresponding values are in quotation marks.

2. resultAs=html

If resultAs=html is set, the server sends an HTML page. The structure of the HTML page is not specified, which means that graphical elements can be used as much as required.



Error Codes An error that occurs when a function is executed can be recognized in the HTTP status code.

HTTP Status Code Meaning Used For

200 (OK) OK, information or component was delivered, transferred, changed, appended, or deleted

info, get, docGet, update,append, delete, putCert, search, attrSearch

201(created) OK, component(s) created (if create was used)

OK, (all) document(s) created (if mCreate was used)

create, mCreate

250 (missing documents created)

OK, all missing documents were created

mCreate


All functions

401 (unauthorized) Security breach info, get, docGet, create, update, append, delete, mCreate, search, attrSearch

403 (forbidden) Document or component already exists

create, mCreate

404 (not found) Document, component, or content repository not found

info, get, docGet, update, append, delete, search, attrSearch

406 (not acceptable) Certificate not recognized putCert

409 (conflict) Document, component, or administration data inaccessible

info, get, docGet, append, update, delete, search, attrSearch


All functions

If an error occurs, the content server must deliver an ASCII string describing the error. The error must be entered in the header field X-ErrorDescription.



Cache Server and Interface Version 4.6 Use You can use the Cache Server provided by SAP (see also Cache Server) in conjunction with third-party content servers to cache documents while they are being read accessed.

Features From release 4.6B, you can use the SAP Content Server (see SAP Content Server) in conjunction with a cache server (see also note 216419, Multi-Level Caching and Content Server Proxies).

To allow you to use signed URLs between the SAP Content Server and the cache server, the Content Server component of the SAP Content Server HTTP Interface has been extended. To differentiate the new extended version from the previous version (version 4.5 or 0045), the new version is called version 4.6 or 0046.

If you want to use a third-party content server in a heterogeneous environment consisting of SAP Content Server, SAP’s own cache server, and a third-party content server, the third-party content server needs to be enhanced so that it supports all SAP Content Server HTTP Interface commands. The new command getCert must also be implemented so that the requirements for the new version of the interface are fulfilled.

For further information, see the documentation on the Content Management Service in the SAP Library in the sections Knowledge Provider and Caching, Cascaded Caching, and Content Server Aliases. You can also get information from the SAP Integration and Certification Centers.



Appendix

Parameters and Keywords A parameter appears no more than once in a URL. The parameters and key words defined are listed below in alphabetical order. The data type is given in square brackets (a “string” consists of characters from the ASCII character set and an “integerstring” consists of characters from the set {0,1,2,3,4,5,6,7,8,9}): The following parameters and key words are defined:

• accessMode [string] Access Mode

• authId [string]

Client ID

• caseSensitive [y|n]

Determines whether the search is case-sensitive. The default value is n.

− caseSensitive=n

Search is not case-sensitive

− caseSensitive=y

Search is case-sensitive

• charset [string]

Describes the character set used to encode the component content (for example, ISO-8859-1; see also RFC 2046). Other values can be defined, but must have an X- placed before them. The character set is transferred as a Content-Type parameter.

• compDateC [string]

Creation date of a component in UTC format, that is, YYYY-MM-DD

• compDateM [string]

Date component was last changed, in UTC format.

• compId [string]

Identifies a component within a document.

Additional information for partners who already support the SAP ArchiveLink interface:

Data files for stored print lists and outgoing documents are interpreted as compId “data”. The corresponding description files as interpreted as compId “descr”. Notes have compId “note”.

Predefined values for components:

- “data” data file

- “descr” attribute file

- “note” note

• compTimeC [string]

Time the component was created, in UTC format: HH:MM:SS

• compTimeM [string] Time the component was last changed, in UTC format



• compStatus [online|offline] Status of component in the content repository. Meaning:

− online:

Component known and accessible

− offline:

Component known and currently inaccessible

• Content-Disposition

Content-Disposition can be transferred with compId as an additional parameter if documents are being transferred as multipart/form-data (see also HTTP-POST multipart/form-data). If Content-Disposition is used in this way, it must be consistent with X-compId.

This parameter can be ignored.

• Content-Length [integerstring]

Size of body or component in bytes. The parameter Content-Length can occur both in the response header and in part headers.

• Content-Type [string]

Identifies the Content-Type of a component or a transferred document. Can occur in the response header and in part headers. With charset, the character set used to write the component content can be specified as the Content-Type parameter.

• contRep [string]

Specifies the content repository

• contRepDate [string]

Content repository date in UTC format: YYYY-MM-DD

• contRepDescription [string]

Text describing content of the repository content

• contRepErrorDescription [string]

Text describing a content repository error

• contRepStatus [running|stopped|error]

Content repository status. Meaning:

− running

Content repository is running

− stopped

Content repository has been stopped

− error

Error in content repository

• contRepTime [string]

Content repository time in UTC format: HH:MM:SS

• contRepVendorId [string]

Manufacturer and version of content repository software



• dateC [string]

Creation date of a document, in UTC format: YYYY-MM-DD

• dateM [string]

Date the document was last changed, in UTC format:YYYY-MM-DD

• docID [string]

Unique identifier for document header

• docProt [string]

Security level of a document docProt controls the security level of a document and its information. docProt is a combination of the access rights r,c,u,and d. The parameter can overwrite the default set on the content server.

For example, the combination docProt=rcud fully protects a document.

• docStatus [online|offline]

Status of document in the content repository. Meaning:

− online

Document known and accessible

− offline

Document known and inaccessible

• expiration [string]

Expiry time of a signed URL, in UTC format: YYYYMMDDHHMMSS

• fromOffset [integerstring]

Specifies the starting point for a search or the beginning of a byte range within the component. The default is 0. This parameter is needed so that parts of the component (with print lists, for example) can be read.

• numComps [integerstring]

Number of components in a document

• numResults [integerstring]

Determines the maximum number of results (hits) a search can return

• pattern [string]

Character pattern used for an unrestricted search. See the function search.

The counterpart of pattern [string] in the attribute search is pattern [integerstring+integerstring+string].

• pattern [integerstring+integerstring+string]

Attribute pattern searched for in the attribute search. See function attrSearch.

The counterpart of pattern [integerstring+integerstring+string] in the unrestricted search is pattern [string].

• pVersion [string]

Specifies the interface version. Versions 0021, 0030 and 0031 were defined for the SAP ArchiveLink interface. The HTTP Content Server interface begins with version 0045.

• resultAs [string]

Chooses the presentation form for the result of the info function. The default is ASCII.

− resultAs=ascii



Results given in ASCII format

− resultAs=html Results given in HTML format

• retCode [integerstring]

Part of the ASCII string sent by the content server to the client after an mCreate call. Contains the HTTP status code for the corresponding document.

• secKey [string]

Specifies an access key that can be used to check access authorization. The SAP system generates the access key.

• serverDate [string]

Content server date in UTC format: YYYY-MM-DD

• serverErrorDescription [string]

Text describing confirmed content server error

• serverStatus [running|stopped|error]

Content server status. Meaning:

− running

Content server is running

− stopped

Content server has been stopped

− error

Content server error

• serverTime [string]

Content server time in UTC format: HH:MM:SS

• serverVendorId [string]

Manufacturer and version of content server software

• timeC [string]

Creation date of a document, in UTC format: HH:MM:SS

• timeM [string]

Time the document was last changed, in UTC format: HH:MM:SS

• toOffset [integerstring]

Specifies the end of a byte range within the component. The default -1 means that the search should continue to the end of the component. toOffset has priority over any content range that may be set.

• version [string]

Describes the application version used to create a document or component. The version is transferred as the Content-Type parameter. For some MIME types, version numbers are registered at IANA, so that they are always used consistently. For example, versions 2w, 4, 5 and 6 are used for application/msword.

• serverStatusDescription [string]

Header field in which the content server enters an explanatory text if an error occurs.



Migrating Existing Archives

This section is only relevant for partners who supported the SAP ArchiveLink interface in the past and who now want to support the new HTTP Content Server Interface.

When a component is stored, the MIME type is transferred by means of the field Content-Type in the request header (see RFCs 2045 and 2046). The content server then contains the MIME type, but does not evaluate it. The MIME type is used as the response Content-Type (for the get function, for example).

In older archives, only document classes such as ALF, FAX, and DOC were recognized. Therefore, a MIME type must be derived from these old document classes, so that previously stored documents can be accessed via the new interface. The MIME type is derived from the document class.

Document Structure There are many documents in the old SAP ArchiveLink interface that consist of several components. This is particularly true of documents in the document classes FAX, OTF and ALF. As well as one or more (FAX) data files, these documents sometimes also contain a description file (ALF) and a note file.

When existing archives are being migrated, a component ID (compId) must be assigned to each component. The procedure is as follows.

• The compId data is assigned to the data file. If several data files exist (for document class FAX, for example, if there are several pages and each page is saved separately as a TIFF file), they are assigned to the components “data1”, “data2”, and so on. In this case there is no component “data”.

• A description file (ALF only) is assigned to the component “descr”.

• Finally, the note file is assigned to the component “note”.

Deriving MIME Types from Document Classes When an archive is migrated, the MIME type of the component “data” (or “data1”, “data2”, and so on) is derived from the document class.

Conversion rules are shown in the following table. The order of the entries is significant. The first appropriate entry from the top is used for conversion.

Document Class MIME Type

FAX image/tiff

BIN application/octet-stream

DOC application/msword

PDF application/pdf

PS application/postscript

RTF application/rtf

XLS application/vnd.ms-excel

MPP application/vnd.ms-project

PPT application/vnd.ms-powerpoint

ALF application/x-alf



OTF application/x-otf

RAW application/x-raw

REO application/octet-stream

SCR application/x-scr

BMP image/bmp

GIF image/gif

JPG image/jpeg

PCX image/pcx

TIFF image/tiff

TIF image/tiff

HTM text/html

TXT text/plain

No MIME type is set for document classes not listed here.

The components "descr" (ALF only) and "note" contain the MIME type as follows:

compId MIME Type

note application/x-note

descr application/x-alf-descr
