Integrating Oracle iStore with Oracle Application Server Web Cache

This chapter covers the following topics:

Overview of Integrating Oracle iStore with Oracle Application Server Web Cache 10g Chapter

This chapter describes the integration of Oracle iStore with Oracle Application Server Web Cache 10g.

Important: Oracle iStore is certified with Oracle Application Server Web Cache 10g (10.1.2). Implementers should refer to Oracle Application Server Web Cache 10g documentation for detailed menu steps, both those generic in nature and those specific to the setup of Oracle iStore.

Oracle iStore with Oracle Content Manager integration is not certified with Oracle Application Server Web Cache 10g. If Oracle Content Manager is enabled, .gif/.jpg files will not be cached.

Overview of Oracle Application Server Web Cache 10g

An integrated component of Oracle's application server infrastructure, Oracle Application Server Web Cache 10g is an innovative content delivery solution designed to accelerate dynamic web-based applications and reduce hardware costs.

Oracle Application Server Web Cache 10g accelerates the customer presentation of Oracle iStore's non-transactional content, including:

By compressing and caching dynamically generated content, Oracle Application Server Web Cache 10g reduces the load on the other tiers in the architecture and shortens the amount of time required to serve cached content. Once a page is loaded into the cache, other requests for the same page are served from the cache memory instead of the application server.

Through the inclusion of a set of Oracle Application Server Web Cache 10g-specific tags in the HTML, Oracle Application Server Web Cache 10g is also capable of caching content with some personalization.

Additionally, the cache server can load balance requests across multiple HTTP servers.

Oracle Application Server Web Cache 10g is compatible with Oracle HTTP Server or any other HTTP-compliant application web server.

Possible scenarios for deployment of Oracle Application Server Web Cache 10g include the following:

Oracle iStore Functionality with Oracle Application Server Web Cache 10g

In order to integrate Oracle Application Server Web Cache 10g with the Oracle iStore Customer UI, you must deploy it in the same domain as the application web servers. The reason for deploying it in the same domain is that Oracle iStore session cookies are created by application servers and are only visible to other servers within the same domain. The subdomain, however, can be different.

You can set up Oracle Application Server Web Cache 10g to cache and serve the following Oracle iStore pages and files:

For complete information about Oracle Application Server Web Cache 10g deployment, see documentation for Oracle Application Server Web Cache, Release 10g. If you are running a version of Oracle Application Server Web Cache 10g other than the one listed here, please use the documentation appropriate to your version.

Preview Mode Not Supported Through Oracle Application Server Web Cache 10g

Oracle iStore's Preview mode allows merchants to preview Customer UI specialty sites while working on them in the Site Administration UI. In a typical scenario, when the merchant selects the Preview button in Site Administration UI, the Customer UI is retrieved through the application server and uses data cached through JTT Cache. This ensures freshly cached data.

There may be cases, however, when the merchant enters Preview mode through Oracle Application Server Web Cache 10g. This type of preview is not supported due to likelihood of seeing stale cached data.

Using Oracle Application Server Web Cache 10g with SSL

Other than setting the profile options listed in the next paragraph, nothing specific from Oracle iStore is required when using Oracle Application Server Web Cache 10g with Secure Socket Layer (SSL) functionality. Check Oracle Application Server Web Cache 10g documentation for details of setup with SSL.

When integrating Secure Socket Layer functionality with Oracle Application Server Web Cache 10g, set the profile options, IBE: iStore Non Secure URL and IBE: iStore Secure URL to the web cache non secure and secure URL.

For example, set IBE: iStore Secure URL to https://<web cache servername>:<port number>/<JSP directory or OA_HTML>/.

Bounce the server after making these changes.

Setting up Oracle Application Server Web Cache 10g

Set up Oracle Application Server Web Cache 10g to cache and serve Oracle iStore Customer UI pages, using the procedures in the following sections.

For complete information about Oracle Application Server Web Cache 10g deployment, see documentation for Oracle Application Server Web Cache, Release 10g. If you are running a version of Oracle Application Server Web Cache 10g other than the one listed here, please use the documentation appropriate to your version.

