Multi-Layer Caching and Content Server Aliases
Use
The SAP system knows the locations of the connected content servers, cache servers, and client. Two concepts work together in order to determine the optimum access path for client requests: Multi-layer caching and content server aliases.
-
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).
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 using content server aliases can be handled in such a way that controlled content server accesses from the extranet can be allowed using 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 which all access the same physical database. In the third-party area there are some vendors that use upstream 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 subnets
-
SCMSIPNET – location for subnets (TA SCMSIP from release 4.6C)
The table SCMSIPNET allows you to define the location using the IP address. The subnet 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 subnets 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. In this way automatic load distribution takes place.
-
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 ( C ontent S erver P ro x ies)
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. Note the exact spelling when you specify technical data. Upper and lowercase is relevant. 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 disabled
-
SCMSCSPL - Further locations content server aliases ( C ontent S erver P roxy L ocations)
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.
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.
Restrictions
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.
