Understanding Content Caching Understanding Service Caching with the Site Studio Tag Library

1-8 Oracle Fusion Middleware Developers Guide for Site Studio for External Applications

1.8 Understanding Content Caching

Content is cached in a temporary location on the application server. This can be customized to a particular location using the stagingDir attribute on the staging element in the wcm-config.xml file. The content cache stores a local copy of all files, associated metadata, and any associated conversions or renditions. Any request for content first checks the local cache. If not found, the content server is contacted and the content is placed into the cache. Note that no security information is cached; all security calls go to the content server. Additionally, only Latest Released content is cached; content retrieved during contributor or design modes Latest Rendition is not put into the cache. A background thread, controlled by the contentServer element using the pollerInterval attribute, pings the content server at regular intervals to keep the cache content up to date. A content server administrator can request all caches be refreshed by visiting the Cache Administration page on the content server at this URL example: http:localhost:16200csidcplg?IdcService=SSXA_GET_ADMIN_PAGE

1.9 Understanding Service Caching with the Site Studio Tag Library

The caching facilities in Site Studio allow for the caching of service calls. Any service call can be cached to the same location that content and metadata is currently cached. The caching facility is defined using DataBinder properties: 1. Specify a special parameter to enable caching. 2. Determine the cache key using one of the following methods: ■ Specify a custom cache key. ■ Specify the local data fields to use to generate a key. ■ Allow the system to calculate the cache key by using a hash of all local data. Caching Properties All caching is controlled using properties set in the DataBinder. For JSPJSPX, these properties can be added with the wcm:idcParameter tag to either a wcm:idcService call or a wcm:dynamicList call. Parameters: ■ __ssxaCacheEnabled: Set to true to enable caching. ■ __ssxaCacheKey: Specify a cache key to use for this request. Optional. ■ __ssxaCacheFields: Specify a comma-separated values CSV list of fields to use to generate the cache key if not specified, all local data is used. Optional. ■ __ssxaCacheTTL: Specify a time to live value, in milliseconds, for the cached data. If not specified, the default value of 5 minutes is used. If value of 0 zero or less is specified, the cache item will live indefinitely no timeout. Optional. Example of caching a dynamic list, with the value being refreshed every 60 seconds: wcm:dynamicList var=searchResponse element=nativedocs wcm:idcParameter name=__ssxaCacheEnabled value=true wcm:idcParameter name=__ssxaCacheTTL value=60000 wcm:dynamicList About Site Studio for External Applications 1-9 Example of caching a GET_SEARCH_RESULTS service call: wcm:idcService var=dataBinder service=GET_SEARCH_RESULTS wcm:idcParameter name=QueryText value= wcm:idcParameter name=__ssxaCacheEnabled value=true wcm:dynamicList Cache Details Service calls are staged into the cache directory, alongside the content, metadata and project files. The directory idc-service is created with this directory structure: idc-serviceservice_nameuser_namecacheID.hda This example shows a cache directory for a GET_SEARCH_RESULTS service call: +- idc-service +- ssxa_get_dynamic_list_results +- anonymous +- 3164744485.hda +- get_search_results +- anonymous +- 2452981209.hda

1.10 Understanding Site Studio JSPJSPX Templates