Part IV covers each of the components that are available within the Data Model Manger.
- Scheduler
- Specs/Mappings
- Attribute Collections
- Scripting
- Security
- Alerts
- Staging Area
- Workflows
The Scheduler component is used to track the status of activities within WebSphere Product Center (i.e. imports, exports, reports). The Jobs Console provides a unified view to manage all scheduled jobs that can be executed based on a defined timetable and monitored with status information.
Scheduler terminology
Jobs A job is an import, export, or report that is created in their respective consoles. Multiple scheduled can be identified for a single job. Schedule A schedule is defined for a job. Multiple schedules can be created for a single job. Scheduler The Scheduler component of the Data Model Manager allows a user to view information on all schedules that are associated to the various jobs that have been created.
The Jobs console displays jobs that are scheduled to run, which include imports, exports, and reports. Users can disable a job, compare jobs, view the status of a job, or update schedule information.
Figure 13.1 - Jobs Console
Jobs Console columns
The following table lists the columns that are available in the Jobs Console.
Created by Identifies the creator of the job. This column can be sorted by clicking the arrow next to the column heading name
Description Description of the job Schedule Information Lists the number of associated schedules. Click to view all schedules associated to the job Action Functional buttons available for each export job listed Jobs Console buttons
The following table lists the functional buttons from the Jobs Console screen.
View the status of the job
Update the schedule information
Disable a job so that it does not execute as scheduled
Compare two different instances of a job or to a different job
Click to access the Schedule Status page to search by the status of scheduled jobs
Accessing the Jobs Console
Use the menu path: Data Model Manager > Scheduler > Jobs Console. The Jobs Console interface appears.
Viewing job information
From the Jobs Console click on the description for the job to take you to a screen that provides a calendar of the day the job was executed along with additional details related to the job.
Update schedule information
From the Jobs Console, click the associated schedules hyperlink for the job to take you to a screen that provides view additional job information and the ability to update the schedule information for a job.
Figure 13.2 - Schedule information
Select a job from the Schedule Information table and click one of the following action icons:
Enable selected schedules
Disable all associated schedules
Edit scheduled job
View Schedule Status Information
Delete scheduled job
Compare schedules that have already been executed
Viewing job status
From the Jobs Console, click the status button from the Action column for a job. The Schedule Status Information table appears displaying detailed information for the selected job.
Comparing Scheduled Jobs
The Compare action allows a user to compare jobs that have already been executed.
1. Select a job from the Jobs Console and click the Compare button from the Action column. The "Runs Progress Comparison For Job" table displays with the job statistics for the job.
2. From the table, find the job to compare with and click the [< Compare] hyperlink in the column heading.
3. There are six components that can be used to analyze the performance of a job. Select one of the following action buttons.
Displays the current status percentage bar, and also two charts to plot progress over time.
An expandable/collapsible table to provide insight into all the operations that were performed during the job run.
Displays useful debug information for certain job types.
Displays the duration from the start of the job it took to reach each percentage point. The durations are in milliseconds.
Displays a comparison between different jobs.
Expanded versions of the Progress Table. Extra columns for the durations for each job/schedule run are also displayed.
1) Progress Chart: This displays the current status percentage bar, and also two charts to plot progress over time.
2) Performance: An expandable/collapsible table to provide insight into all the operations that were performed during the job run. If the job is still running, the row with a yellow background was the last updated row (operation last performed during the job run)
3) Debug Report: Displays useful debug information for certain job types. To write messages to this debug report, use the logDebug script operation
4) Progress Table: Displays the duration, in milliseconds, from the start of the job it took to reach each percentage point. Also, displayed on this screen for comparison are the average duration times for the job and for the schedule.
5) Compare With Job Runs: Compare the progress between jobs that have been executed at different times.
6) Compare With Schedule Runs
Displays an expanded version of the Progress Table. There are extra columns for the duration of each scheduled job. If desired, delete the information displayed for this job. Change the focus to a different job by clicking the " Compare" link.
Searching the jobs console
User can search for a job in the Jobs Console using the search feature.
1. From the Jobs Console, click the Search Options button located above the table heading row.
2. Select to search by the "Created by" or "Description" column. Add a search criterion (use * for wildcard) and view the results in a table.
Disabling/stopping a scheduled job
1. From the Jobs Console, click the disable button, located in the Action column. A dialog box appears confirming the job will be disabled.
2. Click OK to disable the job, or Cancel to continue the job.
Issues with stopping an import in progress
Stopping an import in progress can be somewhat risky at certain points in the import process and could possibly damage a catalog. If a job is stopped at 75% completion, a rollback must be done manually.
If the job has surpassed 75% and the job is killed, extra steps need to be taken to make sure data is not in an inconsistent state. This can be done by first performing a catalog difference with the last version before the import. If data appears in the catalog, a rollback needs to be setup and executed to return the catalog to its previous state.
This component displays the status of all item macros or saves that have completed running, currently running, or items that have caused an error.
Accessing the Entry Processor Status page
Use the menu path: Data Model Manager > Scheduler > Entry Processor Status. The Entry Processor Status Search interface appears.
Search for entry processor status
1. From the Entry Processor Status page, select a value from the Current Status drop-down field.
- ALL
- Completed Running
- Error Completing
- Running
2. Select a value from the Processor Type drop-down field (Item Marco or Item Save).
3. Select a time frame to search from the Date From and Date to fields.
4. Select a user from the Created By drop-down field. The default is the current user.
5. When the search parameters have been selected, click Search and the results display in the Entry Processor Runs table.
6. To view the error log for any item processor runs, click the view button in the Error Log column.
Schedule information can be obtained on all job types (import, export, reports), which can also be obtained from the Jobs Console. Within this component, the user has the option to view system job runs.
Accessing the schedule status page
Use the menu path: Data Model Manager > Scheduler > Schedule Status. The "Schedule Status Search" and "Schedule Status Information" interfaces appear along with a table of scheduled status information on the most recent jobs executed.
13.3 Schedule Status page
Searching the status of a schedule
To search the status of a schedule, do the following:
1. From the "Schedule Status" page select one of the following values from the By current State drop-down field:
- Completed and Running
- All
- Completed Running
- Error Completing
- Running
- System Error
2. Select a time frame to search by selecting values from the Date From and Date To drop-down fields.
3. Select a user in the Created By drop-down field.
4. OPTIONAL: Check the View System Job Runs box to include jobs that were executed by the system automatically.
6. Click the Search button and the results of the searched schedules appear in a Schedule Status Information table.
If a job has been generated and awaiting an approval, the job is placed in the approval workflow. The approving authority is notified through the Alerts Module of their My Task List and the generated file can be reviewed before it is approved or rejected.
Approving Scheduled Jobs
1. From the "My Task List" of the approving authority for the job, the Approval Module displays all of the jobs that have been requested for approval or submitted for approval from a user.
Note: If the Alerts Module is not configured to display, edit the My Task List settings to do so.
The following is a list of authorizing status icons.
Accepted
Pending Authorization
Rejected
2. If the job status is in pending status, click on the Pending icon. The Task Approval Information screen appears.
3. Accept or Reject the job by clicking on the associated button. If desired, enter a reason for your decision. The job status is updated in the user's task list and in the associated console for the job (i.e. Import Console).
Figure 13. 4 – Approving a job
The Specs/Mappings component of the Data Model Manager provides access to the Specs Console and the Spec Map Console.
The following is a list of spec characteristics:
- A model for how data is stored, calculated, and managed within WebSphere Product Center
- A model for data as it resides outside of WebSphere Product Center
- Flexible data templates that are used for data validation and can be changed on-the-fly
- Can be updated and maintained by a selected group of users
The Specs Console allows a user to easily navigate and view the following specifications.
- File
- Primary
- Lookup
- Destination
- Secondary Specs
- Script
Figure 14.1 - Specs Console
Accessing the Specs Console
To access the Specs Console, use the menu path
Data Model Manager > Specs/Mappings > Specs Console.Navigating the Specs Console
To navigate between different spec types, use the Spec Navigation bar.
Figure 14.2 - Spec navigation bar
The top-level buttons can be clicked to view its associated spec type
To search a spec by name for a specific spec type, select a spec type and a letter from the alphabet selection on the navigation bar. All specs starting with the selected letter appear. Click "All" to view a list of all specs for a selected spec type
Spec Types
File Defines data elements of incoming data Primary Defines item attributes, category hierarchy attributes, and organizational hierarchy attributes. These specs can be attached to catalogs, category hierarchies and organization hierarchies
Lookup Defines lookup table record attributes Destination Defines data elements at destination Secondary specs Secondary specs are used as item hierarchy specs or as standalone specs. The secondary specs are attached to categories. If a secondary spec is attached as a item hierarchy spec, the attributes will be available to all items under the category.
If a secondary spec is attached to the category as standalone specs, it will be available only at the category level for a specific category
Script An input spec that defines attributes to be passed to a script (input parameters)
Creating Specs
To create a spec, select a spec type from the Spec toolbar and click the New button located in the spec table heading. Refer to the following sections on creating and defining specs (Attribute Management).
Editing Specs
If desired, a spec can be edited from the Specs Console by clicking on the Edit button . Edit can be made from the spec tree and saved by clicking the Save button at the bottom of the screen.
When a spec is created, nodes are be added in a treelike structure and parameters are defined for each node, such as the field length and the data type. If needed, additional parameters can be added (i.e. maximum length, required flag, data type, etc.)
Add attributes to a spec
1. To add a node, click the Plus icon on the spec tree.
2. Enter a name for the node and click the Plus icon, located at the end of the entry field. The attribute is added to the Spec Tree and the details box appears. The next step is to define the node parameters.
Figure 14.3 - Adding a node
3. To define node parameters, enter information in the Details table and click Save to commit the change.
Figure 14.4 - Define node parameters
4. To add additional attributes, choose a value from the drop-down selection under the Display Name field, then click the Plus icon. The value is added in the Details box. Enter a value for the attribute and click Save.
5. Enter information into the new attribute field and continue adding nodes and node parameters, as needed.
6. When all of the nodes and node attributes are added, click the Save button at the bottom of the screen to store the spec.
Note: If the Save button is not clicked, the newly created nodes will not appear in the spec.
Nodes on a spec tree can be edited or deleted at anytime. Be careful when making any changes to a spec as it will change all the objects that are using the spec. For example, if a node is deleted from a primary spec, any catalogs that use the spec will no longer have the node in the catalog along with their values. This action cannot be reversed.
Editing node
To edit an attribute, click on the node name on the spec tree. Make modifications and click the Save button.
Deleting a node
To delete a node, simply find the node in the spec tree structure and click the garbage can icon next to it.
A node parameter can be in any type of spec, a number of parameters may be set for each attribute (node). These parameters define how data is to be calculated, stored and/or validated for that attribute (node).
All specs are created in a tree structure that is built by adding and defining node parameters. This section explains how to add and define spec nodes.
Defining node types are important to create and maintain a standard structure for product information. With multiple users handling the data, a miscue in data entry will produce an error message.
When adding nodes to a spec, they can be defined with the following parameter characteristics:
Data Types Strings, Numbers (Integer, Decimal, Currency), Enumerations (Number, String), Images (Binary), Dates, Flags, URLs, Groupings, etc. Editable
An attribute can be made editable or not. If unchecked, the value for this field is viewable and cannot be edited
Unique
Creates a requirement for the node to be unique in a catalog. If a user attempts to enter a duplicate value, an error occurs. Option only available in Primary specs.
Link
Defines a node as the "source attribute" or "foreign key" to the master catalog. Option only available in Primary specs.
Hidden
Defines a node that is not displayed and is useful for nodes that are used as placeholders for intermediate values. When this box is checked, the node is hidden and when unchecked it is displayed. Although this feature hides a node from the item view screens, it is exposed to scripts and searches.
Runtime Searchable Check this box to include the node for runtime searches. If the box is not checked then it is available to background searches. Use this option for common searchable nodes. Non-Persistent
Provides the ability to make a node not constant
Localized
Set attribute for localization. Company must be set with the desired locales.
There is a limit to the number of characters in a value/validation/string-enumeration rule. It can be at most 3000 bytes, which in most cases translates to 3000 characters (including spaces). It can be less than that depending on the characters used e.g. Japanese characters etc. can be more than one byte long.
Each node within a spec is associated to a node of any type. Therefore, scripts can be created to perform rules for a node.
- Validation rule
- Value rule
- String or number enumeration rule
Each node within a spec is associated with a data type, which controls the following:
- Display properties in the user interface
- Storage in the database
- Presentation in an export
- Search capabilities
- Implicit validation on Import/ Export/ Data Entry
The available data types differ between each spec type. This section lists the different data types available in WebSphere Product Center.
Binary
Function: Store binary data, i.e. PDF files, Image files.
Available in Specs: All
Rules associated: NoneAfter an attribute has been defined as Binary, the catalog attribute can be used to upload a binary file into WebSphere Product Center. Click the Edit icon from the Item Edit screen and the Upload Image screen appears.
Currency
Function: Define currency fields. By default, the value is rounded to the second decimal place
Available in Specs: All
Rules associated: Default value, Minimum length, Pattern, Validation rule, Value RuleWhen adding a value to the attribute, it is rounded to the second decimal point.
Date
Function: Define date fields
Available in Specs: All
Rules associated: Date format, Default value, Minimum length, Validation rule, Value ruleApply the spec to an object and the date format appears in the format as defined. Select from a set of pre-defined date values or enter a date manually.
Flag
Function: Holds one of two states, true or false
Available in Specs: All
Rules associated: Default value, Validation rule, Value ruleA checkbox is created for selection. An empty box could be searched for as a null value for the node.
Image
Function: Used to store images
Available in Specs: All
Rules associated: NoneAfter a node has been defined as "Image", the catalog attribute can be used to upload an image file into WebSphere Product Center. Click the Edit icon and the Upload Image screen appears.
Image URL
Function: Used to store a URL location of an image. WebSphere Product Center fetches the URL from the defined location
Available in Specs: All
Rules associated: Default value, Minimum length, Patter, Validation rule, Value ruleIn the catalog item view, a URL for a graphic can be entered. Click on the Preview button to view the image.
Integer
Function: Used to store only integer numbers. Numbers with decimals are rounded to form an integer.
Available in Specs: All
Rules associated: NoneAny of the natural numbers, the negatives of these numbers, or zero must be entered for this attribute. If an integer is not entered for this attribute, an error occurs.
Lookup table
Function: Associate to a lookup table, which provides a drop-down selection of lookup tables that have been created
Available in Specs: All
Rules associated: Value ruleNumber
Function: Used to store double numbers, i.e. number which can hold decimal values. (For example, 10.98)
Available in Specs: All
Rules associated: Default value, Minimum length, Pattern, Validation rule, Value ruleA number is defined to allow a number value with a decimal value. If no decimal value is given, it given a value of ".0". Negative values are allowed.
Number Enumeration
Function: Used to create a list of number data types. Negative and decimal values are allowed.
Available in Specs: All
Rules associated: Number enumeration rule1. Set the data type to "Number Enumeration".
2. The details table adds a Number enumeration row. Click the "CLICK HERE" hyperlink and a separate dialog box appears.
3. Add a number in the Spec Enum Details table and click the Plus icon.
4. Continue to add number values to the enumeration and click Close Window when finished.
5. The values entered are displayed in a drop-down selection format and are listed in ascending order.
Password
Function: Refers to an alphanumeric field which hides the contents to the user
Available in Specs: All
Rules associated: Default value, Minimum length, Pattern, Validation rule, Value ruleWhen entering a value, it is displayed with asterisks. This is useful when values are to be hidden.
Period
Function: Creates two Date fields, Start Date and End Date
Available in Specs: All
Rules associated: Default value, Minimum length, Validation rule, Value ruleThe GUI creates a field with a Start and End Date value.
Relationship
Function: Used to hold a link to another item in the same or another catalog
Available in Specs: Catalog Spec
Rules associated: Default Value, Validation rule, Value ruleThe GUI allows a user to select a catalog and a key attribute to link two catalogs. The Key value allows for a link relationship to be established.
Sequence
Function: Used to create a numbered sequence field
Available in Specs: Catalog, Lookup table, Category, Hierarchy
Rules associated: Default value, Increment sequence by, Default value for sequence start, Minimum length, Validation rule, Value ruleSet a rule associated to the data type, i.e. set the Default value for sequence start at "1". When a new item is added, the sequence field automatically enters "2". This field is not editable to the user.
String
Function: Holds a string or character data
Available in Specs: All
Rules associated: Default value, Minimum length, Pattern, Validation rule, Value ruleIf desired, create an associated rule for the attribute. The GUI displays an empty field for data entry.
String Enumeration
Function: Create a string enumeration data type that holds a list of string data types
Available in Specs: All
Rules associated: Default value, Minimum length, Pattern, String enumeration rule, Validation rule, Value ruleAssociate a rule with the data type, which displays all values in a drop-down selection field.
Thumbnail image
Function: Stores a thumbnail image
Available in Specs: All
Rules associated: Default valueA user is able to load a thumbnail image and view it from the GUI.
Thumbnail Image URL
Function: URL link to a thumbnail image. WebSphere Product Center will fetch the image from a defined URL.
Available in Specs: All
Rules associated: Default value, Value ruleThe field allows for an address to be entered for the Thumbnail Image URL. Set a Maximum length for the attribute.
URL
Function: Define a URL field and appears as a link on the item list and item detail screens
Available in Specs: All
Rules associated: Default value, Minimum length, Pattern, Validation rule, Value ruleThe field allows for an address entered for a URL.
Once a data type is selected, additional rules can be added to further define the characteristics for an attribute.
Default Value
Function: Define a default value for an attribute.
Available in Specs: AllDefault value for sequence start
Function: Define a default value for a sequence.
Available in Specs: All
Rules associated: SequenceHelp URL
Function: Define a Help URL; used to customize help.
Available in Specs: AllAlthough WebSphere Product Center has general help topics available for application assistance, the ability to have an attribute link to a URL can be utilized to create customized help topics.
Increment sequence by
Function: To increment a sequence by a defined value
Available in Specs: All
Rules associated: SequenceLookup Table
Function: Defined an associated lookup table. No value is available if no lookup tables exist.
Available in Specs: All
Rules associated: Lookup TableMinimum Length
By default, the Maximum Length is provided. To set the node to a minimum length is must be defined explicitly from the attributes details screen.
1. A minimum length can be defined by selecting "Minimum Length" and click the Plus button.
2. Enter a value in the Minimum Length field.
3. Click save to update the spec.
Number Enumeration
Function: To defined a enumerated number attribute:
1. Select Number Enumeration Rule and click +, the Number Ennumeration field appears.
2. Click "CLICK HERE" to access the pop up window used to create a number enumeration..
3. After creating a number enumeration, click Close.
Occurrences To Display
Function: To defined the number of occurrences that are displayed, if an attribute is defined as multi-occurrence:
1. Select the Occurrences To Display Rule and click +.
2. Enter a value in the Occurrences To Display field.
Pattern (regular expression)
To defined an attribute with a pattern for a regular expression.
1. Select the Pattern (regular expression) Rule and click +.
2. Enter a pattern for a regular expression.
String Enumeration
Function: Create a string enumeration data type that holds a list of string data types
Available in Specs: All
Rules associated: Default value, Minimum length, Pattern, String enumeration rule, Validation rule, Value rule1. Set the data type to "String Enumeration".
2. Click "CLICK HERE" for a pop up window used to create a string enumeration
String Enumeration Rule
Function: Create a string enumeration rule for data type that holds a list of string data types
Available in Specs: All
Rules associated: Default value, Minimum length, Pattern, String enumeration rule, Validation rule, Value rule1. Set the data type to "String Enumeration Rule".
2. Click "CLICK HERE" for a pop up window used create a string enumeration rule.
Validation Rules
Function: To defined a validation rule for a node.
1. Select Validation Rule and click +, the Validation Rule field appears.
2. Click "CLICK HERE" to access the Validation Rule Editor.
3. Create a Validation Rule for the attribute and click Save.
Value Rule
Function: Create a value rule for the node
Nodes can be grouped on any spec tree. When grouping nodes, it is important to create all major groupings before adding sub-nodes to each group. Use the Single Edit screen to view grouped nodes as the multi-edit screen will not appear in the Multiple Edit screen.
Creating grouped nodes
Figure 14.5 - Grouped nodes
The following steps create an example of grouped nodes.
1. When creating a spec, click the root node and add the first level group node (i.e. Group A).
2. Click the "Group A" attribute to add a sub-node, "Group A1"
3. Click the "Group A1" node to add a sub- attribute, "Group A1-1". The spec tree appears with three group levels.
4. Add a node under any of the grouped nodes. Before adding sub-nodes, all parent level groupings must be created before adding sub-nodes.
Note: When grouped nodes have been created, use the Single Edit screen to display groups as they do not appear in the Multiple Edit screen.
A file spec is created to define the file structure of an external data source. The file spec is needed for the importation of a source file into WebSphere Product Center. Analyze the structure of the data source and create a file spec that emulates the structure.
If the data source changes at a later time, the file spec can always be modified to reflect the changes.
Creating a File Spec
- From the Specs Console, select File from the spec navigation bar, the Specs Console appears with a list of previously created file specs, if any.
- Find the Files Spec(s) column heading and click New. The Spec Tree interface appears.
- Complete each step of the wizard driven GUI.
1. Select Spec Type
By default, File Spec displays in this step.
2. Enter File Spec Name
Enter a unique name for the new file specification. Choose an intuitive name for easier retrieval. The system will not allow duplicate File Spec names.
3. Specify File Format
Select one of the following formats and click the Select button:
- Character Delimited - Used for a file that uses a custom character to separate the fields in the incoming file. For example, a file could use the character # to separate the fields
- Tab Delimited - Used for a file that uses the TAB character to separate the fields in the incoming file.
- Comma Separated Values (CSV) - Used for a file that uses the comma to separate the fields in the incoming file.
- Fixed Width - Used for a file that uses a constant space for all fields in the incoming file. Such a file is easily recognizable as all fields are nicely aligned in columns.
- XML - Used for a file that uses the XML format.
- line(s) at the tope of the file. - enter a value for the number of lines to ignore in the heder.
The file spec is created and nodes can be added as needed. When all nodes have been added, click Save to store the file spec.
A Primary Spec is needed in order to configure the format of a WebSphere Product Center catalog structure. The primary spec is mapped to a file spec, defining how information should be routed from data source to the catalog. Primary specs are also used to define hierarchies associated to catalogs.
Creating a Primary spec
- From the Specs Console, select Primary from the spec navigation bar, the Specs Console appears with a list of previously created primary specs, if any.
- Find the Primary Spec(s) column heading and click New. The Spec Tree interface appears.
- Complete each step of the wizard driven GUI.
1. Select Spec Type - By default, File Spec displays in this step.
2. Select Name - Enter a unique name for the primary spec and click Next to display the spec tree.
3. Define the primary spec with nodes defined with parameters as needed.
4. Set Primary Key Field - A unique identifier is required when creating a catalog spec. Select a node as the primary key by clicking on the checkbox. A primary key must be identified before the spec can be saved.
5. When all attributes have been added, click Save to store the spec.
Note: Once a primary key is selected and the spec has been saved, the primary key cannot be changed. If a new primary key needed, create a new spec.
Hierarchies (or Taxonomies) are used in WebSphere Product Center with catalogs as a way to classify the items that are stored within. It can be compared to how library books are placed in certain areas of the building, such as "Non-Fiction", "Reference" and "Periodicals." The books are classified in a way that makes them easier to browse, both for the library patrons and for the librarians.
In the same way that a librarian uses this categorization scheme, WebSphere Product Center provides users with the tools to build and modify multiple hierarchies to help them organize the items stored within their catalogs.
Before hierarchies can be created, it must have an associated Primary Spec. Once a Primary Spec has been created, a hierarchy can be built using the Hierarchy Console.
Create Hierarchy Spec
Creating a hierarchy spec is the same as creating a primary spec. Use the same instructions as creating a primary spec.
When an export job is created in WebSphere Product Center, a destination spec is created to define the exact requirements of the destination file. Similar to a file spec or primary spec, each attribute of the destination spec is defined. During the exportation of data, the destination spec generates a file that adheres to a set of predefined requirements.
A set of pre-defined destination specs is available (i.e. Ariba, Yahoo Shopping, Commerce One) and is not editable.
Create Destination Spec
- From the Specs Console, select Destination from the spec navigation bar, the Specs Console appears with a list of previously created destination specs, if any.
- Find the Destination Spec(s) column heading and click New. The Spec Tree interface appears.
- Complete each step of the wizard driven GUI.
1. Select Spec Type - By default, Destination Spec displays in this step.
2. Select Name - Enter a unique name for the destination spec and click Next to display the spec tree.
3. Define the destination spec with nodes defined with parameters as needed.
4. When all attributes have been added, click Save to store the spec.
When creating an export, a primary spec can be mapped to the destination spec. All available destination specs are displayed when creating a Spec Map or an Export job.
Any spec can be imported and exported from the Specs Console. Specs can be exported in XML or XSD formats and can be imported into another WebSphere Product Center instance. The export feature is a great way to back up all specs so they do not have to be recreated from scratch.
Importing a spec
1. Select a spec type from the spec navigation bar and click on the Import button. The "Upload of a Spec XML or XSD" appears in a separate window. To import all the currently displayed specs appearing in the Spec Console, click the All checkbox.
Note: The spec type of the imported spec file must be selected. If Primary is selected in the Specs Console and the user attempts to import a File Spec, an error occurs.
2. If selecting a XML Document, click Browse and select a file to import then click Upload. The document is stored in the Document Store.
3. If selecting an XSD Schema Definition, the "XSD Options" section appears. Enter the required information and click Upload.
4. The imported spec appears in the Specs Console. If an error occurs, it is possible that the imported file type does not match that of the Spec Console.
Exporting a spec
Select a spec type from the spec navigation bar and select a spec to export from the Specs Console. To export all the currently displayed specs appearing in the Spec Console, click the All checkbox.
1. To export a spec, simple check the box next to the spec in the Specs Console and click on the Export XML or Export XSD button. The Specs Export Results interface appears.
2. A system-generated name is given to the exported spec and is stored in the Docstore. A new window appears providing details of the spec export results.
Note: If exporting to file type XML, it is saved to the docstore. If the same file is exported to file type XSD, it will overwrite the previous XML file and replaces it with the XSD file.
3. Click on the export file name hyperlink in the "Spec Export Results" window to view the spec file details. View the last modified information, view content link, and the audit log for the exported file.
Figure 14.6 - Spec export results
4. Click the "this link to docstore" hyperlink to navigate to the Docstore directory where the file was saved.
Spec Maps are created to define how information from one source is going to route to another source. For example, a catalog spec, which defines the fields of a catalog, is mapped to a destination spec, which defines the fields of a destination. Therefore, when the catalog is exported using the Catalog spec to Destination Map, the information is routed in the proper structure.
The Mapping Console displays all of the previously created maps of the following types:
- Catalog Spec to Destination
- Catalog to Catalog
- Catalog to Destination Spec
- File Spec to Catalog
- File Spec to Catalog Spec
The following are the icons in the Mapping Console.
Delete mapping
Edit mapping
![]()
View mapping
Create a new mapping The following are the columns in the Mapping Console
Type
Type of mapping
Name
User defined name for the map
Source
The source spec used
Destination
The destination spec used
Accessing the Spec Map Console
To access the Specs Console, use the menu path
Data Model Manager > Specs/Mappings > Specs Maps > Spec Map Console.Creating Spec Map
All specs maps are created the same way. This section describes how to create a catalog to destination spec map.
The Catalog to Destination Spec map is similar to the File to Catalog Map in that it instructs WebSphere Product Center with how the fields in the catalog should be routed during an export. The fields in a catalog are mapped to the fields of a destination file. This mapping is used when defining an export of the catalog to a destination.
- From the Spec Map Console, select Catalog to Destination Spec from the drop-down field and click the New Map button. The Source to Destination Mapping wizard appears.
- Complete each step of the wizard driven GUI.
1. Select spec map type - This defaults to the type of spec selected from the Spec Map Console
2. Select Catalog Source - Select the catalog that is to be exported and click Select.
3. Select Destination Spec - Select the destination spec that is to be used and click Next, the Source Mapping table appears.
4. Enter name for the spec map in the Enter map name field.
5. Select a node from the Selected Source Attribute drop-down field and click +ADD to map it to a destination attribute.
6. To add an expression to the mapped attributes, click the expression button. The "Scriptlet Editor" interface appears.
7. When all spec nodes have been added, click Save.
The implementation of Attribution Collections increases the efficiency of data model management, performance and becomes very apparent when working with a large number of attributes (500+). Attribute Collections were introduced to simplify the management of large sets of attributes. Instead of working with an entire attribute group, it is possible to work on a functional subset of attributes.
The subset of attributes can be used to create views, tabs, workflows, inheritance rules, privileges, etc. Associating a subset is more efficient than associating individual attributes.
With the use of Attribute Collections, data is modeled in a more efficient and organized manner. Instead of managing a large amount of attributes for an item, managing them in subsets creates a more manageable dataset.
Attribute Collections were designed to improve performance when fetching and saving an item category where only the attribute selected for a view are retrieved and saved. Limiting the fetching and saving to the attributes in the view could cause issues by saving invalid items. Therefore, core attributes were introduced.
There are two types of core attributes:
- Default core attributes
- User define core attributes
When fetching and saving a record, the attributes included come from the default core attributes, the user defined core attributes and the superset of the attributes included in the single edit and multiple edit views
Default Core Attributes are system defined attributes that are retrieved and saved for every object and include only the attributes that are critical to making sure an item is not saved to the database in violation of key rules; this includes:
- The primary key
- The path attribute (for categories only)
- Any required attributes (either from a primary or a secondary spec)
For other attributes, it is not possible for the system to determine if they are needed or not. In some cases, some validation errors should run for every item, and therefore should be included in the core attributes. For this reason, user-defined core attributes can be added to the total set of core attributes. These attributes are included in an Attribute Collection. For each catalog and category tree, it is possible to associate an Attribute Collection as the user defined core attributes.
User Defined Core Attributes: attributes that are required when an attributes needs to be retrieved and saved for every object; these core attributes are defined per container and could include attributes that need to be validated or calculated every time an item or category is saved; one set of user defined core attributes will be associated per container. When creating user defined core attribute collections, include any required attributes located in secondary specs.
Note: It is recommended for the user defined core attributes to be kept at a minimum to achieve optimal performance. Therefore, remove any unnecessary attributes if they are not needed.
What is an Attribute Collection?
An attribute collection is a group of attributes that will be associated or behave the same way in a given context.
For example, a subset of attributes can be created for an electronic product catalog with an attribute set for features. This section can have multiple feature "types" (technical, marketing, etc.) Therefore, an attribute subset can be created for "technical" attributes and "marketing" attributes.
When defining an Attribute Collection, there are two types available for definition:
- General – used for a collection of attributes that are not associated with inherited attributes (i.e. views, tabs, workflow, etc.). Selecting this type allows the selection of primary or secondary spec attributes.
- Inheritance – used for a collection of attributes that are used to define inheritance rules. Selecting this type allows the selection of sub spec attributes only.
When defining an Attribute Collection, if it is known that the attributes will not be inherited, then select the type "General", otherwise select "Inheritance".
Note: For type "Inheritance", refer to the section "Attribute Collections for Inheritance Rules"
What is the difference between an attribute group, a spec and a subspec?
Subspec
Primary/Secondary Spec
Attribute Collections
A sub-spec is a collection of attributes that could be edited at different levels in the data model. Sub specs are used for inheritance purposes.
Primary specs and secondary specs are full or partial item or category templates. They define the object that will belong to it. They can be made of sub-spec attributes or individual attributes
Note: What was formerly known as hierarchy specs and catalog specs have been replaced by Primary Specs.
Attribute Collections are a group of specs and attributes that will behave the same way in all contexts
Where are attribute collections used?
When the association of an attribute is made to an Attribute Collection, the attribute is made available wherever the Attribute Collection is used. Attribute Collections are used to define the following:
- Access privileges
- Views
- Tabs
- Workflow steps
- Inheritance rules
When are attribute collections created?
An Attribute Collection is defined as a group of attributes that will be associated or behave the same way in a given context. Specifically, a new attribute collection is created to group attributes that share the same characteristics for the following purposes:
- Security – Create a collection of attributes that is used to setup Access Privileges, thus following the same security guidelines (i.e. create a group for all the merchandising attributes that should be edited only by the merchandising users)
- Function – Create a collection of attributes that will be edited or viewed together, as part of the same process, or step; these groups will be used to set up Views, Tabs and Workflow steps (for example, create a group for all the attributes needed for the creation of an item by a supplier in a supplier product introduction workflow)
- Behavior – Create a collection of attributes that inherit their content following the same path (for example, create a group for all marketing attributes that are used for a worldwide catalog and are inherited by a regional catalog)
What is the attribute picker?
The attribute picker is a portion of the attribute collection edit screen that is used to search and select specs and/or nodes to add to an attribute collection. It is planned for this feature to be used in other areas of the application in a future release.
What changes have been made to the GUI to support Attribute Groups?
Several changes were made to the GUI to support Attribute groups and are identified in the following sections.
Attribute Collections are organized in a typical WebSphere Product Center Console format, thus the following standard characteristics apply:
- Console displays Attribute Collection names and descriptions
- Sort names and descriptions by clicking on the column headings
- Console paginates when more than twenty groups exist
- Configure Console to sort and hide columns
- Available buttons to Add, Delete, or Edit an Attribute Collection
- Attribute Collection names are hyperlinked, click to edit a collection
- Click on the checkbox next to an Attribute Collection to delete, then click the Delete button
- Attribute Collections cannot be deleted if the group is associated with a view, a tab, an access privilege, an inheritance rule, or workflow. If this is the case, deletion is not permitted and if attempted, a pop up message indicates where the group is associated
Attribute Collection Console
The Attribute Collection Console is accessed using the menu bar options:
- Console: Data Model Manager > Attribute Collections > Attribute Collection Console
- Create New Attribute Collection: Data Model Manager > Attribute Collections > New Attribute Collection
Attribute Collection Screen
The attribute screen is used to create a new attribute collection or edit an existing one. The screen is segmented into three parts:
- Attribute Collection – Enter Attribute Collection information, display specs and attributes that are associated to the attribute collection
- Attribute Picker - Search for specs or attributes
- Results – View the search results for specs or attributes and make selection for attribute collection
Attribute Collection Information
- Each Attribute Collection requires a name. This can be modified at any time
- A description is optional and can have up to 2000 characters
- Locales can be selected for the given collection; if needed, locales can be added/removed after the collection has been set-up. The implication of selecting a locale means that any localized attributes added to the spec already in the collection will be part of the collection only if they belong to the selected locale.
- The attribute collection type can be either "Inheritance" or "General"
- When creating an attribute collection, click Save in order to display the bottom portion of the screen that allows for searching and adding individual specs, individual attributes or localized node parents. Adding a spec will not add the individual attributes of a spec, rather all the attributes in the spec at the moment the group is called upon will be considered part of the group. Adding individual attributes creates a static list of attributes. It is also possible to add a grouping node when a node is localized.
Attribute Associations to Attribute Collections
View Attribute Collection Association
- To view the Attribute Group(s) that an attribute is associated with, click on the icon next to "Attribute Collection Associations" from the attribute's Detail screen. The "Attribute Collection Associations" screen is displayed.
- Click to view Attribute Group association
- Attribute Collection association screen
- Edit Attribute Collection Associations
- Removing attributes or specs from an attribute collection is performed in the Attribute ollection definition screen.
Note: Generated Default Core Attributes cannot be edited, as they are system generated.
Attribute Picker
The Attribute Picker screen is new to 4.2 and is used to define attribute collections. In future releases, it is planned for this feature to be used throughout the application to select attributes.
- Specs are displayed alphabetically
- Attributes are presented in the order they were setup in the spec
Searching for an Attribute
The search feature in the Attribute Picker was designed to reduce the need to browse through longs lists of attributes. Several search methods are available to the user and are located in the Search section of the Attribute Picker. All results are displayed at the bottom of the screen.
Search by field A user can search using one of the two following fields:
- A Spec Name field where a portion of a spec name can be entered
- An Attribute Path field where a portion of an attribute name can be entered
Search Type
- Specs and Attributes - Display results of Specs and Attributes
- Specs Only – Display results of Specs
Search by Spec Type Select a Spec Type to search for
- Search by Locale(s)
- Select to search by Locale
Results:
The results will either present specs only or specs and attributes depending on the option selected
A locale selection list presents a list of the locales for this company where multiple locales can be selected
A file spec list that allows selecting one or multiple attributes; the list of spec type will be filtered depending on the context (for example, to create a group of type inheritance, the only spec type available should be "subspec")
When a locale is selected and the Spec Only option is selected, the specs that are listed are the spec that have that locale associated with the spec, regardless of whether there are any nodes localized or not
When a locale is selected and the spec and attribute option is selected, the specs that are listed are the specs that have that locale associated with the spec and have localized nodes for the selected locales
The list displays up to 50-100 results per page, with the ability to navigate back and forth between pages. For each page, up to 20-50 attributes are displayed, with a scroll bar to view the rest of them. Going from one page to the next will lose selected attributes. The list will present a list of specs, leaf nodes and localized nodes. Localized node should have a special indication next to them.
Selecting Specs and Attributes
After a search is performed for a spec and/or attribute, the results are displayed in the results section of the Attribute Picker. Select from the list of results and click Selected, or just click All to select the complete list of results. It is possible to also right click on the spec and select "Add Spec" from the short menu.
Localized parent nodes can be selected for an attribute collection.
This section describes how to associate an Attribute Collection to Catalog Access Privileges and Views
Access Privilege Setup
- Previously, access privileges were setup by selecting individual attributes., simply select an Attribute Collection
- Use the search field if there exists a large list of Attribute Collections
- Only Attribute Collections of type "General" is available for selection for access privileges
Setting up Views
Similar to catalog access privileges, Views are created by selecting Attribute Collections, rather than individual attributes. The following are general characteristics of creating views:
- Attributes Groups are ordered, which determine the order in which the specs are displayed.
- The order of the attributes is dependent on their order in the Primary or Secondary Spec to which they belong
Note: Only Attribute Collections of type "General" are available for selection.
Tab Views
Previously, it was necessary to select individual attributes to create Tab Views. This can be can be a huge task when working with items with many attributes. With the introduction of Attribute Collections, the user simply selects from a list of attribute collections to create a Tab View. Any changes to the Attribute Collection will be reflected in the Tab View.
Note: If changes were made to an Attribute Collection, it is necessary to log out and log back in for the changes to take effect in the Tab Views.
If an entire Attribute Collection is not needed, it is possible to select individual attributes as needed.
WebSphere Product Center's Scripting Engine allows for extremely sophisticated data manipulations during the import or export of information to and from WebSphere Product Center. With this added flexibility to your product information management capabilities, users can do the following:
- Apply business rules to standardize data
- Define calculated fields
- Run custom reports
- Perform rules-based cleansing of data
- Create validation rules
Using the Scripts Console, users can view, create, and edit scripts of the following types:
Catalog Differences Export The Catalog Differences Export script allows the update of product information to an external destination. The script does not provide a full update, but only the changes that have been made since the last version of the catalog.
For example, if the images for a line of products have changed, these changes can be updated without having to update the entire catalog.
Catalog Export Catalog Export scripts are used during syndication. They can be used to perform advanced on-the-fly operations on the data held in the catalog before it is actually exported to an output file. The modifications made to the content through the scripting engine at the time of syndication are not applied to the catalog but rather simply applied to the output file, as a one-time content modification.
Similar to aggregation, the syndication to an external target file can take two forms: either the fields in the catalog map on a one-to-one basis to the external target file, or the fields in the catalog require some modifications before they are exported into the external target file.
All syndications require the use of a script. Contrary to aggregation, selecting a script during syndication is a mandatory step.
Catalog Import Catalog Import scripts are used during aggregation and can be used to perform advanced operations on incoming data before it is imported into a catalog. Simple scripts are generated from WebSphere Product Center, with no customization, but can be user specific with as many modifications as necessary.
The aggregation of an external file is taken in one of two types:
- Mapped on a one-to-one basis to the fields of a catalog
- Modifications performed before being imported into a catalog
Catalog Preview Script A Catalog Preview script is used to create a user-defined preview of a catalog. The script defines how the catalog is displayed. Catalog Script A Catalog script is a sequence of operations that a user specifies to be run at the time of item creation and edit. This function provides another layer of functionality over the attribute level operations available via catalog specs. Catalog to catalog export script A Catalog-to-Catalog Export script allows the automation of an export where information from one catalog is exported into another catalog. Custom tools Create a script to work with custom tools. Functions related to the custom tools can be created. Distribution script Distributions scripts are used to create a custom distribution that is not addressed by the built-in WebSphere Product Center distributions (i.e. Ariba Catalog Upload, FTP, HTTP POST and email.)
Entry build script The Entry Build script allows a user to execute a script within the data entry screens. For example, a script could be written to replace all strings with a certain value. Entry Macro script The Entry Macro script allows a user to execute a script within the data entry screens. For example, a script could be written to replace all strings with a certain value.
Entry Preview script The entry preview script allows a user to create a sample view of a current item set, which can be executed from the data entry screens. For example, a script could be written to view how an item would display using an XML format.
Hierarchy Import script This function is used during aggregation. Although a user can create a hierarchy manually, the Hierarchy Import script allows the building of a full hierarchy out of an incoming flat file.
Hierarchy script The Hierarchy Script allows a user to build a hierarchy without having to manually create one.
Images and Binary Files Differences Export script Images and Binary Files Export script take catalog images or binary type files and exports them through syndication. With the Images and Binary Files Differences Export script, a user can export changes that have been made from a previous catalog version.
Images and Binary Files Export script Images and Binary Files Export script take catalog images or binary type files and exports them through syndication. In most cases, images and binary files are handled differently; therefore the scripts allow these types of files to be exported based on the external systems requirement.
Lookup Table Import script Lookup table scripts are very similar to aggregation scripts in that they are used to parse an incoming text file. When triggered through the lookup table interface, they are used to populate the contents of a lookup table instead of a catalog.
Order export script Create a script to execute order distributions. Order import script Create a script to execute order imports. Order status update import script Used to create a status update on order imports. Queue message processor Create scripts to process queue messages created in Websphere Product Center Report script Report scripts are used to create custom reports. When creating a report in WebSphere Product Center, a script is needed to define the report output. The report script is used to define how the information is ordered and formatted.
Secure Trigger script Similar to a regular trigger script with additional security. Trigger script Trigger scripts are created to avoid the need to populate the same script operations in multiple places. The scripts are stored in the Document Store and can be called from another script function.
Used to externally trigger events, i.e. import, exports, etc., in WebSphere Product Center.
Web Service Implementation script Create a script to implement web services Workflow step This script is used to automatically create workflow steps, which can then be viewed using the Workflow Console.
Creating New Scripts
To create new scripts do the following:
1. Click Data Model Manager > Scripting > Scripts Console. The Scripts Console appears with a user-friendly navigation bar.
2. From the navigation bar, select a type of script to create. The script console appears with a list of associated scripts. For example, if "Catalog Export Scripts" was selected, a list of created catalog export scripts appears, if any.
3. To create a new script of the selected type, click the New button, from the Scripts Console interface. A wizard-driven GUI appears.
4. Follow each step of the wizard. In step four, the script editor appears. This is where script is created.
5. When the script is complete, click the Save at the bottom of the screen.
The Script Sandbox provides an expression builder with a library of available script operations with a prototype and description (The Prototypes and Description fields do not appear until "Script Operations" is selected.
Users can create sample scripts, which can then be run and tested to see if the results are valid. Click "Run Script" to compile and return an expected value or error, which is viewable to the user. This is a great way to test a script before it is implemented.
The security menu selection is located under the Data Model Manager. It includes the following menu selections.
- User Console
- Role Console
- Company Attributes
- Access Control Group
- Access Privileges
- Activity Logs
The management of users within WebSphere Product Center is controlled through a set of roles that are created through the Administer Roles component of the Security module.
Rule: Privileges are not set to the individual, rather to the role that they are assigned to. If a user is assigned to multiple roles, they inherit the privileges from each role.
Customized roles can be created (i.e. content reviewer, content approver, catalog manager) with permissions to specific WebSphere Product Center functionalities and/or objects. Thus, to apply the privileges for a customized role, assign a user to the role.
Use WebSphere Product Center's Access Control Groups (ACGs) to set the permissions in accordance with which user(s) can view/edit specific catalogs. Assign a user to one or multiple ACG's, depending on the user's responsibilities. If needed, group various roles to a single object.
Additional control for catalog access is available through the Catalog Access Privilege Console. A set of privileges can be set for which roles can view/edit specific columns in a catalog.
Roles are created to control a user's privileges to catalog management. Privileges are not set to the individual, rather to the role that they are assigned to. The objective of creating an ACG helps to control user's privileges, but is created to group a set of users to a single object.
Note: Objects cannot be mapped to more than one ACG.
Access control privileges are used as follows:
- Each role can contain multiple users
- A user can belong to multiple roles
- Each access control group contains a number of objects (in this case catalogs)
- A catalog can only belong to one Access control group
John has spent the time creating a set of users and catalogs. Now he would like to specify which catalogs each user can access and define their privileges through the use of roles and ACGs.
Assuming that the users and catalogs have already been created and the catalogs have not been assigned to an ACG, the following sections will step through the following tasks:
- Create a New Role
- Create a New Access Control Group
- Assign an ACG to an Object (Catalog)
- Assign User to a Role
Create a New Role
1. Use the menu path: Data Model Manager > Security> Role Console. The Role Console table appears.
2. Click New and enter a Role Name and Role Description, which are required fields.
3. For the Access Control Group, select 'Default'.
4. Select a set of privileges for this role. (Note: The privileges that a role can have for a specific access control group are defined later; they will be a subset of the privileges given here.)
5. Click Save (top of screen).
Summary
After saving the new role, it appears in the Role Console table, see figure below. Notice that the Assigned to column contains the number of users assigned to the role.
Note: When managing users, each user must be assigned to at least one role in their User Profile.
Create a New Access Control Group
1. Use the menu path: Data Model Manager > Security > Access Control Groups > Access Control Group Console and click New.
2. Enter a Name and Description for the new ACG.
3. Select a role from the drop-down menu.
4. Select the set of privileges for the role selected. (Note: These privileges are to control what the user can do.)
5. Click Save.
Assign ACG to an Object
The following will apply an ACG to a catalog.
1. Use the menu path: Data Model Manager > Security>Access Control Groups>Object to Access Control Group Map. A wizard-driven GUI appears.
2. Select the object type "Catalog." Select a catalog from the Select Object drop-down list.
3. Select an ACG. This will assign the catalog to the control group.
Summary
At this point, roles have been created and grouped into different ACGs, which have been mapped to a catalog. Now that all of the privileges have been set, users can be assigned to any role and all privileges to the selected role applies.
Assign Users to a Role
1. Use the menu path: Data Model Manager > Security >User Console. The Current Users table appears.
2. Click on a user hyperlink to view the user's profile. From the Roles for current user table, select all roles assigned to the user.
3. Click Modify Role Info.
Summary
The privileges given to the user are determined by the role they have been assigned to and to the Access Control Group the role belongs to.
Creating User
Before a user is created, at least one role must exist in the application.
1. From the left pane, select an Organization Hierarchy. Right-click on the name of the organization and select Add user from the short menu. The New User screen appears.
2. Enter the required details in the User Profile interface.
3. Enter the password for the user.
4. Assign a role(s) to the user. Multiple roles can be selected based on responsibility.
5. Once all the information needed is entered, click Save to store the information.
6. The last step is to enable the user in the system. New users always default to Disabled.
Enable User
When a new user is created, they are disabled. To allow the new user to access the application, they must be enabled.
From menu Data Model Manager > Security > User Console, click on the Disabled button. The button changes to Enabled.
Access Control Groups - Use WebSphere Product Center's Access Control Groups (ACGs) to set the permissions in accordance with which user(s) can view/edit specific catalogs. Create an access group and assign access privileges to each role in the ACG. Map the ACG to an object. Then, assign a user to one or multiple roles, depending on the user's responsibilities.
ACGs can be applied to the following:
- Catalogs
- Collaboration areas
- Hierarchies
- Selections
- Workflows
Privileges can be placed on various objects by creating rules that restrict access to a group of roles. The rules are enforced to all users assigned to the roles.
The wizards used to create catalogs and hierarchies require an association with an ACG. This is true with other objects created in WebSphere Product Center. The following objects listed in the table below require an association with an ACG. The right column describes how an ACG is mapped to the object.
Object
How ACG is associated
Catalogs
Data Model Manager > Security > Access Privileges > Catalog Access Console
Or
Data Model Manager > Security > Access Control Groups > Object to Access Control Group Map
Collaboration Areas
Associate ACG during the creation of a collaboration area
Hierarchy
Data Model Manager > Security > Access Privileges > Hierarchy Access Console
Or
Data Model Manager > Security > Access Control Groups > Object to Access Control Group Map
Selections
Associate ACG when creating a selection
Workflows
Associate ACG during the creation of a workflow
Example: Associate ACG with Catalog
In order to enforce access control to a catalog, the catalog must be mapped to an ACG, which is done during the creation of a catalog.
1. Use the menu path, Product Manager > Catalogs > Catalog Console, to display the Catalog Console.
2. Click New to create a new catalog.
3. For the "Select Access Control Group" step, create and ACG or select an existing ACG.
Example – Apply Access Control for Selections
The ability to control a user's access to view selections, edit selection rules, and deleting selections can be restricted based on the access privilege definition of the role that is assigned to the user. In order to restrict access to a selection, the role defined with restricted access privileges must be associated with the ACG that the Item Selection is using.
Therefore, a single selection can be made available to a specific ACG and all roles that are part of the ACG will have access to the Item Selection. A user is allowed access to the Item Selection once they are assigned to the role.
Troubleshooting
If the user cannot view item selection that is defined by the ACG, check the following:
- Make sure the user has been enabled
- Check to make sure the user has been assigned to the proper role
- Check the access privileges for the role have been properly defined as described in the step "Create New Role".
- Check to see if the user belongs to an ACG that allows access to the specific catalog. A user can be setup for access to an items selection, but with no access to the catalog, the user will not see any information.
Creating a new role and assign to ACG
For each role, there are three areas of security that can be implemented:
- Group Access – restrict access to the role for each associated ACG
- System-wide Access – restrict access to various application features
- Locale Access – restrict access to one or more available locales
When setting group specific access for a role, it is recommended to select access for the ACG "Default". ACG – Default is created by default and when no custom ACG is selected for an object it uses the ACG "Default". All objects that can be associated to an ACG require that an ACG is associated with the object. Therefore, it is important to create a set of group access privileges for the role.
1. Use the menu path Data Model Manager> Security > Role Console, the "Role Console" dialog appears.
2. Click New and enter a name and description for the Role. For this exercise, use the name "Basic View".
3. From the Group specific access for role table, select the group access for each Access Control Group.
Note: These changes are also updated in the ACG Console.
4. Click Save to commit settings. A message appears indicating a successful role creation.
5. Scroll down to the "System-wide access for role" table; click the "Edit Screens" hyperlink to access the Edit Screen Access page.
6. Select the screens that are to be made available to the role. The following screens must be selected as a bare minimum requirement:
- View WebSphere Product Center Main' screen
- View ' WebSphere Product Center' screen
- View 'Catalog Navigation Pane' screen
- View 'My Home' screen
- View 'Collaboration Area Console' screen
7. Click Modify to commit settings.
Creating Access Control Groups
ACG's are mapped various objects, which then enforces a set of security rules defined in the group's roles. Objects required that an ACG be selected and if a customized ACG is not desired, select the ACG "Default".
1. Use the menu path Data Model Manager > Security > Access Control Groups> Access Control Group Console, the ACG console appears.
2. Click New and enter a Name and Description for the ACG. For this exercise, the ACG is named "E".
3. Select any Role from the drop-down list. A new role will be created in the next section, which will be added to the ACG.
4. In the Access Control Group table, select the following checkboxes:
- Catalog – List
- Catalog – View
- Catalog – Search
- Selection – List
5. Click Save to create the new ACG.
To enforce the access control rules that have been set up for an ACG, the user must be assigned to a role member of the ACG.
Assigning a role to a user
Once a user and role have been created, use the User Console to assign a role to a user.
1. Use the menu path Data Model Manager > Security > User Console; the Current Users table appears.
2. Click on a user name
3. Scroll down to the Roles for Current User table and select the role "Basic View", which was previously created.
4. Click Modify Role Info to commit the new user profile.
Note: Any user assigned to the Basic View role will have view only access to Items selection created in the next section.
Setting Access Privileges are an extension of the security rules defined for ACG's. Using WebSphere Product Center's Catalog Access Privileges Console, users have the ability to restrict associated attribute collections of a catalog to one or multiple role members.
For example, when defining the access privileges for a catalog, it is possible to enforce View and/or Edit privileges for an attribute collection of a catalog, therefore providing complete control of which catalog attributes a role can view or edit. If locales have been implanted, it is possible to restrict attributes based on the available locales.
Setting Catalog Access Privileges
A role can be restricted to any catalog based on a set of defined privileges that are configured in the Catalog Access Privilege Console. Users assigned to the role will be restricted to the catalog access privileges.
Create rules to allow a role to enforce viewable and/or editable privileges to any catalog. Privileges will need to be defined for each role that needs access to the catalog.
1. From the menu path Data Model Manager > Security > Access Privileges > Catalog Access Console, click the New button next to the name of the catalog from which access privileges will be created. The Catalog Access Privileges wizard appears.
2. Select a Role from the drop-down field. Only roles that are members of the ACG tied to the selected catalog are displayed.
3. From the Catalog Access Privileges Editor, select the attribute collections as viewable or editable.
Note: A "V" appears next to the attribute denoting view privileges. A "V+E" denotes view and edit privileges.
4. To remove a rule, click on an attribute collection from the Selected box and click Remove.
5. When all of the privileges have been defined, click Save. A message indicates the privileges were successfully saved.
6. If desired, create privileges for all associated roles. Each role that has been defined with privileges appears in the Catalog Access Privileges Console.
7. To edit the privileges for a role, click on Edit icon from the Catalog Access Privileges Console, make the changes in the editor, and click Save.
Removing Catalog Access Privileges
To remove all catalog access privileges for a role, do the following:
1. From the Catalog Access Privileges Console, click the edit button to edit the role.
2. Highlight all of the attributes from the Selected Attributes box and click Remove.
3. Click Save. Return to the Catalog Access Privileges Console and attribute collection is removed.
Restrict access privileges for roles, which apply to any user assigned to the particular role. Changes made in the Edit Role Access screen are reflected in the associated Access Control Group Details and System-wide Access pages.
Editing role access
1. To edit role access, use the menu path Data Model Manager > Security > Roles Console. The "Roles Console" table appears with a list of roles that have been created.
2. Select a role to edit and the Edit Role Access page displays. Each Access Control Group that is associated to the role is displayed in separate columns.
3. Select specific access privileges for each Access Control Group. In the table "System-wide access for role" click on the Edit Screens link to restrict access to specific application screens.
Note: Refer to the table below for role access descriptions.
Group specific access for role
Catalog
list
Allows display of catalogs in Catalog Console and in lists throughout WebSphere Product Center.
If not selected, the Catalog Console states "No catalogs found."
edit catalog views
Allows creating, deleting, and editing of catalog views
view items
Allows view only access to catalog items
add items
Allows new items to be created. If not selected, all buttons and short menus used to add items are disabled
modify items
Allows items to be modified
* Note: If unselected, "add items" and "recategorize items" must be unselected
delete items
Allows the deletion of items. If not selected, the DELETE button in the Item Edit Screen is disabled
recategorize items
Allows the recategorization of items in catalogs.
If not selected, the Categorize button in the Item Edit screen is disabled
summary items
Not functional. Will be removed in future release
export
Allows the export of a catalog items or item-category attribute values from a catalog
attributes
Allows access to the attributes page via the Attributes button in the Catalog Console
differences
Allows the display of differences between catalogs
rollback
Allows the rollback of a catalog
search
Allows a basic or rich search on a catalog
delete
Allows the deletion of a catalog from the Catalog Console
run preview script
Allows running a preview script for an item (i.e. Item HTML Preview, Item Tab Delimited Preview)
Hierarchy
list
Allows display of hierarchies in Hierarchy Console and in lists throughout WebSphere Product Center
If not selected, the Hierarchy Console states "No hierarchies found."
edit hierarchy views
Allows creating, deleting, and editing of category views
view hierarchy nodes
Allows view only access to hierarchies
* Note: If unselected, "add categories", "modify category names", and "modify category attributes" must also be unselected.
add hierarchy nodes
Allows new categories to be created
modify hierarchy node attributes
Allows modification to hierarchy node attributes
* Note: If unselected, the "add categories" must also be unselected
delete hierarchy nodes
Allows the deletions of categories
recategorize hierarchy nodes
Allows the recategorization of categories
summary hierarchy nodes
Not functional. Will be removed in future release
specmap hierarchy nodes
Allow
attributes
Allows the view of hierarchy attributes
rollback
Allows the rollback of a hierarchy
delete
Allows the deletion of a hierarchy
Selection
list
Allows the display of selections in the Selection Console
edit rule
Allows the creation of rules applied to a selection
delete
Allows the deletion of a selection
Import
list
Allows the display of imports in the Import Console
perform import
Allows the initiation of importing catalog items or item-category attribute values into a catalog
delete
Allows the deletion of an import
SelectionMembers
View items
View item selections
add items
Add items to selection
modify items
Modify items in a selection
delete items
Delete items in a selection
recategorize items
Recategorize items in a selection
view hierarchy nodes
View hierarchy node in selection
add hierarchy nodes
Add hierarchy node in selection
modify hierarchy node attributes
Change hierarchy node attribute in selection
delete hierarchy nodes
Delete hierarchy node in selection
recategorize hierarchy nodes
Recategorize hierarchy node in selection
specmap hierarchy nodes
Create specmap hierarchy nodes in selection
DocStore
view files
View files in the docstore
delete files
Delete files in the docstore
PurchaseOrderExport
list
Allows the display of purchase order exports in the PO Export Console
export
Allows the initiation of a purchase order export
delete
Allows the deletion of a purchase order export
Workflow
list
Allows the display of workflows in the Workflow Console
edit
Allows workflow to be edited
delete
Allows the deletion of a workflow
CollaborationArea
list
checkout entries
Allows entries to be checked out in the Collaboration Console
System-wide access for role
Spec
modify spec
Allows modification of any spec
modify spec map
Allows modification of any spec mapping
Screen
Edit Screens
(click to edit screen access privileges)view
Allows access to the screens selected in the "Edit Screens" above. If this box is not checked, the list of selected screens is not available to the role.
Script
create modify scripts
Allows the creation of scripts. When this is not selected, the New button in the "Scripts Console" does not appear
Scheduler
view company jobs
Allows display of jobs in the Jobs Console
Security
modify users
Allows creating, deleting, editing of users
modify roles access
Allows creating, deleting, and editing of roles
"Local access for role" is used to select from a list of available locales for a role.
Locale access for role
Available Locales
List of available locales that have been setup in "Administer Company Attributes"
Selected Locales
List of selected locales that have been made available for the role
It is possible to restrict a role to specific WebSphere Product Center screens. In the System-Wide Access table, click on the Edit Screens hyperlink and the Role Info table appears with a hierarchical list of screens.
Each listed screen can be restricted to a role by leaving the checkbox next to the screen name empty. Thus, a checked box allows access to the screen. When all restrictions to screens have been made, click Modify to update the changes.
Minimum Requirement Settings
Although the behavior of the Edit Screens is fairly straight forward, there are a few special cases to note and are described in the following sections.
A user's home page is made up of various screens; therefore access to each screen must be provided. The following settings are the minimum requirements for a user to login and view the home page.
- View WebSphere Product Center Main' screen
- View WebSphere Product Center screen
- View 'Catalog Navigation Pane' screen
- View 'My Home' screen
- View 'Collaboration Console' screen
With the access privileges to the above screens, the user home page displays the WebSphere Product Center Main, Navigation Pane, and the Collaboration Console.
If one of the above screen permissions is unchecked, instead of getting the Collaboration Console you will get the error message "You do not have the privilege to access this page".
The following sections define each of the screen settings in the Role Info table.
The activities performed by users can be monitored through WebSphere Product Center's Activity Logs. Monitor which pages the user has visited, which catalogs have been edited, and have an instance of an activity notify another user via email. When a new user is created, they are automatically added to the list of the users in the Activity Log.
Configure Activity Log
1. Use the menu path: Data Model Manager > Security > Activity Logs > Activity Log.
2. Monitor a user's activity, have activities notified, or track deletion activities by clicking on the appropriate box selection.
3. To receive an update via email, click the Update Notification Email check box and enter an email address.
4. When all activities have been configured, click Update.
View User Activity
From the Users Monitored table, select Sessions, Log, or Summary to view current activities for a user.
- The Sessions link provides a list of pages visited by the user.
- The Logs link displays a log of pages visited by a user.
- The Summary link displays an overview of the number of times the user has visited a page.
Notify Users
From the Activity Log screen, a message can be created and sent to all users or only to those users currently logged in to the application The Users Monitored table displays all current users. The message is sent to the email address defined in the user's profile or the notification email defined in the Users Monitored table. This email can be different than the one defined in the user's profile.
Send a Message to Users
1. Scroll to the end of the Activity Log screen. Enter a message in the Notify Users table.
2. Select to send the message to all users listed in the Activity Log box or only to the users who are currently logged on.
3. Click Send and the message is sent to each user's email address.
The alerts functionality is in essence WebSphere Product Center's messaging system. Alerts can be tied to any type of event and can be used to notify specific users or group of users that a specific event has occurred.
Events include a successful export job to a problem during an import job. WebSphere Product Center supports a number of different alerts that accommodate a wide variety of events.
The Alert Console is the area where all alerts are managed in WebSphere Product Center. From this screen, it is possible to subscribe to alerts and browse through alerts that have been triggered. It is also where alerts can be configured and users can be associated to specific alerts.
The Alert Console is broken down into multiple sections that correspond to the various functional areas of the application. The alerts can also be monitored from the Alerts display in the left quick access bar.Accessing the Alerts Console
Use the menu path: Data Model Manager > Alerts > Alerts Console.
Figure 18. 1 - Alerts subscription console
Figure 18. 2 - Alerts displayed in the Left Pane
Displaying alert activities
The Alerts Subscription Console displays a user's subscribed alerts. To display all alert activities, use the menu path Data Model Manager > Alerts > Alerts Display. A table appears "Current Results" that show all of the alerts that have triggered.
Subscribing to an alert
Alerts can be individually set up for each user through the Alerts Subscription Console.
Use the menu path: Data Model Manager > Alerts > Alerts Console.
1. Select Event Group
Available event groups available correspond to the functional areas of the application, including:
- Util
- Import
- Export
- Product Manager
- Workflow
Select an event group and click +ADD and the "Add A New alert Subscription" wizard appears.
2. Select Event Type
An event type defines the precise nature of the alert to be configured. The list of event types is dependent upon the group selected in the first step.
3. Select Event Conditions
Specify additional parameters that trigger an alert under very specific circumstances. This step can be skipped if no parameters are necessary
4. Alert Description
Provide a description for the alert that will make it easy to locate when reviewing a long list of pre-configured alerts.
5. Select Distribution
Click the question mark button and select a distribution group that is to be notified when the alert is triggered or click New to create a new distribution group. Click Select to go to the next step.
Note: The user setting up the alert is automatically subscribed for the alert, and therefore a user who selects their own name from the user list while subscribing to an alert will get the alert twice!
6. Select Users
Instead of selecting a distribution group, select the user(s) that is to be alerted when the event occurs.
Once the alert subscription wizard is completed, alerts can be viewed from the Alerts Subscription Console.
Note: Alerts can be viewed from the Left Pane if it has been added.
Viewing alerts results
Alert results can be viewed from one of three areas:
1) Alerts Console - Click on the alert name to view results
Figure 18.3 - View alert results from the Alerts Console
2) Left Pane - click on the alert number in the Left Pane and the results appear in the right pane
Figure 18.4 - View results from the Left Pane
3) My Task List - From the Alerts Module, click on the Alert Description name to view results.
Figure 18.5 - View results from My Task List
Business processes are supported and enforced through the use of a staging area. For example, Product Managers can launch data changes on an item level into a temporary staging area, identify jobs that would ask for manager approvals with alerts that will notify pertinent parties, which then can be rolled back granularly if rejected, and that will automatically trigger a differences report for managers and monitors.
When a staging area is created, nothing appears in the Staging Area Console. When creating an Export using the "Create Staging" wizard, Step 9 selects a distribution. This is where the Staging Area is selected and when the export runs, it sends it to the selected staging area and appears in the Staging Area Console.
Creating a staging area
To create a staging area, do the following:
1. Use the menu path Data Model Manager > Staging Area > Staging Area Console, to display the Staging Area Console and then click Create new Staging Area. The Create Staging Area wizard appears.
2. Enter a name for the new staging area and click Next. A message box appears notifying of a successful creation.
Figure 19. 1 - Selecting a staging area for exports
Viewing staging area details
As files are added to the staging area, they are listed in the Staging Area Console.
1. Click on the name of the staging area to view all of its associated files in the Docstore.
2. Click on the generated document name to view its contents.
3. Click on the view button to display the audit log for the document.
Figure 19. 2 - Staging area console
The PIM process can be managed through the definition of a workflow. The Workflow Console is used to create a workflow process, containing multiple instances that are viewable through the definition display.
A workflow instance can be created to appear in the Workflow Console and based on the status, an alert can be sent to notify that an approval is needed before it is escalated to the next step in the workflow.
This chapter summarizes the Workflow feature using the following key questions:
- What is a WebSphere Product Center workflow?
- How is a workflow setup?
- How does data move through workflow steps?
- What is the available task list/status functionality?
- What is the available workflow reporting functionality?
Each question is provided with a high-level response and is provided with a more thorough discussion in the Workflow Technical Details section.
What is a WebSphere Product Center workflow?
A WebSphere Product Center workflow implements a business process in either the Product Center application or a separate WebSphere Product Center application. WebSphere Product Center's workflow component offers a set of screens to setup task lists/status screens, and reporting functionality.
Example business processes:
Within the WebSphere Product Center core application:
- Add item
- Modify item
Within a WebSphere Product Center Item Synchronization application:
- UCCNet Item Add
Within a WebSphere Product Center Supplier Self Service application:
- Supplier file submittal
How is a workflow set up?
A Business Process Analyst uses the UI screens to build a series of steps corresponding to a specific business process. Although it is possible to configure most steps without any scripting, further workflow definitions can be performed using scripting for any workflow step.
There are a variety of predefined step types for each workflow step including:
- Modify
- And Approval
- Or Approval
- Automated
- General
Based on the step type, it is possible to setup parameters for the step. These available parameters include
- The roles or users with access to the step
- The editable attributes in the step
- The exit values for the step (including escalation)
- The email notifications at the step
- The timeout for the step
- The script for the step
If needed, a nested workflow can be defined by having a step feed another workflow, or a step can accept data from another workflow. A step can also call out to external systems via HTTP, MQ, JMS, FTP, or SMTP.
How does data move through the workflow steps?
Catalog or hierarchy attribute values move through the workflow steps in a collaboration area. A collaboration area is a "mini-catalog" that supports regular catalog/hierarchy functionality - including content authoring screens, views, spec validation rules, and scripts.
Note: WebSphere Product Center Workflows currently only support handling catalog and hierarchy attribute values, not handling specifications for attributes.
Insert data into a collaboration area via either "checking-out" an existing attribute value from a main catalog/hierarchy, or via importing new values into a collaboration area.
For example, a user may checkout one attribute of an item into a collaboration area in one workflow (e.g.: English short description), while checking out another attribute of the same item into a different collaboration area in another workflow (e.g.: French short description).
A checked-out attribute is available as read-only in the main catalog. There is a lock symbol on the item in the Catalog or Hierarchy Multiple Edit screen to indicate that an attribute of the item is checked-out. As a read-only attribute, the attribute can be viewed or exported from the main catalog/hierarchy but not modified. Only the parties with access rights to the modification steps in the collaboration area containing a checked-out attribute can modify a checked-out attribute.
Note: It is possible to setup a main catalog/hierarchy as fully read-only, while forcing all attribute value changes to be made in workflows.
If the Add Items box in any step is checked, it is feasible to import new items into the collaboration area at that workflow step. All items imported into a collaboration area are validated by the same import validation as for an import into a main catalog/hierarchy. It is not possible to save invalid records into a collaboration area, as it is not feasible to save invalid records into a main catalog.
After a set of items completes its transit through the workflow, it is possible to "check-in" new or modified records into a main catalog/hierarchy. It is also possible for a user to drop an item + attribute from a collaboration area at any time (where dropping an item releases the item + attribute in the main catalog for editing). After all records in the collaboration area complete their passage through the workflow, it is possible to set a property of the collaboration area to automatically delete an empty collaboration area. An administrator can also manually delete an empty collaboration area. The system retains the history of a deleted collaboration area for reporting.
What is the available task list/status functionality?
The workflow includes a standard collaboration console that pictorially represents the status of data in each collaboration area in each workflow step.
A business process analyst can supplement the standard collaboration console with custom scripted screens generated by the Invoker.
The collaboration console/task list is available for any user in their default Home Page. If a user has access to any step in a workflow, the user will have access to the collaboration console for that workflow. The collaboration console indicates the number of items at any step in the workflow. The user can directly interact with items in green by clicking on the green number at any step. The user can see the number of items at any step with a red number, but cannot interact with the items in that step.
As well as maintaining the status of a collaboration area, the system supports an item history for each item in the collaboration area. A user in the collaboration area can click on an item to see the changes to the item at each workflow step, approvals/rejections, and user comments.
What is the available workflow reporting functionality?
The workflow includes an extensive audit trail. It stores every attribute change at each workflow step for each collaboration area in the database. With the provided script operations it is possible to build extensive attribute-level lifecycle reports. Example reports are -
- Time to Shelf Report - showing the time for newly introduced products to move from receipt to syndication into external systems
- Cost per Managed SKU Report - measuring the time and number of resources required to move product from receipt to delivery
- Price Change Report - indicating all price changes at each workflow step with each user's name, datetime of change, and comments
- User Throughput Report - showing the number of items processed by each user over time at each workflow step
- Approval Chain Report - presenting all approvals within a given workflow
- Current User Status Report - showing a snapshot of the number of items at each workflow step for a given user
- Escalation Report - indicating all items that were escalated by timeout during a time period
The following sections summarize the technical details for WebSphere Product Center Workflows:
- Workflow Setup Steps
- Data Movement and Task Lists/Status
- Reporting
Workflow Setup Steps
A business process analyst sets up the overall workflow in the Workflow Setup Console and Edit Workflow Step screens.
There are two key characteristics for all workflows:
1) All workflows automatically include Initial, Success, and Failure steps. Timeout steps are also available by default.
- An Initial step is always the first step in a workflow
- A Success step attempts to check in all items that reach this step
- A Failure step drops all items that reach this step
- A Timeout step places all item that reach this step into a "fix-it" holding area for review
2) A workflow will only save as long as the process moves from the Initial step to a Success, Failure, or Timeout step without a break in the flow.
It is not necessary to have a route from the Initial step to each of the Success, Failure, and Timeout steps. But for a workflow to be valid, all paths from the Initial step must lead to a Success, Failure, or Timeout step.
WORKFLOW SETUP FOR TYPICAL BUSINESS PROCESS
A typical process for a business process analyst to set up a workflow is:
0. User creates a workflow flowchart in a program such as Visio.
1. Open the Workflow Console screen
2. Press New to create a new workflow. Reach the Edit Workflow Details screen.
3. Name the workflow.
4. Provide a Description of the workflow (optional).
5. Set the Access Control for the workflow. This Access Control determines which roles can view, edit, or delete this workflow.
6. Determine the Container Type supported by the workflow.
There are two supported Container Types - Catalog or Hierarchy. A workflow supporting a Catalog can support a collaboration area containing the attributes directly supported by catalogs - catalog attributes and item-category attributes. A workflow containing a hierarchy can support a collaboration area containing the attributes directly supported by hierarchies - hierarchy attributes and category secondary attributes.
7. Press Add Step to define the first step after the Initial step (if any - as it is possible to complete a workflow by mapping the Initial step directly to a Success step). In this example, the second step is Modify Price.
8. The Add Step button opens the Edit Workflow Step screen.
9. Provide a Name for the step
10. Provide a step Description (optional)
11. Select the step Type.
In this example the step type for the Modify Price step is Modify. There are two broad types of steps - Steps that involve user interaction and steps that do not involve user interaction.
The Step Type Table below describes the available step types, the exit values available at each step, whether performers are available at a step, whether nodes are accessible at a step, whether a deadline is available for the step, whether notifications are available at a step, and whether a script is available for the step.
12. Select the Exit Value if the Exit Value is not predetermined for the step type. In this example with a Modify step type, the Exit Value is predefined as DONE.
If a step involves user interaction, the Exit Value is the text displayed on the button(s) that enable moving to the step mapped to the Exit Value.
If a step does not involve user interaction, each outcome in the script within the step should map to an Exit Value.
13. Select the Performers at the step if Performers can be selected for the step type. A performer is a role and/or user who is allowed to perform the action supported by the step (the action could be modify, and_approval, or_approval, dispatch to another step, etc.). Performers are the only roles/users who can access the step.
It is possible to combine roles and users in any step. If a user is within a role and both the user and role are mapped to a step, the user will be able to act on behalf of the role.
Note: In order to deselect a selection in this popup window, press the CTRL key, then left click on the selection.
14. Optionally select the Nodes for the step if Nodes can be determined for the step type.
The Nodes are the catalog or hierarchy attributes available for editing within the step. These attributes must be available with the specification of a given catalog or hierarchy. For a catalog spec, the attributes can include catalog attributes and item-category attributes. For a hierarchy spec, the attributes can include hierarchy attributes or category secondary attributes.
If the container is catalog, it is possible to add nodes from multiple catalog specs. Likewise if the container is hierarchy, it is possible to add nodes from multiple hierarchy specs.
15. Optionally set the Deadline for the step if a Deadline can be determined for the step type. Upon reaching a Deadline, an item will move to the step mapped to Timeout.
There are two available Deadlines for a step -
- Duration based Deadline at a Step - which will move items in a collaboration area from the current step to the step mapped to Timeout after the item remains in the step for the duration time. Duration based deadlines can be fractions of a Day or Hour.
- Date based Deadline at a Step - which will move all items in a collaboration area from the current step to the next step upon reaching the date
Note: There is also a Deadline available for the whole collaboration area that can be set upon loading items into the collaboration area. With this deadline for the whole collaboration area, all items in the collaboration area have the same Deadline.
16. Optionally set if it should be possible to Add Items to the step. If the Add Items box is checked, it will be possible to run an import feed into a collaboration area at that step.
Note that if the business process analyst setting up the workflow enables adding items to a step after approval steps, the items would not go through the approval steps.
17. Optionally set the Notifications for the step. Notifications are available for every step type. Notifications are emails that are triggered upon Entry into the step or upon the Deadline for the step. The business process analyst enters email addresses into the notifications boxes. The system sends predefined emails to the addresses upon step Entry or reaching a step Deadline.
If the business process analyst wishes to send custom emails to users, it is possible to configure custom emails via the script in a step.
18. Optionally set the Script for the step. Access the script functionality by saving the step, then by pressing the Add Script button. Any step can have a Script. There are three methods available in a Script - IN(), OUT(), and TIMEOUT(). Timeout is equivalent to Deadline. It is not necessary to include a script in each method. It is necessary to map each exit value to a script function.
It is possible in the script step to use any WebSphere Product Center script operation. We expect that customers will frequently use the script step for the following purposes:
- Route workflow records based on certain criteria (e.g.: margin > 10% is mapped to Exit Value = FINAL APPROVAL else is mapped to Exit Value = SPECIAL APPROVAL)
- Run an Invoker trigger script to send workflow data to an external product via HTTP, MQ, JMS, UCCnet, SMTP, or FTP or receive workflow data from an external product
- Run an Invoker trigger script to push data into custom HTML pages or receive data from custom HTML pages
- Create reports such as an add/modify report
19. Repeat Steps 7-18 for the remaining steps in the workflow. In this example the remaining step is Approve Price.
20. In the Select Next Steps screen, map each step to appropriate next step based on the step Exit Value. In this example we need to setup the following mappings:
- Initial Modify Price
- Modify Price Approve Price
- Approve Price/Approved Success
- Approve Price/Rejected Modify Price
21. Setup the pictorial representation of the workflow in the Edit GUI screen. This screen enables a user to depict the steps and the flow between steps in a picture. There is a link to this picture in the Edit Workflow Details screen.
To access the screen, press the blue magnifying glass button in the toolbar in the Edit Workflow Details screen.
The screen displays all of the steps created above. There is a tool tip on each step displaying the step path, description, type, transitions in, and transitions out.
Position each step on the screen by clicking on the step, then clicking on the appropriate box on the screen. Use the lines in the Transition Library to connect steps.
23. Save the workflow.
The tables on the following pages contain all of the workflow step types with an explanation of each step type, which is following with a description.
Base System Steps
Step Type
Initial
Description
A workflow always starts with an Initial step and must end in either a Success, Failure or Timeout step. There is only one instance of an Initial step per workflow.
Exit Values
SUCCESS
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
Yes (if the user wishes to create new records in the workflow by running an import feed into the Initial step, the user must check the Add Entries box in the Initial step)
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Success
Description
If records reach the Success step in a workflow, the system attempts to check the records into the core container (catalog or hierarchy) connected to the collaboration area tied to the workflow.
Exit Values
SUCCESS
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Failure
Description
If records reach the Failure step in a workflow, the system drops the records from the collaboration area.
Exit Values
FAILURE
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Fixit
Description
This step is a special step used to repair entries. An user can send an entry in any step to a fixit step for not satisfying a requirement.
Exit Values
FAILURE
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
User Steps
Step Type
And_Approval
Description
An approval step where all the performers must approve an record before it moves to the next step. It only takes one approver to reject the record.
Exit Values
APPROVED
REJECTED
[ TIMEOUT ]Exit values editable?
No
Performers
At least one
Nodes
No
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
Or_Approval
Description
An approval step where it only takes one of the performers to approve a record before it moves to the next step. It only takes one approver to reject the record.
Exit Values
APPROVED
REJECTED
[ TIMEOUT ]Exit values editable?
No
Performers
At least one
Nodes
No
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
Dispatch
Description
This step is used when you want a user to decide which next step should be taken. Note that this is a view only step. A user cannot modify attributes.
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
Yes
Performers
At least one
Nodes
No
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
Modify
Description
Use this step when you want users to modify a set of records.
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
No
Performers
At least one
Nodes
At least one
Can Add Entries?
Yes
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
General
Description
Use this step when you want users to modify a set of records.
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
Yes
Performers
At least one
Nodes
Yes
Can Add Entries?
Yes
Deadline
Yes
Notifications
Yes
Script?
Yes
Automated Steps
Step Type
Automated
Description
Use this step to automate a task. The logic of this step is captured in the IN() and OUT() functions of the script. Please see below for the Step Transition information that explains the execution sequence of the IN() and OUT() functions.
Exit Values
DONE
Exit values editable?
Yes
Performers
No
Nodes
Yes (It is necessary to include a Node in an Automated step when a workflow only contains Automated steps and the user desires to check out attributes into the workflow.)
Can Add Entries?
Yes
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Wait
Description
This step is used when you want records to wait for a user or script to move them to the next step. This step can also be used for checking-in entries back into the source container at a specific date. For instance, if you want the entries to be merged with your source container only on Nov 15, you would insert a wait step with a deadline of Nov 15 before the Success step.
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
Yes
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
Make Unique
Description
Use these step when you want to remove every other copy of a record in other branches of the worfklow (usually after a split). This ensures that a record reaching this step is in this step and this step only.
Exit Values
DONE
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Merge
Description
Use this step to merge several steps after a split. Note that if you have n steps pointing to the merge step, then n copies of the record must go through the merge step before this record can move to the next step. Use the condenser to reduce the number of incoming steps...
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Condenser
Description
This step is used in front a merge step to reduce the number of entries pointing to a merge step. You achieve this by having several steps pointing to the condenser…
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Condenser
Description
This step is used in front a merge step to reduce the number of entries pointing to a merge step. You achieve this by having several steps pointing to the condenser…
Exit Values
DONE
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Partial_Undo
Description
This step is used to undo the changes done to nodes in this workflow. What really happens is that the values of these nodes are re-fetched from the main catalog when a record enters this state.
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
No
Performers
No
Nodes
At least one. These nodes will be re-fetched from the main catalog.
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
Nested_Workflow
Description
This step is used to include another valid workflow as a step. The exit values for this step are the same as the termination exit values for the included nested workflow.
Exit Values
SUCCESS
FAILURE
TIMEOUTExit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Transitions
Step transition for automated steps:
1/ The IN() function is executed (could be empty)
2/ The OUT() function is executed (could be empty). The OUT() function should set the exit value of the records. If the step only has one exit value, it is selected by default.
3/ Using the workflow graph (which maps each exit value to one or multiple next steps), records are routed to the next stepStep transition for user steps:
1/ The IN() function is executed (could be empty)
2/ The records in this step will be shown in the Advanced Content Authoring screens
3/ There, the performers will select records and assign one of the step exit values to this set of records.
4/ The IN() function is executed (could be empty). The IN() function has a chance to modify the exit value before an record really leaves this step.
5/ Using the workflow graph (wich maps each exit value to one or multiple next steps, records are routed to the next step.
- NOTE: It is possible to enable backward data movement in a workflow by inserting steps that point to an earlier step. If a step in a workflow has a deadline, the step is automatically mapped to a TIMEOUT exit value. The workflow designer may map the TIMEOUT exit value to a step in the workflow. If the workflow designer leaves the TIMEOUT exit value unmapped, the system maps the TIMEOUT exit value to the FIXIT step.
Nested Workflows
It is possible to nest a workflow within another workflow. Here is the process:
- Create both the main workflow using the above process. Save the main workflow.
- Create the nested workflow using the above process. Save the nested workflow.
- Edit the main workflow (by for example selecting the main workflow in the workflow console, then pressing the Edit button).
- In the top toolbar, select the nested workflow in the dropdown box. Press the Add Workflow button.
Note: It is not possible to nest a workflow of a different container type. So it is not possible to nest a hierarchy workflow within a catalog workflow.
- Map the exit values in the nested workflow to the appropriate steps in the main workflow.
- Save the main workflow.