Ch 5 Advanced Topics for Catalogs

This chapter covers advanced topics for creating catalogs and managing content within catalogs.


Search engine

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. 

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:

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.

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 attribute data modeling

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:

  • 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.

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

Invoke the Location Data Screen from the Single-Edit screen

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.

#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:


Customized Help Text (Context sensitive)

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.

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:.


Views

Catalog Views allow users to personalize which item attributes are editable, read only, or not visible. Views are created for the following purposes:

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:

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

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:

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.


Linking Catalogs

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.

Purpose and Pre-Requisites of Linking Catalogs

Purpose of linking catalogs:

Pre-requisites

Example 1:

Example 2:

Multiple customer catalogs share the same description and list price, however, the customer price is different for each

Example 3:

Linking catalogs "normalizes" the product information

Design Catalog Architecture

When designing the architecture of linked catalogs, decide where the information for a catalog is going to be retrieved.

There are two ways to link catalogs, which provide different types of relationships to one another.

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

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


Catalog to Catalog Exports

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.