Clientside Caching
Depending on the Web browser settings, you can store Web pages in the Web browsers cache. To a limited extent, this caching behavior can be influenced by users, so you must assume that the user has configured a given behavior.
To handle this, you need to influence the browser's caching behavior from the server side to ensure that when the user performs an action in the browser, a requested page is not taken from the browser's local cache but is displayed after communication with the SAP system.
Undesired caching causes problems when the request method get is used. This method has the semantics of a pure read operation and is used with hyperlinks. It is not absolutely necessary to communicate with the server if the browser can fall back on a result which exists for an earlier request. The worst case scenario is that the server is not activated by the user action.
Suppose the service ECS3 is to be activated via the hyperlink
"http://pn0208:1080/scripts/wgate.dll?~Service=ECS3"
The first time this hyperlink is selected, the request from the browser is sent to the server, which returns the relevant page and starts the appropriate service. The browser stores this page in the local cache. If the configuration is appropriate, the next time the user selects this hyperlink, the browser will load this page directly from the cache without communicating with the server. This means that no service is started on the server side. When the user has finished with the cached page and sends it to the server, the server responds to the request with the error message
Session not found!
This response is correct, since no service was started.
If you use a form ( <form> tag) and a request is sent to the server via the post method, this problem does not arise. The post method has update semantics, causing the browser to communicate with the server when a request is made.
In Web transactions, you must use post to trigger actions with updates. You cannot use hyperlinks.
Using an Expiration Date
To be able to use both request methods equally, pages given to the browser by the server should be allocated an expiration date according to their type. This allows you to control when the browser should consider a page to be out-of-date and no longer access it in the cache. When such a page is activated, the browser will re-establish contact with the server.
Use the HTTP header " Expires" to define the expiration date and give it the value "0" to instruct the browser not to cache this page.
This HTTP header is only used for pages which are addressed using the "get" method, for example, via a hyperlink. Pages which are read by "post" are not given an expiration date.
To ensure that automatic cache control functions correctly, the caching behavior of HTML templates must not be influenced by subsequently adding < meta http-equiv...> tags.
Frame Set Documents
To start a service indirectly via a frame set document you should assign an expiration date to this page statically. This guarantees that the service will actually be started.
The following example shows an indirect service start using a static frame set page:
<a href="http://pn0208:1080/ecs1/index.html"> Service ECS1 </a>
Contents of index.html:
<html><head><title> Order Status </TITLE>
<meta http-equiv="Expires" content="0"> <!-- IMPORTANT!! -->
</head>
<frameset rows=90,*>
<frame name="PRISMA" src="/ecs1/uptodate.html" scrolling="no" >
<frame name="R3" src="/scripts/wgate.dll?~Service=ECS1">
</frameset>
</html>
If the initial pages are static and they are activated using the get method, the tag <meta http-equiv="Expires" content="0"> must be specified in the < head> area of the HTML page. Please note the uppercase and lowercase characters in " Expires".