Prerequisites

Your Oracle iStore implementation must meet the following requirements for integration with Oracle Application Server Web Cache 10g:

Implementation Steps

Step 1 - Perform Initial Setup for Oracle Application Server Web Cache 10g

Check your deployment requirements. Make sure the following Oracle Application Server Web Cache 10g setups are correct:

Step 2 - Create a Rule for Multiple Documents with Same Selector (URL) by Cookies

You can set up Oracle Application Server Web Cache 10g to use the Oracle iStore cookie, CombinedCookie, to identify multiple versions of the same catalog page based on the cookie value. CombinedCookie allows the Web Cache to then cache the page versions separately for different users.

CombinedCookie combines:

While serving a page, Web Cache looks at the CombinedCookie to determine if the appropriate version of the page is available in the cache. If it is available, then the page is served from the cache. If it is not, the request is forwarded to Apache/Jserv and the resulting page is cached against that page version.

Using the steps below, create a rule for multiple documents with the same selector by the CombinedCookie cookie.

You will later create a selector association between this rule and the catalog JSPs, as described later in this chapter.

Steps

  1. In Oracle Application Server Web Cache Manager, select Rules for Caching, Personalization, and Compression > Cookie Definitions.

  2. In the Cookie Definitions screen, select Add.

  3. In the Edit/Add Cookie Definition screen, enter CombinedCookie in the Enter cookie name: textbox.

  4. In answer to the question, Also cache documents whose requests do not contain this cookie?, select No.

  5. Select Submit.

Step 3 - Create Session/Personalized Attribute Definitions

Session tracking does not alter the actual content of a page. Therefore, session definitions enable Oracle Application Server Web Cache 10g to share the same caches with multiple sessions by substituting one user's session information with another's based on the session information in the session cookies.

For Oracle Application Server Web Cache 10g to serve pages to a client browser, the browser's cookies must be enabled. If cookies are disabled, Oracle iStore still works, but Web Cache does not serve its pages. Instead, Web Cache redirects any HTTP request that does not include session cookies to the application servers.

Oracle iStore uses the following session cookies:

You must create the session definitions JTTSession and ICXSession so that Web Cache can track the session cookies.

You must also create personalized attribute definitions for the Oracle iStore cookies PersonName and CartTotal.

Oracle Application Server Web Cache 10g can use the Oracle iStore cookies listed in the following table to share the same cache with multiple users by substitution of personalized information into the catalog pages' welcome bin.

Oracle iStore Cookies for Welcome Bin Personalization
Cookie Function
UserNameCookie PersonName
CartTotalCookie CartTotal
ICXSession The ICX Session Cookie name is <DB_HOST>_<DB_NAME>, where the values for DB_HOST and DB_NAME come from the .dbc file in the directory $FND_TOP/secure/. The same value should be put in URL or POST Body Parameter.
JTTSession The JTT Session Cookie name is <<DB_HOST>_<DB_NAME>_p<JTT Cookie property value>. You can set the property in Oracle Business Center. The same value should be put in URL or POST Body Parameter.

Oracle Application Server Web Cache 10g's substitution of personalized information into cached pages is called Session-Encoded URL Association. ibeCAcdWelcome.jsp, the seeded JSP for the Welcome Bin, includes the Oracle Application Server Web Cache 10g tags for Session-Encoded URL Association within HTML comments, which are transparent to application servers. You will later enable Session-Encoded URL Association as described in the section, "Create Session-Encoded URL Association".

If you are previewing the specialty site display of items and sections before publishing them, you should access the application server directly and not via Web Cache. This ensures that you are previewing the latest version of the pages.

Steps

  1. In Oracle Application Server Web Cache Manager, select Rules for Caching, Personalization, and Compression > Session Definitions.

  2. In the Session Definitions screen, select Add.

  3. Select either the For all sites or Specific site radio button, depending upon whether you have enabled the Oracle E-Business Suite Web Cache rules to be site specific or generic to all sites. If you have defined the Oracle E-Business Suite Web Cache rules to be site specific, then Oracle iStore rules also should be site specific. Conversely, if you have defined the Oracle E-Business Suite Web Cache rules to be for all sites, then ensure that the iStore cacheing rules are for all sites. Also ensure that the Oracle iStore cacheing rules are sequenced prior to the Oracle E-Business Suite Web Cache rules.

  4. Using the data in the following table, create the sessions and personalized attributes listed in the table.

  5. Select Submit.

