CRM Content Server 1 PDF

Content Management Service (BC-SRV-KPR)
PDF download from SAP Help Portal:

http://help.sap.com/saphelp_crm70/helpdata/en/26/72a1376f6cd903e10000009b38f8cf/content.htm
Created on June 25, 2015
The documentation may have changed since you downloaded the PDF. You can always find the latest information on SAP Help Portal.
Note
This PDF document contains the selected topic and its subtopics (max. 150) in the selected structure. Subtopics from other structures are not included.
2015 SAP SE or an SAP affiliate company. 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 SE. The information contained herein may be changed without prior notice. Some software products marketed by SAP SE
and its distributors contain proprietary software components of other software vendors. National product specifications may vary. These materials are provided by
SAP SE and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be
liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express
warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty. SAP and other
SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE in Germany and other
countries. Please see www.sap.com/corporate-en/legal/copyright/index.epx#trademark for additional trademark information and notices.
Table of content
PUBLIC
2014 SAP SE or an SAP affiliate company. All rights reserved.
Page 1 of 62
Table of content
1 Content Management Service (BC-SRV-KPR)
1.1 Storage Types
1.2 Concepts
1.2.1 HTTP Access for Repositories on SAP Web Application Server
1.2.2 Storing URLs
1.3 SAP Content Server
1.3.1 Architecture of the SAP Content Server
1.3.2 Advantages of the SAP Content Server
1.3.3 Security Mechanisms of the SAP Content Server
1.3.3.1 Secure URLs
1.3.3.2 Protection Against Tapping and Forging of the Data Stream
1.3.3.3 Security Mechanisms Against Data Loss
1.3.3.4 Creating a System-Specific Certificate for Content Server Access
1.3.3.5 Access Protection for Administration
1.4 Logical Repository
1.5 Knowledge Provider and Caching
1.5.1 Cache Servers
1.5.1.1 Architecture of the Cache Server
1.5.1.2 Deletion Strategy and Performance
1.5.1.3 Optimal Access Path for Client Requests
1.5.2 Customizing for Caching
1.5.3 Cascaded Caching
1.5.4 Content Server Aliases
1.5.5 Cascaded Caching and Content Server Aliases
1.5.6 Cache Preload
1.6 Distribution
1.6.1 Configuring the Distribution Settings
1.6.2 Reading via Distributed Cache Servers
1.6.3 Different Locations with Different Content Servers
1.6.4 Redirecting the Web Server
1.6.5 Overview of Transactions
1.6.5.1 Locations
1.6.5.2 IP Sub-Nets
1.6.5.3 Hosts
1.6.5.4 Content Server Administration
1.6.5.5 Content Repositories
1.6.5.6 Content Categories
1.6.5.7 Caches
1.6.5.8 Distributing Categories
1.6.5.9 Web Servers for Document Spaces
1.6.5.10 Web Servers for Document Classes
1.7 Content Server and Cache Server Administration
1.7.1 Choosing a Server
1.7.2 Functions
1.7.2.1 Overview Information
1.7.2.2 Details
1.7.2.3 Certificates
1.7.2.4 Settings
1.7.2.5 Statistics
1.7.2.6 Creating New Content Repositories
1.8 Content Server and Cache Server Monitoring
1.8.1 Monitoring for Content Server
1.8.2 Monitoring for Cache Server
1.8.3 Monitoring with KPro Web Server
1.9 SAP Content Server HTTP 4.5 Interface
1.9.1 Introduction
1.9.1.1 Definitions of Terms
1.9.1.2 Implementation
1.9.1.3 Security
1.9.1.3.1 secKey
PUBLIC
Page 2 of 62
1.9.1.3.2 Security Level / Access Permissions

