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, inheritance 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. Section 10.8 below contains the new script operations available with the workflow.

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.