The sections illustrates the concepts for work baskets and
business categories with
Work baskets represent a different approach to assign tasks to users
and groups.
Using work baskets, tasks are not assigned to users by the means of verbs
during modeling time. Work baskets are assigned to tasks during
modeling time, and users are granted authorizations for work
baskets at execution time. Therefore the real difference in using the concept of work
baskets is the work basket provides an dynamic abstraction between the tasks and users/groups:
Figure 1 illustrates these concepts. Work is
distributed from generic, to topic, to individual work baskets.
Transfer of work is
used for administrative as well as clearing purposes, i.e. for requests
that failed allocation or were incorrect.
|
| Figure 1: Overview |
Figure 2 shows the differences between the known user assignment using staff verbs compared with the indirect user / task assignment exploiting the concept of work baskets.
On the left hand side, the task "Create Response" is associated
with a
staff verb. Herein technical roles, e.g. the Potential Owners are
specified as members of a group. For each member of this group a task
instance
is allocated to the worklist or tasklist in form of workitems conveying
authorization and status. During staff resolution a workitem for the
task instance
"Create Response" is created.
The workitem defines the access rights, like workitem reason =
Potential Owner as long as the task is in state = ready. A work- or
task list shows all workitems assigned to this
user considering certain filters.
The tasklist even shows workitems
that are available because the user is authorized to work with a
specific work basket (see task property WORK_BASKET).
Using the paradigm of work baskets - shown on the right hand side -
the process developer only
identifies the initial work basket for this human task. That's all to
be done during business process modeling. No staff verbs are used to
identify the Potential Owners.
Another person, e.g. the domain
administrator within an organization creates and configures work
baskets.
As part of this job access rights to work baskets and access
rights for the allocated tasks are specified. One of these access
rights is to specify users or groups to become a Potential Owners of task instances within such a work basket.
At the end, every knowledge worker (enduser) accesses the tasks he may
potentially own from his worklist. It does not matter
whether these tasks had been given to him via regular staff assignment
using staff verbs, or because he has the right task access rights to a
number of work baskets - this is completely transparent for the user.
However, if the knowledge worker wants to know whether a task
instance on his
worklist comes from a work basket, he can use use the
WORK_BASKET property to filter, sort, or group workitems. Even more, a
worklist can be customized so its name correlates with the name
of a work basket. Specified in such a way a user's worklist exactly
looks like a
specific work basket.
 |
| Figure 2: Relationship between staff verb and work basket |
Work baskets provide a different form to distribute tasks among and
to route tasks between users. Who's allowed to work with the tasks in a work basket in what way is specified by the work
basket system administrators while assigning work basket roles, task roles,
distribution targets, and localized descriptions as shown in Figure 3.
 |
| Figure 3: Work basket concepts |
Work basket roles
First, this concept specifies roles and authorizations for work
baskets themselves, not only for tasks within a work basket.
The following are the roles authorized to perform the following actions:
Task roles
Besides the work basket roles, the compelling reason for introducing work baskets is their ability to define people assignments for the contained tasks on the respective work baskets. The following technical task roles exist for all tasks for each work basket, and are "inherited" to the tasks contained within the work basket:
Authorizations can be specified on work baskets and / or on human
tasks. Therefore, when defining people's task assignments on work
baskets, then additionally specifying
the people assignment criteria on the human tasks is
optional. When verifying if somebody can perform an operation on a
task, or if somebody does see a
certain task these different authorization rights are combined. It may
be therefore recommended to use only one way to the other.
Moving tasks from one work basket to another, often a more specific work basket, is called distribution and can be done either manually or automatically. Distribution may be done shortly before the task is actually performed. During distribution all permissions given to a task change immediately to the permissions defined for all tasks contained in the new work basket. A user must have the work basket role Distributor to route tasks to distribution targets. The distribution targets define the work baskets which can receive tasks from another work basket when performing work distribution for whatever business reasons.
Transfer occurs after the tasks have been initially distributed. People and groups can collaborate by transferring tasks from one work basket to another work basket. Transfer is used for administrative purposes when work is incorrectly specified or assigned. A user must have the work basket role Transfer-Initiator to start routing tasks from one work basket and must have the work basket role Appender to the target work basket. As already said, when transferring tasks all task permissions are changed immediately to the permissions defined for all other tasks contained in the target work basket.
Figure 4 illustrates the differences between distribution and transfer and introduces different types of work baskets.
 |
| Figure 4: Distribution and transfer of tasks |
Work basket types
The work basket type is used by a work basket business client to present the right symbol / icon to users working with a particular work basket. Following work basket types exist:
Work basket properties are accessible via APIs. Work basket properties are work basket name, owner, type, and query table. The latter one is used to retrieve lists of task instances using the established query table mechanisms. Figure 5 summarizes the concepts introduced.
 |
| Figure 5: Work basket concept model details |
Business categories is a separate concept from work baskets. They can be used to categorize human tasks in task lists and work baskets thus improving productivity:
Business category model
Similar concepts to work baskets apply to business categories:
 |
| Figure 6: Business category model |
The management and administration of work baskets as well as business categories requires the following roles specified with Java EE authorizations. People in these roles must not require IT skills but should have business domain knowledge:
These management activities are performed via widgets in Business Space. The domain administrators use the widgets to create, retrieve, update and delete work baskets and business categories. This includes the specification of properties, access rights, and distribution targets. Updates to these specifications become effective immediately. The feature pack provides a new business space template and this set of new widgets.
Work basket Business Space templates and widgets
The Work Baskets Administration page allows to administer work
baskets. It includes the following widgets with corresponding actions and
interactions:
Work baskets can be further configured and customized by users
authorized to edit spaces in Business Space.
The Business Categories Administration page allows to administer business categories. It includes following widgets with corresponding actions and interactions.
Figure 7 shows the work basket widgets. The upper one
to
create, edit or delete work baskets. The lower one is the Work Basket Information
widget to specify the properties and details of the selected work basket.
 |
| Figure 7: Administration
of work baskets |
What you do in this sample is quickly explained here. You perform these activities in the sections named Build It Yourself and Run the Sample:
 |
| Figure 8:
Inquiry request business process |
In this sample we use a simplified business process from the finance industry which however applies to other industries in the same way. The process deals with an inquiry request. The request is entered by the customer using a request form. The customer selects a subject, enters personal data and provides additional comments on the request form. Next an automatic activity of the process determines - depending on the subject selected - the topic-related work basket. The analysis and response to the inquiry request is performed in a next step using a replacement variable to associate the human task with the determined work basket respectively the endusers authorized for this basket.
 |
| Figure 9:
Inquiry request business process |
For more information refer to following documentation:
install root. Navigate to the
feature pack directories
\runtimes\bi_v7\feature_packs\bpmfep\docs\. Expand the doc.zip
file, and navigate to the com/ibm/task/api/workbasketxxx.html files.