1.9.2 Syntax
1.9.2.1 General
1.9.2.2 URL Encoding
1.9.2.3 Coding in the Response Body
1.9.2.4 Functions
1.9.2.4.1 Access Functions
1.9.2.4.1.1 Function: info
1.9.2.4.1.2 Function: get
1.9.2.4.1.3 Function: docGet
1.9.2.4.1.4 Function: create
1.9.2.4.1.4.1 Function: create with HTTP-PUT
1.9.2.4.1.4.2 Function: create with HTTP-POST multipart/form-data
1.9.2.4.1.5 Function: mCreate
1.9.2.4.1.6 Function: append
1.9.2.4.1.7 Function: update
1.9.2.4.1.7.1 Function: update with HTTP-PUT
1.9.2.4.1.7.2 Function: update with HTTP-POST multipart/form-data
1.9.2.4.1.8 Function: delete
1.9.2.4.1.9 Function: search
1.9.2.4.1.10 Function: attrSearch
1.9.2.4.2 Administration Functions
1.9.2.4.2.1 Function: putCert
1.9.2.4.2.2 Function: serverInfo
1.9.2.5 Error Codes
1.9.3 Cache Server and Interface Version 4.6
1.9.4 Appendix
1.9.4.1 Parameters and Keywords
1.9.4.2 Migrating Existing Archives
PUBLIC
Page 3 of 62
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 The central feature 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 Notes
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 system database
Content Server
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. Special tools have been developed for monitoring and administrating 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 Server and Cache Server Monitoring.
SAP Content Server
SAP provides a standard content server that can be installed separately on an NT server (sieseehe SAP Content Server).
Cache Server
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.
Areas of Application
PUBLIC
Page 4 of 62
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.
1.1 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.
1.2 Concepts
Entities and Relations
The following entity relationship diagram illustrates the components and terminology used in CMS:
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:
repository is abstracted from the physical storage location. Repositories can be created in the DLTP 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 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 onyl 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
creating these models.
Content Models) what document types are used in an application. The Knowledge Provider provides tools for
PUBLIC
Page 5 of 62
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.
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 DLTP database. The repository types, in turn, are assigned concrete content
servers, such as an HTTP content server for the storage category HTTP.
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 Providers Content Management Service can use both the HTTP server and the HTTP client interface of SAP Web Application Server (see also
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:
PUBLIC
Page 6 of 62
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 SAP system 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 (ICM) 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 more information about the ICM, a component of the SAP Web Application Server see
Internet Communication Manager (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, especially SAP system 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_DISis 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 is used only for certificate administration in the SAP system database repository. 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.
PUBLIC
Page 7 of 62
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
Store User in the SICF

1.
2.
3.
4.
Call transaction SICF.

Expand the services tree.
Double-click on the service contentserver , which is located under /default_host/sap/bc .
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), refer to the ICF
documentation under
Creating an ICF Service.
1.2.2 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.
1.3 SAP Content Server

Purpose
The SAP Content Server is based on the database instance
MaxDB and is available on Microsoft Windows operating systems as of Release 4.6.
Therefore, besides the SAP database, an independent content server is always available in every SAP system installation. This provides the required technical
infrastructure for all document-oriented applications and business scenarios that do not require long-term archiving. Since the SAP Content Server is also
PUBLIC
Page 8 of 62
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.
Implementation Notes
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.
Restrictions
The SAP Content Server is not intended to replace optical storage systems and other storage media for long-term document archiving.
Architecture of the SAP Content Server

The SAP Content Server consists of the following components:
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
Database Instance. However, the Content Server engine does not communicate directly with the database instance.
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 client driver to access the database instance. The database instance 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 improve the capacity and performance of the SAP Content Server 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
Database Instance version is independent of the SAP release. The database version 7.2 is included in the SAP release 4.6C package. This database
version has a capacity of 64 terabytes. In the unlikely event of this space being used up, another database instance can be installed.
Database administration tools, which are easy to use, are delivered with it. 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.
1.3.3 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:
PUBLIC
Page 9 of 62
Secure URLs
Encoded Data Transfer
Security Mechanisms Against Data Loss
Access Protection for Administration
1.3.3.1 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
and if it contains a valid signature.
secKey (digital signature). A signed URL is only valid if the expiration time has not been exceeded
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
Signatures (BC-SEC-SSF).
Secure Store & Forward / Digital
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 (
Certificate) 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 systems digital signature can be used properly.
See the section
Creating a System-Specific Certificate for Content Server Access.
1.3.3.2 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

The SAP Content Server is subject to the security requirements for
Database Instances. To avoid data loss, the following measures can be taken:
Redundant hardware
Mirror disks, RAID systems, and so on
Standard security measures
Data Backup,
Log Backup
Note that security against data loss is only ensured, if, in addition to the standard security measures stated above, file ContentServer.ini and directory
Security are also backed up.
See also note 319332 (Content Server Backup Strategies).
PUBLIC
Page 10 of 62
1.3.3.4 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
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 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.
Choose Applications .
Choose New Entries .
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.
Make the following entries:
1. In the field Security/Product , enter
SAPSECULIB.
In the field SSF Format , choose
International standard PKCS#7.
In the field Priv. add. book , enter
SAPHTTPCS.pse.
In the field SSF profile , also enter
SAPHTTPCS.pse.
In the field SSF ProfileID , enter
CN= <Common name>,OU= <Organization Unit>,O= <Organization>,C= <Country>.
For example:
CN= BCECS,OU= DEV,O= SAP-AG,C= DE
Check Distribute PSE (Only SAPSECULIB) .
6. Save your entries.
7. Call transaction
STRUST again.
Select HTTP Content Server .
Choose Replace from the context menu.
Confirm this at the confirmation prompt.
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 the SAP System Note the following security considerations in relation to administration on the Content Server:
PUBLIC
Page 11 of 62
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 instance 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 .
1.4 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
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.
PUBLIC
Page 12 of 62
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.
1.5 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 Providers 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 actually 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
1.5.1 Cache Servers
PUBLIC
Page 13 of 62
Purpose
The purpose of the Cache Server is to provide the following benefits:
1. Seamless, transparent integration into existing content server landscapes
2. Significant reduction in client response times
3. 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.
1.5.1.1 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 Caches).
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.
1.5.1.2 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).
PUBLIC
Page 14 of 62
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
SAPs 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.
1.5.1.3 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.
1.5.2 Customizing for Caching