The following table shows the session and personalized attribute definitions.

Web Cache Session and Personalized Attribute Definitions
Session/Attribute Cookie Name
UserNameCookie PersonName

Additional Information: Leave URL or POST Body Parameter values blank.
CartTotalCookie CartTotal

Additional Information: Leave URL or POST Body Parameter values blank.
ICXSession See Finding a Value for ICXSession Cookie, below.

Additional Information: The same value should be put in URL or POST Body Parameter.
JTTSession See Finding a Value for JTTSession Cookie, below.

Additional Information: The same value should be put in URL or POST Body Parameter.

Note: Customers who are running Oracle iStore patchset IBE.M and above must remove or disable the following two personalized attributes and related caching rules: SignInOutUrlCookie and SignInOutImageCookie. These personalized attributes were obsoleted in Oracle iStore patchset IBE.M.

Finding a Value for ICXSession Cookie

Derive the ICXSession cookie value from the following procedure:

  1. Find the value of the ICX_PARAMETERS.SESSION_COOKIE_NAME column:

    Look at the ICX_PARAMETERS.SESSION_COOKE_NAME using the following query:

    select session_cookie_name from icx_parameters

  2. If the ICX_PARAMETRS.SESSION_COOKE_NAME value is null, look up the APPS_DATABASE_ID profile value. To do so, log into Oracle Forms with System Administrator responsibility and query for the profile in the Find System Profile Values Form. For more information about using Oracle Applications profile options, see the Oracle E-Business Suite Setup Guide.

  3. If the APPS_DATABASE_ID profile value also is null, then the ICX cookie name should be derived from DB_HOST_DB_NAME.

Finding a Value for JTTSession Cookie

The value for JTTSession cookie is the ICXSession cookie name value (plus _p) with the JTTCookie property value appended. In other words:

JTTSession Cookie name = <ICX Session cookie name>_p<JTTCookie Property Value>

Use the following procedure to find the value of the JTTCookie property value:

  1. Log in to Oracle CRM Login Servlet as the System Administrator.

  2. Navigate to Settings, then Properties, then Advanced.

  3. Select JTF in the View list of values.

  4. Find the key, cookie_name, in the table. This is the value of the JTTCookie property to use in the JTTSession cookie value.Find the key, cookie_name, in the table. This is the value of the JTTCookie property to use in the JTTSession cookie value.

Note: Ignore the semicolon (;) in the property value.

Step 4 - Create Session/Personalized Attribute Related Caching Rules

You must create caching rules for the sessions and personalized attributes that you have defined. Use the following steps to create caching rules for previously established sessions.

Steps

  1. In Oracle Application Server Web Cache Manager, select Rule Association > Session Caching Policy Association.

  2. In the Session Caching Policy Association screen, select Add.

  3. In the Add Session Caching Policy screen, select a session and answer the questions for the session, using the parameters specified in the table below.

  4. Select Submit when finished.

Web Cache Session/Personalized Attribute Caching Rules
Session Cache documents whose requests contain this session? Cache documents whose requests do NOT contain this session? Can the default session value be used for substitution...?
UserNameCookie Yes No No
CartTotalCookie Yes No No
ICXSession Yes Yes No
JTTSession Yes No No

Note: If you have already set up Oracle Application Server Web Cache 10g with iStore 11.5.6, please remove the following personalized attribute definitions and the related caching rules: SignInOutImageCookie and SignInOutUrlCookie.

Step 5 - Create Cacheability Rules

Set up Oracle Application Server Web Cache 10g to cache all Oracle iStore catalog pages, except ibeCCtpBuyRoute.jsp, for the HTTP methods GET, GET with query string, and POST with any parameters. The Oracle iStore catalog pages are named ibeCCt*.jsp.

