[warmonga]

@kukeltje: Many thanks for your immediate reply!

Yes, it is understandable what you want to achieve, process wise. What I still do not understand is why you try to implement it by run-time modifying of the processdefinition.

This is because I want to give the user the possibility to model his/her process in jBPM and, separated from that, define a set of business rules that should hold. Thus my validation mechanism is to function on any process no matter how it is modelled. The only thing that needs to be done by my "validation tool" in the XML-file of the process itself is to add the ActionHandler to each TaskNode programmatically.

Questions:
- If you do not want the 'next' task to show up directly, when do you want it to show up and is there any trigger for it

Ok I want, in case any of the rules fires, the process to stop, a new TaskInstance (which in my current implementation is outside of the current process in a kind of "alert process" only holding this one Task with the error message) to be displayed, and after the user clicked on that task instance that showed up (I assume that the user changes some data in his backend systems in order to make the system "rule conform" again) the process should be continued. So I thought a call of processInstance.suspend() at the moment when the rule fires and a processInstance.resume() at that moment when the TaskInstance of the "alert process" is executed would be best.

- what if the info entered for it is still not correct?

Well as explained above the user does not necessarily need to enter new information, his information is assumed to be changed in the backend by the user / other users. Ok but the question persists: Well, the best solution would be, that the rules are validated again right away and the main process would only continue if this time everything is conform with all rules. So best would be if the ActionHandler which fires the rules or a similar ActionHandler would be called again somehow at this point.
But for now I am Ok with a situation where I just assume that the user corrects his data after I told him that someting is incorrect (through the TaskInstance of the "alert process"), so the rules do not need to fire again and the main process should just continue execution.

- Why not just use a jsf validator on the input field that requires the entry to be > 4

Because of the requirement that the rules do not belong to a specific process and the entries are not necessariliy made through process variables

Any hints for solving this issue?

Many thanks again for your help!
Cheers,
Maurice

[warmonga]

@ kukeltje and others: Don't you have any hint/suggestion for solving this problem?

I would appreciate any help!
Many thanks again!
Regards,
Maurice

[estaub]

Maurice,

If everything wasn't concrete classes, I'd consider injecting a common proxy for all of the action-handlers that performs the post-processing. It would also provide proxy interfaces for JbpmContext, et al, to the actionhandler, so, for instance, when it did a signal() the proxy would defer it until after it ran its validation rules.

I don't think this flies with the current architecture, though - there aren't interfaces in the right spots.

This seems related to the problems likely to be encountered when someone wants to implement a process simulator/debugger. There isn't enough abstraction to do the kind of injections required.

This is probably a pretty useless note!

-Ed Staub