PUBLIC
Page 15 of 62
In order to use caching, you need to take the following basic Customizing steps:
Define caches
Host name and locations (transaction SCMSHO)
Define the cache (transaction SCMSCA)
Define locations for the following:
Users (clients), using
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
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 .
1.5.3 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 Providers 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 necessary Customizing steps are explained in the Implementation Guide (IMG) under SAP Web Application Server Knowledge Provider
Distribution Define Location Path for Multi-Layer Caching .
More information:
Distribution
Content Server Alias
Restrictions
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.
1.5.4 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, for example, 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:
PUBLIC
Page 16 of 62
SAP Web Application Server Basis Services Knowledge Provider Content Management Service Distribution Define Content Server
Alias
and
Define Location Path for Multi-Layer Caching
More information:
Distribution
Cascaded Caches
1.5.5 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.
1.5.6 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 KPro Implementation Guide (IMG) under SAP Web
Application Server Basis Services Knowledge Provider Distribution Define Cache Preload .
Activities
The Customizing steps you need to implement are also detailed in the Knowledge Provider IMG.
1.6 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:
User
Content Server
Cache Server
Web server
In conjunction with author scenarios, locations can also be used to distribute categories.
PUBLIC
Page 17 of 62
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.
1.6.1 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.
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.
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 .
Use transaction
OACT to maintain the associated category for your repository (see Content Categories).
Create a location (see
Locations).
Maintain the location for IP subnets (see
IP Subnets).
If necessary, maintain the location for hosts (see
Hosts).
Maintain the data for the cache servers you want to use (see
Caches).
If you are using an authoring scenario, you can also define settings for distributing categories (see
Distributing Categories).
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).
PUBLIC
Page 18 of 62
1.6.2 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.
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.
If LU = LC, access is provided directly.
Caching is not carried out.
The caches at the location LU are determined from the host table.
If one cache is found, access takes place via this cache.
If more than one cache is found, the load is automatically distributed among them.
1.6.3 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).
1.6.4 Redirecting the Web Server

Purpose
PUBLIC
Page 19 of 62
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).
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):
1.
2.
3.
4.
5.
6.
Is there a special Web server for the given combination of location and logical document class?
If this is not the case, is there a standard Web server for the logical document class?
If this is not the case, is there a Web server for the logical document class?
If this is not the case, is there a special Web server for the relevant combination of location and document space?
If this is not the case, is there a standard Web server for the document space?
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.
1.6.5 Overview of Transactions

The following section provides an overview of the most important maintenance transactions in the SAP system for maintaining the Content Management Service
and distribution functions.
1.6.5.1 Locations
Transaction Code
Name in the SAP System
OALO
Locations as a distribution criterion
IMG Activity
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.
1.6.5.2 IP Sub-Nets
PUBLIC
Page 20 of 62
Transaction Code
SCMSIP
Locations of IP sub-nets
IMG Activity
Defining locations of IP sub-nets
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
1.6.5.3 Hosts
Transaction Code
SCMSHO
Hosts and properties
IMG Activity
Defining hosts and properties
IP subnet locations (see IP Subnets) can be specified with 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.
1.6.5.4 Content Server Administration

Transaction Code
CSADMIN
Content Server Administration
IMG Activity
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.
More information: Content and Cache Server Administration.
1.6.5.5 Content Repositories

