|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
Query : Staff Assignment Techniques : MQWF Vs WBISF |
View previous topic :: View next topic |
Author |
Message
|
puneet.kathuria |
Posted: Tue Jun 13, 2006 4:06 am Post subject: Query : Staff Assignment Techniques : MQWF Vs WBISF |
|
|
Newbie
Joined: 13 Jun 2006 Posts: 1
|
In MQWF we had a concept of "Team Worklist" which ensures that only one workitem is created and all the participating users can still work on the task. This boosts the performance as the number of workitems is not equal to the required users (which can be as high as 50-60).
I was wondering if the concept of Team Worklist still exists in WBISF 5.1.1?
Here is one paragraph about Team Worklist.
IBM MQSeries Workflow: Staff Assignment Techniques
Role vs. Team Worklist
In MQWF, the term role is used to designate a job function that may be associated with a person. A person may be a member of zero or more roles. If the process model specifies “dynamic” staffing for an activity, then during process execution (when an activity becomes instantiated) the process engine will determine which persons satisfy the role/ organization/level criteria and create a workitem for each of those users. There is a oneto-one relationship between workitem and owner. If there are 10 users who satisfy the staffing criteria, then 10 workitems will be created. Staff resolution is done only when an activity is instantiated (initially becomes ready). If additional users are added to a role after staff resolution occurs, workitems will not be created for them.
In contrast, consider the designation of a “special” user ID to perform the same work assignment function that role is typically used for. (In our example, the person “TEAM_A” is logically equivalent to the role “Role_A”.) In Buildtime, the activity would be targeted for this person instead of a role. (This is how a user ID can behave like a team worklist.)
During process execution, such an activity instance would result in a single workitem being created. Any logged-on user who is authorized for the workitems of this user ID (team worklist) will be able to view that workitem and assume (transfer) ownership of it in order to work on it. Also, if workitem authorization is granted to a user (for this team worklist), then, after an activity has gone through staff resolution, that user will immediately (upon logon or refresh) be able to view or transfer all workitems currently owned by that team worklist. This is extremely powerful.
Another way to think of the difference between the use of role and team worklist is that with role you are moving work to people, whereas with team worklist you are moving people to work -- which is inherently more flexible and requires less system resource. |
|
Back to top |
|
 |
jefflowrey |
Posted: Tue Jun 13, 2006 6:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
|
Back to top |
|
 |
|
|
  |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|