Maciej, Jordi,
thanks for the discussion.
Personally, I think we need a freedom to do both things, because it is obvious that both scenarios are common.
My point is that calling
ksession.signalEvent(type, eventData);
looks as one is trying to signal all process instances in a given knowledge session, but not in *all* knowledge sessions.
It would be nicer to have something like this:
ksession.signalEvent(type, eventData) - signals all processes in a given knowledge session
ksession.signalEvent(type, eventData, processInstanceId) - signals all processes in a given knowledge session
ksession.signalEvent(type, eventData, Collection<Long> processInstanceIds) - signals all processes with a given Id in a given knowledge session
ksession.signalEvent(type, eventData, long processInstanceId) - signals process with a given id in a given knowledge session
processInstance.signalEvent(type, eventData) - signals a particular process instance (the same as previous call)
StatefulKnowledgeSession.signalEvent(type, eventData) - signals *all* processes that use this event type
And of course, persistency model should be altered based on the API to reflect the changes.
BTW, Jordi, can you ask you to share part of your process definition regarding wait states? I'm curious to see an alternative way of doing it by using a fact....
I have a situation where I have to implement a lot of "waiting nodes" that are going to decide whether to continue with processing, based on a fact that is going to be asserted every day (in some batch processing, for example).
Right now I've developed two solutions:
1. custom work item node waiting for the right data to come - fact is part of my work item, and I don't think it will work as work item handlers are not persisted
2. calling signalEvent() to wake up waiting node to continue - I'm not happy with this solution as I have to have a number of intermediate catch events scattered through my process
Is there a better way to wake up process? Did anyone created a custom work item handler that is registered to respond to signalEvent?
Thanks,
Miljenko