Transaction Code
OAC0
Content Repositories
IMG Activity
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. See
below for more information.
SAP system database
Choose this setting if you want to store your content directly into the SAP system database. See below for more information.
RFC archive
Choose this setting if you want to store documents in an
uses SAP ArchiveLink (see also
SAP ArchiveLink or
Archive Development Kit (ADK) environment, or in an application that
SAP ArchiveLink Application Scenarios) or ADK (see also
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.
PUBLIC
Page 21 of 62
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 creators user name, and the creators 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 OAC0for 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 OAC0to 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 for a HTTP content server repository in OAC0
Usually, the simple administration function is sufficient.

You only need to use full administration in special cases, such as the following: 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.
Repositories in the SAP System Database

To store content in an SAP 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).
You set all this information in the simple administration function for HTTP content server repositories in the SAP system database in transaction OAC0.
Example of a repository in the SAP system database in OAC0
PUBLIC
Page 22 of 62
As before, simple administration is usually sufficient here.

You only need to use full administration in special cases, such as the following: 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.
1.6.5.6 Content Categories

Transaction Code
OACT
Maintain categories
IMG Activity
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.
Background:
A document is identified by its ID and the category. The category here represents the purely logical view. The category is mapped to a content
repository, which represents the physical view.
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.
1.6.5.7 Caches
Transaction Code
SCMSCA
Caches
IMG Activity
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.
PUBLIC
Page 23 of 62
1.6.5.8 Distributing Categories

Transaction Code
OADI
Distributing Categories
IMG Activity
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.
1.6.5.9 Web Servers for Document Spaces

Transaction Code
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.
1.6.5.10 Web Servers for Document Classes

Transaction Code
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.
Specific administration tools are provided to monitor and administrate the underlying
PUBLIC
Database Instance.
Page 24 of 62
Use transaction CSADMIN to go to the 1.7 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.
1.7.1 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
Choose a content server or a cache server.
1. The first time you call up Content Server Administration, the content server selection screen is displayed automatically.
2. If you are already in Content Server Administration, you can choose a server by choosing
The following options are available for calling up the administration functions for a content server:
1. On the Repository tab, enter the name of the content repository that you defined in the
Maintain Content Repositories.
Choose F4 to display a list of options.
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.
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.
1.9.2.4 Functions
PUBLIC
Page 25 of 62
1.7.2.1 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.
PUBLIC
Page 26 of 62
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.
1.7.2.2 Details
Use
The Details tab contains detailed information on the content repositories of the content server.
Prerequisites
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.
1.7.2.3 Certificates
Use
The Certificates tab page contains information on the certificates sent to the Content Server.
Prerequisites
PUBLIC
Page 27 of 62
Features
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
Activities
1.7.2.4 Settings
Use
The Settings tab contains information on the settings for your content repositories.
Prerequisites
Features
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.
1.7.2.5 Statistics
Use
PUBLIC
Page 28 of 62
The Statistics tab provides statistical information from the content server on the individual HTTP commands.
Prerequisites
Features
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.
Activities
1.7.2.6 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
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.
Enter a short description.
Set whether or not digital signatures should be checked.
Change the entries for content storage host, and so on, as required.
Save your entries.
You now have two options:
1. If the creation process is successful, the detailed view (tab page Detail ) opens automatically. The content repository should have the status Running .
2. If the creation process is unsuccessful, check the settings and correct them if required (tab page Settings ). Then try to create the repository again.
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.
1.8 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
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
PUBLIC
Page 29 of 62
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 the 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).
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.
1.8.1 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).
PUBLIC
Page 30 of 62
Features
The following graphic shows an overview of the information provided by the monitoring function:
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
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.
1.8.2 Monitoring for Cache Server

Use
The cache server has an automatic monitoring function.
Prerequisites
The Customizing recognizes the cache server (see also
SCMSCA).
Features
PUBLIC
Page 31 of 62
Activities
Alert Monitor.
To go directly to the Administration screen, double-click on the server name (see also
Content and Cache Server Administration).
1.8.3 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.
Prerequisites
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).
Features
PUBLIC
Page 32 of 62
Activities
Alert Monitor.
1.9 SAP Content Server HTTP 4.5 Interface

This document describes the SAP Content Server HTTP Interface.
Points relevant to the changeover from the former ArchiveLink interface to the SAP Content Server HTTP Interface are explained in this
documentation as they become relevant.
For communication with external storage systems via this interface, SAP AG uses only general industry standards like HTTP and BAPIs.
The HTTP Content Server Interface can be certified.
1.9.1 Introduction
1.9.1.1 Definitions 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:
PUBLIC
Page 33 of 62
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 SAP Content Server HTTP 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).
1.9.1.2 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.
1.9.1.3 Security
Security - that is, ensuring secure data transfer - is a central aspect 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
PUBLIC
Page 34 of 62
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

