You typically use invalidations rules to expire specific content stored in cache. When you invalidate content, that content is immediately expired but not removed from the disk.
For the invalidations rules examples, you have four top-level nodes on the Policy Tree as follows:
For this example, any request for the /apps/doSomething.jsp application changes content returned by /srch/doSimpleSearch.jsp. However, you want requests for doSimpleSearch.jsp to be updated only if its producttype query parameter matches the value set for the group query parameter on doSomething.jsp.
For example, consider the following request:http://www.somesite.com/apps/doSomething.jsp?group=Doors&....
The WebAccelerator™ system should send, to the origin web server, any subsequent requests that appear as follows:http://www.somesite.com/srch/doSimpleSearch.jsp?producttype=Doors&....
To accomplish this, you create an invalidations rule for the Default leaf node, because you know that all requests for the path, /apps/doSomething.jsp, match to that node. The target, requests for doSimpleSearch.jsp, always match to the Search node and should include a producttype query parameter when a value matches the value of group in the triggering request for /apps/doSomething.jsp. Therefore, the Cached Content to Invalidate setting should specify doSimpleSearch.jsp for the path, and producttype for the query parameter.
Perform these tasks to configure the invalidations blog example Post node.