Additional Guidelines

Steps

  1. In Oracle Application Server Web Cache Manager, select Rules for Caching, Personalization, and Compression > Caching, Personalization, and Compression Rules.

  2. Select the last default rule or the last site specific (depending upon whether caching rules are site specific or for all sites) and press Insert Below.

  3. Using the data in the following tables, create cacheability rules.

  4. Select Submit when finished.

The following table shows Part 1 of the cacheability rules.

Web Cache Cacheability Rules (Part 1)
Priority Name Expression Type URL Expression HTTP Methods
1 iStore as files Regular Expression \.js$ GET, GET with query string
2 iStore route jsp files Regular Expression /OA_HTML/ibeCCtpBuyRoute\.jsp.* GET, GET with query string, POST
3 iStore Catalog jsp files Regular Expression /OA_ HTML/ibeCCt.*\.jsp.* GET, GET with query string, POST
4 iStore jtfdload files Regular Expression /OA_HTML/jtfdload.jsp GET, GET with query string

The following table shows Part 2 of the cacheability rules.

Web Cache Cacheability Rules (Part 2)
Priority URL and POST Body Parameters POST Body Expression Cache Policy Compression Enabled
1 n/a n/a Cache None Yes
2 n/a .* Don't cache On for all browsers Yes
3 n/a .* Cache On for all browsers Yes
4 n/a n/a Cache None Yes

Step 6 - Create Expiration Rules

When you change catalog content, Oracle Application Server Web Cache 10g does not automatically invalidate cached pages. You must define expiration rules based on a time interval or invalidate cached pages manually in Web Cache Manager. Expiration rules specify when documents expire in the cache, and how long documents can reside in the cache after they expire.

You should set up your expiration rules according to your content management needs. Since Oracle iStore JSPs and HTML pages do not include expiration headers, you cannot set up expiration rules for these pages using "As per HTTP Expires header."

Here is an example of some expiration rules that you can define:

To set up these sample expiration rules, use the following procedure.

Steps

  1. In Oracle Application Server Web Cache 10g Manager, select Rules for Caching, Personalization, and Compression > Expiration Policy Definitions.

  2. In the Expiration Policy Definitions screen, select Add.

  3. In the Create Expiration Policy screen, add two expiration policy definitions, using the following table as a guide.

  4. Select Submit when finished.

The following table shows the expiration rules setup for Expire and After Expiration.

Web Cache Expiration Rules (Part 1)
Expire After Expiration
7200 seconds after cache entry Refresh on demand as application web server capacity permits AND no later than: 120 seconds after expiration
172800 seconds after cache entry Refresh on demand as application web server capacity permits AND no later than: 300 seconds after expiration

After adding the expiration policy definitions, create the rule associations using the following steps and table.

Steps

  1. In Oracle Application Server Web Cache Manager, select Rule Association > Expiration Policy Association.

  2. In separate procedures, select the radio buttons of the rules shown in the table above and press the Change Rule Association button.

  3. In the Change Expiration Policy Association screen, map the expiration rules and selector associations listed in the following table.

  4. Press Make Association when finished.

The following table shows the expiration rules setup for Expire, After Expiration, and Selector Association.

Web Cache Expiration Rules (Part 2)
Expire After Expiration Selector Association
7200 seconds after cache entry Refresh on demand as application web server capacity permits AND no later than: 120 seconds after expiration \.html?$, \.css, \.js$, /OA_HTML/ibeCCt.*\.jsp.*
172800 seconds after cache entry Refresh on demand as application web server capacity permits AND no later than: 300 seconds after expiration \.(gif|jpe?g|png)$, /OA_HTML/jtfdload\.jsp.*

Step 7 - Create a Selector Association for the Multiple Documents Rule

Create a selector association to associate catalog JSPs with the rule for multiple documents with the same selector by the Oracle iStore cookie CombinedCookie.

Steps

  1. In Oracle Application Server Web Cache Manager, select Rule Association > Cookie Association.

  2. In the Cookie Association screen, select the rule for the cookie, CombinedCookie, and select Change Rule Association.

  3. In the Change Cookie Association screen, create an association between the selector /OA_HTML/ibeCCt.*\.jsp.* and the rule.

  4. Press Make Association when finished.

