A1: it looks ok, are you having any trouble with that?
A2: the process will not be automatically resumed.. unless you keep the session alive
A3: I'm not up to date with those discussions, but I can imagine how to create the mechanisms for "long running timers"
A4: a) you can use an external quarts which a handler that load the session and do something with it, b) same as 'a', I think that you get it right, just get an external source
that notifies you when the timer is due and reload the session and some something like signal an event or insert a fact.
A1+ Only that processes are not resumed
A2+ What does "keep the session alive" mean? My scenario is: loads of processes running fine, tin fails, restart on new tin some time later, start container, loadStatefulKnowledgeSession..... then what?
A3 & 4+ I'll look further into these. The quartz (or equivant) is not my problem. I'm a learner on jbpm so don't know I can a) stop a process to wait signal and then b) handle a signal to move on to next state & resume the process.
Hello again. Thanks for your reply. Sorry I was drawn into something else for a couple of days...
Let me try to understand. I understand how I can have something in my process that fields a signal. I am not sure how I get that to move my process forward only if it is in certain places in the flow (where I used to have the timers.
Consider a flow like this:
[Call external API1 SR] ==> (timer1) ==> [Get API1Response] ==>[Call extenal API2] ==> (timer2) ==> [Get API2Response] ==> (END)
If the timers don't trigger when I resume the session, can I replace this with something like ...
[Call external API1 SR] ==> (SignalHandler) ==> [Get API1Response] ==>[Call extenal API2] ==> (SignalHandler) ==> [Get API2Response] ==> (END)
... and have an external signal generator that will cause any (SignalHandler) node to resume execution at the next step? I have lots of processes with many timers so I'd not want to have a separate signal to replace each timer in each process. I obviously don't want the signal to divert the line of execution unless it was at the handler.
Yes, you can do what you described with signal events and in my opinion it is more suitable than timers. In fact both timer and signal are events (in your case intermediate catch events) so only event definition needs to change.
Signals have types (signalRef in bpmn2) that is used to distinguish between different signals so you could have different types for given places in your process. You can also pass data when signaling so it could be an alternative for you to send back the response from external api if you signal generator will have it. You can either signal via session which will signal all process instances that awaits given type of signal or signal dedicated process instance.
I was really looking forward to picking this up again but .... not good news. My external timer events are not getting handled.
I am still digging but I thought I'd float the problem in case anyone can volunteer advice.
The first time I call kSession.signalEvent I see
- DefaultSignalManager.addEventListener is called OK
- DefaultSignalManager.removeEventListener is called before
- DefaultSignalManager.internalSignalEvent is gets called but by then no registered listeners
- DefaultSignalManager.removeEventListener is called some more
All of this is down below kSession.signalEvent. When removeEventListener is called, the stack tells me that this is inside a commit. I have NO transaction runningw when I call kSession.signalEvent.
The second time I see no addEventListeners calls.
Thanks for your continuing help.
I am not sure I follow you on what you're trying to do now. Do you use timers and then would like to trigger them manually? If so, that is not what I had in mind. I suggested to use signal event definitions )with corresponding type) instead of timers. Then as soon as you enter the signal node events will be registered.
In addition what could simplify discussion here is to have an example (process) with test case if possible.
I am generating events periodically. Sorry for the bad choice of terms. Every so oftern I call kSession.signalEvent ("xxx", null).
The process looks like this.
[Call external API1 SR] ==> (SignalEvent) ==> [Get API1Response] ==>[Call extenal API2] ==> (SignalEvent) ==> [Get API2Response] ==> (END)
Interestingly I have found that the code works if I enumerate the process instances and iterate around calling kSession.signalEvent ("xxx", null, processInstanceId).
(Yep - if I get stuck again I will abstract a but of code.)