Re: [Concern-users] Evaluating con:cern

[Holger E. <he...@me...>]

Quoting Andy Depue <an...@ma...>:

> Hello,
>   I'm currently in the process of evaluating workflow solutions for our=
=20
> product and have some questions about con:cern.  First, how hard do you=
 think
>=20
> it will be for an English only reading/speaking developer to get acquai=
nted
> with con:cern?

Hm, there's no documentation in english beside a few javadoc comments in =
the
package org.concern. However, I can guide you a little, respond to questi=
ons,
..

> Second, how active is the con:cern project?

Very active. We're using it as a part of some of our products. Integratio=
n with
our erp suite is in the works. An integration workshop with tarend octopo=
s will
be held in may. I'm currently porting the kernel to hibernate 3. ...

> Third, how do you handle "compensation" in con:cern?  Some workflow eng=
ines
> provide the ability to undo actions, others provide the ability to defi=
ne
> compensating branches to execute in the case of an error, etc.

o escalations after error / timeout can compensate problems programmatica=
lly.
  whenever a asynchronous activity times out or a synchronous activity fa=
ils
  permanently, the activitie's escalate method is called. for example: we=
're
  forwarding approval requests to the superior automatically, if the assi=
gnee
  misses to handle it in time.

o the kernel evaluates the state of the subject matter in order to decide=
,
  what activity should be executed next. If you change the subject, the
  workflow will always react correctly according to the current state. th=
us
  you can undo everything, if you just rollback the subject to some older
  state. a good practice is keeping a history of the subject's state.

> Fourth, how well will con:cern integrate with a Swing based rich client=
?  In
> our arrangement, there will be a server (across the internet) that driv=
es
> the workflow.  When a user logs in (via their Swing rich client), they =
will
> be able to pull up a task list containing tasks waiting for human
> intervention.  Of course, these tasks will be from workflows that are
> currently in progress.

Very well. expose the kernel interface (org.concern.Controller) with what=
ever
remoting technology, you like (RMI, SOAP, ..). The interface is completel=
y
string based.

> Fifth, what kind of support does con:cern provide for assigning tasks/s=
teps/
> actions/whatever to a particular role, group, or user?  What would be r=
eally
> cool is if con:cern even went farther than that and provided a way to q=
uery
> outstanding tasks by various criteria (role, department, etc).

The controller provides what we call "activity lists". It only cares, whi=
ch
asynchronous (user) activites have to be executed next. It's the worklist=
's
(package org.concern.client) responsibility to assign these tasks to some
actor. The UserRoleWorklist is based on a static relation between activit=
ies
and users / roles. The FilterWorklist queries the subject for various
criteria to determine, if it should be included in the tasklist (is this
really cool ;-)  .. of course you can write a different implementations, =
that
- let's say - queries the weather forecast in order to shrink down the ta=
sk
list reasonably ;-)

Kind regards,

Holger Engels
(Dipl Inf Med)

--
Consultant, Architect, Developer
Mobile: +49 176 20119752


-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/