Step 8 - Create Selector Associations for Sessions and Personalized Attributes

You must associate the selectors that are listed in your cacheability rules with the sessions and personalized attributes that you have defined. Apply the session definitions JTTSession and ICXSession to all cached JSPs. Do not bind them to other cached files, such as image files and scripts. Use the following steps to create selector associations for sessions/personalized attributes.

Steps

  1. In Oracle Application Server Web Cache Manager, select Rule Association > Session Caching Policy Association.

  2. In the Session Caching Policy Association screen, select a session or attribute and press Change Rule Association.

  3. In the Change Session Caching Policy Association screen, make the selector associations listed in the following table for each session and attribute.

  4. Press Make Association when finished.

The following table shows the session or attribute and the selector associations.

Web Cache Session/Personalized Attribute Selector Associations
Session/Attribute Selector Associations
UserNameCookie /OA_HTML/ibeCCt.*\.jsp.*
CartTotalCookie /OA_HTML/ibeCCt.*\.jsp.*
ICXSession /OA_HTML/ibeCCt.*\.jsp.*/OA_HTML/jtfdload.jsp
JTTSession /OA_HTML/ibeCCt.*\.jsp.*/OA_HTML/jtfdload.jsp

Step 9 - Create Session-Encoded URL Association

Use the following procedure to set up session-encoded URL association.

Note: The functionality previously referred to as "simple personalization" is now termed "session-encoded URL association".

Steps

  1. In Oracle Application Server Web Cache Manager, select Rule Association > Session-Encoded URL Association.

  2. In the Session-Encoded URL Association screen, select an association and press Change Rule Association.

  3. In the Change Session-Encoded URL Association, from the list, select the following:

    • <your Web Cache host: port>, /OA_HTML/ibeCCt.*\.jsp.*, GET/GET with query string/POST, .*

  4. Select Make Association.

    Web Cache Simple Personalization Selector Association
    Selector Parse HREFs
    /OA_HTML/ibeCCt.*\.jsp.* NO

Step 10 - Set Up Test Environment

You can validate cacheability rules by monitoring three log files:

Set up the Oracle Application Server Web Cache 10g event log in verbose mode using the following procedure.

Steps

  1. In Oracle Application Server Web Cache 10g Manager, choose Administering Oracle Web Cache > Event Logging.

  2. Click Edit and check YES for Verbose mode.

  3. Apply the change to Oracle Application Server Web Cache 10g.

Post-Setup Step

After performing the Web Cache setups, bounce the Application server.

Partial Web Cache

Oracle iStore supports using Partial Web Cache to dynamically cache parts of catalog pages. Out-of-the-box, only the seeded Welcome Bin uses this feature. This section outlines how to use Oracle iStore Partial Web Cache feature in your customized JSPs.

Partial Web Cache Overview

Also known as Partial Page Caching in Oracle Application Server Web Cache 10g, this functionality provides dynamic assembly of web pages with both cacheable and non-cacheable page fragments. Therefore, web pages can be broken down into fragments of different cacheability profiles. These fragments are each maintained as separate elements in the application web server or content delivery network. The fragments are assembled into HTML pages as appropriate when requested by end users. The page assembly can be conditional, based on information provided in HTTP request headers or end-user cookies.

The basic structure a content provider uses to create dynamic content is a template page (container page) containing HTML fragments (for example, Oracle iStore bins). The container page is associated with the URL that end users request, and also configured with Edge Side Includes (ESI) markup tags that tell Oracle Application Server Web Cache 10g to fetch and include each individual bin.

Out-of-the-box, Partial Web Cache is pre-integrated with Oracle iStore section layout pages and the seeded Welcome Bin.

Terminology

The following terminology will be used in this section:

Partial Web Cache Functional Flow

