Multi-Layer Caching and Content Server Aliases (SAP Library

Multi-Layer Caching and Content Server Aliases

The SAP system knows the locations of the connected content servers, cache servers, and client. The concepts of multi-layer caching and content server aliases work together to determine the optimal access path for client requests.

Multi-layer caching means that multiple caches between the client and the server are accessed when a read access attempt is made on the content server.

In complex environments, especially those with firewalls, multiple servers may be involved in the handling of a request, regardless of the locations of the servers. Each of these servers plays a role in retrieving the requested content, or, as the case may be, in forwarding the request (similarly to cascaded caches).

These servers are known as content server aliases (in the sense that they "represent" the content server).

Note

A content server alias can be, for example, an IP filter on a firewall that forwards the requests unchanged to the content server. An alias can also be an instance of a distributed content server, provided that the content server in question supports this. This option is particularly intended for content server providers who can themselves organize distributed storage or content caching, or both.

The concepts of multi-layer caching and content server aliases mutually support each other. The main aim of multi-layer caching is to minimize access times. Also, URLs received via a content server alias can be handled in such a way that controlled content server accesses from the extranet can be allowed via a firewall.

Using Content Server Aliases

Firewalls: regardless of the location of the client, the client may on occasion directly access the content server using the actual host name (intranet) or via a firewall using an abstract domain name (extranet).

Distributed servers that all access the same physical database: there are some third-party providers that use what are known as "satellite servers" instead of caching. Satellite servers make it possible to access a repository via multiple content servers. Using the alias concept, you can designate one of these satellites as the actual content server, and the others as its aliases.

Using Multi-Layer Caching

To use multi-layer caching, the locations of the client, content server, and caches have to be known, just like with single-layer caching. You must also decide which path will be used to access the content server from a specific location. You have to maintain the following tables:

SDOKLOC - locations (transaction OALO)

The table SDOKLOC defines the possible locations. Enter all the locations here.

SCMSIPNET – location for sub-nets (TA SCMSIP from release 4.6C)

The table SCMSIPNET allows you to define the location using the IP address. The sub-net is defined using the format XXX.XXX.XXX.XXX/YY. XXX.XXX.XXX.XXX is the usual format for IP addresses. /YY (/00 .. /32) defines how many bits, beginning from the left, are valid. If multiple sub-nets are assigned to one IP address, the smallest sub-net is the one that applies (that is, the one for which the most bits are defined). The location determined for the user in this way can be overwritten by the user parameter LCA.

SCMSHOST – properties of hosts (transaction SCMSHO from release 4.6C).

The table SCMSHOST defines the location of hosts. Enter all hosts here that are used as content servers or cache servers. Make sure that you enter the host names correctly, including upper case and lower case letters.

SCMSCACHE – definition of caches (transaction SCMSCA from release 4.6C)

The table SCMSCACHE defines the cache server. Enter all cache servers here. If a particular cache server is inactive, you can mark it accordingly.

SCMSLOPA – location path for multi-layer caching

To enable multi-layer caching, enter the path on which the cache server should be used. Do this for two locations at a time. The fields LOC_CLNT and LOC_DEST define the location of the client and the content server. The field LOC_INDX is numbered from 1 to N. The locations between the client and the server are entered in the field LOC_NODE. Do not enter the locations of the client and the server themselves. The location LOC_NODE = 1 is the closest to the client, while the location LOC_NODE = N is closest to the server.

If signed URLs are being used, the content server and the cache server have to closely interoperate. Therefore, caching can only work if the content server has the version number 0046, or if no signature is used for access.

Procedure for Read Access

The system determines the location of the client (LCA parameter, SCMSIPNET).

The system determines the location of the content server (SCMSHOST, SCMSIPNET).

The system determines the path between the client location and the server location (SCMSLOPA). If the client and the server are at different locations, the client location is inserted at the beginning of the path.

The available cache servers are determined for every location on the path. If multiple caches are available at one location, one is selected. Load distribution is automatically used at this location.

A URL is then constructed that ensures that the content servers and cache servers along the path are searched for the content in question. The retrieved content is then stored in all cache servers between the client and the content server or the cache where the content was found.

Incorporating a Content Server Alias

You have to make the following Customizing settings:

SCMSCSPX – content server aliases (the CSPX here comes from content server proxies, an alternative term for aliases).

The technical data of the alias is stored in this table. By specifying the technical data of the content server, you define which content server is represented. Ensure that you enter all the technical details correctly, including upper-case and lower-case characters. The individual fields have the following meanings:

PX_SERV	Host name of the alias server
PX_PORT	Port of the alias server
PX_SPORT	SSL port of the alias server
PX_SCRPT	HTTP script of the alias server
CS_SERV	Host name of the content server
CS_PORT	Port of the content server
CS_SPORT	SSL port of the content server
CS_SCRPT	HTTP script of the content server
NO_GET	Alias is not used for ‘cacheable’ get requests
INACTIVE	Entry inactive

SCMSCSPL – other locations of content server aliases (the CSPL here comes from content server proxy locations).

This table contains other locations, besides those entered in table SCMSHOST, that can also be used for the alias server.

The data for the content server must be exactly the same as that in the Customizing for the repository (transaction OAC0).

Only from release 4.6D can you explicitly specify the port. Up to release 4.6C, the port is added at the end of the content server name in the form :<port>.

You have to explicitly define the HTTP port when defining the alias server. In releases before 4.6D, leave the SSL port at its initial value.

The field NO_GET can be used to specify that a content server alias is not to be used for ‘cacheable’ get requests.

Note

This is useful if the caches can support the cacheable get requests better than the alias.

The field INACTIVE can be used to stop the alias in question being used.

Determining the Alias

The system checks whether there is an alias for the content server in question at the client’s location.

If there is no alias at that location, the system looks for another alias that can be used.

If an alias is found, the technical data of that alias is used instead of those of the content server.

If more than one alias is found, load distribution is used automatically.

Multi-layer caching and aliases can also be used in combination. The system always looks for an alias first. If it finds one, the technical data of the alias is used instead of the data of the content server. This means that the location of the server may change. This information is then taken into account when the cache server is being located.

Constraints

Caching and content server aliases are only used if the client location is known when the URL is being constructed. Usually, the client location is known if the Knowledge Provider processes 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 caches and the alias server do not, therefore, play any role.

This can often be the case with ArchiveLink.

Related Notes

0181696, Caching

0209478, SAP KPro Server Infrastructure Components 4.6C

0303278, SAP KPro Server Infrastructure Components 4.6D

0352518, Using the SAP Content Server Cache

0376033, Cache Server Knowledge Warehouse 5.1

0407520, Information on the Cache Server