The PIM process can be managed through the definition of a workflow. The Workflow Console is used to create a workflow process, containing multiple instances that are viewable through the definition display.
A workflow instance can be created to appear in the Workflow Console and based on the status, an alert can be sent to notify that an approval is needed before it is escalated to the next step in the workflow.
This chapter summarizes the Workflow feature using the following key questions:
- What is a WebSphere Product Center workflow?
- How is a workflow setup?
- How does data move through workflow steps?
- What is the available task list/status functionality?
- What is the available workflow reporting functionality?
Each question is provided with a high-level response and is provided with a more thorough discussion in the Workflow Technical Details section.
What is a WebSphere Product Center workflow?
A WebSphere Product Center workflow implements a business process in either the Product Center application or a separate WebSphere Product Center application. WebSphere Product Center's workflow component offers a set of screens to setup task lists/status screens, and reporting functionality.
Example business processes:
Within the WebSphere Product Center core application:
- Add item
- Modify item
Within a WebSphere Product Center Item Synchronization application:
- UCCNet Item Add
Within a WebSphere Product Center Supplier Self Service application:
- Supplier file submittal
How is a workflow set up?
A Business Process Analyst uses the UI screens to build a series of steps corresponding to a specific business process. Although it is possible to configure most steps without any scripting, further workflow definitions can be performed using scripting for any workflow step.
There are a variety of predefined step types for each workflow step including:
- Modify
- And Approval
- Or Approval
- Automated
- General
Based on the step type, it is possible to setup parameters for the step. These available parameters include
- The roles or users with access to the step
- The editable attributes in the step
- The exit values for the step (including escalation)
- The email notifications at the step
- The timeout for the step
- The script for the step
If needed, a nested workflow can be defined by having a step feed another workflow, or a step can accept data from another workflow. A step can also call out to external systems via HTTP, MQ, JMS, FTP, or SMTP.
How does data move through the workflow steps?
Catalog or hierarchy attribute values move through the workflow steps in a collaboration area. A collaboration area is a "mini-catalog" that supports regular catalog/hierarchy functionality - including content authoring screens, views, spec validation rules, 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 -
- Time to Shelf Report - showing the time for newly introduced products to move from receipt to syndication into external systems
- Cost per Managed SKU Report - measuring the time and number of resources required to move product from receipt to delivery
- Price Change Report - indicating all price changes at each workflow step with each user's name, datetime of change, and comments
- User Throughput Report - showing the number of items processed by each user over time at each workflow step
- Approval Chain Report - presenting all approvals within a given workflow
- Current User Status Report - showing a snapshot of the number of items at each workflow step for a given user
- Escalation Report - indicating all items that were escalated by timeout during a time period
The following sections summarize the technical details for WebSphere Product Center Workflows:
- Workflow Setup Steps
- Data Movement and Task Lists/Status
- Reporting
Workflow Setup Steps
A business process analyst sets up the overall workflow in the Workflow Setup Console and Edit Workflow Step screens.
There are two key characteristics for all workflows:
1) All workflows automatically include Initial, Success, and Failure steps. Timeout steps are also available by default.
- An Initial step is always the first step in a workflow
- A Success step attempts to check in all items that reach this step
- A Failure step drops all items that reach this step
- A Timeout step places all item that reach this step into a "fix-it" holding area for review
2) A workflow will only save as long as the process moves from the Initial step to a Success, Failure, or Timeout step without a break in the flow.
It is not necessary to have a route from the Initial step to each of the Success, Failure, and Timeout steps. But for a workflow to be valid, all paths from the Initial step must lead to a Success, Failure, or Timeout step.
WORKFLOW SETUP FOR TYPICAL BUSINESS PROCESS
A typical process for a business process analyst to set up a workflow is:
0. User creates a workflow flowchart in a program such as Visio.
1. Open the Workflow Console screen
2. Press New to create a new workflow. Reach the Edit Workflow Details screen.
3. Name the workflow.
4. Provide a Description of the workflow (optional).
5. Set the Access Control for the workflow. This Access Control determines which roles can view, edit, or delete this workflow.
6. Determine the Container Type supported by the workflow.
There are two supported Container Types - Catalog or Hierarchy. A workflow supporting a Catalog can support a collaboration area containing the attributes directly supported by catalogs - catalog attributes and item-category attributes. A workflow containing a hierarchy can support a collaboration area containing the attributes directly supported by hierarchies - hierarchy attributes and category secondary attributes.
7. Press Add Step to define the first step after the Initial step (if any - as it is possible to complete a workflow by mapping the Initial step directly to a Success step). In this example, the second step is Modify Price.
8. The Add Step button opens the Edit Workflow Step screen.
9. Provide a Name for the step
10. Provide a step Description (optional)
11. Select the step Type.
In this example the step type for the Modify Price step is Modify. There are two broad types of steps - Steps that involve user interaction and steps that do not involve user interaction.
The Step Type Table below describes the available step types, the exit values available at each step, whether performers are available at a step, whether nodes are accessible at a step, whether a deadline is available for the step, whether notifications are available at a step, and whether a script is available for the step.
12. Select the Exit Value if the Exit Value is not predetermined for the step type. In this example with a Modify step type, the Exit Value is predefined as DONE.
If a step involves user interaction, the Exit Value is the text displayed on the button(s) that enable moving to the step mapped to the Exit Value.
If a step does not involve user interaction, each outcome in the script within the step should map to an Exit Value.
13. Select the Performers at the step if Performers can be selected for the step type. A performer is a role and/or user who is allowed to perform the action supported by the step (the action could be modify, and_approval, or_approval, dispatch to another step, etc.). Performers are the only roles/users who can access the step.
It is possible to combine roles and users in any step. If a user is within a role and both the user and role are mapped to a step, the user will be able to act on behalf of the role.
Note: In order to deselect a selection in this popup window, press the CTRL key, then left click on the selection.
14. Optionally select the Nodes for the step if Nodes can be determined for the step type.
The Nodes are the catalog or hierarchy attributes available for editing within the step. These attributes must be available with the specification of a given catalog or hierarchy. For a catalog spec, the attributes can include catalog attributes and item-category attributes. For a hierarchy spec, the attributes can include hierarchy attributes or category secondary attributes.
If the container is catalog, it is possible to add nodes from multiple catalog specs. Likewise if the container is hierarchy, it is possible to add nodes from multiple hierarchy specs.
15. Optionally set the Deadline for the step if a Deadline can be determined for the step type. Upon reaching a Deadline, an item will move to the step mapped to Timeout.
There are two available Deadlines for a step -
- Duration based Deadline at a Step - which will move items in a collaboration area from the current step to the step mapped to Timeout after the item remains in the step for the duration time. Duration based deadlines can be fractions of a Day or Hour.
- Date based Deadline at a Step - which will move all items in a collaboration area from the current step to the next step upon reaching the date
Note: There is also a Deadline available for the whole collaboration area that can be set upon loading items into the collaboration area. With this deadline for the whole collaboration area, all items in the collaboration area have the same Deadline.
16. Optionally set if it should be possible to Add Items to the step. If the Add Items box is checked, it will be possible to run an import feed into a collaboration area at that step.
Note that if the business process analyst setting up the workflow enables adding items to a step after approval steps, the items would not go through the approval steps.
17. Optionally set the Notifications for the step. Notifications are available for every step type. Notifications are emails that are triggered upon Entry into the step or upon the Deadline for the step. The business process analyst enters email addresses into the notifications boxes. The system sends predefined emails to the addresses upon step Entry or reaching a step Deadline.
If the business process analyst wishes to send custom emails to users, it is possible to configure custom emails via the script in a step.
18. Optionally set the Script for the step. Access the script functionality by saving the step, then by pressing the Add Script button. Any step can have a Script. There are three methods available in a Script - IN(), OUT(), and TIMEOUT(). Timeout is equivalent to Deadline. It is not necessary to include a script in each method. It is necessary to map each exit value to a script function.
It is possible in the script step to use any WebSphere Product Center script operation. We expect that customers will frequently use the script step for the following purposes:
- Route workflow records based on certain criteria (e.g.: margin > 10% is mapped to Exit Value = FINAL APPROVAL else is mapped to Exit Value = SPECIAL APPROVAL)
- Run an Invoker trigger script to send workflow data to an external product via HTTP, MQ, JMS, UCCnet, SMTP, or FTP or receive workflow data from an external product
- Run an Invoker trigger script to push data into custom HTML pages or receive data from custom HTML pages
- Create reports such as an add/modify report
19. Repeat Steps 7-18 for the remaining steps in the workflow. In this example the remaining step is Approve Price.
20. In the Select Next Steps screen, map each step to appropriate next step based on the step Exit Value. In this example we need to setup the following mappings:
- Initial Modify Price
- Modify Price Approve Price
- Approve Price/Approved Success
- Approve Price/Rejected Modify Price
21. Setup the pictorial representation of the workflow in the Edit GUI screen. This screen enables a user to depict the steps and the flow between steps in a picture. There is a link to this picture in the Edit Workflow Details screen.
To access the screen, press the blue magnifying glass button in the toolbar in the Edit Workflow Details screen.
The screen displays all of the steps created above. There is a tool tip on each step displaying the step path, description, type, transitions in, and transitions out.
Position each step on the screen by clicking on the step, then clicking on the appropriate box on the screen. Use the lines in the Transition Library to connect steps.
23. Save the workflow.
The tables on the following pages contain all of the workflow step types with an explanation of each step type, which is following with a description.
Base System Steps
Step Type
Initial
Description
A workflow always starts with an Initial step and must end in either a Success, Failure or Timeout step. There is only one instance of an Initial step per workflow.
Exit Values
SUCCESS
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
Yes (if the user wishes to create new records in the workflow by running an import feed into the Initial step, the user must check the Add Entries box in the Initial step)
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Success
Description
If records reach the Success step in a workflow, the system attempts to check the records into the core container (catalog or hierarchy) connected to the collaboration area tied to the workflow.
Exit Values
SUCCESS
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Failure
Description
If records reach the Failure step in a workflow, the system drops the records from the collaboration area.
Exit Values
FAILURE
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Fixit
Description
This step is a special step used to repair entries. An user can send an entry in any step to a fixit step for not satisfying a requirement.
Exit Values
FAILURE
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
User Steps
Step Type
And_Approval
Description
An approval step where all the performers must approve an record before it moves to the next step. It only takes one approver to reject the record.
Exit Values
APPROVED
REJECTED
[ TIMEOUT ]Exit values editable?
No
Performers
At least one
Nodes
No
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
Or_Approval
Description
An approval step where it only takes one of the performers to approve a record before it moves to the next step. It only takes one approver to reject the record.
Exit Values
APPROVED
REJECTED
[ TIMEOUT ]Exit values editable?
No
Performers
At least one
Nodes
No
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
Dispatch
Description
This step is used when you want a user to decide which next step should be taken. Note that this is a view only step. A user cannot modify attributes.
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
Yes
Performers
At least one
Nodes
No
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
Modify
Description
Use this step when you want users to modify a set of records.
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
No
Performers
At least one
Nodes
At least one
Can Add Entries?
Yes
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
General
Description
Use this step when you want users to modify a set of records.
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
Yes
Performers
At least one
Nodes
Yes
Can Add Entries?
Yes
Deadline
Yes
Notifications
Yes
Script?
Yes
Automated Steps
Step Type
Automated
Description
Use this step to automate a task. The logic of this step is captured in the IN() and OUT() functions of the script. Please see below for the Step Transition information that explains the execution sequence of the IN() and OUT() functions.
Exit Values
DONE
Exit values editable?
Yes
Performers
No
Nodes
Yes (It is necessary to include a Node in an Automated step when a workflow only contains Automated steps and the user desires to check out attributes into the workflow.)
Can Add Entries?
Yes
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Wait
Description
This step is used when you want records to wait for a user or script to move them to the next step. This step can also be used for checking-in entries back into the source container at a specific date. For instance, if you want the entries to be merged with your source container only on Nov 15, you would insert a wait step with a deadline of Nov 15 before the Success step.
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
Yes
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
Make Unique
Description
Use these step when you want to remove every other copy of a record in other branches of the worfklow (usually after a split). This ensures that a record reaching this step is in this step and this step only.
Exit Values
DONE
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Merge
Description
Use this step to merge several steps after a split. Note that if you have n steps pointing to the merge step, then n copies of the record must go through the merge step before this record can move to the next step. Use the condenser to reduce the number of incoming steps...
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Condenser
Description
This step is used in front a merge step to reduce the number of entries pointing to a merge step. You achieve this by having several steps pointing to the condenser…
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Condenser
Description
This step is used in front a merge step to reduce the number of entries pointing to a merge step. You achieve this by having several steps pointing to the condenser…
Exit Values
DONE
Exit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
No
Notifications
Yes
Script?
Yes
Step Type
Partial_Undo
Description
This step is used to undo the changes done to nodes in this workflow. What really happens is that the values of these nodes are re-fetched from the main catalog when a record enters this state.
Exit Values
DONE
[ TIMEOUT ]Exit values editable?
No
Performers
No
Nodes
At least one. These nodes will be re-fetched from the main catalog.
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Type
Nested_Workflow
Description
This step is used to include another valid workflow as a step. The exit values for this step are the same as the termination exit values for the included nested workflow.
Exit Values
SUCCESS
FAILURE
TIMEOUTExit values editable?
No
Performers
No
Nodes
No
Can Add Entries?
No
Deadline
Yes
Notifications
Yes
Script?
Yes
Step Transitions
Step transition for automated steps:
1/ The IN() function is executed (could be empty)
2/ The OUT() function is executed (could be empty). The OUT() function should set the exit value of the records. If the step only has one exit value, it is selected by default.
3/ Using the workflow graph (which maps each exit value to one or multiple next steps), records are routed to the next stepStep transition for user steps:
1/ The IN() function is executed (could be empty)
2/ The records in this step will be shown in the Advanced Content Authoring screens
3/ There, the performers will select records and assign one of the step exit values to this set of records.
4/ The IN() function is executed (could be empty). The IN() function has a chance to modify the exit value before an record really leaves this step.
5/ Using the workflow graph (wich maps each exit value to one or multiple next steps, records are routed to the next step.
- NOTE: It is possible to enable backward data movement in a workflow by inserting steps that point to an earlier step. If a step in a workflow has a deadline, the step is automatically mapped to a TIMEOUT exit value. The workflow designer may map the TIMEOUT exit value to a step in the workflow. If the workflow designer leaves the TIMEOUT exit value unmapped, the system maps the TIMEOUT exit value to the FIXIT step.
Nested Workflows
It is possible to nest a workflow within another workflow. Here is the process:
- Create both the main workflow using the above process. Save the main workflow.
- Create the nested workflow using the above process. Save the nested workflow.
- Edit the main workflow (by for example selecting the main workflow in the workflow console, then pressing the Edit button).
- In the top toolbar, select the nested workflow in the dropdown box. Press the Add Workflow button.
Note: It is not possible to nest a workflow of a different container type. So it is not possible to nest a hierarchy workflow within a catalog workflow.
- Map the exit values in the nested workflow to the appropriate steps in the main workflow.
- Save the main workflow.