incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <...@toolazydogs.com>
Subject RE: [Agila] assigning tasks to groups of users
Date Tue, 09 Nov 2004 14:52:58 GMT


> -----Original Message-----
> From: Jeremy Boynes [mailto:jboynes@apache.org]
> Sent: Monday, November 08, 2004 1:54 PM
> To: general@incubator.apache.org
> Subject: Re: [Agila] assigning tasks to groups of users
> 
> jastrachan@mac.com wrote:
> >
> > On 8 Nov 2004, at 15:58, Jeremy Boynes wrote:
> >
> >> jastrachan@mac.com wrote:
> >>
> >>> Its very common with people workflow to assign a task to a group
of
> >>> users (or a role) rather than assigning it to a specific
individual
> >>> user. Then a user sees a list of all available tasks they could
> >>> perform - they then grab one ('locking it') and then execute the
task
> >>> or releasing it back into the pool if they don't want to complete
the
> >>> task.
> >>> Right now Agila uses a single UserID for assigning tasks. Unless
I'm
> >>> missing something, it looks like Agila needs some kind of 'role'
or
> >>> 'group' entity so that users can grab tasks rather than a workflow
> >>> just assigning it directly to them. Or am I missing something
subtle
> >>> here?
> >>
> >>
> >> I think there was a design trade off here around how that list of
> >> users would be determined.
> >>
> >> One option is that when task is being generated, the actor
resolution
> >> process pre-calculates the list of users and assigns tasks to all
of
> >> them. When one of them completes their task, then all other
> >> assignments are marked 'already-completed-by-another-user'. This
means
> >> the expansion process, which can be very expensive, is only done
once.
> >> It also means that there is a permanent audit trail of all tasks
that
> >> have been assigned to a user, whether they were the one who did
them
> >> or not. The downside, of course, is that a lot of assignments may
be
> >> generated and not used.
> >
> >
> > Agreed.
> >
> > Its often better to just assign a task to a group and then let a
user
> > grab a task - again the same audit trail can be kept, but it can
result
> > in just 2 simple database operations rather than lots for large
groups.
> >
> 
> In these situations the resulting number of users is often small
making
> for a very manageable set. The set is also defined by some correlation
> id associated with the activity and so can be handled by two simple
> database operations.
> 
> >
> >> The other option is to assign the task to a group deferring
expansion
> >> until a task list is displayed. The set of tasks returned is then
> >> calculated based on the union of all groups to which the user
belongs.
> >> If there are more views of the list than there are assignments then
> >> this may be a more expensive solution.
> >
> >
> > Agreed - though its the more common approach on all the systems I've
> > worked on in the past. e.g. folks often want to search the available
> > tasks by role/group.
> >
> > Typically a users group membership is not that great (only a few
groups)
> > and the groups in which a user belongs does not change that often,
so
> > its common to be able to cache this around for a while, so the query
of
> > all tasks for 1..N groups is usually pretty cheap.
> >
> 
> Funny - I have seen systems collapse under such load even with caching
> (the cost of a cache miss was too high when dealing with hundreds of
> thousands of users).
> 
> >
> >> The audit trail is also more expensive as you have to record the
list
> >> of tasks that was calculated from the group membership expansion.
> >
> >
> > I don't quite follow. So long as you've an audit trail of tasks to
> > groups and users to groups, you're OK right?
> >
> 
> You have to generate audit events for the tasks that were displayed as
a
> result of the expansion. In the pre-calculated one you have specific
> unique task-ids that can be logged. In the dynamic one you have to be
> able to reconstruct the user/group hierarchy as it was at the time of
> display. This involves an effective dating mechanism for users/groups
> (which you would probably have anyway) plus way of making that data
> available to the auditor.
> 
> >
> >> In certain business scenarios (especially HR, Finance or Health)
the
> >> group membership rules can be quite complex. For example, something
> >> simple sounding like "get approval for my expense report" could
> >> involve calculations to determine which managers have approval
> >> authority based on the employee, the value of the report, the date
of
> >> the report, who "default" approvers (such as HR) are, and so forth.
> >
> >
> > That sounds more like an approval workflow rather than just a group
of
> > users. i.e. if it requires complex logic to figure out what a group
is,
> > then its more about a step in the workflow chooses which users
should
> > get what tasks.
> >
> 
> It depends on how you view actor resolution. Yes, the rules for it can
> be scripted by an analyst in the workflow itself (or in a reusable
> sub-flow). Alternatively they can be managed by more specialized
systems
> such as a rules engine. Yes, you can have an activity encapsulate such
> an agent, but I was trying to avoid having to write low-level
iteration
> code (e.g. to loop over a number of assignees) in the workflow model
> itself - it just doesn't fir with what I see an analyst doing.
> 
> > The group feature I'm more keen on is where you have groups of
people
> > doing similar roles who compete for tasks, taking tasks and
completing
> > them while avoiding dual work.
> >
> 
> This is certainly one model. Another is what I was describing as the
> call-center model where work is more directed - it is the software
that
> determines what task to perform next and people often have little
choice.
> 
> >
> >> In situations like this I believe pre-calculating the list of users
is
> >> more effective.
> >
> >
> > Sure. I've just never had that requirement yet :)
> >
> >>
> >
> >> On the other hand, in applications like a call-center the expansion
> >> rules tend to be determined less by business rules and more by the
> >> dynamic nature of the pool; basically the task is assigned to the
> >> worked pool and some queuing algorithm will assign it to a user
based
> >> on their availability.
> >
> >
> > Or the user gets to choose what to work on.
> >
> > e.g. they have a task list of all pending tasks and they just pick
one
> > through the UI.
> >
> >
> >> In that case, I believe the dynamic nature of the pool is outside
the
> >> scope of the business process. In other words, actor resolution in
the
> >> process would result in an assignment to the pool and not to
> >> individual users.
> >
> >
> > Agreed - that's what I want.
> >
> >
> >>  The call-center software would manage the mapping between the
> >> assignment and which specific user was going to perform the task.
This
> >> could be done with a call-center-specific implementation of the
> >> TaskService.
> >>
> >> Having said all that, it sounds like having the TaskService deal
with
> >> UserId (being a single person) is too limiting.
> >
> >
> > Agreed. Especially because there could be a trivial 1-1 mapping
between
> > a group of users and an individual - so its really just an
indirection
> > to allow more flexibility
> >
> >
> >> Given it needs to represent concepts such as a pool of workers in a
> >> call-center, then some form of collective concept is needed. If
this
> >> is done then I think it is important to keep the notion of two
phases
> >> of expansion:
> >>
> >> 1) when converting from an actor to an assignee where the business
> rules
> >>    may need access to information in the process instance (e.g. the
> >>    value of the expense report)
> >>
> >> 2) when determining the tasks that have been assigned to a user
(i.e.
> >>    where they are or are a member of the assignee) which should not
> >>    need information from the instance
> >
> >
> > Agreed.
> >
> > So how about we have some kind of Group entity and we provide access
to
> > assign a task to a Group and then let a user belong to 0..N groups
and
> > allow tasks to be queried by group? We can always keep the Task ->
User
> > mapping for those who want to follow the model of allocating tasks
to
> > all available users and then completing all of them when one person
> > completes their task.
> >
> 
> I think we may be in violent agreement here :-)
> 
> I think we should add some type of collective entity, I just hesitate
to
> call it a Group as that tends to be associated with a specific model (
a
> relatively static set of users and other groups). Call it Assignee or
> something and allow for more dynamic models :-)

Why not do something akin to JACC?  


Regards,
Alan



---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message