|Oracle iStore Implementation and Administration Guide|
Part Number E13575-06
This chapter covers the following topics:
This chapter describes the implementation of various Internet-related features and functionality.
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.
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.
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
Oracle iStore can use the Oracle CRM Technology Foundation (JTT) Cache to improve site performance.
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.
|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_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.
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.
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.
Keep the following rules and guidelines in mind as you implement and use the feature:
To improve ranking in search engine indices, the site context ID constituents (site, responsibility, language) are concatenated into one parameter, separated by a colon (:), and recognized as a new parameter. Users can store the encoded URL as a bookmark in their browsers.
Oracle iStore recognizes Web crawler user agents; when it does, it will not perform a URL rewrite. A "URL rewrite" refers to the system action of generating URLs with encoded session information when session cookies cannot be set on the client machine.
Oracle iStore seeds the names of popular web crawler user agents in a lookup. See the "Implementing Search Engine Indexing" section, below, and the Implementing Messages and Prompts chapter, for more information.
Only pages not requiring login (public pages) will be indexed and returned as results by search engines.
Following are the high-level steps to implement search engine indexing:
Enable Search Engines in Lookup (optional)
Register Catalog Pages with Search Engine
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.
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 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.
To enable protocol switching between secure and non-secure URLs, set the following mandatory profile options:
IBE: iStore Secure URL --- Set to the base URL where HTTPS is installed.
IBE: iStore Non Secure URL --- Set to the base URL where HTTP is installed. See the chapter, Integrating Oracle iStore with Oracle Application Server Web Cache, for information on Oracle Application Server Web Cache and SSL.
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:
In contrast, relative hyperlinks have the following syntax:
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.
Navigate to the following URL:
The page opens. All hyperlinks are now relative to the following URL:
The following table summarizes which Oracle iStore components have SSL-enabled pages and which do not.
|SSL-Enabled Pages||Non-SSL-Enabled Pages|
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 http://www.xyz.com/path1 and the HTTPS server is https://secure.xyz.com/path2, 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.
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.
Copyright © 2001, 2010, Oracle and/or its affiliates. All rights reserved.