Skip Headers

Oracle iStore Implementation and Administration Guide
Release 12.1
Part Number E13575-08
Go to Table of Contents
Go to previous page
Go to next page

Implementing Miscellaneous Internet-Related Features

This chapter covers the following topics:

Overview of This Chapter

This chapter describes the implementation of various Internet-related features and functionality.

Customer Application Page Caching

This section describes the implementation and administration of caching Oracle iStore Web pages without the use of Oracle Application Server Web Cache 10g, Oracle iStore's integration with Oracle Application Server Web Cache 10g is described in the chapter, Integrating Oracle iStore with Oracle Application Server Web Cache.

Overview of Caching

Caching technology allows the storage and monitoring of web object (Java object) requests from a server. On subsequent requests for the same object, the cache delivers the object from its storage rather than passing the request on to the origin server. This increases the speed with which objects are retrieved, and thus speeds the performance of your web site.

Web objects change over time, so each web object has a useful life, or "freshness." Caches determine whether or not their copy of an object is still "fresh," or whether they need to retrieve a new copy from the origin server. The higher the number of people requesting the same object during its useful life, the more upstream traffic the cache eliminates. By handling object requests rather than passing them upstream to the origin server, caches reduce network traffic and improve the browsing experience for users.

Overview of Cached Data in Oracle iStore

You can set up Oracle iStore to rely on Oracle CRM Technology Foundation (JTT) Cache to cache your specialty site page objects.

Note: Oracle iStore no longer supports the use of IBE Cache. You should use JTT Cache. For details on how to set up JTT Cache, see the Oracle Applications CRM System Administrator's Guide.

You also can integrate Oracle iStore with Oracle Application Server Web Cache to serve cached data. See the chapter, Integrating Oracle iStore with Oracle Application Server Web Cache, for more information.

JTT Cache is a component-level cache known as an application cache. Oracle Web Cache is a page-level cache known as edge-server caching. These two types of caches do not interconnect in any way.

The following diagram explains the relationship between JTT Cache and Oracle Web Cache. The diagram depicts how when a user requests an object from a web page, the edge-server cache and application server cache deliver the objects to the page. If the cached data is not available, the system retrieves the objects from the origin server.

Web Caching in Oracle iStore, using Oracle Web Cache and JTT Cache

the picture is described in the document text

Setting up JTT Cache

Oracle iStore can use the Oracle CRM Technology Foundation (JTT) Cache to improve site performance.

Component Caches for Oracle iStore in JTT

JTT Cache framework manages caches in two levels: component level and object level. A cache component is a collection of cached objects of the same type. Each cache component holds all the Java objects associated to an application. For example, IBE_SECTION_CACHE component contains all cached section objects, while IBE_ITEM_CACHE contains all item (product) objects.

Each application uses one or more component caches. Within each component cache, are component identifiers. Cached objects, which are striped by unique keys, are used almost everywhere in JSPs and Java classes. Where these objects are used is fully determined by business logic and the underlying implementation.

The following table shows the JTT component cache identifiers that are seeded in Oracle iStore. The table lists the Oracle iStore component identifier (component cache) and the what each identifier caches.

Oracle iStore Component Caches
iStore Component Identifier What it Caches
IBE_ACCESSNAMEID_CTX_CACHE Stores programmatic access names of the display styles' logical IDs
IBE_ADDRESS_VALIDATION_CACHE Stores address validation status for each operating unit
IBE_ATTACHMENT_CACHE Stores attachment information
IBE_CURRENCY_CACHE Stores currency information, including currency symbol and translated currency names
IBE_FND_LOOKUP_CACHE Stores FND lookup values based on language -- the key is the column lookup_code (in FND_LOOKUP_VALUES) and the return value is the meaning column containing the actual phrase (e.g. shipping method).
IBE_INVORG_SHPMTHD_CACHE Stores shipping methods based on inventory organization ID
IBE_ITEM_CACHE Item objects
IBE_ITEM_LANG_DESC_CACHE Stores the language-specific description and language description of items in the catalog
IBE_ITEM_PRICE_CACHE Stores prices of items in catalog.
IBE_LAYOUT_COMPONENT_TEMPLATE_CACHE Stores the template mapped to a section in a specific component of the layout
IBE_LOCALE_CACHE Stores the locale for a given language
IBE_MEDIA_CACHE Stores logical name to physical file mapping for content components
IBE_MEDIA_CTGCTX_CACHE Stores the context of content components for product categories
IBE_MEDIA_DEFAULT_CACHE Stores the context of default content components
IBE_MEDIA_PRDCTX_CACHE Stores the context of content components for products and sections
IBE_MEDIA_TEXT_CACHE Stores text media (i.e., Oracle Application Object Library messages)
IBE_MENU_CACHE Stores iStore Customer UI menus retrieved from FND
IBE_MSITE_AN_CACHE Specialty site object by access name
IBE_MSITE_ID_CACHE Stores specialty site objects by Site ID
IBE_MSITE_RESP_CACHE Stores the SortedMinisiteResponsibilities object where the key is the language code
IBE_OU_CACHE Stores operating unit object, which stores information such as ship-to and bill-to countries
IBE_PARTNUM_CACHE Stores part number and Inventory ID mapping
IBE_PHONE_CODE_CACHE Stores international phone code of each country -- the key is the territory code and the return value is the international phone code
IBE_PRINTED_TAXNAME_CACHE Stores printed tax names based on tax code, organization ID, and language code
IBE_RELATED_ITEM_PRICE_CACHE Stores prices of the related items in the catalog.
IBE_SECTION_ACCESSNAME_CACHE Stores mapping between a section’s access name and its unique identifier.
IBE_SECTION_LANG_DESC_CACHE Stores language-specific description and language description of sections in the catalog
IBE_QUOTE_STATUS_CACHE Stores quote statuses
IBE_SEARCH_CATEG_CACHE Stores category-level product search LOV in sites' menu bars
IBE_SEARCH_SECTION_CACHE Stores section search cache for Customer UI
IBE_SECTION_CACHE Stores section objects and navigational hierarchy
IBE_STORE_LANGUAGE Stores the SiteLanguage object where the key is the language code
IBE_STORE_PROFILE_CACHE Stores application-level profile option settings
IBE_STYLE_CACHE Stores address style for each country
IBE_TEMPLATE_CACHE Stores logical name to physical file mapping for templates
IBE_TEMPLATE_DEFAULT_CACHE Stores default context of templates
IBE_TEMPLATE_PRDCTX_CACHE Stores context of templates for products and categories
IBE_UOM_CACHE Stores units of measure and their translations

