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
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 :-)
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)
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.
xtreme typing, yes, but without the testing, but do not let Tom hear that....
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
Tom is like ME ?????
yes my son, everybody is like you
bartender, please serve me one cup of what the gentlemen at this table are drinking!
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.
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.
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.