The Product Manager module, designed for business users, reduces the complexity in managing content from multiple sources and audiences. It allows users the ability to provide customer-focused content.
The Product Manager offers the following features:
- Catalog creation and management
- Category Hierarchy/Taxonomy and management
- Lookup Table creation and management
- Importing and exporting of data to the catalogs
- Item selections
Part II section covers each of the components and sub-components that are available within the Product Manager module.
Product Manager Component Description Catalog The catalog console is where most of the data management activities start Hierarchies Update hierarchies (category and organization) Selections Selections are subsets of catalogs which can be used for edit, updates and exports Reports Custom Reports can be written according to specific business requirements on data statistics, audit trail, etc. Lookup Tables Lookup tables are used to store data that items, categories, validation rules and other business rules
Catalogs are repositories or containers for items with the following characteristics:
- Catalogs are defined by several components that are required to build a catalog (Name, Primary spec, Primary category hierarchy, (ACG)Access control group)
- Additional optional attributes can be specified for any catalog (Secondary category hierarchy, Linked catalogs, catalogs scripts (pre and post processing)
- Catalogs can be linked, allows attributes to be managed for a single item across multiple catalogs
- Catalog views can be customized to personalized how item attributes are presented to a user
The Catalog Console is where all the centralized product information is managed and manipulated before it is exported to a defined destination.
Through the Catalog Console, the following tasks can be performed:
- Browse and modify a catalog
- View items within a category
- View and modify catalog’s associated specs
- Edit the contents of a catalog using the Single or Multiple edit screens
- View catalog attributes
- View catalog differences
- Rollback a catalog version
- Search a catalog’s content
- Delete a catalog
- Customize catalog views
The Catalog Console displays all of the current catalogs that have been created. The console view can be customized to show specific catalog attributes, if desired. The default view shows the catalog name, catalog spec, primary/secondary hierarchies, access control group, and the catalog view that is curretnly applied to the catalog.
Customizing the console view
The console can be customized to sort or hide columns. The settings are saved to the user’s profile. To customize the view of the Catalog Console, do the following.
1. In the top right corner of the Catalog console, click the configure button
. The Configure table appears in a popup window.
2. To sort a column, make a selection in the Sort Column. Only one selection can be made.
3. To hide a field, make a selection in the Hide column. Multiple selections can be made.
4. In the "Other Options" table, set the sorting order to display in ascending or descending order and set the number of rows to display per page.
5. To save the customized settings, click Save. The Catalog Console appears with the new customized settings.
Catalog console columns
Name
The name of the catalog.
Spec
The name of the catalog spec used to build the catalog. When clicked, the specification can be viewed an edited.
Primary Hierarchy
The name of the hierarchy used to organize the catalog items. When clicked, the hierarchy details screen appears.
Secondary Hierarchies
The name of the secondary hierarchy used to create sub-categories. When clicked, the hierarchy details can be viewed.
Access Control Group (ACG)
The Access Control Group used to control the access levels for each role.
Views
The catalog view that is applied to the catalog. New catalogs are set to use the system default. The edit icon allows the user to edit the customized view; the system default view cannot be edited.
Catalog console toolbar
The Catalog console toolbar contains buttons that are used to manage the catalogs in the console.
Fig 3.1 - Catalog console buttons.
NEW Create a new catalog
ATTRIBS. Edit/modify the attributes of a catalog. Create different versions of a catalog, view a different version of a catalog, rename the version of a catalog, create a new hierarchy, add a second hierarchy to a catalog, review the summary statistic of a particular catalog
DIFFS. Provides the ability for the user to run a comparison between two different versions of a catalog
ROLLBACK Provides the ability for the user to rollback a catalog
RICH SEARCH Provides the ability for the user to run a more comprehensive search within a catalog and view the results in an item list table
DELETE Delete a catalog
VIEWS Create different views of a catalog
IMPORT Select a catalog and click the Import button. All imports associated to the catalog appears
EXPORT Select a catalog and click the Export button. All exports associated to the catalog appears
The Catalogs component of the Product Manager is used to design, structure, and maintain product information within catalogs. This section assumes that all components required to create a catalog have been completed. Refer to the appropriate sections in this user’s guide for information on creating the following catalog components:
- Primary/secondary specs
- Access Control Groups (optional)
- Hierarchies (optional)
New Catalog
Catalogs can be designed and structured to meet the requirements of business units. Once a data model has been built, catalogs can be created to maintain product information within catalogs.
This section assumes that all components required to create a catalog have been completed. Refer to the appropriate sections in this user’s guide for information on creating the following catalog components:
- Primary/secondary specs
- Access Control Groups (optional)
- Hierarchies (optional)
Creating a new catalog
Use the menu path Product Manager > Catalogs > New Catalog or click the New icon from the Catalog Console. The Create Catalog wizard appears. Complete each step of the wizard.
1. Select Specification: Choose the specification to use for the catalog and click Select. To edit the selected spec, click the Edit button or click New to create a new spec for the catalog.
2. Select Display Attribute: Select the spec attribute that is to be displayed for the catalog.
3. Select Access Control Group: Select the ACG used for the catalog and click Select. If desired, edit or create the ACG.
4. Catalog Name: Enter a name for the catalog and click the Create Catalog button.
5. Select Hierarchy: Select a hierarchy to use for the catalog and click the Select button. Click the Edit button to edit the current selected hierarchy or click New to create a new hierarchy.
A message box appears notifying of a successful catalog creation. Click the "Catalog Console" hyperlink or the back arrow icon to return to the Catalog Console page.
Delete catalogs
The Delete function allows a user to "clean things up" by deleting old or useless catalogs. It is important to note that once a catalog is deleted, there is no way to recover it. The catalog cannot be used or otherwise be viewed again.
When deleting a catalog, there are two confirmation dialog boxes that occur which makes it hard to delete a catalog by accident. When a catalog is confirmed for deletion, it is placed in the scheduler for completion.
Deleting a catalog
1. From the Catalog Console, select a catalog to delete by clicking the radio button next to the name of the catalog.
2. From the toolbar, click Delete. A dialog box appears confirming the operation. Click OK to delete the catalog or Cancel to quit the operation.
3. If OK was clicked, the "Choose a Catalog to Delete" wizard appears with a warning message notifying the user that the operation is not reversible. Click the Delete button to complete the deletion of the catalog.
4. Another dialog box appears to confirm the deletion of the catalog, Click OK to complete the catalog deletion.
5. A message appears notifying the user that the catalog deletion has been scheduled. Click the timer icon to view the schedule status.
Catalog Versioning
A version is automatically created when changes have been made to a catalog, whether it is an update import, change of catalog attributes, manual changes to items, etc. All catalog versions appear in the Version Summary table of the Catalog Attributes screen.
Figure 3. 2 - Version summary table
Creating a catalog version
To manually create a tagged version of a catalog, which timestamps the catalog version, go to the Catalog Details screen:
- Left Pane - Right-click in the Left Pane and select Attributes from the short menu
- Catalog Console - select a catalog and click Attib.
Enter a name in the "Add a version with a name" field and click +ADD. The new catalog version is saved to the "Version Summary" table.
Rename a catalog version
To rename a catalog version, select a catalog version from the Version Summary table, edit the version name, and click the Rename Version button from the toolbar.
View specific catalog version
Add a catalog in the Left Pane, click "Show On- Demand Filter". Select a catalog version to view and the catalog is populated with the catalog version data.
Note: The selection from the Version drop-down field matches that of the Version Summary table.
Figure 3. 3 - Change catalog version
Catalog differences
The Catalog Differences function allows the analysis between two catalog versions. Choose to view details on various difference types (added, modified, deleted, unchanged, or all).
From the Catalog Console, select a catalog and click the Diffs. button. The "Catalog Differences" wizard appears. Complete each step of the wizrd.
1. Select Catalog: Automatically filled with the name of the catalog selection from the Catalog Console.
2. Select Version one: Select the first catalog version.
3. Select Version two: Select a second catalog version
4. Select difference type: Click the Question Mark icon and select a difference type, then click Save to close the window, then click Select to apply the difference type to perform.
5. A Difference Summary table appears. Click on the View button to display the Item List details.
Figure 3. 4 - Differences Summary
Catalog rollback
A catalog "Rollback" enables a user to change the version of a catalog that is currently being used to a different catalog version, which may contain modified items. This is especially useful if changes that were made to a catalog were later determined to be unnecessary or otherwise done by accident.
After clicking on the Rollback button, the user must select the version of the catalog that he or she would like to roll back to. A catalog is versioned just before and just after data is moved into (during an import) and out of (during an export) WebSphere Product Center.
By default, each version is given a name in terms of two properties: A. the operation that was performed on it and B. the date and time that the operation was performed.
USE WITH CAUTION!!! This operation is not reversible.
Note: Specs are not reverted during a catalog rollback so items will be displayed according to the latest specs. Attributes for spec nodes that have been deleted will not be shown although they existed in the rollback version.
Performing a catalog rollback
To rollback to a different catalog version, do the following:
1. From the Catalog Console, click on the radio button next to the catalog name and click the Rollback button.
2. Select a catalog version from the drop down selection and click the SELECT button. A message appears to remind you that the action is not reversible, proceed by clicking on the Rollback catalog button and then OK in the popup dialog box to confirm the action.
Fig 3.5 - Select catalog to rollback
3. The rollback is scheduled; click the status icon to view the status.
Note: When a rollback is completed, all catalog versions that occurred after the selected version is cleared from the Versions Table.
The attributes of a catalog can be viewed/modified through the Catalog Detail screen. There two methods to view a catalog’s attributes.
- From the Catalog Console, select a catalog and click the Attrib button
- From the Left Pane, display a catalog and right-click next to the catalog name. Select "Catalog Attributes" from the short menu.
CATALOG ATTRIBUTES
Name
Name of the catalog
Spec Name of associated catalog spec Primary Hierarchy
The primary hierarchy being used
Add Secondary hierarchy
Click the +ADD button to include a secondary hierarchy
Use Ordering Check to apply ordering to the catalog. Add a version with the name
Customize the name of a catalog version
Catalog display attribute Select an attribute to display in the Left Pane User Defined Core Attribute Collection Select the associated user defined core attribute collection for the catalog Entry Build Script
Build a script that runs after data retrieval for items/categories
Pre-processing Script
Build a script that manipulates the data before it is imported into a catalog
Post-processing Script
Build a script that manipulates the data after it is imported into a catalog
Post-save Script
Build a script that runs after an item is saved
Link Attributes
Displays nodes that have been linked to other catalogs
Version Summary
Displays all of the versions for the catalog
Scripts are created to validate and cleanse data before it is imported or exported. The catalog attributes allow for the selection of various script types to be processed at different stages (before import, after being saved, before export). The specs that are used for a catalog allow further manipulation to data such as applying validation or value rules. The combination of defining catalog attribute scripts and spec attributes allows for flexibility when manipulating data.
Although there are various types of scripts and rules that can be used to process data not every type needs to be defined and each type is performed in the specified order listed below:
- Entry Build script
- Pre-processing script
- Validation and Value rules
- Post-processing script
- Post-save script
Multiple hierarchies can be associated to a single catalog through the Catalog Details screen. The Primary Hierarchy cannot be removed.
Adding a secondary hierarchy
1. From the Catalog Console, select a catalog and click Attribs.
2. Select a hierarchy from the Add a Secondary hierarchy drop-down selection and click +ADD.
3. A message appears confirming the action.
4. If desired, add another secondary hierarchy.
5. To remove the associated Hierarchy, click the Delete button. A confirmation dialog box appears.
The function of the user-defined logs can be used to track deltas for catalogs or hierarchies. All changes are captured and viewed using the Log link in the Catalog or Hierarchy detail screen. Logs can be created for any of the available scripts that are built through the Catalog/Hierarchy Details screen.
Creating a user defined log for a catalog
1. From the Catalog Console, select a catalog and click Attribs. The details of the Catalog are displayed.
2. Click Logs and a table of user-defined logs appear. Click New to create a new user-defined log.
3. Enter a name and description for the log and check the Running Log checkbox, if desired, and click +ADD.
Note: If the Running Log box is not checked, the system captures the most recent change, whereas if the box were checked the system would capture all changes that have been made.
4. At the Catalog Details screen, select a script (i.e. Post-save script) to create and write it to a log. For more information on creating scripts, refer to WebSphere Product Center’s Scripting Documentation.
Editing user-defined log for a catalog
1. From the Catalog Console, select a catalog and click Attrib. The details of the Catalog are displayed.
2. Click Logs and a table of user-defined logs appear. Click the Edit button next to the log name that is to be edited.
3. Make any changes and click Save.
Deleting user-defined log for a catalog
1. From the Catalog Console, select a catalog and click Attrib. The details of the Catalog are displayed.
2. Click Logs and a table of user-defined logs appear.
3. Click the Delete icon next to the log name that is to be deleted.
Creating user defined log for a hierarchy
1. From the Hierarchy Console, select a hierarchy and click Attrib. The details of the tree are displayed.
2. Click Logs and a table of user-defined logs appear. Click New to create a new user-defined log.
3. Enter a name and description for the log and check the Running Log checkbox, if desired, and click +ADD.
4. At the Category Details screen, select a script (i.e. Post-save script) to create and write it to a log. For more information on creating scripts, refer to WebSphere Product Center’s Scripting Documentation.
Editing user defined log for a hierarchy
1. From the Hierarchy Console, select a hierarchy and click Attrib. The details of the tree are displayed.
2. Click Logs and a table of user-defined logs appear. Click the Delete icon next to the log name that is to be edited.
3. Make any changes and click Save.
Deleting user-defined log for a catalog
1. From the Hierarchy Console, select a hierarchy and click Attrib. The details of the tree are displayed.
2. Click Logs and a table of user-defined logs appear.
3. Click the Delete icon next to the log name that is to be deleted.
Item edits are performed using the Standalone or Advanced Content Authoring screens. From either screen type, items can be added or edited. The Advanced Content Authoring screen allows multiple items to be added/edited at one time.
Differences between Standalone and Advanced content authoring screens:
Standalone Content Authoring screen Advanced Content Authoring screen
- No Rich Search, Single Edit, or Multiple Edit Tab
- No navigation to move to next or previous record
- Rich Search, Single Edit, and Multiple Edit tabs are available
- Exit button
Setting content authoring screen type
The type of content authoring screen used is set in the "Specific Screen Settings" configuration of My Settings. Find the "For editing and entering data, use:" row and select to use one of the following
- Stand Alone Content Authoring Screens
- Advanced Content Authoring Screens
The default setting is set to "Standalone Content Authoring screen".
When several items are selected in the Left Pane, they are displayed in an item list screen. For single items, they are displayed in a single edit screen. This screen allows a user to sort the list by any column of the item list table and to easily navigate through long lists of items.
Figure 4.1 - Sample Item List screen
Sorting item list
If desired, items can be sorted in descending order by clicking on any Attribute Name column headings of the Item List table. The down arrow indicates that if clicked, the items are sorted in descending order. If the up arrow is displayed, click it to sort the item list in ascending order.
Figure 4.2 - Sort item list table
Navigating item list
For large item lists, use the navigation links at the bottom of the item list table. Select a page to view or skip to the middle or last page of the item list.
Figure 4.3 - Navigate item list
Item list buttons
Figure 4.4 - Item list toolbar buttons
The following Item list buttons are described counter clockwise starting from the top-left corner.
Add Enter a number of items to add (default is 1) then click the ADD button. In the Multiple Edit screen, the new items are added to the top of the list.
Edit Selected Edit Selected Items
Edit All Edit all items on item list
Hierarchy drop-down field Browse or select Hierarchy
Edit hierarchy Select a hierarchy from the drop-down filed and click this edit button to edit the hierarchy Re-categorize items into different hierarchy Select an item or group of items to re-categorize first then select a hierarchy from the drop-down selection. Click the re-categorize button to display a new window that allows the user to select a different hierarchy. The change is not committed until the Save button is clicked. Copy item to a different category Select an item or group of items to copy first then select a hierarchy from the drop-down selection. Click the copy button to display a new window that allows the user to select a different hierarchy. The change is not committed until the Save button is clicked
Save as Basic Selection Click this button to save the current Item List as a basic selection in the Selection Console Append Selection Append the current item list to a saved selection. Check the "Append Selection" box and select a saved selection from the drop-down field box to add the current item list to the selection Selection drop-down field Select a saved selection to append an item list to Delete Deletes all an item. Be cautious when using this button. Once an item is deleted the action cannot be undone. Select an item or group of items, and then click the delete icon.
Number of items field and the Bulk Add button Enter a number of items to add and click Bulk Add. The defined number of items to add appears in the Multiple Edit screen for data entry.
The Single Edit screen allows a user to edit a single item. This screen is displayed when a single item is selected for viewing or editing. For "Advanced Content Authoring", this screen is the Single Edit tab.
Single Edit screen buttons
There are a series of buttons, navigation tools, a status icon at the top and bottom of the Single Item screen.
Figure 4.6 - Single Edit screen buttons (top screen)
The following Single Edit screen features are described left to right.
Left icon Provides the status of the item. For example, if the item is synched with the database, or if an error has occurred Catalog Name The catalog name is displayed in this top bar Navigation buttons and Go Allows a user to navigate between pages of items. Type a page to go to and click Go. View drop-down field and Go To change a view for the item, select a view and click Go. Bring to top Allows a user to bring to the top of the order of items based on one of the following status:
- Failed
- Modified
- New
- Non-modified
- Processing
- Selected
For example, if "Failed" is selected, all of the failed items are pushed to the beginning of the item list.
Figure 4.5 - Single Edit screen buttons (bottom screen)
The following Single Edit screen buttons are described counter clockwise starting from the top-left corner.
Checkout Check out an item into a workflow Macro Run a macro against the item Action Preview item in a CSV, HTML, or Tab delimited format Logs
View user defined logs for the item
Location Data This button is disabled unless location data has been configured for the item Undo Changes Undo Change
Refresh Refresh the screen information.
Add
Add an item
Clone
Select an item to clone and Click Clone. The item information is cloned into a new item with the primary key left blank
Drop
Drop an item from the catalog
Save
Save an item
Hierarchy drop-down field By default, this field shows the current hierarchy for the item. To switch the hierarchy used, select a value from the drop-down field Hierarchy
Add or replace category mappings
Delete Delete item
The Multiple Edit screen allows a user to edit multiple items. This screen is displayed when a multiple items are selected for viewing or editing. This screen is only available through the "Advanced Content Authoring" screens in the Multiple Edit tab.
The Multiple Edit screens has many of the same features as the Single Edit screen except for the following screen feature unique to the Multiple Edit screen (see image).
Figure 4.7 - Added feature in the Multiple Edit screen
Select Page Select all items on this page only Unselect Page Unselect all items on this page only Select All Select all items in this selection/list Unselect All Unselect all items in this selection/list Resize column widths At the top of each column, there is a set of four resize options. This is used to Increase/reduce the size of the column or sort the columns ascending/descending Attribute type indicator At the top of each column is an image that indicates the attribute type Down arrow next to enter value field Enter a value for an attribute in the top row, check the items that are to take this new value, click the down arrow to set the new value for all checked entries
To edit content using either the Standalone or Advanced Content Authoring screens, simply change the information in any field and click Save to commit the changes. Errors will occur if the user does not have authorization to make edits in the specific fields or if view only fields have been applied.
Edit Items
Editing a single item
1. Select an item from the Left Pane or from an Item List. The item appears in a single edit screen.
2. Update the item information and click Save. If the item is not saved and the user attempts to leave the screen, a confirmation dialog box appears. Click "OK" to not save the item and to leave the edit screen.
Performing bulk edits
Editing multiple items can be done using the Multiple Edit Screen, which can be accessed through the Advanced Content Authoring screens. A single change can be made to multiple items, with the exception of the unique Primary Key.
If a field is grayed out and no changes can be made, the item has not yet been saved to the database, thus the information has not been updated. Once the information is saved to the database, it is made available for editing.
1. From an item list, select a group of items to edit and click Edit Selected. The group of selected items appears in a screen for edit.
2. The top row in the Item Edit screen is used to perform a single change through out multiple item with the same attribute. Enter a value in the first row of the item attribute and click the ALL icon. The item attribute is updated with the new value.
3. Click Save to save all edits.
Add Items
Users have the choice to add an item one at a time or in bulk. Similar to Bulk Edits, users can add multiple items. Adding multiple item are performed using the Multiple Edit screen. This allows the user to update a single attribute for multiple items if the value is the same.
Adding a single item
1. Use one of the following methods to add an item:
- From the Left Pane, right click on a hierarchy node and select Add Item
- From and Item List, click +ADD
2. Items are added through the Single Edit screen and are not committed to the system until clicking on Save before leaving the screen.
3. If a required field is not completed, an incorrect value was entered, or any other errors are performed, errors will display and the item is not saved.
Performing a bulk add
1. Multiple items can be added through the item list screen. Enter the number of items to add (defaulted to 20) and click +BULK ADD; the Multiple Edit screen is displayed.
2. The top row in the data entry screen is used to populate a single value to all item attributes. Enter a value in the first row of the item attribute and click the ALL icon or enter items one row at a time.
3. Once all items have been entered, click Save to add them to the catalog.
Copy Items
Items can be copied from one category to another category in the same catalog in the Left Pane. This does not move the item but creates an exact copy of the item to another category.
Items cannot be copied to the Unassigned folder.
Copy a single item
Note: If an item is copied to multiple categories and then the item is deleted from one of the categories, ALL items are deleted from all categories. Use the Remove selection from the short menu to remove an item from a single category.
1. Right-click on the item to copy and click Copy.
2. Right-click the category where the item is to be copied and click Paste.
Clone items
Cloning an item is different than copying an item as all the item attributes remain the same except for the Primary Key, which is left blank. Thus, a unique value must be entered for the primary key attribute.
Cloning a single item
Cloning a single item can only be done from the Single Edit screen.
1. From the Single Edit screen, click Clone.
2. The item attributes are cloned, except for the Primary Key attribute, which is left empty.
3. Enter a unique value for the primary key and click Save.
Cloning a bulk of items
Bulk cloning items can only be performed from the Multiple Edit screen.
1. From the Multiple Edit screen, select the items to clone and click Clone.
2. All items are cloned except for the primary key attribute.
3. Enter a unique value for the primary key attribute and edit any information. Click Save to commit changes.
Delete Items
Items can be deleted from the left pane or from the an item list. To delete multiple items, use the item list.
Deleting a single item
Note: If an item is deleted using the Delete selection from the short menu, all instances of the item in the catalog will be deleted. Use the Remove selection to remove an item from a category, not all categories in the catalog.
1. Use one of the following methods to delete a single item:
- Right click on the item in the left pane and click Delete
- Select an item from the item list and click Delete
2. When deleting items, a confirmation dialog box appears. Click OK to confirm the action.
Delete multiple items
Perform the deletion of multiple items in an Item List screen or Multiple Edit screen.
1. From the list of items, select the items to delete and click Delete.
2. A delete confirmation dialog appears, click OK.
Categorizing items
Items that are Unassigned can be categorized into their associated categories using the following steps:
1. From the Left Pane, open a catalog and view all items under "Unassigned Items".
2. To categorize a single item, click on an item and from the single edit screen, click the Hierarchy button, select a category, and click Save. The item is moved to the new category.
3. To categorize multiple items, select multiple items from the Left Pane and the items appear in an Item List. Select all items to categorize and lick the categorize button. Select a category and click Save. All the items are moved to the category.
Remove item from category
An item can be removed from a catalog using the short menu in the left pane.
1. Right-click on an item and select Remove.
2. A confirmation dialog appears confirming the item removal. Click OK.
3. The item is moved to the "Unassigned" folder unless the item has been assigned to multiple categories.
Recategorize Items
After an item is categorized, it can be changed to a different category from the Left Pane or from the Item List.
Recategorize items in the Left Pane
From the Left Pane, items can be moved from one category to another, but cannot be moved to the "Unassigned" folder. An item can only be moved to another category from the same catalog.
1. Right-click on the item to move and select Cut.
2. Right-click on the category to move to and click Paste.
3. The item is moved into the new category.
Recategorize from the Item List
1. From the Item List screen, select a single or multiple items and click on the categorize button.
2. All categories for the catalog appear in a separate window. Select a category, click Save, and items are moved to the new category.
Uncategorized Items
Uncategorized from the Left Pane
1. From the Left Pane, select an item, right click, and select "Remove" from the short menu.
2. The item is removed from the category and moved into the "Unassigned " folder, unless the item is a part of another category.
Uncategorized from the Item List
1. Select an item from the Item List and click the Categorize button.
2. From the popup window, DO NOT select any category and click Save.
3. The item is moved to the "Unassigned" folder.
Errors Saving Data
If an incorrect value is entered for a catalog attribute, an error dialog box appears describing the type of error where it has occurred. Click OK, re-enter a correct value type, and click Save.
Selections are created to return a list of items that can be used for the following purposes:
- Viewing and editing items
- Export a defined group of items to a specific destination
Users have the ability to create a basic item selection. A Basic Selection is a list of items where the primary key of the items is the criteria remembered by the selection.
The Item Selection Console is used to perform the following tasks:
- Create selections
- Delete selections
- Edit the selection criteria
- View the items in the selection
Item Selection console buttons
previews a selection edits a selection deletes a selection Basic Selection
A Basic Selection is configured with the following objects:
- Catalog
- Catalog version
- Access Control Group
- Hierarchy
Note: Limit a selection to 5000 items or less. Larger selections may hang the application, causing a user to exit and log back into the application.
Create a new basic selection
Use the path Product Manager > Selections > Selections Console. The Item Selection Console appears. Click on the New Basic Selection and complete each step of the "Catalog Selection Editor" wizard.
1. Select Catalog
2. Select Version
3. Select Access Control Group
4. Select Hierarchy
5. Enter a name for the item selection in the Enter the Selection Name field.
7. Select a whole hierarchy, a specific hierarchy, or unassigned items.
8. To recursively select all sub-hierarchies, select a hierchy from the list and then at the bottom of the screen, click "On" and the Go button. To deselect all sub-hierarhcies, click "Off" and the Go button.
9. When the selection has been configured, click the Save button. The newly created selection is listed in the Selection Console.
Previewing selections
To preview a selection, click the Preview icon from the Item Selection Console. The results are displayed in an item list table format.
Hierarchies are stored separately from catalogs within WebSphere Product Center. This allows a user to view and eventually export a catalog using a hierarchy of their choice. The Hierarchy Console allows the user to modify all of the hierarchies stored within WebSphere Product Center. The user also has the option of creating a new hierarchy from this interface.
Before a hierarchy can be created a primary spec must be created for the hierarchy, which is done from the Specs Console. The primary spec that is attached to the hierarchy should contain the following minimum attributes:
- Display Name
- Path - used by scripts to locate the category
- Primary Key - unique identifier for the category (as determined during spec creation)
There are two types of hierarchies that are used to organize information.
- Category Hierarchy - Used to categorize items for a catalog
- Organization Hierarchy - Used to create an organization of users
Creating a hierarchy
Used the following instructions to create either a category hierarchy or an organization hierarchy:
From Product Manager > Hierarchies > New Hierarchy, the Create Hierarchy wizard appears. Complete each step of the wizard.
1. Hierarchy Name: - enter a name for the hierarchy
2. Select Primary Specification: select a primary spec to use with the hierarchy
3. Select Display Attribute: select a display attribute from the drop-down selection
4. Select Path Attribute: select a path attribute from the drop-down selection
5. Select Hierarchy Type: select either "Category Hierarchy" or "Organization Hierarchy"
6. Select Access Control Group: select an ACG to use for the hierarchy
7. Once the hierarchy has been created, add it to the Left Pane and add sub-hierarchies (categories or users) as needed. Category hierarchies are listed in the left-pan drop down under "Hierarchies", and organization hierarchies are listed under "Organizations".
Managing Hierarchy Nodes
1. To edit a hierarchy, use the Left Pane to add, move, copy, delete, or view hierarchy attributes. Add a hierarchy from the Left Pane drop-down menu.
Note: Default hierarchies cannot be edited.
2. Click on a hierarchy node and view the hierarchy attributes.
3. To modify the hierarchies, right-click on a category and select an action from the short menu. If adding a category, make sure to right-click on the parent node where the new category will be added.
The short menu provides the user with five different functions to manipulate the hierarchy structure.
Add Category
Used to add a new category
Cut
Used to move an existing category to a new location within the hierarchy
Copy
Used to copy an existing category to a new location within the hierarchy without creating a new category
Paste
Move a category to a new location within the hierarchy after selecting Cut or Copy
Remove
Removed the category from use but does not delete it from the hierarchy.
Delete
Used to delete an existing category
Refresh
Used to refresh the hierarchy display
Hierarchy Rollback
Like catalogs, hierarchies have versions that can be rolled back.
- Select a hierarchy from the Hierarchy Console and click the Rollback button. Then select a version to rollback.
Hierarchy Delete
- Select a hierarchy from the Hierarchy Console and click the Delete button. An error will occur if the hierarchy is being used by another object (catalog, organization)
Hierarchy Mappings
Categories can be mapped between two hierarchies, which provide the ability to map an in-house categorization to a standard categorization without having to worry about individual item mappings.
For example, an internal tree called "Product Category" can be mapped to the standards of a "UNSPSC" tree.
When an item is created, the item can be mapped to a category in one tree. If the category is mapped to other trees, the item inherits the additional mappings.
Create hierarchy map
1. Use the menu path Product Manager > Hierarchies > Hierarchy Map > Mapping Hierarchies, the category map wizard appears.
2. Select a hierarchy to map "from" and a hierarchy to map "to".
3. A list of categories appears. Click the double arrow icon next to the category to map.
4. A separate window appears with the second hierarchy. Find the category to map (multiple categories can be selected) and click Save.
Note: A green checkmark indicates where a mapping exists.
5. Continue steps 3-4 until all categories have been mapped.
Adding a hierarchy mapping
1. Use the menu path Product Manager > Hierarhcies > Hierarchy Maps > Hierarchy Mapping Console, click the edit tool button next to the row that shows the source and destination hierarchies.
2. Browse the tree to find the category that is to be mapped.
3. Click on the double arrow icon next to the category to map. A screen pops up with the second hierarchy.
4. Find the categories to map to, select it and click Save.
Delete hierarchy mappings
- Click the delete button next to the name of the hierarchy in the Hierarchy Mapping Console
- Edit the hierarchy mapping, click on a mapped category to view the list of mapped categories. Click the delete button to delete a single mapping.
Hierarchy name search
The Category search feature is implemented in various locations within WebSphere Product Center. This section discusses performing a search for category nodes in the Left Pane.
Features
- Criteria incorporates 'like' search
- Returns the paths to all matching nodes
1. Add a hierarchy to the Left Pane.
2. Click the Show On-Demand Search in the left pane to display the search criteria.
3. Define a criterion for the search, enter a string and select to search on the Display Name or Name. Click the green arrow button. The results are displayed in the Left Pane.
Note: Users can use a wildcard " * " when entering a string search. If a wildcard is not added as part of the search string, the system will look for an EXACT match.
WebSphere Product Center’s analysis module leverages the application’s powerful scripting engine to enable users to create and run custom reports. The report scripts are used to define how the information is ordered and formatted. Users can utilize these sophisticated reporting tools to analyze online sales activity along multiple dimensions: by customer, product/SKU, region, destination, etc.
A report structure for analyzing and reporting progress and results can easily be created once and then many instances of it can be run against different catalogs. The results might be delivered to a location of choice: by email, ftp, post, or XML connect. Copies of the outgoing reports are of course always stored in Document Store as well.
A user might analyze how catalogs are being processed, for example, by creating a report that summarizes all categorized items in all published versions of a particular catalog.
Report Console
The Report Console is the command center for creating, viewing, and editing reports, as well as scheduling them for delivery to user specified destinations. The console table lists the existing instances of reports in alphabetical order.
Name
User specified name for the instance of the report. A single report type might have multiple instances if it includes input parameters.
Type
User-defined script that generates the report is what defines its type. The user names the type during the report creation flow and then defines the report in the WebSphere Product Center script editor. All instances of this report type will now use the defined script as the template for generation.
Schedule
The Schedule icon takes the user to the Schedule Status Information screen where details on the report generated by clicking "Go" may be viewed in summary.
Action
The "Go" button schedules the report instances to be generated and distributed. The "preview" link simply generates the report in a new window for immediate preview.
Delivery Location
The delivery location tells the user what the chosen mode of distribution for the report, during the creation of the report instance, and links to the distribution flow where the details of that distribution may be modified.
Creating a report
Use the menu path: Product Manager > Reports > Reports Console. The Reports Console appears. Click the NEW icon and the Create/Edit Report wizard appears. Complete each step of the wizard.
1. Select Report Type: Choose a report type from the drop-down menu and click Select. In this step it is possible to create or edit a report type.
2. Report Name: Enter a name for the report and click Next.
3. Select Distribution: Choose a distribution type from the drop-down menu and click Select. In this step it is possible to create or edit a distribution type.
4. A message box indicates that the report was successfully created. Return to the Reports Console to view the newly created report.
Preview Report
From the Report Console, click the preview button under the Action column to generate an on-screen display of the report. This enables the user or administrator who creates it to view the report for accuracy before scheduling its distribution.
1. Find the report to preview from the Reports Console.
2. From the Action column, click the preview button.
3. A new window appears with the report details. If desired, send the report to a printer.
Generate Report
The "Go" button performs the action of generating and delivering the report. To manually generate a report, use the following steps:
1. Find the report to generate from the Reports Console.
2. From the Action column, click the Go icon to generate and distribute the report to its defined destination mode.
View Report Status
To view the status information of a report, do the following:
1. Find the report from the Reports Console.
2. From the Schedule column click the status button. Status information is displayed in the Schedule Status Information interface.
3. Click the Job Details button for more information regarding the generated report.
4. Click the Refresh button, to update the status information.
Delete Report
To delete a report, use the following steps:
1. From the Reports Console, find the report that is to be deleted.
2. From left side of the report name, click the delete button.
3. A dialog box appears confirming the deletion of the report. Click OK to delete the report or Cancel to quit the delete operation.
Lookup tables are provided to enhance the content management functionality available in WebSphere Product Center. They are used to perform search and replace functions within a catalog, and can also be used to validate data contained in specific catalog fields. Create standard tables, i.e. units of measure (UOM), currencies, or countries. Create custom replacements tables, i.e. BK = Black and BL = Blue.
The creation and management of lookup table records is very similar to standard item creation and management. The set of tools available to manage lookup tables, like available for catalogs, include Bulk operations (add,edit) and the Search tool.
Creating Lookup Tables
To manually create a lookup table:
- First, create a lookup table spec
- Use the menu path Product Manager > Lookup Table > Lookup Tables, the Lookup Table console appears.
- Click New, the Create Lookup Table wizard appears. complete each step of the wizard.
1. Select Type: Select "Single String Key".
2. Select spec: Choose a lookup table spec to use. In this step, it is possible to create or edit a lookup table spec.
3. Lookup Table: Enter a name for the lookup table.
4. From the Lookup Table console, click the preview button to view the newly created lookup table. Since it is a new table, no items are found.
5. Click the add or bulk add buttons to enter values for the lookup table.
Deleting items from lookup table
1. From the lookup table, select the items to delete by clicking on the box next to the item name.
2. Click delete button and the item is removed from the lookup table.
Search lookup tables
1. From the Lookup Table Console, select a lookup table and click SEARCH. The Search screen appears.
2. Enter a criterion in the Search Criteria table and click SEARCH. The results are displayed in the same screen.
This chapter covers advanced topics for creating catalogs and managing content within catalogs.
The development of inheritance functionality within WebSphere Product Center’s product reduces the need to duplicate item information for similar items. Thus, a single item is able to obtain an attribute value from a separate category or from another item. Another advantage of implementing inheritance within a catalog is that the integrity of information is increased. There is no need to create similar attribute value throughout multiple catalogs, thus causing an opportunity for user error.
The concept of inheritance within WebSphere Product Center provides a natural classification for attributes and allows for the commonality of attributes to be explicitly taken advantage of in modeling and constructing product information. A catalog can be structure so that a single value can be shared throughout multiple catalogs or all instances of an attribute value can be pulled into one catalog.
Inheritance is a relationship between categories, items, and items to categories. One object is the parent (base/super class/ancestor/etc.) class of another. The use of inheritance provides an extension to product information, as opposed to reinvention. Although the natural state of inheritance allows an object to have the same behavior as another object, the ability to extend or tailor that behavior to provide special action for specific needs is provided through override controls.
Use the following application as an example. Both categories Televisions and Audio Components have similar attributes such as managing a name, a type, and a description. Rather than define the attributes in both of these categories separately, the shared attributes are placed under a new parent category called Home Audio and Video. Both Audio Components and Televisions become a subcategory of the Home Audio and Video category, and both inherit similar Home Audio and Video category attributes.
Both Audio Components and Televisions categories can add additional attributes that are unique to them. For example, Audio components can have information related to CD players or Receivers. On the other hand, the Televisions category might want to keep track of whether the television is Digital, Projection, Combo, or Handheld.
Managing product information using inheritance provides an extension of information that would otherwise be cumbersome to create. Here is another example. A catalog has a parent category "Pentium 4 - 2GHz" and the child categories are organized by model number. Using inheritance, all items in each "Model" category use the following values:
Complete sys - Pentium® 4 2.0GHz CD COA Win98, 2000Mhz, ATX tower/400w, 1 yr warranty, (upgradeable)
To change this value for a particular model category, the governing inheritance rule can be overridden and the description can be change to read "Win2K" instead of "Win98".
Complete sys - Pentium® 4 2.0GHz CD COA Win2K, 2000Mhz, ATX tower/400w, 1 yr warranty, (upgradeable)
Defining Inheritance Rules
Inheritance rules are defined to direct which path an attribute uses to obtain its value. Once the path of ordered targets is defined, the inheritance rule must also specify whether to accumulate all data found in the path or to choose the data with the highest precedence, which by default is the first value found.
When defining targets, they must either be a Hierarchy or a Catalog, which has data for the given Attribute. The choice of target determines the type of inheritance relationship being applied. For example, if an item obtains its value from a target category, the Item to Category inheritance type is applied.
If a change is made in the Inheritance Rule of the target, all objects referring to it will automatically reflect the change. Thus, the inherited values will reflect the change in the rule itself. This dynamic inheritance allows the ability to change parent category attributes, which automatically updates all child items or categories.
The following example is an example of an Inheritance rule. Three targets have been defined and the use of dynamic inheritance is applied. If a rule change is made to the first target, all objects referring to it will append those changes.
Sub-specs
Sub-specs are used to support inheritance. Created in the spec console, Sub-specs are only used when assigned to a master spec (catalog specs, hierarchy specs and secondary specs). Sub-spec attributes are different from other specs in that they are not unique, do not have a link, and can only be made a primary key when they are used by a catalog spec.
This section describes the different concepts related to inheritance. It is important to understand these concepts as they are applied to the implementation of inheritance within WebSphere Product Center.
Sharable Attributes
Attributes must be shared so that the same attribute can exist in different catalogs and hierarchies. The shared attribute is a requirement for inheritance, as a source attribute has to know which target attribute in a separate catalog or hierarchy to inherit values from.
Sharable attributes allow the ancestral inheritance from category attributes to item attributes and like node inheritance between item attributes in separate catalogs.
In order for an attribute to be shared, a Sub Spec is created to define all shared attributes, which are then and appended to a non-shared spec. When creating a new Catalog Spec, the option to add shared or non-shared nodes is available.
Like Node Inheritance
The concept of "Like Node Inheritance" is the dynamic inheritance of an attribute value from the same type attribute of an item with a like inheritance key (see next section) in a separate catalog. The like node works as an inheritance key for like node inheritance jumps. The receipt of inherited values for like attributes is based on a key attribute value of the item in another catalog.
Like Node Inheritance Key
A requirement for implementing inheritance between objects is the like node inheritance key. Two catalogs contain "like" nodes that is used to identify "like" items in different Catalogs. There must be a like node that is identified as the inheritance key in both hierarchies. This allows a category to jump between catalogs with like node inheritance.
Ancestral Inheritance
(No longer supported in 5.2 and subsequent releases)
Ancestral Inheritance is the dynamic inheritance of an attribute value from the same attribute of a category node with which an item is associated. Category nodes inherit an attribute value from the same attribute in the parent category nodes.
Inheritance Path Definition
An Inheritance Rule defines where catalogs and hierarchies look for inheritable values; this target is defined by specifying the Inheritance Path. If no values are found, is null, then no information is used.
Extend Inheritance Path Based Upon Item Attribute Values
Individual items may have different inheritance paths; therefore the path to be followed is based upon an attribute value of an item.
Multiple Inheritances
Multiple Inheritances occur when an item or category inherits from more than one item or category. For example, a CD_ROM can inherit values from the "Internal components" category as well as "External components", or a 20 GB hard drive from the categories "EIDE" or "SCSI".
Dynamic Inheritance
Dynamic inheritance allows objects to change and evolve over time. If a new category is added under a parent category structure, the path of inheritance can change as well. Since a parent category would hold attributes for child categories, changing a parent attribute changes the attributes of the child categories. More specifically, dynamic inheritance refers to the ability to add, delete, or change parent category attributes which automatically/dynamically updates all child items or categories.
Overriding Inheritance
The previous sections detail how inheritance can be used to communalize a group of information, which can be updated from a single source. In the event that an attribute does not follow the inheritance rule that governs it, the ability to override inheritance is allowed.
Inheritance provides the ability to inherit values based on a user-defined hierarchy, referred to as "inheritance rules". The data is not only being passed through; it might need to be overwritten as well. On every object that inherits values, it is be possible to tell where the data is coming from, whether it is being inherited, or if it has been overwritten.
For example, the Televisions category has an attribute called "Description" which uses the following value:
More to adore
From personal TVs for a bedroom or kitchen to bay-window-size HDTV-ready showpieces for your state-of-the-art home theater; it is all here. If you really love TV, you've come to the right place.Digital TVs is a subcategory of Televisions and uses the above value. The inheritance rule that governs Digital TVs can be overridden and have the following value assigned:
Get the ultimate experience from one of our next-generation digital sets
- Enjoy the biggest change to TVs since color
- The lifelike picture will amaze your eyes
- Digital sound will astound your ears
The following characteristics apply to overriding inherited values:
- If a value is edited upstream from attributes that inherit the value, the inherited values appear updated instantaneously
- The overwritten value is not be modified if an upstream value is modified
- If inherited data exists, users can view where the data is inherited from (catalog name, or hierarchy name) using the graphical display of the inheritance path.
- If there is overwritten data and inherited data, users have the ability to look at the inherited data and see where it is coming from
- If there is only inherited data, users can choose to override the content and enter new content
- If there is overwritten data, users have the ability to see a list of items/category that MAY inherit this data and DO override this data
- It is possible to tell when a value has been inherited or not
- It is possible to tell when a value could be inherited even if there is currently no data to be inherited
- It is possible to tell where a value could be inherited from
- When attributes are grouped, the inheritance rule is defined for the group
Precedence order:
- Overwritten value/provided value (if a value is provided, this is what will be saved)
- Default value/Sequence (if no value is provided, if the sub-spec is setup to have a default value or a sequence, this is what will appear)
- Inherited value (if no value is provided, and there is no default value or sequence for an attribute, the inherited attribute will appear)
Accumulate Inherited Values
This concept is used when an attribute retrieving a single inherited value is not sufficient. Therefore, it can be defined that an attribute follows the entire target path defined by an Inheritance rule and accumulates all values for display.
From the parent category
More to adore
From personal TVs for a bedroom or kitchen to bay-window-size HDTV-ready showpieces for your state-of-the-art home theater; it is all here. If you really love TV, you've come to the right place.From the child category
Get the ultimate experience from one of our next-generation digital sets
- Enjoy the biggest change to TVs since color
- ·13 The lifelike picture will amaze your eyes
- ·14 Digital sound will astound your ears
Multi-occurrence inheritance
If a group of attributes has a multi-occurrence value greater than one, the option to accumulate all the values down the inheritance path, add occurrences, and override the inherited values is turned on by default.
Important limitations: Inheritance for multi-occurrence will only support accumulated inheritance for group nodes; it will not support non-accumulated multi occurrence, and it will not support inheritance of multi occurrence single attributes, or multi-occurrence within a group.
The following are characteristics for multi-occurrence inheritance:
- Default option is set to accumulate all the data found in a path, displaying all of the values found in the paths above
- Users will be able to override any value in the group; once a value is overridden it is possible to see the value that would be inherited or revert to it. This is done through the GUI, the same way it is done for single occurrence attributes
- Multi-occurrence inheritance remembers the occurrence it is inheriting from as if each occurrence had an internal counter (i.e. it is not the position or the value that is being overwritten but the specific occurrence)
- The specified maximum occurrence is enforced and will count the total of occurrences, inherited and native
- Overriding a multi-occurrence attribute is done through the same screen as overriding single occurrence attribute
- Nodes within multi-occurrence group can be localized
- It is possible to have group multi-occurrence inheritance with groups having up to 3 levels of sub-attributes in addition to localization
- A given item may have up to 50 grouped attributes with multi-occurrence inheritance and up to 15 occurrences
- If an attribute is changed from multi-occurrence to single occurrence and the accumulate option was turned on, the accumulate option is turned off
- If a record exceeds the maximum number of occurrence because of the inherited occurrences, this does not prevent saving the record, however it should prevent adding more occurrences for this record
Workflow support for inheritance
Items and categories can be updated as part of a workflow. The source of inheritance and inherited attributes need to be included in workflow.
The following are characteristics of workflow support for inheritance:
- If an attribute is updated in a workflow, the target values are inherited from the attribute
- The new value is visible once the attribute is checked back in
- If an attribute that inherits its value as part of a workflow, this attribute will see the checked in value of the source. Any changes to the checked in source appears on the inherited attribute even if the source attribute is in the same workflow and has been modified
- Data entry screens have the same inheritance icons and functions as they do in the main catalogs/hierarchies
Inheritance of localized attributes
Inheritance supports localized attributes. Localized attributes are to be considered as individual attributes. The following are characteristics for inheritance of localized attributes:
- It is possible to inherit localized attributes
- It is possible to override inherited localized attributes
- It is possible to define inheritance rules for the original attribute of the localized node
Importing and Exporting Inheritance rules
To facilitate updating or recreating an environment, users may import and export inheritance rules.
- Import new inheritance rules
- Update inheritance rules using import function
- Export existing inheritance rules
Before discussing the different types of inheritance relationships, this section will review the relationships between WebSphere Product Center objects, which are illustrated through the following diagram.
Note: This section uses the term Category Tree, the application refers to this as Hierarchies.
1. The hierarchy is a hierarchical arrangement of categories used to organize and classify items within catalogs.
2. A Catalog is used as a repository / container for Items, which is the most basic content object in WebSphere Product Center.
3. A Hierarchy is associated to a catalog and a single hierarchy can be associated with multiple catalogs, thus catalogs may be associated with multiple hierarchies.
4. Items can be mapped to any number of categories within any number of categorization hierarchies.
Inheritance is implemented within WebSphere Product Center using three types of relationships that expand a product’s information, which is shared with other related information types.
- Category to Category
- Item to Category
- Item to Item
(No longer supported in 5.2 and subsequent releases)
A category-to-category relationship provides ancestral inheritance between categories in a hierarchy. With this relationship, a child category can obtain a value from the parent category, thus it is not necessary to provide the same value for all similar category attributes.
Values
The values for a category-to-category relationship are defined at the parent category level and are inherited by the child categories. There can be multiple child categories within the category hierarchy which all obtains its value from the parent category.
Defining Inheritance Rules
There is no need to identify an Inheritance Key as the category hierarchy is used to determine the data path. Inheritance rules are defined at the Hierarchy Attribute level (category spec) and must specify the target category. If desired, multiple target categories can be selected.
- Inheritance rules are defined at the Hierarchy Attribute Level
- Values defined at ancestral category level are inherited by child categories
- No Inheritance Key is needed since Hierarchy is used to determine data path
Characteristics
When creating a tree, there is an option to make inheritance available or not; this option must be selected to enable category ancestral inheritance
Inheritance can be setup for attributes that are in the Hierarchy Spec or in a Standalone Spec
To setup inheritance for attributes used only in Standalone Specs, the attribute must be assigned to at least one category
Inheritance works with multiple levels of category hierarchy
The values for an Item-to-Category relationship are defined at the Category level, which are inherited by items associated with the category. Therefore, there can be multiple items that obtain their values from the associated or assigned to a Category.
Values
The values for an Item-to-Category relationship are defined at the Category level, which are inherited by items associated with the category. Therefore, there can be multiple items that obtain their values from the associated or assigned to a Category.
Defining Inheritance Rules
Inheritance rules for an item are defined at the attribute level per catalog. The flow of inheritance traverses up the categorization hierarchy as defined by the hierarchy inheritance rule.
Characteristics
- Values defined at the category level are inherited by items associated with the category (immediate parent)
- Inheritance Rules are defined at the Attribute Level per Catalog
- Values are inherited directly from the Category to which an Item is assigned
- Traversal up the Categorization Hierarchy is defined by Hierarchy Inheritance Rules
In order to setup item ancestral inheritance, when creating a catalog, the following steps must be performed:
- Select a primary tree (or a secondary tree) where inheritance is available
- Specify that inheritance is turned on for the given catalog
Inheritance works with a combination of at least 10 levels of category hierarchy and 10 levels of catalog hierarchy
Changing category mappings updates the displayed inherited values
Two items in different catalogs can be related to each other via their primary key and can inherit data from each other. The value of one item is defined by "like" items in other catalogs. Items are unique to a catalog but can appear in multiple catalogs. One catalog might hold different values than another, but with an item-to-item relationship, the values can be inherited.
Value
The value of one item is defined by "like" items in other catalogs. Items are unique to a catalog but can appear in multiple catalogs. One catalog might hold different values than another, but with an item-to-item relationship, the values can be inherited.
Defining Inheritance Rules
Inheritance rules are defined at the attribute level (catalog spec) for the catalog that specifies the target items. In order to for an item to inherit values from another item, like nodes must be defined by specifying an "Inheritance Key" at the catalog level.
Characteristics
- Values defined by "like" items in other catalogs.
- Inheritance Rules are defined at the Attribute Level per Catalog
- The primary key must come from the same sub-spec
- When creating a catalog, to enable inheritance across items, inheritance must be turned on, which has to come from a sub-spec attached to the catalog spec
- Inheritance works with multiple levels of catalog hierarchy
Characteristics
To understand how inheritance is implemented within WebSphere Product Center, the following characteristics must be understood:
- Inheritance Rules are specified at an attribute level
- All items in a Catalog will follow the Inheritance Rule specified by the Catalog
- Items will have to define an Inheritance Key which will be used to identify "like" items in different Catalogs
- All Categories in a Hierarchy will follow Inheritance Rules specified by the Hierarchy
- Inheritance is always defined on Shared Nodes within a Spec
- Inheritance rules can differ between attributes – I.e. two attributes of an item may follow different inheritance paths
Inheritance Scenarios
The following examples provide scenarios of when inheritance can be beneficial.
Example 1
Multiple Inheritances occur when an item or category inherits from more than one item or category. For example, a CD_ROM can inherit values from the "Internal components" category as well as "External components", or a 20 GB hard drive from the categories "EIDE" or "SCSI".
Example 2
A parent catalog "Pentium 4 2Ghz" holds the following attributes:
- Category
- UNSPSC Code
- Product Name
- Product Type
- Description
The child category "Model" holds the following attributes.
- Image
- Detailed Description
The inheritance rule is defined at the parent hierarchy level, specifying which sub spec is to be shared, thus allowing the child categories to inherit the values of the parent category.
Applying the category-to-category inheritance relationship, the new structure would include all the categories from both trees. Thus, the values defined in the parent category are inherited by the child category.
- Category
- UNSPSC Code
- Product Name
- Product Type
- Description
- Image
- Detailed Description
Sub Specs create an advanced method of maintaining data integrity. Nodes of a single sub spec can be shared in multiple catalogs and, which allows the ability to create a single defined attribute that is consistent throughout all associated catalog.
Creating inheritance within catalogs can only be accomplished by using Sub Specs. Inheritance is implemented using Sub Specs, which create a shared attribute set. Only Attributes in a Sub Spec can be used for inheritance. Sub specs do not have a primary key that is needed, but at least one attribute must be used
Creating Sub-Specs
The following characteristics apply when working with sub-specs:
- No primary key required (attribute can be designated a primary key after inclusion in a catalog spec)
- Create node hierarchies within sub-specs
- In the details for the parent node of the sub-spec, all specs that make use of the sub-spec are displayed in the "Associated Specs" section. When the nodes are removed from the master spec, they are also removed from the Associated Specs list.
- Maximum Length, Maximum Occurrence, Minimum Occurrence can be defined
- All field types are available (Binary, Currency, Date, Flag, Image, mage URL, Integer, Lookup table, Number, Number enumeration, Password, Period, Relationship, Sequence, String, String enumeration, Thumbnail image, Thumbnail Image URL, URL)
- All additional parameters are available (Default value, Default value for sequence start, Delimiter for category path, Help URL, Increment sequence by, Lookup Table, Minimum Length, Number enumeration, Pattern (regular expression), String enumeration, String enumeration rule, Validation rule, Value rule)
- Attributes can be made Editable, Hidden or Non- Persistent
- Localization is supported when using sub-specs
Assigning Sub-Specs
The following characteristics apply when assigning sub-specs:
The following specs (referred to as ‘Master Specs’) can utilize sub-specs:
- Primary Spec
- Secondary Spec
When one or both the master and the sub-specs are localized, both specs must have the same locales associated with them to be able to assign the sub-spec
A single sub-spec can be assigned to any number of master specs
Any number of sub-specs can be assigned to a single master spec
The attributes of a sub-spec can appear on a master spec only once
Users have the option to add sub-specs when adding nodes to a master spec
When a sub-spec is added to a spec, all the unique attributes from the sub-spec are added to the bottom of the master spec and the name of the sub-spec will not appear. If there are duplicate nodes, an error message is displayed and all the nodes that can be added are added
It is not possible to edit sub-spec nodes in a master spec
It is possible to view the originating sub-spec of an attribute. In the master spec, click on a sub-spec node to view its details
It is possible to remove a node that was added through the sub-spec
If a sub-spec has already been added, re-adding it will look for nodes that are not in the master spec (whether they are new or had previously been deleted) and add them to the bottom of the master spec
Modifying sub-spec attribute parameters modifies their behavior in the master specs in which they are used
This section details each step that is performed to apply inheritance rules. The following steps assume that no pre-existing specs, catalogs, and categories will be used and everything is created from new.
- Create Primary Spec for Inheritance
- Create Hierarchy with Inheritance
- Create Catalog with Inheritance
- Define Inheritance Rules
- Enter Targets
- Enter Items into a Catalogs
- Enter category data and category inheritance
Create Catalog Spec For Inheritance
The goal of this section is to create two catalogs (parent and child) that use the same Sub Spec.
Create a Sub Spec
1. From the Specs Console, click Sub-spec from the Spec toolbar then click New.
2. Add nodes to the spec, as needed. When all nodes have been added, click New.
Note: A Sub Spec cannot be deleted if it is in use.
Create new Catalog Spec
Goal: Create two catalog specs for the parent child catalogs and add nodes from the sub spec created in the previous section.
1. From the Specs Console, click Catalog from the Spec toolbar then click New. The Spec Tree Wizard appears.
2. Enter a name for the first Catalog Spec, then click Next.
3. Add non-shared nodes as needed, then add shared nodes. To add a shared node, select the newly created sub spec from the popup window. All nodes from the sub spec are inserted into the Catalog spec.
Note: Share nodes are denoted with a hand in the attribute type icon.
4. Select a Primary Key and click on Save.
5. Create a second Catalog spec and select the same sub spec.
Create Hierarchy with Inheritance
Goal: Configure a Hierarchy for inheritance.
1. From the Hierarchy Console, click New. The Create Hierarchy Wizard appears.
2. Enter a name for the Hierarchy.
3. For "Select Inheritance Available", select Yes, and click Next.
4. For the purposes of this document, select No for "Select Use Code for Aggregation and Syndication".
5. Click create hierarchy and the new tree appears in the Hierarchy Console.
Note: There is no inheritance icon that appears next to the hierarchy name until an inheritance rule is defined for it.
Create Catalog with Inheritance
Goal: In this step, two catalogs are created with inheritance using the catalog specs created in the previous sections.
1. From the Catalog Console, click New. The Create Catalog Wizard appears.
2. Complete each step of the Wizard.
- Select a Catalog Spec to use
- Select a Node to use as the Inheritance Key. The values that appear in the drop-down list are the same from the Sub Spec created in the previous section
- Select an Access Control Group for the Catalog
- Enter a Catalog Name
- Select the Hierarchy that was created in the previous section
3. Create another Catalog using the same inheritance key selected in Step 2.
When both catalog have been created, they appear in the Catalog Console. Catalogs that have been configured with inheritance have the Inheritance icon next to the catalog name.
Define Inheritance Rule
Goal: Edit the Inheritance Rules for both catalogs so that the inheritance paths (targets) are properly defined.
1. Click on the Inheritance icon next to the catalog. The Inheritance Rule table appears. Click New.
2. Complete the Define Inheritance Targets Wizard.
- Select a catalog spec node to define a target path, click Select.
- Select No for "Accumulate for this catalog"
3. A table appears showing the available targets. Select the target paths, more than one target can be selected. Click Save.
4. Define inheritance rules for each catalog, as needed.
5. View all Inheritance rules by using the menu path Data Model Manager > Specs/Mappings > Inheritance Console.
Now that everything is setup with Inheritance rules, Items can be entered into catalogs or categories. The following sections step through how different inheritance relationship types being applied.
Enter Items into Catalogs
1. Enter an Item into the one catalog and add data to the attributes.
2. Enter an Item with same SKU into the other Catalog.
3. Press Refresh to get Inherited Data.
The item shows the values from the target path. The following functions are available:
View the inheritance path in a separate window
View the data from the inherited item
The "I" button denotes that the attribute is using its inheritance rule. Click the "O" button to override the attributes governing rule.
View Inheritance Path
To view the inheritance path of an attribute, click the view button, a separate window appears displaying the path for each attribute.
Overriding Inheritance Rule
To override an inheritance rule, click on the "O" button and change the attributes value. The original value can be returned by clicking the ‘I’ button, but if it is saved, the original value will not return.
Enter Category data and Category Inheritance
Use the following steps to add category data, and then view how information is inherited
1. Create a Hierarchy Spec and add to Hierarchy with Inheritance.
2, Update Inheritance Rules to include Hierarchy
3. Add Data into the Categories with Items assigned to them.
4. Add / Modify Data in Items to see Inheritance scenarios
Implementing inheritance within a catalog structure can have some implications with existing catalogs. Test inheritance with data in a test environment to ensure stability.
Inheritance Key = Primary Key
When identifying an inheritance key, it is recommended to use an attribute that is set to be the Primary Key. This ensures that the value is unique and does not create. Remember, a Sub-Spec does not have a primary key, yet a defined node can be the same primary key used for a catalog.
Non-Unique Inheritance Key
Although an Inheritance Key can be defined as a non-unique attribute, it is not recommended. The results of selecting a non-unique inheritance key are undeterminable. Where an attribute obtains its value can differ from case to case. Therefore, it is suggested to select an attribute that is unique.
Relationship Performance
When structuring a catalog to use inheritance, the use of an inheritance relationship can provide different performance results. The following list of inheritance relationship is rated by performance, with the first being the fastest.
- Item-to-Item
- Item-to-Category
- Category-to-Category
Entry Build Scripts
Entry Build Scripts are usually executed when values are entered into the data entry screen. An entry build script can be defined at the Catalog attribute screen. Advanced WebSphere Product Center users with good amount of scripting experience should use this feature.
Avoiding Circular Reference
It is not possible to create a circular reference when implanting inheritance and WebSphere Product Center does not allow a user to do so. For example, there are three items (Item 1, Item 2, and Item 3). With inheritance defined, Item 3 looks to Item 2 for a value and then to Item 1. It would not be possible to define an inheritance path that looks for a value in Item 3.
Deleting Parent Values
When deleting attribute values that have inheritance rules associated to them, it is recommended to first view all associated inheritance paths and double-check the data integrity of other catalogs. When using this feature for large catalogs, it should be expected for the operation to take a good deal of time to complete as the application is directed to find all associated instances.
How to Migrate Catalogs to use inheritance
If it is desired to implement inheritance with a current set of catalogs, a new catalog structure must be created with shared nodes from Sub Specs. It is recommended to contact WebSphere Product Center on the best way to architect a catalog with inheritance implemented.
Other limitations to note
- It is not possible to search on inherited values
- Inheritance between items within a given catalog is not available
- Inheritance across trees is not available
- Inheritance of empty values is not available
- Multi-occurrence inheritance may cause to exceed the number of occurrences and make an item invalid without going to the item; multi occurrence inheritance should only be used with a large number of maximum occurrence and without the intention of enforcing the maximum occurrence.
- Deleting multi-occurrence inherited is not possible
- Inheritance will not support inheritance for multi-occurrence fields within a group
- If an inheritance rule exists for a multi-occurrence group, and the spec is modified to no longer be multi-occurrence, the inheritance rule will have to be deleted and recreated
- It is possible, in the GUI, to tell not what item/category is inheriting from an item, but what category or item COULD be inheriting, up to a maximum of 50 category or items
- For category-to-item inheritance, items can only inherit from their immediate parent
- Nodes within sub-specs cannot be made unique and cannot be created as links
- Sub-specs cannot be used by specs other than catalog specs, hierarchy specs, and secondary specs
- Sub-specs cannot be added under a group in a master spec
- If the same sub-spec attribute is inherited more then once by the same item, only one instance of the attribute will be shown; it will not be possible to predict which instance will be shown
- If an item or a category has more then one possible inheritance source, it will not be possible to predict which value will be inherited
- When adding a new item or category, the inherited values will not appear until after saving and refreshing the screen
- Inherited values will not appear on a screen automatically; users will need to refresh the screen to see the inherited values
- It is not possible to create distinct inheritance rules for attributes within a group, which includes localized nodes
- Inheritance does not support attributes of type FLAG unless the source catalog's flag is set to "false". The work around for this is to simply use the STRING_ENUM type with three choices: YES/NO/NA
- Currently, Multi-value inheritance is ONLY supported for Grouped Multi-values. Therefore, NON_GROUPED, MULTI_VALUED attributes cannot have inheritance on them
- Inheritance DOES NOT support value rule nodes
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. 1 – 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 screen 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
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.
WebSphere Product Center provides localization that adheres to ISO’s Internationalization Standards. Locales are created based on language/country pairs, which provide variances across countries (i.e. U.S. English, British, English).
Localization is configured at the spec level (primary, lookup table, or secondary spec), therefore, it is possible to localize a single node or multiple nodes and set localized display names for each node. Once a spec has been configured with localization and associated with a catalog, localized data can be imported into or exported from WebSphere . Catalogs that contain localized nodes can be set to view a specific set of locales for an item set displayed in the user interface through the user's settings.
Localizing spec node values for a primary, lookup table, or secondary specs
- Supports attaching language + country locales to any node in a primary spec, lookup table spec, secondary spec
- Locales incorporate language + country pairs, which provides for language variances across countries (e.g.: American English vs. British English)
Localize catalog display names
- Enables entering a locale-specific display name for all localized catalog attributes, or using a default display name
Display catalog items in one or more locales depending on the user's settings, role, and views
- User can set desired locales in a User Setting dropdown box
- Any locale created in the user's environment is automatically loaded into the User Settings
- User can restrict display via a User Setting to one locale or all available locales
- User can also setup catalog views to display one or more locales, which are displayed as they are ordered in the spec
- Catalog Access Privileges apply to all localized catalog nodes
The restriction of locales that are displayed in the user interface is controlled through company attributes, user settings and/or role configurations.
- Company Attributes - Define the available locales for the company. This setting defined what locales are available in the user settings and role configuration.
- Role configuration - The locale setting can be defined for a Role, hence the user’s locale is based on the role they are assigned. The user can only control which locales are displayed based on what is available for their assigned role.
- User settings - A user can set the desired locale(s) using "Restrict the displayed attributes in item and category screens to the selected locale" within their user settings. Any locale created in the user’s environment is automatically loaded into the User Setting’s "Available Locales". Restrict a user's view to a single or multiple locales (if more than one locale has been created).
Setting available locales for the company
Before any data can be localized, the available locales must be set for the company. This task should be performed by the WebSphere Product Center administrator.
1. Use the menu path Data Model Manager > Security > Company Attributes; the "Company Locales setup" table appears.
Figure 6.1 - Company Locale setup table
2. Click on a language from "Languages" and a country from "Countries", then click Add to add the locale to the "Selected column".
3. To remove a locale, click on a locale from the "Selected" column and click "Remove".
4. When all locales have been selected, click Save. All selected locales are available to users in the company.
Restricting locales to display for a role
Restricted locales can be defined for a role. When a user is assigned to the role, the user's graphical interface will be restricted to the locales defined for the role. Therefore, the user’s locale is based on the role that they are assigned to and the role locale restriction overrides control from the user settings. From the list of roles to restrict or make available in the user settings, the user is able to control which locales are restricted based on the locales that are made available through the role definition.
1. Use the menu path: Data Model Manager > Security > Role Console; the Role Console is displayed.
2. Select a Role to edit and click Edit or simply click on the name of the role to get to the edit role screen.
3. When a new role is created, it is defaulted for all categories and hierarchies to use all available locales for the company. To change the locales available for this default setting, scroll to the bottom of the screen to the "Locale access for role" table. Click on the edit button and add/remove locales and click Save.
4. To create a new locale access for the role, click the New Locale Access button to display the "Containers To Locales Map" wizard. This allows the restriction of locales to a specific object (catalog or hierarchy. Add/remove locales and click Save.
Figure 6.2 - Locales access configured for role
5. To apply locale restrictions defined by the role, assign a user to the role using the User Console.
Restricting locales to display in user settings
1. Use the menu path Home > My Settings; the several user setting tables appear.
2. Select one of the following settings to control which locales are displayed in the user's graphical interface:
Locale for user interface display
Select a locale to use for the User Interface. This only applied to the graphical user interface.
Locale for Item and Category Data Display
Set the locale to display item or category data.
Restrict the displayed attributes in item and category screens to the selected locale
This option restricts the display of a selected locale for attributes in item and category screens.
3. Click Save, to commit the settings.
Localization is defined at the spec level for primary, lookup table, and secondary specs. This section details how to configure localization for a spec.
The implementation of localization within WebSphere Product Center provides the proper structure to support database localization, because all locales are stored as separate strings. The data for the node is moved to the leaf nodes.
The display names that are created will appear in the item list/edit screens based on the locale setting in the user settings. The actual translation of the data is done manually, but is stored in each individual leaf node.
Note: The localized check box option is not available if it has already been localized or localization is not available.
Configure spec for localization
1. From the Specs Console, select a primary, lookup table, or secondary spec to localize and click Edit.
2. Select the Localized checkbox in the "Details for ... spec" table. The "Localization Information" section appears.
3. Select the locales from the "Available Locales" column and add them to the "Selected Locales" column. Click Save to save the spec.
4. Click on a spec node. Enter localized display names in the "Display Name" section. This allows for the display name for the spec node to appear in different languages.
5. Click the Localized checkbox for the spec node. Notice that the node has been localized for all locales defined for the spec. Continue to localize each node of the spec, if desired.
Figure 6. 3 – Localized node
Entering localized data
Once the a spec has been localized, data can be entered separately for each locale for an item. All locales appear in the catalog item list, unless specified otherwise in the user's setting or role. If no localized display name was created for the locale, the default name appears.
Figure 6. 4 - Data for localized node entered manually
Creating attribute collections with localized nodes
When defining an attribute collection, it is possible to include a node for a specific locale. When searching for a spec and/or attribute from the create attribute collection screen, localized nodes are indicated by "(L)'.
Figure 6.5 - Select node for specific locale for attribute collection
Import/Export to localized nodes
The ability to import/ into localized nodes is made simple through the use of WebSphere Product Center’s Mapping Console. If a source file contains fields that are localized for various regions they can be mapped to the proper localized nodes of the catalog. Thus, the same can be done for exports.
There are no locale selections in My Settings
The company has not been configured for any locales. Use the menu path Data Model Manager > Security > Company Attributes, the Company Locales Setup screen appears.
Select the required locales for the company. The selected locales appear as a selection in the user's settings.