For information on how to set up and use JTT Cache, see the Oracle Applications CRM System Administrator's Guide.

Search Engine Indexing

Oracle iStore supports the indexing of its public Customer Application pages by search engines. Oracle iStore public pages can be traversed and indexed by search engine Web crawlers. When the page URLs appear as part of a search result, users can navigate directly to the catalog page by clicking on the URL.

Indexing Behavior in Oracle iStore Customer Application

Each Oracle iStore catalog page has a "site context", which is a combination of site ID, responsibility ID, and language code. For Web crawler support, Oracle iStore encodes the site context within the catalog page. Oracle iStore identifies Web crawler visits by reading the user-agent string in HTTP request headers. Oracle iStore maintains a list of Web crawler user-agent strings that match the user-agent strings in request headers. This list is extensible to support additional Web crawlers.

Guidelines for Search Engine Indexing

Keep the following rules and guidelines in mind as you implement and use the feature:

Implementing Search Engine Indexing

Following are the high-level steps to implement search engine indexing:

  1. Enable Search Engines in Lookup (optional)

  2. Register Catalog Pages with Search Engine

Enable Search Engines in Lookup

The factor to determine whether a client is a Web crawler is based on the popular Web crawlers’ identifier in the HTTP header. By default, Oracle iStore seeds the identifier for the following Web crawlers: Google (Amerca Online uses Google), MSN, AskJeeves, and Yahoo. Implementers may support additional search engines by adding their user-agents to the Oracle Applications lookup. See the Implementing Messages and Prompts chapter, for more information.

Register Catalog Pages with Search Engine

In order for search engines to find Oracle iStore catalog pages, you must ensure that the pages are registered with the search engines to be used. Consult the product documentation for the specific search engines for more information.

Secure Socket Layer Connections

Secure Sockets Layer (SSL) is a protocol that allows the transmission of private documents via the Internet. SSL works by using a public key to encrypt data that's transferred over the SSL connection.

Both Netscape Navigator and Internet Explorer support SSL, and many web sites use the protocol to obtain confidential user information, such as credit card numbers. By convention, URLs that require an SSL connection start with https: instead of http:.

Oracle iStore provides support for serving pages through SSL network connections, and can switch seamlessly between HTTP and HTTPS protocol. This reduces the hardware required to serve Oracle iStore pages through SSL. It also provides improved performance with HTTP for non-secure Oracle iStore pages, such as the catalog pages.

Pages that are SSL-enabled are considered secure, while pages that are not served through SSL are considered non-secure.

Enabling SSL Switching

To enable protocol switching between secure and non-secure URLs, set the following mandatory profile options:

See the appendix, Profile Options, appendix for more information about these profiles.

These URL parameters enable the application to recognize hostnames and ports. If you do not want to support protocol switching, leave the profiles blank.

When you set these profile options, hyperlinks that cause a transition from SSL to non-SSL and vice versa become absolute. Also, hyperlinks that are shared by both SSL and non-SSL pages become absolute. Absolute hyperlinks have the following HTML syntax:

<a href="https://<host>:<port>/OA_HTML/ibeCAcdLogin.jsp?a=b"></a>

In contrast, relative hyperlinks have the following syntax:

<a href="ibeCAcdLogin.jsp?a=b"></a>

Accessing the Database with a Private Middle Tier

Your support team may need to access the database using its own private middle tier. For example, if your HTTPS server is down for maintenance, the team may need this access to test other functionality. To allow access to the database with a private middle tier, you will need to make all hyperlinks relative.

You can make the hyperlinks relative by appending "?intra=t" to your Oracle iStore home page URL.

Use the following procedure to make the hyperlinks relative.


  1. Navigate to the following URL:

  2. The page opens. All hyperlinks are now relative to the following URL:


SSL and Non-SSL Enabled Pages in Oracle iStore

The following table summarizes which Oracle iStore components have SSL-enabled pages and which do not.

Oracle iStore Secure and Non-Secure Pages
SSL-Enabled Pages Non-SSL-Enabled Pages
  • Login

  • Cart Saving and Sharing

  • Checkout Flow

  • Express Checkout

  • Customer Profile

  • Order History

  • Catalog

  • Shopping Cart

Setting JTT JVM Cookie Parameters

If your HTTP and HTTPS servers are set up in different sub-domains and paths, two JVM parameters must be set in Oracle CRM Technology Foundation so that the session cookies are sent to both servers. The following are the parameters:


If the HTTP server is and the HTTPS server is, the JVM parameters should be set as follows:

For instructions on how to set these parameters in the Oracle CRM System Administrator's Console, see the online help accessible from the console.

DeMilitarized Zone Environment Support

Oracle iStore is certified to be deployed in a DeMilitarized Zone (DMZ) environment. Deployment options, required patches, configuration details and other information are available in OracleMetaLink Note 287176.1.