Secure Store & Forward / Digital Signatures.
1.9.1.3.1 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 senders
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 senders 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
PUBLIC
Page 35 of 62
1.9.1.3.2 Security Level / 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
Create
Change
Delete
The security level applies to all components of a 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, a secKey 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.
PUBLIC
Page 36 of 62
1.9.2 Syntax
1.9.2.1 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 may not contain any blank spaces.
1.9.2.2 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
Compiling the URL
http://pswdf009:1080/ContentServer/ContentServer.dll?get&pVersion=0046&contRep=K1&docId=361A524A3ECB5459E0000800099245EC&accessMode=r&authId=pawdf054_BCE_26&expiration=19981104091537
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
PUBLIC
Page 37 of 62
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.
Encoding the
secKey in the ASCII character set
Base64 must always be used to encode the
secKey.
0x83, 0x70, 0x21, 0x42 -> g3AhQg==
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.
1.9.2.4 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
get
Fetch (within a range) a content unit of a component
docGet
Fetch the entire content of a document
create
Create a new document
mCreate
Creates a number of new documents
append
Append data to a content unit
update
Modify an existing document
delete
Delete a document or a component
PUBLIC
Page 38 of 62
search
Search for a text pattern within a content unit
attrSearch
Search for one or more attributes within a document

(search within a print list)
putCert
Transfer client (for example, the SAP system)

certificate
serverInfo
Retrieve information about the content server and the corresponding content repositories
1.9.2.4.1 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
contRep
mandatory
Default
Sign
X
docId
mandatory
compId
optional
pVersion
mandatory
resultAs
optional
accessMode
s-mandatory
authId
s-mandatory
expiration
s-mandatory
secKey
optional
ascii
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
PUBLIC
Page 39 of 62
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
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 here
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
X-compTimeM
HH:MM:SS
X-compStatus
String
Component status
X-pVersion
String
Interface version
(if known)
There are two methods of coding the results in the response body. These methods are explained below. The parameter
resultAs controls coding.
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 Key Words)) for a component, if known, must be transferred as a Content-Type
parameter.
HTTP/1.1 200 (OK)

Server: Microsoft-IIS/4.0
PUBLIC
Page 40 of 62
Date: Wed, 04 Nov 1998 07:41:03 GMT

Content-Type: multipart/form-data; boundary=A495ukjfasdfddrg4hztzu...
Content-Length: 32413
X-dateC: 1998-10-07
X-timeC: 07:55:57
X-dateM: 1998-10-07
X-timeM: 07:55:57
X-contRep: K1
X-numComps: 2
X-docId: ID
X-docStatus: online
X-pVersion: 0045
--A495ukjfasdfddrg4hztzu898aA0jklmAxcvla12319981147528895
Content-Type: application/x-alf; charset=
Content-Length: 0
X-compId: descr
X-Content-Length: 2591
X-compDateC: 1998-10-07
X-compTimeC: 07:55:57
X-compDateM: 1998-10-07
X-compTimeM: 07:55:57
X-compStatus: online
X-pVersion: 0045
Content-Length: 0
X-compId: data
X-pVersion: 0045
--A495ukjfasdfddrg4hztzu898aA0jklmAxcvla12319981147528895--
If the
info command is executed on an empty document, the response body will contain something like the following:
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).
Access Mode
Read (r)
Client Server
The client sends an
HTTP-GET-Request. The URL can contain the following parameters:
Parameter
Optional/Mandatory
contRep
mandatory
Default
PUBLIC
Sign
X
Page 41 of 62
docId
mandatory
compId
optional
pVersion
mandatory
fromOffset
optional
toOffset
optional
-1
accessMode
s-mandatory
authId
s-mandatory
expiration
s-mandatory
secKey
optional
see above
Example
get&pVersion=0045&contRep=K1&docId=361A524A3ECB5459E0000800099245EC&compId=data
This requests the document component "data".
Server Client
HTTP Status Code
Meaning
200 (OK)
OK, content unit of component is transferred
400 (bad request)
401 (unauthorized)
Security breach
404 (not found)
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

content type parameter).
Content-Length
Total length of body actually transferred
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 Key Words))
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
-
Access Mode
Read (r)
Client Server
The client sends an
PUBLIC
Page 42 of 62

