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 :-)
--
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
|