Handling interrupts

[icyjamie]

I would like to implement some sort of interrupt handler for solving following business problem:
In EVERY step, something could occur which could lead to a (series of) step(s), which has to be finished before the main step can continue.
With the current implementation, this can be accomplished with having a transition from every node to the starting step of the "exceptional flow", and a transition back from the end of the steps to every node, with a variable holding the transition which has to be used in case of returning. This is, of course, very cumbersome. An example:
In every step of a workflow, the system checks if the data quality is still high, and in case of quality loss, a process is started to correct the data quality, in order to continue the flow. When the quality is high again, the process can continue.
I would like this on ALL current nodetypes. Two things I can think of:
- the rootToken progresses to the exceptional flow and returns to the current step after finishing. Maybe I can use "node-enter" here, and re-route the token. (I'm typing as I think)
- the rootToken gets a child token, which notifies the rootToken it has ended. Problem is that "addChild" is private, and can only be used within a Fork, constructor-wise.
I'm looking for the workflow pattern which closely resembles this behaviour, but cannot think of any. Any suggestions?

[kukeltje]

you could implement your own nodetype that can either take a normal transition or start a subprocess first (the correct dataquality (sub-)process). After the subprocess finishes the normal functionality can continue. Look at the implementation of the sub process node to see how this is acomplished

[icyjamie]

So I have to precede every "normal" node within a "dataqualityCheck" node (otherwise I cannot use the predefined nodes like tasknode, state etc. anymore). This can be achieved with standard stuff, of course.

It would have been fun if all nodes could have an "interrupt" construct :-)

[kukeltje]

Or (and I have not tried this or do not even know if it works) subclass the tasknodes/... etc for your multiple new tasknodes.

Another possibility is to have default decisionnodes with a kind of loop construction (either follow the normal flow or just go to the 'dataquality subprocess' node. That way you indeed model every step in, but no need to adapt anything.

I'm not sure why, but I have a feeling that adding creating something interruptable introduces a kind of fuzzy state. You are not in, but for a longer time 'entering' a state. hmm.... just does not feel right.

(typing as I think as well, I like that concept. Is almost like I normally program)

[icyjamie]

It's xtreme typing :-)

I guess I just have to create one intermediate node for every step needing such an "interrupt". I too feel it is somehow fishy, but compare it to simple function calling, and you feel awkardly comfortable again.

[kukeltje]

xtreme typing, yes, but without the testing, but do not let Tom hear that....

[koen.aers]

Tom is like God, he sees and hears everything...

Except for the traffic jams on the Antwerp ringway which cause him to miss planes, strangely enough... :-P

Cheers,
Koen

[icyjamie]

Tom is like ME ?????

[kukeltje]

yes my son, everybody is like you

[aguizar]

bartender, please serve me one cup of what the gentlemen at this table are drinking!

[kukeltje]

Here you are sir, one absinthe.... enjoy sir... oh ehh do you need a manual with that. I'd suggest to read the fine manual first, since I've been told van Gogh cut his ear after drinking to much of this. http://www.absinth.com/

Enjoy the company sir.

[tom.baeyens]

i'm not god... it's him that tries to look like me :)

on the original topic: i think that you are mixing execution of the process with process data manipulation. note that you have to call the jbpm to do data updates. i see 2 alternatives:
1) if you update the process variables from outside of the process execution, you could do your checks inbetween the variables updates and the signal that you send to process to resume execution.
2) if you want to integrate this functionality in the core engine, you need to tweak the Node.enter method, only calling the execute when dataquality is met.

regards, tom.

[icyjamie]

To make things clear: the data quality problem was just an example. I was also looking into the node.Enter stuff, which could call a callback that returns true or false whether it can continue or take an alternate path. I'm now comfortable with an in-between node which does the checking and routes it back and forth. I may have a shot at superstates (again :-)) as well.