Following is the Partial Web Cache functional flow:

  1. An HTTP request is made for a container page.

  2. If the requested container page is cacheable, web cache checks to see if the page is already in the cache.

  3. If the requested container page is not cacheable, or if the page is not in the cache, the request is forwarded to the application server which serves up the parsed container page.

  4. From here, the application checks to see if the container page has a non-cacheable ESI include -- If not, the request is fulfilled.

  5. If the container page does have a non-cacheable ESI include page, then the included page is assembled into the container page, and the request is fulfilled.

The following figure depicts the flow:

Partial Web Cache Functional Flow

the picture is described in the document text

Partial Web Cache Prerequisites

The following are required before implementing this technology:

Implementing Partial Web Cache

Following are the steps to implement Partial Web Cache:

Understand Partial Web Cache

When you are preparing to customize your pages to support Partial Web Cache, you first must understand the concepts of partial web cache and ESI INCLUDE, the flow involved in the ESI pages, and the corresponding interactions between the Oracle Application Server Web Cache 10g and the Oracle iStore application server. Please refer to Oracle Application Server Web Cache 10g documentation for more details.

Plan Your Customization

In the planning phase, you need to go through the following questions one by one:

  1. What customization do I need?

Normally, there are two customization cases you can choose:

  1. Web-cacheable ESI container page with non-web-cacheable ESI bin

  2. Non-web-cacheable ESI container page with web-cacheable ESI bin.

Think through your business needs and decide which case applies to your organization.

  1. Which bin(s) needs to be customized as ESI bin(s)?

Out-of-box, only the Welcome Bin is an ESI bin. You can customize other seeded bins, or your customized bins, to be ESI bins. Decide which bin(s) should be customized. Note that the candidate bin(s) should have different web-cacheability than its container page, or at least one of its container pages (if being included by many container pages).

  1. Where should I map my new ESI bin to Oracle iStore runtime?

Find the template access name and the corresponding mapped JSP through the Site Administration UI Template Manager.

  1. Do I need to customize the container page as an ESI container page?

Normally, you do not need this step if your ESI bin is included in the seeded Oracle iStore container page, unless you have a customized container page, and this container page includes some ESI bins that have different web-cacheability rules.

An ESI bin behaves as a regular bin if being included in a non-ESI container page.

  1. Which container page needs to be customized?

Find the template access name and the corresponding mapping condition for your ESI bin JSP page through the Site Administration UI Template Manager.

  1. Where should I map my new ESI container page to Oracle iStore runtime?

Find the template access name and the corresponding mapping condition for your ESI container JSP page through the Site Administration UI Template Manager.

  1. What file name should I use for my new ESI bin and ESI container page?

You should follow the following name convention to name your new ESI bins and container Pages:

  1. ibeCCt*.jsp for web-cacheable ESI container pages and ESI bins

  2. Any other names for non-web-cacheable ESI container pages and ESI bins

Also pay attention to the template access names of your ESI bins. They should NOT end with IBEWC. See the section, "Dynamic Page Cacheability for Section Configurable Layout", in this chapter, for more information.

  1. How should I test my new ESI pages?

First set up the Oracle Application Server Web Cache 10g server and the Oracle iStore application server, and ensure that these work properly for all the of the out-of-box Oracle iStore pages. Then come up with a good test plan to test your customized ESI bins and ESI container pages later.

Customize ESI Bin

Oracle Application Server Web Cache 10g server handles ESI container page and ESI bin page as individual cache entities that can be configured separately. Therefore, you need to customize an ESI bin only when it has different web cache cacheability than its container page.

Also, ESI bins would behave just as regular bins, when:

  1. Being included inside non-ESI container pages

  2. Web Cache is not enabled

Steps

  1. Set the following page context at the very beginning; and

  2. Include ibeCWcpESIBinTop.jsp instead of ibeCZzpRuntimeIncl.jsp, as below:

<% pageContext.setAttribute("esiURL"); %>

<%--@ include file=" ibeCZzpRuntimeIncl.jsp" --%>

<%@ include file="ibeCWcpESIBinTop.jsp" %>

  1. Include ibeCWcpESIBinBottom.jsp at the end, as below:

<%@ include file="ibeCWcpESIBinBottom.jsp" %>

  1. Do not use Web Cache Personalization tags