Parameter
Optional/Mandatory
contRep
mandatory
Default
Sign
X
docId
mandatory
pVersion
mandatory
accessMode
s-mandatory
authId
s-mandatory
expiration
s-mandatory
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.
Server Client
HTTP Status Code
Meaning
200 (OK)
OK, document is transferred
400 (bad request)
401 (unauthorized)
Security breach
404 (not found)
409 (conflict)
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
X-timeM
HH:MM:SS
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
X-Content-Length
Integer string
X-compId
String
Component ID
X-compdateC
YYYY-MM-DD
Creation date (UTC)
X-compTimeC
HH:MM:SS
Creation time
PUBLIC
Page 43 of 62
X-compDateM
YYYY-MM-DD
X-compTimeM
HH:MM:SS
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 Key Words)) for a component, if known, must be transferred as a Content-Type
parameter.
Example
HTTP/1.1 200 (OK)
Server: Microsoft-IIS/4.0
Date: Wed, 04 Nov 1998 07:41:03 G MT
Content-Type: multipart/form-data; boundary= A495ukjfasdfddrg4hztzu...
...some more header information...
X-dateC: 1998-10-07
X-timeC: 07:55:57
X-dateM: 1998-10-07
X-timeM: 07:55:57
X-contRep: K1
X-numComps: 2
X-docId: ID
X-docStatus: online
X-pVersion: 0045
X-compId: descr
X-pVersion: 0045
...component data ...

X-compId: data
X-pVersion: 0045
...component data ...
A495ukjfasdfddrg4hztzu898aA0jklmAxcvla12319981147528895
If the
docGet command is executed on an empty document, the response body could contain, for example, nothing between the boundaries:
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 by means of an HTTP PUT or an HTTP POST.
A single component can be transferred using an HTTP-PUT. Alternatively, a HTTP-POST in the format
PUBLIC
Page 44 of 62
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 in a single response.
Function: create with

HTTP-PUT
Default
A new document with the specified
docId is created. One component is 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 are possible:
Parameter
Optional/ mandatory
Position
Sign
contRep
mandatory
Default
URL
compId
mandatory
URL
docId
mandatory
URL
pVersion
mandatory
URL
Content-Type
optional
body
charset
optional
body
version
optional
body
Content-Length
mandatory
docProt
optional
URL
accessMode
s-mandatory
URL
authId
s-mandatory
URL
expiration
s-mandatory
URL
secKey
optional
URL
Header body
server setting
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: create with

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
Position
Sign
contRep
mandatory
Default
URL
compId
mandatory
body
docId
mandatory
URL
pVersion
mandatory
URL
Content-Type
optional
body
charset
optional
body
version
optional
body
Content-Length
mandatory
docProt
optional
accessMode
s-mandatory
Header body
server setting
PUBLIC
URL
URL
Page 45 of 62
authId
s-mandatory
URL
expiration
s-mandatory
URL
secKey
optional
URL
For 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.
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
Content length: 32413
Content part
--A495ukjfasdfddrg4hztzu898aA0jklm
X-compId: data
Content-Type: application/msword; charset=ISO-8859-1; version=6
... 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
Content length: 38
Content part
--KoZIhvcNAQcB
--KoZIhvcNAQcB--
Server Client
HTTP Status Code
Meaning
201(created)
OK, document(s) created
400 (bad request)
401 (unauthorized)
Security breach
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.
PUBLIC
Page 46 of 62
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 are possible:
Parameter
Header Field in Body
Optional/Mandatory
Default
Position
Sign
X
mandatory
URL
compId
"X-compId"
mandatory
body
docId
"X-docId"
mandatory
body (1.
docId also in URL)
pVersion
mandatory
URL
Content-Type
optional
body
charset
optional
body
version
optional
body
Content-Length
mandatory
docProt
optional
accessMode
s-mandatory
authId
s-mandatory
URL
expiration
s-mandatory
URL
secKey
optional
URL
contRep
X (1.
docId)
body
server setting
URL
X
URL
The parameters for which the request body is specified as position are transferred into 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 special status codes, which confirm 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.
400 (bad request)
401 (unauthorized)
Security breach
Specific HTTP Status Codes
Meaning
201(created)
OK, document created
403 (forbidden)
Document already exists
PUBLIC
Page 47 of 62
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 Definitions 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 can contain the following parameters:
Parameter
Optional/Mandatory
Position
Sign
contRep
mandatory
Default
URL
docId
mandatory
URL
compId
mandatory
URL
pVersion
mandatory
URL
accessMode
s-mandatory
URL
authId
s-mandatory
URL
expiration
s-mandatory
URL
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
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.
Server Client
HTTP Status Code
Meaning
200 (OK)
OK, data appended
400 (bad request)
401 (unauthorized)
Security breach
404 (not found)
409 (conflict)
PUBLIC
Page 48 of 62

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 single component of an existing document. One component only can be loaded onto the Content Server. With HTTPPOST (multipart/form-data), on the other hand, the entire document is always overwritten, not just single components. Thus, an entire document is updated to
the latest version by means of a single request.
Function: update with

