This chapter covers the following topics:
This chapter contains information on advanced display functionality in Oracle iStore. Also refer to the Oracle Integration Repository.
This section contains advanced tasks to assign content (for example, images, HTML files) in your specialty sites.
See the chapter, Implementing Content, for an introduction to content components.
After you create a new content component, you must customize the JSP where it will appear.
To create a new content component, log in to the Site Administration UI and select Advanced, Content Components, Create Content Component.
Keep in mind the following guidelines:
Component Name field --- This name will not appear in the Customer UI.
Programmatic Access Name field --- Enter a unique value in the textbox. This will be the value you enter into the JSP call to the content component. An error message will display if you do not enter a unique name.
Description field --- Optionally, enter a description for the content component. This description will not appear in the Customer UI, and is for your internal business purposes only.
Class field --- Select a class for the content component, based on its display purpose. See see the "Implementing Content" chapter for guidelines.
The Update Content Component page contains textbox, called Default, with a Content section below it. Since this is a new content component with no content mapped, then no information will display in the Content area. After you map content to the media object associated with the content component, the Content area will be populated, and the View Mapping and Add Content buttons will be active.
After creating the content component:
Map a media object to the content component
Map content to the media object,
Create and register a new Display Template (see the sections later in this chapter: "Creating New Templates" and "Registering New Templates in the Template Manager")
In the newly created Display Template, enter the programmatic access name of the new content component in the Display Manager API.
This section contains information on assigning media objects to content components at the site level. For an overview of media objects in Oracle iStore, see the chapter, Implementing Content. You can assign content components to media objects at the Product or Section levels as well (see the section, "Creating and Maintaining Sections", in the chapter, Implementing the Catalog).
To assign a media object to a content component at site level, log in to the Site Administration UI and select Advanced, Content Components, Update.
Keep in mind the following guidelines:
You can enter partial values in the Default textbox in the Update Content Component page to narrow the results that are returned in the Search and Select: Media Object page when you select the flashlight icon; text entered should be based on media object name.
If you haven't done so already, after assigning the media object to the content compnent, map the media object you have selected to a source file or files. You can map content to media objects using the following navigation paths:
Content, Media Objects
Catalog, Sections, Content
Catalog, Products, Content
Descriptive flexfields (DFFs) allow users to extend Oracle applications to meet business requirements without the need for programming. You can use descriptive flexfields in the Oracle iStore Customer UI to gather information, important and unique to your business, that would not otherwise be captured.
Note that this document contains DFF setup and user information related directly to Oracle iStore. For complete details about flexfields, see the Oracle Applications Flexfields Guide.
Oracle iStore merchants can capture information from customers in the shopping cart pages by setting up Oracle Order Capture DFFs. Two of Oracle iStore's product detail templates also support Oracle Inventory DFFs. After you set up DFFs in Oracle Forms, Oracle iStore uses its own JSPs --- along with Oracle CRM Technology Foundation APIs and renderers --- to display the fields in the UI. Merchants can utilize Oracle Order Capture DFFs to capture information that cannot be captured through defined order attributes. The information passes into the Oracle Order Management system and is viewable in the sales order forms when Order Management DFFs are enabled.
Following are the supported Customer UI areas for using DFFs:
In the Shopping Cart page, an action entitled Additional Information allows customers to populate Order Capture DFFs at the cart and item levels.
Three product Display Templates support the use of Inventory DFFs. With this option, the Display Templates display the prompt and the value of descriptive flexfield global segments, if a value is defined for the item.
The following use case examples can aid your understanding of the functionality:
Use DFFs in the shopping cart to allow customers to enter gift wrapping requests for a product, such as gift wrap colors and greetings to be shipped with the product.
Set up a DFF that allows customers to enter a preferred sales representative name; the order administrator could use the information to assign the correct sales representative.
Implement DFF fields that allow customers to enter optional information that could be used for marketing additional services to them.
Set up DFFs for product detail templates that allow users to enter additional information for a particular product, such as entering sizes or colors for a shirt.
The process flows in this section depict how customers enter, edit, and remove cart-level and item-level DFF information.
Following is the flow:
A user visits a site and adds one or more items to the shopping cart.
The user selects the Additional Information action in the Shopping Cart page and presses the Go button.
In the Cart Additional Information area of the Additional Information page, the user enters relevant data in the DFF fields. The user will be required to enter appropriate information in fields that the merchant has marked as required in the Oracle Forms setup screens. These fields will display an asterisk (*) next to them.
The user saves the data.
The user presses the Return to Shopping Cart button to return to the cart.
The following figure shows an example of how the Cart Information page might look in an implementation of Oracle iStore. Since the information is being entered at the cart level, no item information displays. In this example, Cart Additional Information displays at the top of the screen. The entry fields are: Reseller Name (showing the search flashlight icon next to it), Reseller Phone, and Reseller Contact, with values entered for each one. Buttons near the top of the screen are: Save and Clear. In the lower portion of the screen, the Item Additional Information area displays; under this area is a list of items, Wireless Service, Headset, and Envoy Deluxe Laptop. To the far right of each item, is an Item Information icon allowing customer to access the Enter Item Information page. At the top of the list of items is a button, Select Items and..., with the buttons Enter Information and Clear next to it. At the bottom of the screen is a button, Return to Shopping Cart.
Cart Additional Information Page Example
Following is the flow:
A user visits a site and adds one or more items to the shopping cart.
The user selects the Additional Information action in the Shopping Cart page and presses Go.
From the Item Additional Information area of the Additional Information page, the user selects an Item Information icon to access the Item Additional Information page for that item.
In the Item Additional Information page, the user enters the DFF information and saves the data. Required fields are marked with an asterisk.
The following figure shows an example of how the Enter Item Information page might look in an implementation of Oracle iStore. In this example, the title, Enter Item Information displays at the top of the page. The DFF values the user can enter are: Support Contract Number and Context Value (with a search flashlight icon next to it). The buttons, Cancel and Apply, appear on the screen.
Enter Item Information Page Example
Prerequisite: A user has already created a shopping cart and has added DFF information for an item at item or cart level.
A user activates a shopping cart to retrieve the Shopping Cart page.
The user selects the Additional Information action in the Shopping Cart page and selects Go.
To replace cart-level information, the user enters/overwrites the information in the Cart Additional Information area of the Additional Information page and saves the data.
To replace item-level information, the user selects the appropriate Item Information icon for the item he wishes to update and then enters new data in the fields in the Item Additional Information page, saving the data when he is finished.
The following points describe Oracle iStore guidelines and behavior for DFF implementations.
Shopping Cart and Payment Pages DFFs:
In the shopping cart pages, Oracle iStore has implemented Oracle Order Capture's Header: Additional Information DFF at the cart-level. The DFF segment values are stored in the ASO_QUOTE_HEADERS_ALL table. Similarly, in the shopping cart page, Oracle iStore has implemented Oracle Order Capture's Lines: Additional Information DFF at the cart line-level. These DFF segment values are stored in ASO_QUOTE_LINES_ALL table.
Oracle iStore provides the flexibility to implement DFF either at the cart-level or cart item-level, or both. In addition, site DFF implementation can be further controlled at the site and specialty store language levels.
Oracle iStore supports both global and context flexfield segments at the cart and item levels in the shopping cart. However, it does not provide any API-level validation to enforce mandatory segments, for either of these levels, during order placement. However, API-level validation can be indirectly enforced by setting up mandatory DFF segments in Oracle Order Management's DFF.
If cart-level and item-level flexfields have been implemented in Oracle Order Capture, and if the values entered by the end-user need to be available on the order after the cart is converted to an order, then the implementer must set up the Oracle Order Management flexfields at the order header-level and line-level -- these must exactly match the Oracle Order Capture flexfields. The corresponding Oracle Order Management flexfields are: Additional Header Information (OE_ORDER_HEADERS_ALL table) and Additional Line Attribute Information (OE_ORDER_LINES_ALL table).
Caution: DFF values are always passed to Oracle Order Management DFF segments. Hence, if the Order Capture DFFs are not identical to the Order Management DFF setups, and if the same database column is used for a different usage, then the data will be visually misleading. Further, if Order Management DFF segments have validations set up, then the Order placement through Oracle iStore may fail.
Any default values defined for flexfield segments will be shown in Oracle iStore, provided the user had not previously entered values for any of the flexfield segments. Also, Oracle iStore supports default value setup for the DFF Context field, in which case, the context segments for this context are automatically rendered.
Oracle iStore does not support "reference field" setup for a DFF context field.
Cart-level or item-level DFF information is not carried to a shopping list if the cart is saved as a list.
Oracle iStore automatically saves cart- and item-level DFF information whenever a user saves or shares a shopping cart/quote.
The shopping cart is re-priced when cart or item level DFF information is saved.
For cart-level or item-level DFFs, if mandatory global/context segments have been set up, these mandatory segment validations are not enforced when the user selects Express Checkout in the Shopping Cart page.
In some cases, item-level DFF information may not be captured during Express Checkout. For example: Assume DFF setup is done for both the Order Capture and Order Management DFFs for item level, with some of the segments as mandatory, and the user did not enter DFF information at item level. In this case, for normal checkout, Order Management would capture it while placing the order. However, if the items are checked out through Express Checkout from the catalog or shopping cart pages, there is no way to capture the required DFF information at item level.
For configured items, DFF information can only be entered for the parent item. Similarly, for serviceable items with attached services, users can only enter DFF information for the serviceable item, but not for any related services.
Only Independent, Table, and Dependent valuesets can be used with Oracle iStore.
For carts/quotes shared with Read-Only or Viewer access, the user cannot view the DFF information at the cart and item levels, as he cannot activate the cart.
If a customer has ordered multiple quantities of a single item, the items can be split to specify different shipping information for each duplicate item. In such a case, the item level DFF information for the original item is populated in each duplicate item.
If IBE: Merge Shopping Cart Lines is set to Yes, and if the same item is added more than once, when the item in the cart already has DFF information entered, then the DFF values already entered on the existing item in the cart are preserved.
No DFF information displays in order tracker.
If the profile, IBE: Additional Shopping Cart Information, is set to No, or if one of the following two templates is not mapped, then the Additional Information menu will not be available from the Shopping Cart page. The templates are STORE_CART_ADDINFO_HEADER and STORE_CART_ADDINFO_LINE. See the section, "Implementing DFFs in Oracle iStore", below, for more information.
Product Detail Page DFFs:
For the product detail DFFs, Oracle iStore supports DFF segments defined on the Inventory Item table.
Only global flexfield segments are supported.
Out-of-box, the seeded product templates, Product Detail without Image, Product Detail with Image, and Product Detail with Services show product detail DFFs. See the "Implementing the Catalog" chapter for details about these templates.
The sections that follow discuss how to implement DFFs for the Oracle iStore Customer UI.
First, create the DFF segments and associated values using Oracle Forms' Descriptive Flexfields forms. Following are high-level steps to help you accomplish the implementation. For complete information, see the Oracle Applications Flexfields Guide.
Important: Be sure to review the guidelines in the section, "Behavior and Guidelines for DFFs", above.
Steps
Log in to Oracle Forms with the Application Developer responsibility and choose Flexfield, Descriptive, Segments to open the Descriptive Flexfields Segments window.
If setting up shopping cart or payment page DFFs, query for the flexfield with:
Application --- Oracle Order Capture
Title --- Header: Additional Information or Line: Additional Information, depending upon whether you are implementing cart or item level DFFs
If setting up product detail page DFFs, query for the flexfield with:
Application --- Oracle Inventory
Title --- Items
Uncheck the Freeze Flexfield Definition checkbox to allow for changes to the flexfield definition.
Set up flexfield segments: Select Segments and then map each segment you wish to use to a column, specified by the names ATTRIBUTE1 through ATTRIBUTE15. This column data (attributes 1-15) corresponds to columns with the same name in the ASO_QUOTE_HEADERS_ALL and ASO_QUOTE_LINES_ALL tables.
Example: Map "Sales Rep Email" to "ATTRIBUTE1."
Once all the changes for DFF are done, check the Freeze Flexfield Definition checkbox to freeze the changes, and select the Save icon. This compiles the flexfield definition in the database.
After you have set up the DFFs in Oracle Forms, perform the required Oracle iStore-specific steps, depending upon the type of DFF you are implementing:
"Setting up DFFs for Shopping Cart Page"
"Setting up DFFs for Product Detail Pages"
The Additional Information page -- accessible as a hyperlink from the Shopping Cart page -- is used to capture item- and cart-level DFF information.
Use the following steps to set up Shopping Cart page DFFs, after you have performed the required setups in Oracle Forms DFF windows:
Steps
Set the profile option, IBE: Additional Shopping Cart Information, to Yes. See the "Profile Options" appendix for more information on the profile option.
A site administrator has the flexibility to implement DFFs at cart-level, item-level or both, for each site. For this, two different templates are provided which you can map to display a specific JSP, according to the following instructions:
Cart-Level DFF only --- Map STORE_CART_ADDINFO_HEADER to the ibeCScdHdrAdditionalInfo.jsp.
Item-Level DFF only --- Map STORE_CART_ADDINFO_LINE to the ibeCScdLineAdditionalInfo.jsp.
Both Cart- and Item-Level DFF --- Map both templates to the JSPs.
For JSP mapping instructions, see the "Implementing the Catalog" chapter. Remember, with Oracle iStore's template mapping functionality, you can map different JSPs to different site-language combinations.
Important: If the profile option, IBE: Additional Shopping Cart Information, is set to Yes, but the template mapping has not been set up, the Additional Information link will not display in the Shopping Cart page.
Out-of-box, Oracle iStore allows you to use DFF capability in three of the seeded product detail Display Templates -- Product Detail without Image, Product Detail with Image, and Product Detail with Services. See the "Implementing the Catalog" chapter for details about these templates.
If a DFF value is defined for an item, templates mapped at the product level display the prompt and the value of DFF global segments.
Steps
To set up flexfield segments and values for products and their detail pages, log into Oracle Forms with Inventory responsibility.
Navigate to the Inventory Item window and find the item for which flexfield values will be entered. Use the Inventory Organization that is set in the profile option, IBE: Item Validation Organization.
Click on the rectangle enclosed within brackets next to the Description field in the Inventory Item window. A window opens with the flexfield segments set up in the previous steps.
Enter values for the flexfield segments you want to display on the item detail page.
Reboot the Apache server to clear the cache after entering the new data.
Add the product(s) to a section, and map one of the product detail templates listed above at the product level. For steps, see the "Implementing the Catalog" chapter.
To test, in the Customer UI, navigate to the product(s) detail page. The flexfield segment prompts and values should appear on the item detail page.
As discussed elsewhere in this section, out-of-box, Oracle iStore ships two templates for DFF implementation at the cart- and item-level. By default, these templates are not enabled; see the section, "Implementing DFFs in Oracle iStore", for implementation information about these templates and DFF display. The following presents a scenario for enabling DFFs at different levels for three different sites. This is accomplished by setting up unique template-JSP mappings for each site.
For steps to map JSPs to Display Templates at the site level, see the "Implementing the Catalog" chapter.
Scenario 1: Implement only cart-level DFFs in Site 1
For Site 1, map only STORE_CART_ADDINFO_HEADER to ibeCScdHdrAdditionalInfo.jsp.
Thus, when the user selects the Additional Information action, cart-level DFFs display.
Scenario 2: Implement only item-level DFFs in Site 2
For Site 2, map only STORE_CART_ADDINFO_LINE to ibeCScdLineAdditionalInfo.jsp.
Thus, when the user selects the Additional Information action, item-level DFFs display.
Scenario 3: Implement both cart- and item-level DFFs in Site 3
For Site 3, map both the templates to the respective JSPs. Thus, when the user selects the Additional Information action, cart-level DFF information displays, and an LOV allows the user to select either cart or item information.
Note: Remember, along with these templates, the profile option, IBE: Use Additional Information, should be set to Yes.
Oracle iStore's Display Template Mappings Import/Export functionality allows you to export or import template mappings using Extensible Markup Language (XML) files. The functionality is implemented as two concurrent programs:
iStore Template Mapping Import Concurrent Program
iStore Template Mapping Export Concurrent Program
You can find an introduction to Display Templates in the chapter, Implementing the Catalog.
Utilizing the template mappings import/export functionality can provide numerous benefits in your maintenance of Oracle iStore templates. Using the concurrent programs and XML files you can export, update, and import template:
Names
Applicable To categories
Keywords
Descriptions
Source file site/language mappings
Mappings between sites
In summary, this functionality's benefits and features include:
By altering the mappings in the XML file and then importing the changes, you can update template attributes, such as name, Applicable To category, and source file mappings.
You can transfer template mappings between sites in the same instance.
You can transfer template mappings between instances -- for example, between a test and production instance.
Concurrent programs allow you to schedule background jobs to run automatically, thus minimizing the maintenance time impact.
Template creation is supported during the import process. The import program will create a new template if the programmatic access name of the template does not exist in the target instance.
When you run the export concurrent program, you have the ability to select a specific site(s) whose template mappings you wish to export.
The functionality features the ability to export only templates matching a specific Applicable To category.
You can select to export all templates mappings, only seeded template mappings, or only custom template mappings.
The concurrent program log files allow you to view the results of the program execution.
Debug functionality allows troubleshooting of the concurrent program process. See the section, "Setting up Debug for Template Mappings Concurrent Programs", in this chapter, for details.
Note that the comma separated values (.csv) format is not supported for template mappings import/export.
To export template mappings to an XML file, you use the iStore Template Mapping Export concurrent program. To set up debug functionality for the program, see "Setting up Debug for Template Mappings Concurrent Programs", in this chapter.
The following are the parameters you can choose from when running the export concurrent program:
Site Code: The Site Code LOV contains a list of all existing site codes across all instances. To export template mappings from a specific site, select a site from the Site Code LOV. To export from all sites, leave the LOV blank. You can only select one site at a time the LOV.
Note that site code is different from site ID. Site code is an administrator-definable field (accessible from the Site Details page) which will be the same across instances for the same sites, while site ID is a system generated ID which can be different across instances for the same sites.
Template type: The Template type LOV allows you to select either Seeded or Custom (non-seeded) template mappings. To export all types, leave the LOV blank.
Template category: The Template category LOV allows you to filter the output by template Applicable To category. To export all categories, leave the LOV blank. For a discussion of the Applicable To categories, see the "Seeded Display Data" appendix.
Running the concurrent program will create an XML file. The name of the export file is system-generated. See the section, "Template Mapping Export Program Log File", below, for more details.
After running the concurrent program:
View log file details of the export. To view the output, select View Output button on the View Request screen (from the menu select View, Requests).
To save the output file, select File > Save As and save the output as an XML file from the browser. Note that you must set the profile option, Viewer Text, to be able to save the output from the browser.
Edit the XML file as desired. For example, change site codes, file names, or template categories. Save and upload the file to the server on which your concurrent manager is running. Ensure that the user running the concurrent manager program has read-write permission on the server.
The log file contains such information as:
Date the program was executed
Parameters involved in the execution:
Site code (if applicable)
Template type (if applicable)
Template category (if applicable)
Result:
Number of templates successfully exported
Number of errors
Template name of the first template that has an error
The following graphic shows an example of an XML file exported by the iStore Template Mapping Export Concurrent Program. The XML file shows the following text with appropriate XML tags: Template Programmatic Access Name, Row References, Name Language, Description Language, Seed Flag, Applicable to category, Keywords, Site Code, Site Name, Language Code, and File Name of XML file.
Template Mappings Export File Example
To import template mappings from an XML file, you use the iStore Template Mapping Import concurrent program.
Prerequisites:
In order to import template mappings, you must first upload the appropriate XML file to a directory on the application web server. For example, template1.xml is put in /nfs/group/crmeco/html through ftp on machine2.
Ensure that the user running the concurrent manager program has read-write permission on the server.
AutoConfig must be enabled in order for the template import feature to fully work. If AutoConfig is not enabled for the instance, upload the file to a directory of the machine that concurrent manager is running on. Here is how to find the machine that concurrent manager is running on:
Login to Oracle Forms using System Administrator responsibility.
Navigate to Concurrent > Manager > Administer. In the Administer Concurrent Managers window, under the Standard Manager entry, the machine name will appear in the Node (standard manager) column. This will be the machine the concurrent manager is running on. For more information, see Oracle Applications System Administrator's Guide.
Consider setting of the Save after every successful template import input parameter --- If the autosave input parameter is turned on, a commit is called for the successful save of every individual template and its mappings. If autosave is turned off, the data is committed to the database only once for all of the counts of the templates and their mappings. If the rollback/commit segment is less, this may cause some issues in committing the data. In such a case, you should turn on the autosave and re-run the Template Import program.
The following are the parameters involved when running the import concurrent program:
Note: Seeded template mappings are ignored during the import process.
Source file name -- You must enter the import concurrent program parameter source file name including machine name and full path of the file. For example, you would enter machine2:/nfs/group/crmeco/html/template1.xml.
Note: The file name is case-sensitive.
Save after every successful template import: Select Yes to save after every successful template import. If you select No, then the system will save mappings all together at the completion of the import process.
Automatically stop the import if there are too many errors: You can use this parameter to stop the concurrent program execution if a certain number of errors occur during import. Select Yes to use the feature; select No to not use the feature.
If you select Yes, you must fill in a number in the next field, "Number of template errors to stop the import".
Number of template errors to stop the import: Enter the number of data errors after which to stop the import.
This field works only on data errors. The "Automatically stop the import if there are too many errors" field must be set to Yes for this field to be effective. The program will stop executing if a fatal error happens whether this field is set or not.
Note: For the purpose of this functionality, errors are categories as one of two types:
Fatal errors: The source file is not found or file format is incorrect.
Data errors: A template mapping definition is incorrect.
You can use the log file of the concurrent program to view details of the import, including:
Date the program was executed
Parameters involved in the execution:
XML source filename
Save after every successful template import: <Yes/No>
Automatically stop the import if there are too many errors: <Yes/No>
Number of template errors to stop the import: <number>
Result:
Number of templates successfully imported
Number of errors
Row number of first template that has an error
For steps detailing how to view log files, see the "Concurrent Programs" chapter.
Oracle iStore allows troubleshooting of the import/export concurrent program process by turning on the concurrent program's "Turn on trace" parameter. You can enable this flag for both the template mappings import and export concurrent programs.
Use the following steps:
Log in to Oracle Forms using Application Developer responsibility.
Navigate to Concurrent, Program, and find either the iStore Template Mapping Import program or the iStore Template Mapping Export program.
Select the Parameters button.
Find the DEBUG_FLAG parameter and select the Enabled checkbox.
Save the changes.
When you run either of the concurrent program for which you have enabled the debug flag, you will see the "Turn on trace" flag on the parameter screen. The debug information is included in the log file of the concurrent program. See the sections, "Template Mapping Export Program Log File" and "Template Mapping Import Program Log File", for more information.
You can transfer existing template mappings from one site to another within the same instance by doing the following:
Run the export concurrent program with the desired parameters, selecting only one site in the export. For parameters, see the section, "Running the Template Mapping Export Concurrent Program".
Modify the XML file's site parameter to reflect the Site Code of the site you wish to transfer the mappings to.
Run the import concurrent program, selecting the desired parameters. For parameters, see the section, "Running the Template Mapping Import Concurrent Program".
You can transfer existing template mappings (for all sites/categories/types) from one instance (for example, instance A) to another (for example, instance C) by doing the following:
Run the export concurrent program from source instance, leaving Site Code, Template Type, and Template Category blank. For parameters details, see the section, "Running the Template Mapping Export Concurrent Program".
Upload the export XML file to a directory accessible to the destination instance.
Run the import concurrent program from the destination instance, selecting the desired import parameters. Be sure to enter the complete path of the XML file in the Source File Name field. For parameters details, see the section, "Running the Template Mapping Import Concurrent Program".
This section contains information on advanced tasks surrounding product relationships. General information on relationships can be found in chapter, Implementing the Catalog.
If you use any relationship type other than the seeded, supported relationship type Related, you must customize the Oracle iStore JSPs to retrieve the related items with the Java API:
oracle.apps.ibe.catalog.Item.getRelatedItems().
This method can retrieve related items of given an item ID and a relationship type. The method is also overloaded. See the Oracle Integration Repository for documentation of this method.
If the relationship type is also seeded in Oracle Inventory, then oracle.apps.ibe.catalog.Item.getRelatedItems() retrieves related items defined in Oracle Inventory as well as in Oracle iStore.
See Oracle Inventory User's Guide for details on how to set up and use Oracle Inventory.
Use the following Oracle iStore seeded relationship types build relationships:
Collateral --- Entity B is collateral (e.g., marketing brochures) that exists for entity A
Complimentary --- Entity B is available free of charge with entity A
Conflict --- Entity A is not usable together with a related entity B
Cross-Sell --- Entity B can be offered and sold along with entity A
Impact --- Entity A is usable together with related entity B, but only under certain conditions
Mandatory Charge
Optional Charge
Prerequisite --- Customer must have entity B before purchasing entity A, or related product/event must be possessed/attended beforehand
Promotional Upgrade --- Entity A ordered by customer is upgraded to entity B of equal or higher value, with no change in price.
Related --- Entity B is related to entity A
Service --- Entity B is a service item that can be added to cart for a serviceable entity A
Substitute --- Entity B can be substituted for entity A
Superseded --- Entity B supersedes entity A, which is no longer available
Up-Sell --- A newer version, entity B, can be sold instead of entity A
You can define new relationship types using the Site Administration Application.
To define a new relationship type, log in to the Site Administration UI and select Catalog > Relationships > Create Relationship.
Keep in mind the following guidelines:
Seeded relationship types will have a Remove icon that is grayed out. Non-seeded relationship types will display a viable Remove icon next to them for removal of the relationship type.
Create Mapping Rules to use Oracle iStore rule builder, and follow the steps in the section, "Creating Relationships Using Mapping Rules", in the "Implementing the Catalog" chapter.
Create a SQL Rule to specify an SQL query. See the section, "Creating Relationships Using SQL Rules", below, for instructions.
The SQL method of creating relationship rules in Oracle iStore is used in place of the mapping rules by highly technical personnel with knowledge of SQL. Most site managers will use the mapping rules.
Note: You cannot use Relationship rules created using the Oracle iStore rule builder and the SQL rules together for the same relationship.
Caution: If you set up an SQL rule with a relationship type, you cannot delete it.
If a relationship is driven from an SQL rule type, the SQL statement is executed at runtime to get the actual item-level relationships. The SQL query can have up to 10 bind variables (and unlike the mapping rules, SQL Rules are not pre-evaluated). These SQL queries are executed at runtime using the input parameters supplied from the JSP page.
SQL Relationship Rules Example:
A customer is selling books on his web site and has set up the attribute1 in the DFF segment of mtl_system_items_b as the author of the book. By defining an SQL type relationship he wants to retrieve all the books belonging to the same author. Here is his sample SQL rule:
SELECT msi2.inventory_item_id
FROM mtl_system_items_b msi1, mtl_system_items_b msi2
WHERE msi1.organization_id = msi2.organization_id
AND msi1.attribute1 = msi2.attribute1
AND msi1.inventory_item_id = :item_id
AND msi1.organization_id = :organization_id
During runtime, when the value for the bind variable(s) is passed in, the SQL type relationship will retrieve all the items (books) whose author is the same as the item (book) being displayed.
Use the following procedure to create relationships using either the seeded relationship types or types you have created.
Prerequisites
Required implementation tasks have been performed.
Products and related category structures must be set up in Oracle Inventory before they can be imported into Oracle iStore. See Oracle Inventory User's Guide for details.
Products in Oracle Inventory must have the required flags set.
To create relationships using SQL, log in to the Site Administration UI and select Catalog, Relationships (select relationship), Update, Ceate a SQL Rule.
Keep in mind the following guidelines:
In the SQL Rule textbox, enter your SQL rule. For products in Oracle Inventory, retrieve the inventory_item_id column in the MTL_SYSTEM_ITEMS table.
Optionally, select Validate to validate the SQL statement before saving as a relationship rule. This will validate the SQL syntax but not the SQL content.
Note: It is recommended that you use Display Templates instead of Display Styles for displaying product information in your specialty sites. See the chapter, Implementing the Catalog.
You can choose to display products inside a section template based on the Oracle Inventory category to which the products belong. While none of the out-of-the-box Display Templates use display styles, you can create your own custom section Display Template to use the Display Styles functionality. The custom section Display Template can be created so that each product under the section can be displayed differently -- based on its inventory category -- using a Display Style.
The default category set specified by the profile option, IBE: Category Set, contains your sites' product inventory. You can map each category from Oracle Inventory to a Display Style to present content at the category level.
If there are no item-level mappings to Display Styles, Oracle iStore checks for the category-level settings and uses them to display the product.
In Oracle iStore, the display styles functionality allows you to specify a style by which categories of products will display. This allows category-level default display of products in your sites. You can select product categories from within the category set mapped to the IBE: Category Set profile option. Default product display is determined by the display style only when no product-level display parameters are set.
Each display style maps to an Oracle iStore template, which then calls the appropriate template source file (JSP) for the site and language mapping.
When you create and save new display styles in the Display Styles tab, you choose site-level default Display Templates for them. These display styles then appear in the Products and Categories pages. In Products and Categories pages, you can choose a template name to correspond with each display style for a product or a category.
You also can create new Display Styles and register them in the Display Styles pages (in the Advanced tab). See: the section, "Creating Custom Display Styles", in this chapter.
You must set the following profile option in order to enable the Display Styles pages in the Site Administration UI Advanced tab, and to be able to select display styles as defaults for product display in the Catalog, Products and the Catalog, Sections pages.
IBE: Enable Display Style --- This profile option specifies whether display styles functionality is apparent in the Oracle iStore Site Administration UI. Set it to Yes at the iStore application level to enable the appearance of certain functionality which is described below. By default, this profile option is set to No.
When the profile option is set to Yes, the following occurs in the Site Administration UI:
In the Advanced tab, Template Manager subtab, the Display Styles hyperlink appears. You select the Display Styles hyperlink to access the Display Styles page.
The Display Styles page lists all display styles in your implementation. It also allows access to other pages where you can add and update display styles.
In the Catalog pages, within the Products subtab, Use Display Styles is selectable as a display option for products in the Select a Display Template LOV.
In the Catalog pages, within the Sections subtab, Use Display Styles is selectable as a display option for sections in the Select a Display Template LOV.
When a Customer UI page displays a product using a particular display style, Oracle iStore selects the appropriate template as follows:
If there is a product-specific template for the given display style, then the product-specific template is used.
If no mapping is specified at the product level, and there is a category-specific template, then the category-specific template is used.
If no template name is selected for a product or a category, then the display style's default site-level template is used on the web page.
Note: Product-level (item-level) configurations override category-level and site-level settings.
When Oracle iStore ships, five seeded display styles are already set up. In the Site Administration UI, select Advanced, Template Manager, Display Styles to view seeded display styles.
The table below shows the seeded display styles and the Display Templates that they map to out-of-the-box.
Name | Programmatic Access Name | Default Display Template Name and Prog. Access Name |
---|---|---|
Featured Product | STORE_FEATURED_PRODUCT | Catalog - Featured Product STORE_CTLG_FEATURED_ITEM (ibecfitm.jsp) |
Product Detail | STORE_PRODUCT_DETAIL | Product Detail STORE_CTLG_ITEM_DETAIL (ibecitmd.jsp) |
Product Small Description | STORE_PRODUCT_SMALL_DESCR | Catalog - Product Small Description STORE_CTLG_LEAF_ITEM (ibeclitm.jsp) |
Product Details | STORE_PRODUCT_DETAILS | Catalog - Product Details STORE_CTLG_ITEM_DETAILS (ibeCCtdItemDetail.jsp) |
Product Description | STORE_PRODUCT_DESCR | Catalog - Product Description STORE_CTLG_LEAF_ITEM_INCL (ibeCCtdLeafItem.jsp) |
Use the following procedure to create additional display styles beyond those provided out-of-the-box.
Prerequisites
Since each display style must be mapped to a template, for new display styles, you must first register the applicable templates in the Advanced, Template Manager pages. If the template information is unavailable, you may continue the setup and select a default template later. However, if a template association is requested for any product or category with that display style and it is not specified, Oracle iStore will use the default site-level template. To avoid the error, you can also use the seeded values for display styles, listed under Display Styles in the Advanced tab, Display Styles hyperlink.
Enable Display Styles functionality by setting the profile option, IBE: Enable Display Style, to Yes at the iStore application level.
To create custom display styles, log into the Site Administration UI and select Advanced, Template Manager, Display Styles, Create Display Style.
Keep in mind the following guidelines:
Non-seeded display styles will have an active Remove icon, while seeded ones will have a grayed-out Remove icon.
Name field --- This will be the name used internally by your organization.
Programmatic Access Name field --- Enter a unique alphanumeric programmatic access name for the display style. The iStore template associated with the display style use this programmatic access name to call the display style.
Every product in the product catalog is mapped to a category in Oracle Inventory. Using media, Display Templates, and display styles, you can configure category-level defaults for product display.
Use this procedure to modify defaults for categories. You can only specify defaults for categories belonging to the primary display category set (the value of the IBE: Category Set profile option).
Prerequisites
Required implementation tasks have been performed, as described in the chapter, Implementation Tasks for Oracle iStore.
Products have been implemented as described in the chapter, Implementing Products.
The profile option, IBE: Display Style Enabled, has been set to Yes at the iStore application level.
To map category-level default templates, log into the Site Administration UI and select Advanced, Categories, Assign Templates.
Keep in mind the following guidelines:
When searching for categories, you can enter partial values in the search textbox, and Oracle iStore automatically appends a wildcard to the end.
The Category Details: Assign Display Templates page lists all seeded display styles and any mapped, category-level templates.
The Search and Select: Template page by default will only Display Templates which are meant to be used to display products.
After the mapping is established, in site pages related to this category that use a given display style, this template overrides the display style default template.
To map category-level default media objects, log into the Site Administration UI and select Advanced, Categories, Assign Content.
When advertising your specialty sites and products in e-mails and other Web sites, you can provide deep links from the advertisement to your sites.
When users select a deep link, they are automatically directed to the appropriate target based on the parameters in the URL. Possible target pages include, but are not limited to, the following:
A site home page
A section page
An item detail page
A shopping cart
Addition of items to a shopping cart
A published quote
The login and registration pages
A deep link's URL points to the entry page, ibeCZzpEntry.jsp. To the URL, you append specific parameters that are either required or optional, depending on the deep link target and your Oracle iStore setups. The parameters enable redirection of the user to the intended target page.
The following table summarizes the targets specified in the URL parameters.
Parameter Data | Description |
---|---|
Minisite ID or access name | The target specialty site |
Responsibility ID | The responsibility that should be assigned to the user |
Language | The display language |
Section ID | A section within a specialty site |
Item ID | An item, to display its detail page or add it to a shopping cart |
Shopping cart | A shopping cart with or without items |
Quote ID | A published quote's number |
Contract number | A published quote's contract number |
UOM | The UOM of an item being added to a shopping cart |
Quantity | The item quantity being added to a shopping cart |
User name | The user name for login |
Password | The password for login |
Affiliate | The affiliate that posted the deep link |
Source URL | The URL where the deep link was posted |
Source e-mail | The e-mail address to which the deep link was sent |
Party | The party ID of the registered user who received the deep link |
Marketing campaign | The marketing campaign using the deep link |
Marketing source code | The marketing source code used in the deep link |
Promotion code | Promotion code used in the deep link |
Merchant-definable parameters | Ten parameters that you can define to capture other information in the deep link URL |
Use the following procedure to create a deep link.
Steps
Create a deep link URL that uses the following syntax:
http://<domain name>/<directory path>/ibeCZzpEntry.jsp?<go parameter>&<destination parameters>&<globalization parameters>&<tracking parameters>.
For lists of supported parameter values, see:
"Go and Destination Parameters"
"Globalization Parameters"
"Tracking Parameters"
For a sample deep link URL, see the section, "Deep Link Example", below.
Include the deep link in an e-mail, Web site advertisement, or any other appropriate location.
The following deep link adds an item to the user's active shopping cart:
https://oraclestore.oracle.com/OA_HTML/ibeCZzpEntry.jsp?go=buy&item=293947&qty=1
This deep link redirects the user to the URL:
https://oraclestore.oracle.com/OA_HTML/ibeCCtpBuyRoute.jsp?item=293947&qty=1
This page is the user's active shopping cart, with one unit of the Oracle Database Enterprise Edition (item ID 293947) added. The active shopping cart also holds any items that the user had previously added.
Destination parameters specify the link's destination as commanded by the go parameter. The following table lists the supported values. The parameters are required unless otherwise stated.
Destination | Go Parameters | Destination Parameters |
---|---|---|
Specialty site home page. The home page of the specialty site in the site parameter. If the site parameter is not specified, the user is directed to the default specialty site's home page. See the table, "Parameters for Globalization Data" for details about the site parameter. | go=catalog | None |
Section page | go=section | section=<section ID> |
Item detail page | go=item | item=<item ID>§ion=<section ID> The section parameter is optional. |
Shopping cart | go=cart | None |
Quote | go=quote | quote=<quote ID>&contract=<contract number> The contract parameter is optional. |
Add one item to a shopping cart | go=buy | item=<item ID>&qty=<quantity>&uom= <UOM>&promotion=<promotion code>&msource=<marketing source code ID>&ref=<referrer URL> The promotion, msource, and ref parameters are optional. The ref parameter specifies the JSP to redirect the user to after adding the item to the cart. |
Add multiple items to a shopping cart. When creating a deep link that adds multiple items to a shopping cart, you cannot include model bundles or configurable products. | go=buy | item_0=<item ID>&qty_0=<quantity> &uom_0=<UOM>&promotion_0=<promotion code>&msource_0=<marketing source code ID>&item_1=<item ID>&qty_1= <quantity>&uom_1=<UOM>&promotion_1= <promotion code>&msource_1= <marketing source code ID> ... &num=<number of line items>&ref= <referrer URL> Use the sequential numbering convention in this example, beginning with item_0. The promotion, msource, and ref parameters are optional. The ref parameter specifies the JSP to redirect the user to after adding the items to the cart. |
Sign in or register user | go=signin | ref=<referrer> The ref parameter is optional. It specifies the JSP to redirect the user to after login. If the parameter is not set, the user is redirected to the specialty site home page. |
Other pages | go=<JSP name> | None |
Globalization parameters specify specialty site, responsibility, and language information. Globalization parameters are optional unless otherwise stated.
The following table lists the globalization parameters and their supported values.
Globalization Data | Globalization Parameters |
---|---|
Specialty Site | site=<minisite ID or access name> The site parameter is mandatory if the profile option IBE: Default Specialty Site is not defined. |
Responsibility | respid=<responsibility ID> |
Display language | language=<language code> The deep link defaults to the specialty site's default language if the language parameter is not set. |
Tracking parameters specify link tracking information. Tracking parameters are optional.
The following table lists the tracking parameters and their supported values.
Tracking Data | Tracking Parameters |
---|---|
The affiliate that posted the deep link | affiliate=<affiliate code> |
Marketing campaign | campaign=<campaign code> |
Marketing source code | msource=<marketing source code ID> |
The party ID of the registered user to whom the deep link was e-mailed | party=<party ID> |
The e-mail address to which the deep link was sent | src_email=<source e-mail> |
The URL where the deep link was posted | src_url=<source URL> |
Merchant-definable parameters | param0=<parameter> ... param9=<parameter> You can define the ten parameters param0 through param9 to meet other tracking needs. |
Oracle iStore Customer UI page designs use common components, such as tabs, bins, and common section pages. Each component is based on a template, and the templates are combined to create a site web page. The templates control the appearance of the site through the use of JavaServer Pages (JSP), which combine Application Programming Interfaces (API) to call dynamic data and HTML to present static data. The routing and processing pages determine what to do with the templates.
Oracle iStore comes packaged with a complete set of JSP templates needed to run the site. If you want to expand the functionality of the site web pages or customize the pre-packaged templates, then you need to identify the flow of the application and the JSP templates needed to implement the flow. To help determine page flows, see the chapter, Customer Application Process Flows.
Your Customer UI page can call for templates to display in two ways:
Directly by using the template logical (programmatic access) name
Indirectly by using the display style
You assign a template name and a programmatic access name to a template using the Advanced, Template Manager pages. You then assign one or more physical JSP files to combinations of sites and languages. At runtime, Oracle iStore looks at the customer's language and displays the files that are assigned to the customer's language for the site the customer is in. If no file is specified for the language, then the default source file for that site and all languages is displayed. If no file is specified for the site and all languages, then the default file for all sites and all languages is displayed.
You also can use Oracle iStore's Template Mappings Import/Export functionality to preserve existing template mappings and avoid overwriting your customized template mappings
You can indicate that the template associated with a given display style will be used when displaying a product.
Note: Although using the display styles functionality provides additional flexibility, none of the out-of-the-box templates use the display styles concept.
Oracle iStore uses the following process to determine which template to use when displaying a product according to a given display style.
Product Template Display Example
For a given display style, Oracle iStore uses the template that you associated with the product.
If no template is associated at the product level, Oracle iStore retrieves the template associated with the product's primary display category.
If no template is associated with the product or category, Oracle iStore retrieves the default template for the display style.
To customize templates for your site, perform the following tasks after planning your web page designs:
Gain an understanding of the recommended and/or mandatory page flows through your specialty sites. See the "Customer Application Process Flows" chapter for more information.
Create template source files (JSPs) for pages or for blocks within pages using Oracle JDeveloper. If you are implementing multiple languages, create source files in each of the languages which you plan to support. Or, copy the seeded JSPs (save with a new name) and apply your modifications; then, map the new JSP to the page flow through Template Manager. See the sections, "Creating Template Source Files" and "JSP Naming Conventions", in this chapter, for more information.
Choose Oracle iStore template names. See the section, "Creating New Templates", in this chapter, for more information.
Register templates in the Site Administration UI. See the section, "Registering New Templates in the Template Manager", in this chapter, for more information.
Assign template source files to templates. For instructions, see the section, "Mapping Source Files to Display Templates", in the chapter, Implementing the Catalog.
If desired, export or import existing Display Template mappings.
See the Oracle Integration Repository for more information about Oracle iStore Java APIs.
Note: During upgrades, Oracle iStore does not alter custom templates and their JSP mappings -- nor does it overwrite mappings of JSP files to specific site-language combinations.
You can create new JSP templates to replace or add to the Oracle iStore seeded templates. Different physical JSP templates can be used at run-time based on the user's language and the site being accessed.
Caution: Never change an original JSP from Oracle iStore. To modify a JSP, make a copy of the original JSP and modify only the copy.
It is recommended that you use Oracle JDeveloper to create and modify JSP templates. Although you can create JSPs with any HTML or text editor, Oracle JDeveloper also enables you to debug the code.
The main skills required to create and modify templates are HTML and Java. Java language methods in the HTML content generate dynamic content on the web page.
The structure of a JSP is demonstrated in the following HTML example.
<HTML>
<% import="oracle.apps.ibe.util.*" %>
....
....
<P> Name : <% = customer.getName(12334) %>
Where customer is a Java class on the server and getName is a public method in the class to retrieve the customer name.
<P> Picture: <IMGSRC = "<%= customer.getPict(12334) %>">
This step can retrieve the image file name from the customer Java class on the server.
....
</HTML>
The default UNIX directory for JSP source code is $COMMON_TOP/html directory. Store all of your source JSPs in this directory. This will make future Oracle iStore upgrades less problematic.
Changes made to the JSPs may not appear immediately on the web sites, since you must reboot the Apache server before changes take effect.
Deleting the server cache has the same effect as rebooting the Apache server. The server cache is located in the UNIX directory $COMMON_TOP/html/_pages/oa_html. This cache directory contains .java and .class files that are generated after the JSP that has been called is translated. These can be safely deleted and will be regenerated when the JSP is invoked through an HTTP request.
After creating or modifying templates, you can pre-compile them to check for compilation errors and to increase the speed of the initial loading.
Modify JSP source files only after copying them first. As a best practice, all modified JSPs should follow a standard naming convention.
Note that having a standard naming convention is a best practice suggestion only; it is not mandatory to use a specific naming convention in order for the JSPs to be valid.
Creating new templates involves giving the new templates names, descriptions, programmatic access names, and specifying the different physical JSP source files to be used at run-time based on language and specialty site.
The template name is the catalog name that is easy to communicate and use when planning your page designs. An example is ProductHome. Template names may be translated for convenience in site administration.
Every template name also has a programmatic access name that is short, unique, and not as descriptive. You will be using the programmatic access names to access the templates via an Oracle iStore public API in your JSP page. An example is phome. Programmatic access names are not translated.
The template name and programmatic access name potentially can represent several physical template source files. Each physical file can be assigned to combinations of sites and languages. When Oracle iStore retrieves an assigned template name, the template source file is determined by the mapping of the template name to the current site and language.
The Display Manager is the class that implements Oracle iStore's Template Manager. The Template Manager maintains a mapping from a template programmatic access name to a physical name (JSP) in the file system.
To use the Site Home Page as an example, STORE_HOME (programmatic access name) maps to ibezhome.jsp (physical file). When a web site is active, the Display Manager determines which physical file to call, based on the site being accessed and the user's language. Different source files can be called for different site-language combinations.
The following table shows examples of file names for a fictitious template called ProductHome.
Template Name | Programmatic Access Name | File | Specialty Site | Language |
---|---|---|---|---|
ProductHome | phome | hom1f.jsp | Site 1 | French |
ProductHome | phome | hom1e.jsp | Site 1 | English |
ProductHome | phome | hom2f.jsp | Site 2 | French |
ProductHome | phome | hom2e.jsp | Site 2 | English |
In this example, if a French customer enters Site 1 the site displays the home page file hom1f.jsp, which displays information in the French language.
An English customer in the same Site sees hom1e.jsp instead.
If merchants simply want to display the same information in a different language, they can use just one JSP and use AK regions or FND messages for translation. Mapping different JSPs to different languages would be used to display different information, not just translated information.
You can find steps to use AK regions and FND Messages in the Oracle Self Service Implementation Manual.
You must register new templates using the Advanced tab, Template Manager subtab in the Site Administration UI. Use this procedure to create or modify template names and programmatic access names, select default site-level template source files for them, and assign other template source files to them according to site and language settings.
For a list of seeded templates, see the "Seeded Display Data" appendix.
Prerequisites
A site has been created.
A language has been defined.
To register a new template, log in to the Site Administration UI and select Advanced > Template Manager > Add Template.
Keep in mind the following guidelines:
Name field: Enter the name by which the template is referred to during the planning stage, i.e., the common name.
Programmatic Access Name field: Enter the logical name by which the template is referred to in its JSP source file.
Keywords field: Optionally, enter any keywords you wish to associate with this template in the Keywords field. After you enter and save keywords, you can use them in the search utility.
Applicable To LOV: The display class describes where the template will be used in the Customer UI. It has no programmatic purpose, but is helpful for grouping templates, and can be used when searching for templates using the search utility. See the section, "Template Categories", in the appendix, Seeded Display Data.
Default field: Enter the name and extension (.jsp) of the default source file for the template. The default source file is used when a user attempts to retrieve the template and no other site-language mapping combination has been set up. In a single-language implementation, the default source file will generally be the same for all sites. You do not need to enter a directory name, just the JSP name and file extension.
In preparing to customize Oracle iStore's catalog display, you must first understand the flow involved in the seeded Oracle iStore catalog templates and know the logical name, physical file, and description for each template. Understanding the interactions between the catalog templates simplifies the task of customizing them.
The catalog display follows either a section display flow or an item display flow.
This section discusses the flow of section template display using either Fixed Layout or Configurable Layout.
For an introduction to section Fixed Layout and Configurable Layout, see the chapter, Implementing the Catalog.
Oracle iStore uses the following flow to display a section when Fixed Layout is being used:
When a section link is selected, the request goes to the display routing page, STORE_CTLG_SCT_ROUTE (ibeCCtpSctDspRte.jsp), which determines which section processing template should be used and forwards the request to that template.
The section processing template sets the necessary attributes in the PageContext.REQUEST_SCOPE (including the logical template name of the center display page) and forwards to STORE_CTLG_SCT_COMMON (ibeCCtdCmnSt.jsp).
STORE_CTLG_SCT_COMMON (ibeCCtdCmnSt.jsp) displays the section.
Oracle iStore uses the following flow to display a section using Configurable Layout:
When a section link is selected, the request goes to the display routing page, STORE_CTLG_SCT_ROUTE (ibeCCtpSctDspRte.jsp), which determines which Configurable Layout template should be used and forwards the request to that template. If the section is using seeded Configurable Layout, the layout template will be STORE_SCT_CONFIGURABLE_LAYOUT (ibeCCtdCmnSctLayout.jsp).
The STORE_SCT_CONFIGURABLE_LAYOUT (ibeCCtdCmnSctLayout.jsp) gets the bin template mapped to each location and the Display Template mapped to the center location, and displays the JSP pages mapped to those templates.
STORE_CTLG_SCT_ROUTE (ibeCCtpSctDspRte.jsp) is the routing page for sections. It contains the processing logic for determining which template to use when displaying a section. If there is no template associated with a section, the routing page determines which default template to use based on the hierarchy data setup. There are three default templates:
Product Detail Template -- STORE_CTLG_FSUBSCT is used for sections with featured subsections.
Subsection List Template -- STORE_CTLG_SCT_BULLET_SUBSCT is used for sections with only navigational subsections.
Product Detail Template -- STORE_CTLG_LEAF_SCT_SINGLE is used for leaf sections.
The section routing page applies the following rules when determining which template should be used to display a section:
If the section is the site's root section, forward to STORE_CTLG_FSUBSCT_FWD (ibeCCtpFwdSubSct.jsp). The site's root section is treated as a virtual section and the request is forwarded to its first navigational subsection.
If the section has a template associated with it (for Fixed Layout, it is a Display Template set up in the Section, Templates, Display Template page; for Configurable Layout, it is the seeded or a custom Configurable Layout set up in the Sections, Templates, Layout page), forward to that template.
If the section is a Leaf section, forward to STORE_CTLG_LEAF_SCT_SINGLE (ibeCCtpLeafSctSs.jsp).
If the section is a non-leaf section and the section has featured subsections, forward to STORE_CTLG_FSUBSCT (ibeCCtpFSubSct.jsp).
Otherwise, forward to STORE_CTLG_SCT_BULLET_SUBSCT (ibeCCtpStBlSuSt.jsp).
STORE_CTLG_SCT_COMMON (ibeCCtdCmnSt.jsp) is the common display page used for displaying sections when using Fixed Layout. It displays each portion of the common layout for section pages by including the JSP that handles the display in that location. STORE_CTLG_SCT_COMMON includes the following components:
The menu at the top of the page
The left bins (Browse Bin, additional left bins) on the left side
The center components (section path traversed, center display page) in the center of the page
The right bins (Welcome Bin, eMerchandising posting from Oracle Marketing, additional right bins) on the right side
See the section, "Example for Fixed Layout", in this chapter, for an example.
STORE_SCT_CONFIGURABLE_LAYOUT (ibeCCtdCmnSctLayout.jsp) is the seeded common layout page used for displaying sections using Configurable Layout. It gets the template mapped to each location and the Display Template mapped to the center part, and displays the JSP pages mapped to those templates. STORE_SCT_CONFIGURABLE_LAYOUT includes the following components:
The menu at the top of the page
The bins mapped to the top, bottom, left seven locations, right seven locations, and middle four locations
The section path traversed and the central display page
See the section, "Example for Configurable Layout", in this chapter, for an example.
In the following example assume that the data is set up such that template STORE_CTLG_LEAF_SCT_SINGLE is associated with section 1000. This example illustrates the flow through the catalog templates when a user selects on the link ibeCCtpSctDspRte.jsp?section=1000.
Catalog Template Flow for Link ibeCCtpSctDspRte.jsp?section=1000
In the following example assume that the data is set up such that section 2000 is using Configurable Layout, and select template STORE_CUST_ACC_WELCOME for the left 1 location, STORE_CTLG_SCT_BROWSE for the left 2 location, STORE_GLOBAL_STORE_BIN for the right 1 location, and STORE_CTLG_LEAF_SCT_SINGLE_INCL for the Display Template in the center. This example illustrates the flow through the catalog templates when a user selects on the link ibeCCtpSctDspRte.jsp?section=2000.
Catalog Template Flow for Link ibeCCtpSctDspRte.jsp?section=2000
Oracle iStore uses the following flow to display an item:
When an item link is selected, the request goes to STORE_CTLG_ITM_ROUTE (ibeCCtpItmDspRte.jsp) which determines the item template to use (the template for display style STORE_PRODUCT_DETAILS) and forwards the request to that template. The default template is STORE_CTLG_ITEM_DETAILS (ibeCCtdItemDetail.jsp).
The item template displays the item detail page.
For each section display, there is a pair of templates:
A processing page that sets attributes needed by the common display page
A center display page which generates the HTML for the center of the page
The section processing page specifies which center display page should be used. The following naming convention can be used to identify which section processing page corresponds to which center display page.
Section Processing Logical Name: SECTION_PROCESS_NAME
Section Center Display Logical Name: SECTION_PROCESS_NAME_INCL
Section Processing Physical File: ibeCCtpName.jsp
Section Center Display Physical File: ibeCCtdNameI.jsp
Product Detail section Display Template:
Section Processing Logical Name: STORE_CTLG_FSUBSCT
Section Center Display Logical Name: STORE_CTLG_FSUBSCT_INCL
Section Processing Physical File: ibeCCtpFSubSct.jsp
Section Center Display Physical File: ibeCCtdFSubSctI.jsp
For a list of seeded templates, see the "Seeded Display Data" appendix.
The following options are presented:
"Fixed and Configurable Layouts"
"Fixed Layout"
"Configurable Layout"
For both Fixed Layout and Configurable Layout, you can customize the following:
Customize the section routing behavior -- See the section, "Customizing the Section Routing Behavior", below, for details.
Customize the section browse bin -- See section, "Customizing the Section Browse Bin", in this chapter, for details.
Customize the section path -- See the section, "Customizing the Section Path", in this chapter, for details.
For Fixed Layout, you have the following additional customization options:
Customize the section template common fixed layout -- See the section, "Customizing the Section Template Common Fixed Layout", in this chapter, for details.
Create a section template with the common fixed layout -- See the section, "Creating a Section Page With a Common Fixed Layout", in this chapter, for details.
Create a section template with custom fixed layout -- See the section, "Creating a Section Page With a Custom Fixed Layout", in this chapter, for details.
For Configurable Layout, you have the following additional customization options:
Customize the section template common Configurable Layout -- See the section, "Customizing the Section Template Common Configurable Layout", in this chapter, for details.
Create a custom Configurable Layout -- See the section, "Creating a Custom Configurable Layout", in this chapter, for details.
Create a central Display Template for Configurable Layout -- See the section, "Creating a Center Display Template for Configurable Layout", in this chapter, for details.
In most cases, the section routing behavior will not need changes since it is data driven. STORE_CTLG_SCT_ROUTE (ibeCCtpSctDspRte.jsp) contains processing logic for determining the template to forward to based on the template associated with a section. If the section routing behavior needs to be changed (for example, to change the default destination pages when no template is associated with a section), customize STORE_CTLG_SCT_ROUTE (ibeCCtpSctDspRte.jsp).
Steps
Copy ibeCCtpSctDspRte.jsp into a new JSP.
Make the necessary changes in the new JSP.
Modify the template data setup. In this case, the same logical template name should be used because STORE_CTLG_SCT_ROUTE is used in all other JSPs when building links to sections.
Log in to the Site Administration UI and add the necessary logical to physical template mappings for STORE_CTLG_SCT_ROUTE. In the Template Details page, add a new source file for the new JSP. To use this source file for all sites and all languages, add a mapping for ALL sites and each installed language.
For example, if French and American English are installed, add two rows in "Specialty Site And Language Mappings":
All sites, French
All sites, American English
Each time a new language is added, you must add a new mapping.
If the display of the section Browse Bin (section navigation bin) needs to be changed, customize STORE_CTLG_SCT_BROWSE (ibeCCtdSctBrwsBin.jsp).
Steps
Copy ibeCCtdSctBrwsBin.jsp to a new JSP.
Make the necessary changes in the new JSP.
Modify the template data setup. In this case, the same logical template name should be used because STORE_CTLG_SCT_BROWSE is used in other JSPs when including the browse bin.
Log in to the Site Administration UI and add the necessary logical to physical template mappings for STORE_CTLG_SCT_BROWSE. In the Template Details page, add a new source file for the new JSP. To use this source file for all sites and all languages, add a mapping for ALL sites and each installed language.
For example, if French and American English are installed, add two rows in "Specialty Site And Language Mappings":
All sites, French
All sites, American English.
Each time a new language is added, you must add a new mapping.
If the display of the section path needs to be changed, customize STORE_CTLG_SCT_PATH (ibeCCtdSctPath.jsp).
Steps
Copy ibeCCtdSctPath.jsp into a new JSP.
Make the necessary changes in the new JSP.
The template data setup will need to be modified. In this case, the same logical template name should be used because STORE_CTLG_SCT_PATH is used in other JSPs when including the path traversed.
Log in to the Site Administration UI and add the necessary logical to physical template mappings for STORE_CTLG_SCT_PATH. In the Template Details page, add a new source file for the new JSP. To use this source file for all sites and all languages, add a mapping for ALL sites and each installed language.
For example, if French and American English are installed, add two rows in "Specialty Site And Language Mappings"
All sites, French
All sites, American English.
Each time a new language is added, you must add a new mapping.
In the seeded templates, all the section templates using Fixed Layout share the same layout. This layout is specified in STORE_CTLG_SCT_COMMON (ibeCCtdCmnSt.jsp). All section pages using Fixed Layout are ultimately displayed by this page, with the center display page changing dynamically based on the attributes set by the section processing page. If the common layout model will be used, but the layout needs to be changed, customize STORE_CTLG_SCT_COMMON (ibeCCtdCmnSt.jsp).
Steps
Copy ibeCCtdCmnSt.jsp into a new JSP.
Make the necessary changes in the new JSP.
The template data setup will need to be modified. In this case, the same logical template name should be used because the processing section JSPs forward to STORE_CTLG_SCT_COMMON to display the section.
Log in to the Site Administration UI and add the necessary logical to physical template mappings for STORE_CTLG_SCT_COMMON. In the Template Details page, add a new source file for the new JSP. To use this source file for all sites and all languages, add a mapping for ALL sites and each installed language.
For example, if French and American English are installed, add two rows in "Specialty Site And Language Mappings":
All sites, French
All sites, American English
Each time a new language is added, you must add a new mapping.
To provide custom section display, create new section pages. If the new section display will use a common layout, two new JSPs need to be created.
Note: The CENTER_DISPLAY_PAGE used in this example is only a sample logical template used for the purposes of example, not a real template seeded out-of-the-box.
Steps
Create a section processing page. This can be done by copying an existing section processing page (such as ibeCCtpFSubSct.jsp) or using the example below as a guideline.
<%@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.ibe.displaymanager.DisplayManager" %>
<%@page import="oracle.apps.jtf.base.Logger" %>
<%@include file="ibeCZzpHeader.jsp" %>
<%
String JSP_PAGE_NAME = "sectionProcesssPage.jsp";
String lSectionIdStr = "";
String lCenterDisplayPage = "";
String lBeginIndexStr = "";
/* Welcome Bin */
pageContext.setAttribute("showWelcomeBin", "true",
PageContext.REQUEST_SCOPE);
/* Center Display Page *
lCenterDisplayPage =
DisplayManager.getTemplate("CENTER_DISPLAY_PAGE").getFileName();
if(lCenterDisplayPage == null)
{
lCenterDisplayPage = ""
IBEUtil.log(JSP_PAGE_NAME,
"Null template found for logical template name " +
"CENTER_DISPLAY_PAGE",
Logger.ERROR);
}
pageContext.setAttribute("centerDisplayPage", lCenterDisplayPage,
PageContext.REQUEST_SCOPE);
/* Get/Set section ID */
lSectionIdStr =
(String) pageContext.getAttribute("section",
PageContext.REQUEST_SCOPE);
if(lSectionIdStr == null || lSectionIdStr.equals(""))
{
lSectionIdStr = (String) request.getParameter("section");
if(lSectionIdStr == null)
{
lSectionIdStr = "";
IBEUtil.log(JSP_PAGE_NAME, "Section is null", Logger.ERROR);
}
}
pageContext.setAttribute("section", lSectionIdStr,
PageContext.REQUEST_SCOPE);
/* Get/Set beginIndex */
lBeginIndexStr =
(String) pageContext.getAttribute( "beginIndex",
PageContext.REQUEST_SCOPE);
if (lBeginIndexStr == null || lBeginIndexStr.equals(""))
{
lBeginIndexStr = request.getParameter("beginIndex");
if (lBeginIndexStr != null)
{
pageContext.setAttribute( "beginIndex", lBeginIndexStr,
PageContext.REQUEST_SCOPE);
}
}
if (IBEUtil.showPosting())
{
// set item ids in the PageContext.REQUEST_SCOPE for use by
// eMerchandising postings
int[] itemIds = new int[0];
// code to populate itemIds based on the items that will be displayed
// on this section page
if (itemIds.length > 0)
pageContext.setAttribute("itemIds", itemIds, PageContext.REQUEST_SCOPE);
}
String lCommonPage =
DisplayManager.getTemplate("STORE_CTLG_SCT_COMMON").getFileName();
%>
<jsp:forward page="<%=lCommonPage%>" />
Create a center display page. This can be done by copying an existing section center display page (such as ibeCCtdFSubSctI.jsp) or using the example below as a guideline.
<%@include file="ibeCZzpRuntimeIncl.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.ibe.displaymanager.*" %>
<%@page import="oracle.apps.jtf.base.resources.Architecture" %>
<%@page import="oracle.apps.jtf.base.interfaces.MessageManagerInter" %>
<%@page import="oracle.apps.jtf.base.Logger" %>
<%
// processing logic to retrieve all section and item information that will
// be displayed on the page
boolean bSectionLoaded = false;
Section s = null;
// declare variables for other objects that will be displayed:
// for example, featured subsections, navigational subsections, items,
// item prices, etc.
String lSectionIdStr =
IBEUtil.nonNull((String)pageContext.getAttribute("section",
PageContext.REQUEST_SCOPE));
try {
int lSectionId = Integer.parseInt(lSectionIdStr);
s = Section.load(lSectionId, Section.DEEP);
bSectionLoaded = true;
// additional code to retrieve objects that will be displayed on the page:
// for example, featured subsections, navigational subsections, items,
// item prices, etc.
} catch (NumberFormatException e) {
IBEUtil.log(JSP_PAGE_NAME, "Could not parse section id=");
IBEUtil.lod(lSectionIdStr);
} catch (SectionNotFoundException e) {
IBEUtil.log(JSP_PAGE_NAME, "Could not load section. Section id=");
IBEUtil.log(JSP_PAGE_NAME, lSectionIdStr);
}
if (bSectionLoaded)
{
%>
<table width="100%">
<tr>
<td valign="top" width="100%" >
<!-- start middle column content-->
<%-- code to display section --%>
</td></tr></table>
<%
} // end section was loaded
%>
In the Site Administration UI, create a new logical template for the section processing page. Make sure that the category of the template is one of the following:
Section Contains Featured Subsection
Section Contains Navigational Subsections Only
Section Contains Products Only
Uncategorized Section Display Template
In the Site Administration UI, create a new logical template for the center display page. Make sure that the category of the template is one of the following:
Component for Sections Containing Featured Subsections
Component for Sections Contain Navigational Subsections Only
Component for Sections Containing Products Only
Component for Sections
Modify the section processing page as needed.
In the JSP, change the logical template name used for the center display page to be the logical template name created for the new center display page. Change
lCenterDisplayPage =
DisplayManager.getTemplate("STORE_CTLG_FSUBSCT_INCL").getFileName();
to
lCenterDisplayPage =
DisplayManager.getTemplate("CENTER_DISPLAY_PAGE").getFileName();
If Oracle Marketing's eMerchandising postings will be used, an int[] containing the item IDs of the items that will be displayed on the page must be set in the PageContext.REQUEST_SCOPE. There are examples of how to do this in the seeded templates.
Modify the display page as needed.
Retrieve the necessary section and item information using the Section and Item APIs, which are described in the Oracle Integration Repository.
Display the information as desired.
In the Site Administration UI, map the new template to a section as desired. See the chapter, Implementing the Catalog, for steps.
To provide custom section display, create new section pages. If the new section display will use its own custom layout, only one new JSP needs to be created.
Steps
Create a section Display Template. See the example below.
<%@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="java.math.BigDecimal" %>
<%@page import="oracle.apps.jtf.base.Logger" %>
<%@ include file="ibeCZzpHeader.jsp" %>
<%
String JSP_PAGE_NAME = "mySectionJsp.jsp";
MessageManagerInter msgMgr =
Architecture.getMessageManagerInstance();
int lSectionId = -1;
String lSectionIdStr = "";
String lShowWelcomeBinStr = "";
boolean bShowWelcomeBin = true;
String browsePage = "", pathPage = "", welcomePage = "";
Section lSection = null;
// declare variables for other objects that will be
// displayed: for example, featured subsections, items, item prices, etc
/* Get section ID String */
lSectionIdStr =
(String)pageContext.getAttribute("section", PageContext.REQUEST_SCOPE);
try
{
lSectionId = Integer.parseInt(lSectionIdStr);
}
catch(NumberFormatException e)
{
lSectionId = StoreMinisite.getRootSectionID().intValue();
}
/* Get show welcome bin */
lShowWelcomeBinStr =
(String)pageContext.getAttribute("showWelcomeBin",
PageContext.REQUEST_SCOPE);
if(lShowWelcomeBinStr == null || lShowWelcomeBinStr.equals(""))
{
lShowWelcomeBinStr = "true";
}
if(lShowWelcomeBinStr.equalsIgnoreCase("false"))
{
bShowWelcomeBin = false;
/*
* Get the value of all the pages and bins to display
*/
/* Section Hierarchy Tree Browse Bin */
if(IBEUtil.useFeature("IBE_USE_SECTION_BIN"))
{
browsePage =
DisplayManager.getTemplate("STORE_CTLG_SCT_BROWSE").getFileName();if(browsePage == null)
{
browsePage = "";
}
}
/* Section Section Path Bin */
if(IBEUtil.useFeature("IBE_USE_SECTION_PATH"))
{
pathPage =
DisplayManager.getTemplate("STORE_CTLG_SCT_PATH").getFileName();
if(pathPage == null)
{
pathPage = "";
}
}
/* Welcome Page Bin */
if(bShowWelcomeBin)
{
welcomePage =
DisplayManager.getTemplate("STORE_CUST_ACC_WELCOME").getFileName();
if(welcomePage == null || welcomePage.equals(""))
{
bShowWelcomeBin = false;
IBEUtil.log(JSP_PAGE_NAME,
"Welcome Page is either null or not specified",
Logger.ERROR);
}
}
if (IBEUtil.showPosting())
pageContext.setAttribute("pageType", "SECTION",
PageContext.REQUEST_SCOPE);
/* load section and other objects that will be displayed */
try
{
lSection = Section.load(lSectionId);
// additional code to retrieve other objects that will be displayed
// on the page: for example, featured subsections, navigational
// subsections, items, item prices, etc.
if (IBEUtil.showPosting())
{
// set item ids in the PageContext.REQUEST_SCOPE for use by
// eMerchandising postings
int[] itemIds = new int[0];
// code to populate itemIds based on the items that will be displayed
// on this section page
if (itemIds.length > 0)
pageContext.setAttribute("itemIds", itemIds,
PageContext.REQUEST_SCOPE);
}
}
catch(SectionNotFoundException ex)
{
IBEUtil.log(JSP_PAGE_NAME,
"Could not load (shallow) section with ID" + lSectionId,
Logger.ERROR);
lSection = null;
}
if(lSection != null)
{
pageContext.setAttribute("_pageTitle", lSection.getDisplayName(),
PageContext.REQUEST_SCOPE);
}
else
{
pageContext.setAttribute("_pageTitle", "", PageContext.REQUEST_SCOPE);
}
%>
<%@ include file="ibeCCtpPostingI.jsp" %>
<%@ include file="ibeCZzdTop.jsp" %>
<%@ include file="ibeCZzdMenu.jsp" %>
<!-- body section -------------------------------------------------------->
<table border="0" width="100%">
<tr>
<td> </td>
<!-- left column ----------------------------------------------------->
<td valign="top">
<%-- sections bin ---------%>
<%
if(IBEUtil.useFeature("IBE_USE_SECTION_BIN") &&
!browsePage.equals(""))
{
%>
<jsp:include page="<%=browsePage%>" flush="true" /><br>
<%
}
%>
</td>
<!-- center column --------------------------------------------------->
<td valign="top" width="100%">
<%
if(IBEUtil.useFeature("IBE_USE_SECTION_PATH") &&
!pathPage.equals(""))
{
%>
<table width="100%">
<tr>
<td colspan="2" class="smallLink">
<jsp:include page="<%=pathPage%>" flush="true" />
</td>
<td>
</td>
</tr>
</table>
<%
}
if (lSection != null)
{
// code to display section/items.
// for examples, see out of the box section center display templates
}
%>
</td>
<!-- right column ---------------------------------------------------->
<td valign="top">
<%-- RHS bins ----%>
<%-- welcome bin ----------%>
<%
if(bShowWelcomeBin)
{
%>
<jsp:include page="<%=welcomePage%>" flush="true" /><br>
<%
}
%>
<%
if(IBEUtil.showPosting())
{
IBEUtil.log(JSP_PAGE_NAME, "eMerchandising posting - BEGIN");
try {
%>
<jsp:include page="ibapstng.jsp" flush="true" /><br>
<% } catch (Throwable t) {
IBEUtil.log(JSP_PAGE_NAME,
"Error occurred while including eMerchandising page");
}
IBEUtil.log(JSP_PAGE_NAME, "eMerchandising posting - END");
}
%>
</td>
</tr>
</table>
<%@ include file="ibeCZzdBottom.jsp" %>
In the Site Administration UI, create a new logical template for the section display page. Make sure that you create the template as one that "Displays: section."
In the Site Administration UI, map the new template to a section as desired. See the chapter, Implementing the Catalog, for steps.
The layout template STORE_SCT_CONFIGURABLE_LAYOUT (ibeCCtdCmnSctLayout.jsp) is used to display the layout for all the sections using seeded Configurable Layout. This common Configurable Layout template gets the template mapped to each location and the Display Template mapped to the center part, and displays the JSP pages mapped to those templates. If you need to change the layout of all the section using seeded layout template, customize STORE_SCT_CONFIGURABLE_LAYOUT (ibeCCtdCmnSctLayout.jsp).
Steps
Copy ibeCCtdCmnSctLayout.jsp into a new JSP.
Make the necessary changes in the new JSP.
The template data setup will need to be modified. Log in to the Site Administration UI and add the necessary logical to physical template mappings in STORE_SCT_CONFIGURABLE_LAYOUT. In the Template Details page, add a new source file for the new JSP. To use this source file for all sites and all languages, add a mapping for ALL sites and each installed language.
For example, if French and American English are installed, add two rows in Specialty Site And Language Mappings:
All sites, French
All sites, American English.
Each time a new language is added, you must add a new mapping.
You can create a custom Configurable Layout. The new custom layout will be displayed in the Select Layout drop-list in Sections, Templates, Layout page during setup, and you can use the custom layout for a section. The custom layout page should have the similar logic as that in the seeded Configurable Layout: gets the template mapped to each location and the Display Template mapped to the center part, and display the JSP pages mapped to those templates. But it can have different display layout.
Steps
Create a custom Configurable Layout page. This can be done by copying and modifying the seeded Configurable Layout page (ibeCCtdCmnSctLayout.jsp) . In the layout page, the following API can be used to get the bin template mapped to each location (including the Display Template mapped to the center):
Public Template Oracle.apps.ibe.displaymanager.DisplayManager.getSectionComponentTemplate(int SectionId, String locationCode)
The location code can be Top, Bottom, Left 1 through Left 7, Right 1 through Right 7, Middle 1 through Middle 4, or Center. Center is used to get the center Display Template. If there is no template mapped to the location, or there is no JSP mapped to the template, the API returns null.
In the Site Administration UI, create a new logical template for the custom Configurable Layout page. Make sure that the category of the template is Section Layout. Set the custom Configurable Layout page as the default mapping for the template.
Map the custom layout template to the section, and configure the bin templates mapped to each location. See the "Implementing the Catalog" chapter for steps.
You can create a custom center Display Template and map it to a section using Configurable Layout. At run-time, the Configurable Layout template will load the Display Template mapped to the center part, and display the JSP page mapped to that template.
Steps
Create a center display page. This display page is similar to the display page created in step 2 of the section, "Creating a Section Page With a Common Fixed Layout". It can be done by copying an existing section center display page (such as ibeCCtdFSubSctI.jsp) or using the example described in the section, "Creating a Section Page With a Common Fixed Layout", step 2, as a guideline.
In the Site Administration UI, create a new logical template for the center display page. Make sure that the category of the template is one of the following:
Component for Sections Containing Featured Subsection
Component for Sections Contain Navigational Subsections Only
Component for Sections Containing Products Only
Component for Sections
In the Site Administration UI, map the new center Display Template to a section using Configurable Layout, as desired. See the chapter, Implementing the Catalog, for steps.
You can customize item routing behavior and create item detail templates.
In most cases, the item routing behavior will not need changes since it is data driven. STORE_CTLG_ITM_ROUTE (ibeCCtpItmDspRte.jsp) contains processing logic for determining the template to forward to based on the template associated with display context STORE_PRODUCT_DETAILS for a particular item. If the item routing behavior needs to be changed (for example, to change the display context that is used), customize STORE_CTLG_ITM_ROUTE (ibeCCtpItmDspRte.jsp).
Steps
Copy ibeCCtpItmDspRte.jsp into a new JSP.
Modify the new JSP as needed. For example, change the display context that is used. If modifying the display context, make sure that all templates associated with the new display context produce HTML for displaying an entire page.
The template data setup will need to be modified. In this case, the same logical template name should be used because STORE_CTLG_ITM_ROUTE is used in all other JSPs when building links for items. Log in to the Site Administration UI and add the necessary logical to physical template mappings for STORE_CTLG_ITM_ROUTE. In the Template Details page, add a new source file for the new JSP. To use this source file for all sites and all languages, add a mapping for ALL sites and each installed language.
For example, if French and American English are installed, add two rows in "Specialty Site And Language Mappings":
All sites, French
All sites, American English.
Each time a new language is added, you must add a new mapping. Do not change the mapping for ALL sites, ALL languages. If you change this mapping, the change may be overwritten when patches are applied.
To provide a custom display of the item detail page, create a new item detail page.
Steps
Copy ibeCCtdItemDetail.jsp into a new JSP or use the example below as a guideline.
<%@page import="oracle.apps.ibe.order.*" %>
<%@page import="oracle.apps.ibe.catalog.*" %>
<%@page import="oracle.apps.ibe.store.*" %>
<%@page import="oracle.apps.jtf.displaymanager.*" %>
<%@page import="oracle.apps.jtf.base.Logger" %>
<%@page import="oracle.apps.jtf.minisites.*" %>
<%@ include file="ibeCZzpHeader.jsp" %>
<%
MessageManagerInter msgMgr = Architecture.getMessageManagerInstance();
pageContext.setAttribute("_pageTitle",
msgMgr.getMessage("IBE_PRMT_CT_PRODUCT_DETAILS"),
PageContext.REQUEST_SCOPE);
String lItemId =
IBEUtil.nonNull((String)pageContext.getAttribute("item",
PageContext.REQUEST_SCOPE));
if (lItemId.equals(""))
{
lItemId = IBEUtil.nonNull(request.getParameter("item"));
pageContext.setAttribute("item", lItemId, PageContext.REQUEST_SCOPE);
}
if (IBEUtil.showPosting())
{
// used by ibeCCtpPostingI.jsp
pageContext.setAttribute("pageType", "ITEM", PageContext.REQUEST_SCOPE);
// set itemIDs[] for eMerchandising posting
try {
int[] itemIds = new int[1];
String itemIdStr =
(String) pageContext.getAttribute("item", PageContext.REQUEST_SCOPE);
itemIds[0] = Integer.parseInt(itemIdStr);
pageContext.setAttribute("itemIds", itemIds, PageContext.REQUEST_SCOPE);
} catch (NumberFormatException e) {}
}
%>
<%@ include file="ibeCCtpPostingI.jsp" %>
<%@ include file="ibeCZzdTop.jsp" %>
<%@ include file="ibeCZzdMenu.jsp" %>
<%
String lSectionId = "";
int sectid = 0, itmid = 0;
Item itm = null;
// declare variables for other objects that will be
// displayed: for example, item images, item prices, item flexfields,
// related items, etc.
lSectionId = IBEUtil.nonNull(request.getParameter("section"));
if (lSectionId.equals(""))
lSectionId =
IBEUtil.nonNull((String)pageContext.getAttribute("section",
PageContext.REQUEST_SCOPE));
/* sections path */
if(IBEUtil.useFeature("IBE_USE_SECTION_PATH"))
{
try {
sectid = Integer.parseInt(lSectionId);
pageContext.setAttribute("section", String.valueOf(sectid),
PageContext.REQUEST_SCOPE);
pathPage =
DisplayManager.getTemplate("STORE_CTLG_SCT_PATH").getFileName();
} catch (NumberFormatException e) { }
if(pathPage == null)
pathPage = "";
}
try {
itmid = Integer.parseInt(lItemId);
itm = Item.load(itmid, Item.DEEP);
bItemLoaded = true;
// additional code to retrieve other objects that will be displayed
// on the page: for example, item images, item prices, related items, etc.
} catch (NumberFormatException e) {
IBEUtil.log("ibeCCtdItemDetail.jsp", "Could not parse item id="
+lItemId);
} catch (ItemNotFoundException e) {
IBEUtil.log("ibeCCtdItemDetail.jsp", "Could not load item id="+lItemId,
Logger.ERROR);
}
if (bItemLoaded)
{
%>
<!-- body section ----------------------------------------------------------->
<table border="0" width="100%">
<%
if (IBEUtil.showPosting()) {
%>
<!--------- eMerchandising integration ----------------->
<tr><td colspan="4" align="center">
<% try {
%>
<jsp:include page="ibapstng.jsp" flush="true" />
<% } catch (Throwable e) {
IBEUtil.log("ibeCCtdItemDetail.jsp", "eMerchandising error", Logger.ERROR);
}
%>
</td></tr>
<% } //end eMerchandising installed
%>
<tr><td> </td>
<%
if(IBEUtil.useFeature("IBE_USE_SECTION_PATH") &&
!pathPage.equals(""))
{
%>
<td colspan="4" class="smallLink">
<jsp:include page="<%=pathPage%>" flush="true" />
</td>
<% }
%>
</tr>
<tr><td valign="top"> </td>
<!-- center column ------------------------------------------------------>
<td valign="top" width="70%">
<table border="0" cellpadding="0" cellspacing="0">
<%-- code to display item --%>
</table>
</td>
<!-- right column ------------------------------------------------------->
<td valign="top" width="20%">
<table border="0" cellpadding="0" cellspacing="0">
<%-- code to display right bins --%>
</table>
<p> </p>
<p> </p>
</td></tr></table> <%-- end page table --%>
<% } // end item loaded
%>
<%@ include file="ibeCZzdBottom.jsp" %>
<!-- ibeCCtdItemDetail.jsp end -->
Modify the new item detail page as needed.
Retrieve the necessary item information using the Item APIs, which are described in the Oracle Integration Repository.
Display the information as desired.
The template data setup will need to be modified. In the Site Administration UI, create a new logical template for the new item detail display page. Make sure that you create the template as one that displays products.
If the new item detail page should be used as the default template for a display context (such as STORE_PRODUCT_DETAILS), follow the steps in the section, "Using Display Styles for Default Display", in this chapter, for map the new template to a display style.
To associate the new item detail template to the appropriate display style at the item level, follow the steps in the "Implementing the Catalog" chapter.
To associate the new item detail template to the appropriate display style at the category level, follow the steps in the section, "Configuring Product Presentation at the Category Level", in this chapter.
Repeat this step for each applicable category.
You can provide a custom style sheet using the following procedure.
Copy jtfucss.css into another file and make the desired changes to the new file, using the style sheet editor of your choice. Or, create a new style sheet file(s).
Map the logical templates discussed above, as desired, to the new files. See the chapter, Implementing the Catalog, for instructions.
Restart the Apache server after making these changes.
If using a single, customized file for all three branding size profile settings, then map this file to each of the three style sheet templates mentioned above. If you are using separate customized files for the three branding sizes, you can map the source files separately to each style sheet template. If using only the out-of-box stylesheet files, and jtfucss_sml.css and jtfucss_med.css are in your instance, map jtfucss_sml.css to STORE_STYLE_SHEET_SML, and jtfucss_med.css to STORE_STYLE_SHEET_MED.
The help icon on the menu will only be displayed if there is a template association for the help page.
Provide a custom help page using the following procedure.
Steps
Copy ibeCZzdHelp.jsp into another file.
Make the necessary changes to the JSP.
Modify the template data setup. Log in to the Site Administration UI and add the necessary logical to physical template mappings for STORE_HELP_PAGE. In the Template Details page, add a new source file for the new help page. Add the necessary mappings for the desired site-language combinations. To use this source file for all sites and all languages, add a mapping for all sites, all languages. The changes will not be overwritten when patches are applied because there is no seeded default value for STORE_HELP_PAGE.
To make advanced changes to the Customer UI page displays, beyond bin layout and text messages, you must have complete knowledge of the APIs being called from the JSP template source file. The APIs are the key for displaying data on the site pages. These are the application objects and beans. Customers and users cannot modify these class files.
For public class API documentation, see the Oracle Integration Repository.