Part IV - Data Model Manager

Part IV covers each of the components that are available within the Data Model Manger.

Ch 13 Scheduler

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.

Jobs Console

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.


Entry Processor Status

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.

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 Status

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:

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.


Job approvals

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

Ch 14 Specs/Mappings

The Specs/Mappings component of the Data Model Manager provides access to the Specs Console and the Spec Map Console.  


Specifications ("Specs")

The following is a list of spec characteristics:

Specs Console

The Specs Console allows a user to easily navigate and view the following specifications.

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)

Spec Management

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.

Add Nodes

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.

Edit or delete nodes

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.


Spec Node parameters

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.

Node parameters

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.

Node parameter limitation

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.

Adding scripts

Each node within a spec is associated to a node of any type. Therefore, scripts can be created to perform rules for a node.

Node data types

Each node within a spec is associated with a data type, which controls the following:

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

After 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 Rule

When 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 rule

Apply 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 rule

A 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: None

After 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 rule

In 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: None

Any 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 rule

Number

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 rule

A 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 rule

1. 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 rule

When 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 rule

The 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 rule

The 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 rule

Set 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 rule

If 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 rule

Associate 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 value

A 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 rule

The 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 rule

The field allows for an address entered for a URL.

Setting node rules

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

Default value for sequence start

Function: Define a default value for a sequence.
Available in Specs: All
Rules associated: Sequence

Help URL

Function: Define a Help URL; used to customize help.
Available in Specs: All

Although 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: Sequence

Lookup Table

Function: Defined an associated lookup table. No value is available if no lookup tables exist.
Available in Specs: All
Rules associated: Lookup Table

Minimum 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 rule

1. 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 rule

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

Grouped nodes

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.


File Specs

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

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:

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.

Primary Specs

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

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.

Hierarchy Specs

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.

Build Destination 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

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.


Spec imports and exports

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

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.

Spec Map Console

The Mapping Console displays all of the previously created maps of the following types:

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.

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.

Ch 15 Attribute Collections

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:

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:

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:

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:

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:

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 Collection Setup/Console

Attribute Collections are organized in a typical WebSphere Product Center Console format, thus the following standard characteristics apply:

Attribute Collection Console

The Attribute Collection Console is accessed using the menu bar options:

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 Information

Attribute Associations to Attribute Collections

View Attribute Collection Association

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.

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.


Attribute Collection for  catalog access privileges and views

This section describes how to associate an Attribute Collection to Catalog Access Privileges and Views

Access Privilege Setup

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:

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.

Ch 16 Scripting

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:

Scripts Console

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.


Script Sandbox

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.

Ch 17 - Security

The security menu selection is located under the Data Model Manager. It includes the following menu selections.


Roles and Users

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 and Privileges

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:


User Management Scenario

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

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

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:

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.

Map ACG to object

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:

Creating a new role and assign to ACG

For each role, there are three areas of security that can be implemented:

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:

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:

5. Click Save to create the new ACG.

Enforce Access Control for a User

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.


Access Privileges

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.


Edit Role Access

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


Edit Screen Settings

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.

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.


Activity Log

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.

 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.

Alerts

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.


Alerts Console

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:

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

Ch 19 Staging Area

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

Ch 20 - Workflow

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:

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:

Within a WebSphere Product Center Item Synchronization application:

Within a WebSphere Product Center Supplier Self Service application:

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:

Based on the step type, it is possible to setup parameters for the step. These available parameters include

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 -


Workflow Technical Details

The following sections summarize the technical details for WebSphere Product Center Workflows:

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.

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 -

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:

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:

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.


Step Types

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
TIMEOUT

Exit 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 step

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

Nested Workflows

It is possible to nest a workflow within another workflow. Here is the process:

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.