Example: Only the code marked in bold is specific to an ESI bin:

<% pageContext.setAttribute("esiURL", "ibeCAcdWelcome.jsp", PageContext.REQUEST_SCOPE); %>

<%@ include file="ibeCWcpESIBinTop.jsp" %>

<%

final String J = "ibeCAcdWelcome.jsp";

if (! RequestCtx.userIsSalesRep()) {

boolean bEnableTransaction = !RequestCtx.userIsStoreAdmin();

boolean bMaintenanceMode = IBEUtil.isMaintenanceMode();

String _binTitle = mm.getMessage("IBE_PRMT_WELCOME_G");

%>

<%@ include file="ibeCZzdBinTop.jsp" %>

<span class="sectionHeaderBlack">

<%=RequestCtx.getPersonName()%>

</span>

<br>

//…

<%

if (shopCart != null) {

out.println(mm.getMessage("IBE_PRMT_SC_TOTAL2"));

out.println(PriceObject.formatNumber(currencyCode,totalPrice));

}

else {

out.println(mm.getMessage("IBE_SC_NOITMS_CART"));

}

IBEUtil.log(J, "Shopping cart blurb end");

%>

//…

<%@ include file="ibeCZzdBinBottom.jsp" %>

<%

} // end if (! RequestCtx.userIsSalesRep()) %>

<%@ include file="ibeCWcpESIBinBottom.jsp" %>

<!-- ibeCAcdWelcome.jsp end -->

Customize ESI Container Page

Out-of-box, Oracle iStore has two common section layout options (Fixed Layout and Configurable Layout). Both are ESI container pages. Therefore, in most cases, you do not need to customize ESI container page, unless:

  1. You have a customized section layout page that needs to support Partial Web Cache.

  2. You want to support Partial Web Cache page in some other Oracle iStore container pages, like Item Detail Page.

Steps

  1. Include ibeCWcpESIContainer.jsp right after ibeCZzpHeader.jsp as below:

<%@ include file="ibeCZzpHeader.jsp" %>

<%@ include file="ibeCWcpESIContainer.jsp" %>

<%@ include file="ibeCWcpHeader.jsp" %>

  1. Dynamically include the ESI bin page in the appropriate place. Replace MyEsiBinPage.jsp with your real ESI bin jsp.

<jsp:include page="MyEsiBinPage.jsp" flush="true" /><br>

Example: Only the code marked in bold is specific to ESI Container Page.

<%@include file="jtfincl.jsp" %>

<%@page language="java" %>

<%@page import="oracle.apps.ibe.util.*" %>

<%@page import="oracle.apps.ibe.catalog.*" %>

<%@page import="oracle.apps.ibe.store.*" %>

<%@page import="oracle.apps.jtf.base.Logger" %>

<%@page import="oracle.apps.ibe.displaymanager.*" %>

<%@ include file="ibeCZzpHeader.jsp" %>

<%@ include file="ibeCWcpESIContainer.jsp" %>

<%@ include file="ibeCWcpHeader.jsp" %>

<%

String JSP_PAGE_NAME = "ibeCCtdCmnSt.jsp";

int lSectionId = -1;

String lSectionIdStr = "";

String lPageTitleStr = "";

Section lSection = null;

String browsePage = "", pathPage = "", welcomePage = "", globalPage="";

String lCenterDisplayPage = "";

String lRhsBin1="", lRhsBin2="", lRhsBin3="", lRhsBin4="", lRhsBin5="",

lRhsBin6="", lRhsBin7="";

String lLhsBin1="", lLhsBin2="", lLhsBin3="", lLhsBin4="", lLhsBin5="",

lLhsBin6="", lLhsBin7="";

String lTopBin="", lBottomBin="";

//…

/* Welcome Bin */

if(IBEUtil.useFeature("IBE_USE_WELCOME_BIN"))

{

welcomePage =

DisplayManager.getTemplate("STORE_CUST_ACC_WELCOME").getFileName();

if (welcomePage == null)

welcomePage = "";

}

//…

<%-- welcome bin ----------%>

<%

if(!welcomePage.equals(""))

