[Setools] Composite processes

[goran at krampe.se]

Hi!

"=?ISO-8859-1?Q?Bal=E1zs_K=F3si?=" <rebmekop at gmail.com> wrote:
> Hi!
> 
> >> I am exploring case linking and criteria mechanism, to implement
> >> "composite processes".
> >> Does it make sense?
> >
> > Mmmmm, need more explanation of what you mean.
> 
> Sure :) Sadly i don't have a clear definition on what i want to accomplish,
> because i don't have a clear view on the processes of the company, which
> workings i want to automate. But probably sometimes later this
> (incremental process exploration) will be a subject of another thread.

Yes, it is an interesting subject. We are in the middle of it at the
customer. :)

> Luckily i have some idea on what i want to implement :) So: I want a
> mechanism for
> spawning new cases (of arbitary processes) on stage transition events
> (or maybe on case
> events in general). Such a new case will be linked (as a sub-case) to
> the parent case, and
> its state (more specially: its stage) can be used in the parents criterions.

Ok, got it.
 
> Typical usage: the parent case steps in a stage, then it spawns some
> children cases. Then
> the stage's outgoing transition becomes enabled, when all of the
> children cases are in an
> end stage.

Right.

> I think this is already in the system (actions on transition events,
> case linking, and criterions). We need some mechanism (i overuse this
> word) to make it more explicit. And we need UI elements which support
> it (as for so much more things).
> 
> What do you think?

I think that you both have understood what we have (even though
documentation is still quite lacking) and how it could be done. :)

First of all, our customer has a need of a very simple way of manually
creating linked cases (to an existing case). Adding that we should of
course make it easy programmatically too. One of the last things we are
doing right now is adding a "Plugin" architecture. The idea is that
Plugins can be written both as regular Squeak classes, or be added in a
more scriptish fashion.

Magnus is writing such a Plugin right now that talks SOAP with JIRA in
order to create cases in that system and to listen to callbacks from
JIRA. Plugins can register Subscriptions in order to "listen" to system
events. So this could be written as such a Plugin I think, but...

...perhaps this is something we want more explicit support for and we
could simple add some Criterion classes for it, as you might have seen
there are:

	actionOnEnterForExit:
	actionOnEnterForEnter:

If you check senders and implementors you find at least one criterion
that actually has an *action* that is triggered. 

So we could add a subclass to Q2WorkflowCriterion that has an action
that "spawns" a case(s) in another Process(es). And that can then
"watch" those cases and their states in order to validate. Well, that
could of course be another criterion type - not the same. Yes. Indeed.
Definitely. Feel free to hack that up! :)

And yes, UI elements are neeed. For a lot. :)

> cheers: balazs

regards, Göran