This chapter covers advanced topics for creating catalogs and managing content within catalogs.
The search engine allows robust search capabilities. The engine employs a rich and powerful query language with use of the Rich Search screen and with the use of scripting.
Search uses two methods of searching: runtime and non-runtime. The method for the non-runtime searches is that when a user performs a search and the expected result set is large, the search can be scheduled and the result set report will be delivered to the user.
The Rich Search screen can be used to build quick rich search templates. Users also have the ability to construct the custom search queries by using AND, OR, <>, <=, and >= like conditional statements.
Search can also be performed on Multi-Occurrence item, item-location data attributes. In the case of the Multi-Occurrence Attribute search, the search string is searched in each of the occurrences of the Multi-Occurrence attribute and is displayed as part of the search result if the search string exists in that attribute.
When modeling item data, attributes are to be grouped into two categories.
- Global attributes - Attributes that apply to an item regardless of location. These are defined as the core attributes of an item and can contain hundreds of attributes per item. The limitation for this release is that a search can be be performed on Multi-occurring items of global attributes.
- Location attributes - Attributes that apply to an item based on location. These are defined as location specific attributes of an item and can be defined for multiple locations with many attributes per item.
Search method
The item table of the database will only save runtime searchable attributes, which are marked at the spec level when defining a spec attribute.
Two search methods can be employed:
- Runtime: SQL is used to query the item table. Search is performed on the application server
- Non-runtime: searches are performed in JAVA. Search runs in the background and is performed on the Scheduler
The order in which searches are performed are global attributes first, then location attributes. Therefore the Runtime search method is first used to minimize and restrict a result set, then if additional search is required on a larger result set, the non-runtime search is performed.
Restrict the itemset results by setting the Rich Search common.properites configuration. If the itemset is larger than the number set in common.properties, it will perform a background (non-runtime) search search. An notification email reporting the completed search is sent to the user who performed the search.
Set maximum number of items allowed to be searched in realtime
max_number_items_for_realtime_search
Description: Set for rich search: maximum number of items allowed to be searched on in real time. If the number of items returned by the initial query estimate is greater than this number, the search will be scheduled as a background search.
For example:
max_number_items_for_realtime_search=1000
Note: This setting only applies to synchronous searches (runtime). Asynchronous searcher (non-runtime) ignores this setting.
Separation of schema
To better handle searches with large result sets, two schemas have been created as part of the design of creating a more robust search engine.
- Data schema: The serialization of items that reduce the number of rows that is required to save an item
- Search schema: The search schema includes global attributes and category mappings
Searches are performed in a two phase execution:
1. Database driven: search for global attributes and category mappings
2. Java driven: search for location attributes and location mappings
Rich Search screen
The rich search screen allows the search of Global and location attributes. Users can create a search template that is used to define a set of global and/or location attributes.
Through the GUI, if the resulting itemset is larger than the number set in common.properties, the search will be performed in the background. The user will be notified by a dialog box that the completed search result notification is to be sent via email.
Figure 5.1 Rich Search screen
Creating a saved Search Template
1. From the Rich Search Screen (1. Saved Search Template), click New.
2. A dialog box appears. Enter a name for the search template, a description (optional), and select Specs or individual nodes for the search criterion and click SAVE.
Figure 5.2 - Create search template
Run Search based on saved search template
1. At the Rich Search screen, select the saved template and click LOAD. The search attributes appear.
Figure 5.3 - Load search template
2. Select category restrictions if desired. This can be done by selecting an associated hierarchy under (2. Select Category Restrictions:). A window displays and allows the ability to select any number of hierarchies or sub-tree thereof to restrict from the search. Click Done to return to the Rich Search screen.
Figure 5.4 - Select search options
3. Check the box next to the attribute to search and enter the desired search criteria. When all search data is complete, click Search. The results are displayed in the Multiple Edit screen.
4. To create another search with a different criterion, click the Rich Search tab. On the Rich Search screen, click Clear and begin to define the desired search criterion.
Note: It is required to click Clear before creating a new search criteria. If Clear is not clicked, the search results will be inaccurate.
Item-Location Inheritance for Hierarchies
Item-location inheritance for one or more hierarchies in the system is supported in this release. When the item-location attribute inheritance is in place, an item can only inherit location attribute values from one parent and not multiple parents. Clustering is not supported in this release.Example of how item-location inheritance is used:
Assume that there are two location hierarchies in the system – Hierarchy 1 and Hierarchy 2. Hierarchy 1 contains Attributes A and B. Hierarchy 2 contains Attributes C and D. Item 12345 is mapped to both Hierarchy 1 and Hierarchy 2. Item 12345 can inherit values for Attributes A and B from a higher level in Hierarchy 1, and can inherit values for Attributes C and D from a higher level in Hierarchy 2.
If the hierarchies in the above example were two separate locations, the following use case would follow.
When a user moves a store (Store 1) from one market (Market A) to another market (Market B), the system behavior should be the following:
- If an item-store attribute value was inherited from Market A without override, the item-store attribute value should be inherited from Market B without override.
- Example - Assume that the Price for Item 12345 for the stores in Market A was $10 and the Price for the stores in Market B is $20. If a user moves Store 1 from Market A to Market B, the price without override for Item 12345 would change automatically from $10 to $20.
- If an item-store attribute value was inherited from Market A with override, the system should preserve the override upon the move of the store to Market B.
- Example – The Price for Item 12345 for the stores in Market A was $10. A user overrode the Price for Item 12345 for Store 1 within Market A to $12. If a user moves Store 1 from Market A to Market B, the Price for Item 12345 should remain $12.
After a user moves a store from one market (Market A) to another market (Market B), there may be items that were sold in Market A that are not sold in Market B. A user will need to manually remove the items from Market B.
Behavior on Multi-occurrence
If users have occurrences inherited from the parent, users cannot override one occurrence and at the same time retain the rest of the inherited occurrences. If the user chooses to override one occurrence, users will lose all inherited occurrences; therefore, the user will need to start creating a new occurrence from 0 instance again.
Behavior on Rich Search
When users run rich search on an item, the item-location result set created from search results is displayed on the Location Data screen. For example: item01 has an item location data at level BYO1. When users run rich search on item where item id equal to item01 and Location Hierarchy level equal to BYO1, the search will return item01 with BYO1 as its item-location result set. Users can identify the item-location result set, in this case BYO1, by clicking the Location Data button on the item and click on ‘Show Context Locations’ and select ‘Search’ as Context; only then, users will see BYO1 as a shortcut link to the location data.
Item-Location Attribute Handling
User Interface
- A single attribute can be marked with a null value. A child of a parent having a null value would inherit a null value from the parent.
- All attributes for an item-location can be marked with a null value. This applies to all current and future attributes for an item-location. Marking with a null value does not suggest that the item is not available for a location. To make the item unavailable, it is necessary to make the location unavailable.
- All attributes in a multi-occurrence group can be marked with a null value.
Invoke the Location Data Screen from the Single-Edit screen
- Clicking the ‘Location Data" button on the Single Edit screen displays the Location Data window in the additional frames to the right of the Left Pane
- The Location data screen cannot be displayed unless the item is valid and saved
Location Data Screen
The Location Data screen is displayed in a separate window in a similar format as the main screen.
Figure 5.5 - Location Data Screen
#1 Left Pane of the main screen
#2 Location hierarchy
Location hierarchy is defined like any other hierarchy. The Location hierarchy associated to the catalog in #1 is displayed in this frame. Use the Show On-Demand Filter to select any of the location hierarchies associated with a catalog. An icon with a picture of a plain folder indicates that for the selected location, there is no location specific data. An icon with a paper in front of the folder indicates that the selected location has an override data. Even though a location has inherited data, the location icon is displayed with a plain folder.
Locations can be made available or unavailable by right clicking on the location hierarchy to display the short menu. The following selections are available.
- Make Available - Makes the selection location available for the selected item
- Make Available Recursive - Makes the currently selected location and all its children available for the selected item
- Make Unavailable - Makes the selected location unavailable for the selected item
- Make Unavailable Recursive - Makes the selected location and all of its children unavailable for the selected item
#3 Attribute list frame
All location specific attributes defined in the location data view are listed in this frame. This frame provides a way to quickly view all the available location attributes.
#4 Location attribute data edit frame
Unlike the Single Edit screen, the data displayed in this frame is displayed flatly and not in a nested fashion. Required attributes are displayed with a '*' to the left of the data entry field.
#5 Error validation frame
All validation errors are displayed in this frame. All attributes that fail the type validation are shown in red color. Examples of such errors include Min/Max enforcement and Required attributes not being provided. The validation error frame displays the location of validation errors by hyperlinks. Double-clicking on the error messages will focus the cursor on the attribute with the selected error. The location data cannot be saved unless all validation errors are cleared.
Modeling location specific data
Currently, a secondary spec is used to model the item location hierarchy spec. The item location hierarchy spec is limited to the purpose for item-location data and is not available for any other purpose. A location hierarchy can only have one item location spec attached to it, therefore all locations in a location hierarchy shares identical item-location attributes and requires item location attributes are not different for each location.
Associating a location hierarchy with a catalog
Similar to product hierarchies, location hierarchies can be associated with a catalog. Multiple location hierarchies can be mapped as secondary hierarchies of a catalog and only category hierarchies are used for location attributes, not organization hierarchies.
Figure 5.6 - Associated location hierarchy
Assigning a Location Hierarchy to a Catalog
To associate a location hierarchy to a catalog, click Define Location Specific Attributes from the Catalog Attributes screen. Using the Wizard, select the hierarchy that is going to be used as a location hierarchy and choose the appropriate values for the other wizard selections. Only Category Hierarchies that are associated with the catalog are displayed in the drop-down. Multiple hierarchies can be selected as location hierarchies for a given catalog.
Figure 5.7 - Define location specific attributes
Back at the Catalog Attributes screen, the Location Specific Attributes table now includes the newly associated location hierarchy.
Figure 5.8 - View associated location specific attributes
Known limitation: It is not possible to modify an existing location hierarchy with a new spec. It is required to delete it and then add it with the new location spec.
Saving Item Location data
When users click the Save button of the Location Data screen, not only the item-location data is saved, but also the entire item. This applies when users click the save button on the main screen, all the item-location data of the item is also saved.
NOTE: When adding an item, the item must be saved before adding location attribute. Until it is saved, the attribute cannot be populated.
Inheritance
The following inheritance behavior applies to location hierarchies:
- Only attribute collections selected within a location hierarchy for attribute inheritance will inherit the data from their parent.
- Capabilities are provided to Override the inherited data or cancel the inheritance by marking a field as NULL field. Note: Null is treated as a valid value for an attribute field in this release.
WebSphere Product Center provides the ability to create customized help text with the option to make it context sensitive. The help feature is defined at the catalog spec level, which identifies the link to the customized help file. Thus, a separate location can be used to store and maintain all customized help files and WebSphere Product Center is linked to the file location.
- Help files open in a standard separate window and remains open until the user closes it
- Only one modeless window is opened for customized help files, when a new file is accessed the old page is replaced with the new content
Creating help text
1. From the Specs Console, select a primary spec and click on the node that will have a help text defined. This includes localized nodes, which allows the definition to localized help files.
2. Select Help URL from the drop-down field and click the Plus icon.
3. Enter the custom help file location in the Help URL field.
Figure 5. 9 – Access context sensitive help
4. Click Save to store the changes made to the spec.
5. When a user adds or edits items in the catalog, the help icon is displayed next to the nodes that have been defined with a Help URL (Single Edit Screen only). To access the help file, click the button next to the node name in the Single Edit screen, and select "Help about attributes".
Create Context Sensitive Help
By default, customized help files are accessed when accessing a node from the Single Edit screen. If it is desired for the help file to activate when the field is accessed in the Single Edit screen, update the user defined settings. Set the following option:.
- From Home > My Settings, on the Specific Screen Settings table, select "Yes" for "Always display help text.
Catalog Views allow users to personalize which item attributes are editable, read only, or not visible. Views are created for the following purposes:
- Create a more efficient or task-specific view of items when working in a catalog
- Often used to create groups of attributes related to a specific data entry or data maintenance process (i.e. promotion related attributes)
- Created multiple views to be used with each catalog
- Create views shared by all users
- Catalog privileges to determine which attributes a user can choose from to create a view
Catalog views can also be configured to customize the way a catalog is displayed in the Left Pane, Item Lists, or Content Authoring Screens. Views can be configured in the following manners:
- Hide a specific item attribute
- Re-order how attributes are displayed on the screen
- Restrict modification of certain attributes
Views and core attributes
Views are defined by attribute collections that include the following types of collections:
Generated Default core attributes System defined attributes that are retrieved and saved for every object and include only the attributes that are created to making sure an item is not saved to the database in violation of key rules, which include:
- Primary key
- Path attribute (for categories only)
- Any required attributes (either from a primary or secondary spec)
User defined core attributes Attributes that are required to be retrieved and saved for every object. These include attributes that need to be validated or calculated every time an item or category is saved. Views work with core attributes in the following manner:
The benefit is improved user response time and reduced server loads due to focused data retrieval and processing
- Only attributes in the current view are retrieved and saved
- Core attributes (default or user defined) are always retrieved and saved, even if they are not in the view
- System view is modified to display only core attributes
- The benefit is improved user response time and reduced server loads due to focused data retrieval and processing
System Default Views
Each hierarchy is defined with a default view; this view includes all attributes applicable to the hierarchy. The view can be a combination of Default core attributes and User defined core attributes.
Fields with default values, unique fields, or sequences should be considered for the user defined core attributes or a "new item view". If a field with a default value is not in the core attributes or in the view, the field is never populated unless the field was brought up from with a different view.
View management
Views are created, deleted, and modified through the Catalog console and can be used in any are that provides a drop-down list of views.
Creating a catalog view
1. From the Catalog Console, select a catalog and click the Views button. The catalog view wizard appears. A catalog must be selected.
2. Enter a name for the new catalog view and click Next.
3. Choose an attribute from the left column and click the Add Viewable or Add Editable buttons. The selections appear in the right column. There are four view configuration areas:
- Edit Item: choose the fields that are to be made editable
- Bulk Edit: choose the fields that you can add bulk items to (Usually, all fields are chosen since this is an addition of new items to your item catalog)
- Item List: choose the fields that are to be displayed within an item list
- Item Popup: choose the fields that appear in a popup window
- Item Location: choose the fields that appear in item locations data
4. When all selections have been made, click the Save button. A message displays stating that the new view has been successfully created.
5. To use the new view, make a catalog selection from the Catalog Console and select the view from the Views column..
Deleting a catalog view
Any catalog view can be deleted, except for the System Default view. To delete a catalog view, it must first be selected from the Catalog Console.
1. Select a catalog view from the Views column and click the Edit button, the Catalog View Create/Edit page displays.
2. Click the Delete button and a confirmation dialog box appears, click OK.
Modify a catalog view
To modify an existing view:
1. Navigate to the Catalog Console
2. For the catalog for which you wish to modify a view, select the view from the Views column.
3. Click the Edit button next to the view.
Using a catalog view
A catalog view can be changed from the Catalog Console, Single Edit, or Multiple Edit screens.
To use an existing view:
1. Navigate to the Catalog Console
2. For the catalog for which you wish to view, select the view from the Views column.
3. Upon selecting the view, the view is automatically applied and will be remembered upon the next logon. Views can also be changed in the Single and Multiple Edit screens..
Tabbed Views
The customized views created for a catalog restrict the attributes that are viewable or editable and are displayed in a basic layout. WebSphere Product Center has the ability to create Tabbed Views for a catalog, which decreases the need to scroll through a catalog’s long list of attributes.
Tabbed views are created from a current Catalog View. It is possible to display the same attribute throughout multiple Tab Views, except for the Primary Key, which always appears on the top of each Tab View.
Creating a tabbed catalog view
When creating a catalog view, it is possible to create a tabbed view to manipulate further how items are displayed.
1. From the Catalog Console, select a catalog and click the Views button. A catalog must be selected.
2. Enter a name for the new catalog view and click Next.
3. Select all attribute collections that are to appear in all tab views and click Add Viewable or Add Editable. If an attribute is not selected here, it will not appear when creating a Tab View.
4. Click Save, to create the catalog view before creating a tab view.
5. Click the Tab View button to access the Tab View page and click New to create a new tab view. A list of all selected attributes from the Customized view appears in the Tab detail table.
6. Enter a name for the Tab name, which will appear on the tab label, select the attribute collections to appear in the tab and click Save.
Note: Add>> is used to add attribute collections to the Tab View.
The tab is listed in the Tab Views table. A new Tab View must be created for each tab.
Edit Tab View
To add or delete attribute collections from a Tab view, the tab view must be edited.
1. From the Catalog Console, select the Catalog view that has been customized with Tab Views and click the edit button..
2. Click on Tab View button and the Tab for Catalogs table appears.
3. Click the radio button next to the Tab View that is to be edited and click the edit button.
4. Add or remove attributes to the Tab View as needed and click Save to commit the changes.
Delete Tab View
If a catalog view is no longer needed and deleted, all associated Tab Views are deleted. To delete a single tab view, do the following:
1. From the Catalog Console, select the Catalog view that has been customized with Tab Views and click the edit button.
2. Click on Tab View button and the Tab for Catalogs table appears.
3. Click the radio button next to the Tab View that is to be deleted and click the delete button.
Reorder Tab View
The order of the Tab Views can be rearranged
1. From the Catalog Console, select the Catalog view that has been customized with Tab Views and click the edit button.
2. Click on Tab View and the Tab for Catalogs table appears.
3. Click the radio button next to the Tab View that is to be reordered and click the up or down buttons.
WebSphere Product Center’s Linking feature is only available to Catalog specs. In order to create a catalog with information from two or more other catalogs, create a child catalog that has a link to one or more other catalogs.
By linking one catalog (the "source" or "master" catalog) to a second catalog (the "destination" or "child" catalog), items within the destination catalog can be supplemented by the attributes of respective linked items in the source catalog.
- Allows shared attribute values to be maintained in one source/master catalog
- The "source Attribute Name" is the attribute in the child catalog that references the key in the master catalog
- The "Destination Attribute" is the name of the key in the master catalog
Purpose and Pre-Requisites of Linking Catalogs
Purpose of linking catalogs:
- To create a relationship between items in the "master" catalog with items in the "child" catalog
- Inherit Attributes from a child catalog for syndication
Pre-requisites
- Have a linked attribute in the "master" catalog
- Have a "child" catalog
Example 1:
- The master catalog can be an item catalog
- The child catalog can be a customer catalog
- The catalogs are linked via the attribute "customer id"
- Prices can then be recorded by a specific customer in the customer catalog and linked to the master catalog
Example 2:
Multiple customer catalogs share the same description and list price, however, the customer price is different for each
- Create a single master catalog to maintain the master item number, description, and list price
- Create a child catalog for each customer which maintains only the customer price
- Link these customer-specific child catalogs to the master catalog
Example 3:
Linking catalogs "normalizes" the product information
- Placing the data in multiple catalogs enable WebSphere Product Center to present, access, and update the items and attributes much more rapidly
Design Catalog Architecture
When designing the architecture of linked catalogs, decide where the information for a catalog is going to be retrieved.
- One item in two catalogs (merging the attributes for one item)
- Merged list of items
There are two ways to link catalogs, which provide different types of relationships to one another.
- 1 - Link multiple child catalogs to a parent/master catalog. This is useful in the case of having multiple catalogs for various marketplaces and pulling all the items into the master catalog.
- 2 - Create a catalog from two or more catalogs, a child catalog must be created with a link to one or more catalogs
Note: The important thing to note is that an attribute in a child catalog can have at most one link. Therefore, to link two catalogs to one catalog there must be a link in each of the child catalogs.
Case 1
Both links in the child catalog should be selected (probably with the same SKU). They syndication script used will determine how the data is handled.
Case 2
In this case, only one of the two catalogs would be linked. When the catalogs are exported, the import script defines the data output. In the following figure, the Child catalog is linked to the Master Catalog.
Steps to link catalogs
There are several steps to take when creating a link between catalogs:
- Select the source attribute
- Select the catalog to link to
- Select the destination attribute
- Create a link between catalogs
Select the source attribute
The source attribute is the attribute from the sub-catalog that is mapped to the "master" catalog. If there is only one attribute of type link, this is the only attribute that is available in the drop-down. If no attributes of type link exist, no drop-down field is available.
Select the catalog to link to
In the list of catalogs, select which catalog the attribute links. It is possible to select from any of the existing catalogs in the system, except the catalog that a link is currently being created for.
Select the destination attribute
When selecting a catalog, the field of the destination attribute shows, by default, the primary key for the master catalog. This is the field used to link to the sub catalog. To create a link from an item in the sub catalog to an item in a master catalog, enter a value in the source attribute of the item in the sub catalog that corresponds to the primary key of an item in the master catalog.
Create a link between catalogs
The following steps provide an example of linking a catalog for the following use case:
Multiple customer catalogs share the same description and list price, however, the customer price is different for each.
1. Create a single master catalog to maintain the master item number, description and list price
2. Create a child catalog for each customer that maintains only the customer price
3. View the catalog attributes for the Catalog that contains the source attribute
4. From Category Detail screen, select the Source Attributes Name, Product Catalog, and the Destination Attributes Name (all defining the link to the other catalog).
5. Click on "Add" to Add the New Link
To facilitate the loading of print catalogs (or any catalog) from another catalog, use Catalog-to-Catalog Exports. A Catalog-to-Catalog Export loads the categorization and items from one catalog into another catalog.
Setting up a catalog to catalog export
Use the menu path: Product Manager > Catalogs > Catalog-to-Catalog Export > New Catalog to Catalog Export. The Catalog-to-Catalog Export wizard appears. Complete each wizard step.
1. Select Catalog Source: Select the source catalog used for the export
2. Select the group of items to export: the entire catalog or a saved selection
3. Select the Catalog-to-Catalog Export Type: either all items in a version, the differences between two versions, or the differences since the last version
4. Select the Catalog destination: If no catalog destination has been created, one must be created before going to the next step.
5. Select Catalog to Catalog mapping: Map the fields in the source catalog to the fields in the destination catalog
6. Select the Catalog-to-Catalog Export Script: which includes an auto-generated script by default
7. Select approving authority: Optional - Select the approving authority for the export
9. Select the Catalog Export name - Enter a name for the catalog export
After all steps of the catalog to catalog export has been completed, run the Catalog-to-Catalog Export from the Export Console. The export is sent to the scheduler like any other export job.