{

IBEUtil.log(JSP_PAGE_NAME, "PERF: begin include welcome page");

IBEUtil.log(JSP_PAGE_NAME, welcomePage);

%>

<jsp:include page="<%=welcomePage%>" flush="true" /><br>

<%

}

IBEUtil.log(JSP_PAGE_NAME, "PERF: end include welcome page");

}

//…

%>

<!-- ibeCCtdCmnSt.jsp end -->

Post-Setup and Testing

After your customization, complete the following post-setup & testing steps:

  1. Map your ESI bin page and ESI container page properly. Refer to the "Implementing the Catalog" chapter for more information.

  2. Test your pages when Oracle Application Server Web Cache 10g is not present.

  3. Test your pages when Oracle Application Server Web Cache 10g is enabled and the ESI bin is included in an ESI container page. (Skip this step if this scenario doesn't apply to your implementation.)

  4. Test your customized pages when Oracle Application Server Web Cache 10g is enabled and the ESI bin is included in a non-ESI container page. (Skip this step if this scenario doesn't apply to your implementation.)

Dynamic Page Cacheability for Section Configurable Layout

Oracle iStore enables you to dynamically set cachebility rules at runtime, by allowing a web-cacheable container page (the default Configurable Layout JSP, ibeCCtdCmnSctLayout.jsp) to change the cacheability of itself at runtime. This feature is available by default when you use Configurable Layout in your specialty sites. Configurable Layout uses ibeCCtdCmnSctLayout.jsp, which checks the cacheability of each included bin and then either caches the entire page content or not.

Dynamic Page Cacheability Functional Flow

The following functional flow can aid your understanding of this feature.

  1. Implementer maps content to appropriate bins and then configures the layout of the bins using Configurable Layout (see the "Implementing the Catalog" chapter).

  2. At runtime, the default Configurable Layout JSP, ibeCCtdCmnSctLayout.jsp (seeded for STORE_SCT_CONFIGURABLE_LAYOUT template, a container page), checks the cacheability of each of the bins mapped.

  3. If all bins on the page are cacheable, the container page caches all bins.

  4. If the page recognizes a bin as non-web-cacheable, the container page makes itself (and all mapped bins) non-web-cacheable. How the page does this is examined in the next section.

The following graphic depicts the flow.

Dynamic Page Cacheability Functional Flow

the picture is described in the document text

Implementing Dynamic Page Cacheability

By default, when it finds a bin that is non-web-cacheable, the seeded Configurable Layout JSP overwrites existing cacheability rules and disables the web-cacheability of the itself and all mapped bins. If you are using seeded bins and the Configurable Layout option for sections, there are no implementation steps other than to map the bins (see the "Implementing the Catalog" chapter).

The seeded Configurable Layout JSP determines if a bin is web-cacheable by checking the programmatic access name of the bin template. If the access name ends with _IBEWC, the bin is not web-cacheable. Therefore, when using seeded or custom bins in Configurable Layout, consider the access name of each bin template.

How Configurable Layout JSP Disables Web-Cacheability

The process that the seeded Configurable Layout JSP page follows for disabling its own web-cacheability is:

  1. The Configurable Layout JSP sets the webcache attribute to disable in the pageContext, and then includes the JSP, ibeCWcpHeader.jsp.

  2. ibeCWcpHeader.jsp checks the webcache attribute value. If the value is disable, ibeCWcpHeader.jsp sets the Surrogate Control attribute of the HTTP response header to "no-store".

Cacheing Custom Bins with Configurable Layout

If using custom bins with Configurable Layout and you wish the bin content to be cacehable, ensure that programmatic access names do not end with _IBEWC. If the content of a bin is non-web-cacheable, and the bin does not support partial web cache, its access name should end with _IBEWC.

Code Example for Dynamic Page Cacheability

The following is an example of how the JSP code might look with this feature:

<% //check the web cacheability of each included bin, find at least one of them is not web cacheable, then

pageContext.setAttribute("webcache", "disable", PageContext.REQUEST_SCOPE); %>

<%@ include file="ibeCWcpHeader.jsp" %>