HTTP-PUT
Default
One component is stored in the content repository. The security level is set according to the standard specified on the server.
Access Mode
change (u)
Client Server
Parameter
Optional/ mandatory
Position
Sign
contRep
mandatory
Default
URL
compId
mandatory
URL
docId
mandatory
URL
pVersion
mandatory
URL
Content-Type
optional
body
charset
optional
body
version
optional
body
Content-Length
mandatory
body
accessMode
s-mandatory
URL
authId
s-mandatory
URL
expiration
s-mandatory
URL
secKey
optional
URL
Function: update with

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.
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
PUBLIC
Page 49 of 62
Parameter
Optional/ mandatory
Position
Sign
contRep
mandatory
Default
URL
compId
mandatory
body
docId
mandatory
URL
pVersion
mandatory
URL
Content-Type
optional
body
charset
optional
body
version
optional
body
Content-Length
mandatory
body
accessMode
s-mandatory
URL
authId
s-mandatory
URL
expiration
s-mandatory
URL
secKey
optional
URL
Server Client
HTTP Status Code
Meaning
200 (OK)
OK, document(s)/component(s) changed
400 (bad request)
401 (unauthorized)
Security breach
404 (not found)
409 (conflict)

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)
Client Server
The client sends an
HTTP-GET-Request. The URL can contain the following parameters:
Parameter
Optional/Mandatory
contRep
Default
Sign
mandatory
docId
mandatory
compId
optional
pVersion
mandatory
accessMode
s-mandatory
authId
s-mandatory
expiration
s-mandatory
secKey
optional
X
X
all components
PUBLIC
Page 50 of 62
Example
http://pswdf009:1080/ContentServer/ContentServer.dll?delete&pVersion=0046&contRep=K1&docId=4B7689654E73D21197E70060B0672A3C&compId=data
Component "data" is deleted in the named document.
Server Client
HTTP Status Code
Meaning
200 (OK)
OK, document/component(s) deleted
400 (bad request)
401 (unauthorized)
Security breach
404 (not found)
409 (conflict)
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.
Access Mode
Read (r)
Client Server
The client sends an
Parameter
Optional/Mandatory
contRep
mandatory
Default
docId
mandatory
pattern
mandatory
compId
mandatory
pVersion
mandatory
caseSensitive
optional
fromOffset
optional
toOffset
optional
-1
numResults
optional
PUBLIC
Sign
Page 51 of 62
accessMode
s-mandatory
authId
s-mandatory
expiration
s-mandatory
secKey
optional
Example
search&pVersion=0046&contRep=K1&docId=4B7689654E73D21197E70060B0672A3C&compId=data&pattern=Manfred%20M%FCller&fromOffset=80
A search for "Manfred Mller" is carried out in the component "data" of the named object from offset 80 to the end.
Server Client
HTTP Status Code
Meaning
200 (OK)
OK, component was searched
400 (bad request)
401 (unauthorized)
Security breach
404 (not found)
409 (conflict)
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 DAIN00100010147119Brselplc.
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
Prolog
DKEY
PUBLIC
Page 52 of 62
Description of attributes
DAIN
Value of attributes
DEPL
Epilog
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 note.
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
72
DPRL
Parameter
73
DKEY
Client
73
DKEY
Company code
73
DKEY
Account number
73
DKEY
Customer name
15
25
73
138
DAIN
001
0001
0147119
Brselplc
211
120
DAIN
001
0002
0147129
Obelixplc
DEPL
1147
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)
Length in Data File
Variable
Separator (space)
Record type ("DKEY")
Attribute names
40
Offset in the DAIN Line Parameter
Length in the DAIN Line Parameter
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)
Length in Data File
Variable
Separator (space)
Record type ("DAIN")
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
PUBLIC
Page 53 of 62
Attribute Name
Offset in the DAIN Line Parameter
Length in the DAIN Line Parameter
Client
Company code
Account number
Customer name
15
25
Attribute Values
Offset in Data File
Length in Data File
Attribute Name
Attribute Value
73
138
Client
"001"
Company code
"00001"
Account number
"0147119"
Customer name
"Brselplc"
Client
"001"
Company code
"00002"
Account number
"0147129"
Customer name
"
Obelixplc"
211
120
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
Coding in the URL).
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).
Access Mode
Read (r)
Client Server
The client sends an
Parameter
Optional/Mandatory
Default
contRep
mandatory
docId
mandatory
pattern
mandatory
pVersion
mandatory
caseSensitive
optional
fromOffset
optional
toOffset
optional
-1
numResults
optional
accessMode
s-mandatory
authId
s-mandatory
expiration
s-mandatory
PUBLIC
Sign
Page 54 of 62
optional
secKey
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.
Server Client
HTTP Status Code
Meaning
200 (OK)
OK, component was searched
400 (bad request)
401 (unauthorized)
Security breach
404 (not found)
409 (conflict)
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.
1.9.2.4.2 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
authId
mandatory
PUBLIC
Sign
Page 55 of 62
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.
Server Client
HTTP Status Code
Meaning
200 (OK)
OK
400 (bad request)
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 are possible:
Parameter
Optional/Mandatory
Default
contRep
optional
All repositories
pVersion
mandatory
resultAs
optional
Sign
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.
Server Client
HTTP Status Code
Meaning
200 (OK)
OK
400 (bad request)
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
PUBLIC
Text describing server status
Page 56 of 62
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.
1.9.2.5 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 documents created (if
mCreate was used)
create, mCreate
250 (missing documents created)
OK, all missing documents were created
mCreate
400 (bad request)
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.
PUBLIC
Page 57 of 62
1.9.3 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, SAPs 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 Caches, and Content Server Aliases. You can also get information from the SAP Integration and Certification Centers.
1.9.4 Appendix
1.9.4.1 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.
PUBLIC
Page 58 of 62
Additional information for partners who already support the 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/formdata). 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
PUBLIC
Page 59 of 62
[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 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
PUBLIC
Page 60 of 62
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.
1.9.4.2 Migrating Existing Archives

This section is only relevant for partners who supported the ArchiveLink interface in the past and who now want to support the new SAP 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 former 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.
PUBLIC
Page 61 of 62
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 important. 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
PUBLIC
Page 62 of 62

CRM Content Server 1 PDF

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CRM Content Server 1 PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Content Management Service (BC-SRV-KPR)

PDF download from SAP Help Portal:

1.9.1.3.2 Security Level / Access Permissions

Content Management Service (BC-SRV-KPR)

1.1 Storage Types

The individual entities are explained in detail below (see also

Document Management with Knowledge Provider):

Document Classes and Categories

Repositories and Categories

HTTP Access for Repositories on SAP Web Application Server

HTTP Communication with the SAP System as a Server).

HTTP access to the database repository

Use the class CL_HTTP_EXT_CSIF to implement SAP Content Server interface.

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

This user type corresponds to the former CPIC user.

Do not assign any permissions to this user.

Store User in the SICF

Call transaction SICF.

Creating an ICF Service.

1.2.2 Storing URLs

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

1.3 SAP Content Server

MaxDB and is available on Microsoft Windows operating systems as of Release 4.6.

integrated via the HTTP interface (see

Architecture of the SAP Content Server

Advantages of the SAP Content Server

1.3.3 Security Mechanisms of the SAP Content Server

1.3.3.1 Secure URLs

Secure Store & Forward / Digital

1.3.3.2 Protection Against Tapping and Forging of the Data

Security Mechanisms Against Data Loss

1.3.3.4 Creating a System-Specific Certificate for Content

in the next popup ( Replace PSE ).

Access Protection for Administration

1.4 Logical Repository

Logical repositories are maintained in transaction OAC0.

1.5 Knowledge Provider and Caching

Caching is not the same as replication.

Front-End Cache in the SAPGUI

1.5.1 Cache Servers

1.5.1.1 Architecture of the Cache Server

1.5.1.2 Deletion Strategy and Performance

1.5.1.3 Optimal Access Path for Client Requests

1.5.2 Customizing for Caching

1.5.3 Cascaded Caching

1.5.4 Content Server Aliases

Cascaded Caching and Content Server Aliases

1.5.5 Cascaded Caching and Content Server Aliases

1.5.6 Cache Preload

Distribution is intended for the following situations:

1.6.1 Configuring the Distribution Settings

The procedure comprises the following steps:

1.6.2 Reading via Distributed Cache Servers

1.6.3 Different Locations with Different Content Servers

1.6.4 Redirecting the Web Server

1.6.5 Overview of Transactions

Name in the SAP System

Locations as a distribution criterion

Name in the SAP System

Name in the SAP System

Hosts and properties

1.6.5.4 Content Server Administration