No, since there is no commit in the process there is nothing to catch. And if you put in an asynchronous continuation we’re back at step 1. Plus, you can see a timing issue here: what if the signal arrives during the loopback? Now you’ve missed the signal. If you want to introduce some sort of loopback you can put an error boundary event on the service task. Throw the error from your code in the delegate to loop back. This is a simple example:
In my delegate I’m just creating some randomness
if(random.nextInt(100) > 50) {
throw new BpmnError("TimedOut");
}
Again, this has to occur in the code, not in the process. You’re trying to fit an synchronous peg in an asynchronous hole
No worries! Right, so ‘committing’ a process is saving its state to the database. Processes will have ‘natural wait states’ like human tasks where it will automatically save the state to the database. Other things that will save the state are intermediate message catch events or timers. Invoking the REST API to start a process will create a new instance of a process and will either respond when the process hits a save point (natural wait state or asynchronous continuations which are save points that are set by you) or if there are no save points in the process, respond at the end of the process. Java delegates are invoked synchronously. You could put in a save point at the start of a service task but that would trigger a response to the start process REST API. What you wanted was a response back from the start process REST API with the variables from the call in the delegate. The only way to do that is to either invoke the java delegate and wait for the response to the call in the delegate (an example which I provided earlier) or throw an error and try again, synchronously. Since you want to do this synchronously, there’s nothing in the database for other applications to send events or signals to. It’s all in memory and sending messages or signals to instances that have not been committed won’t work. There’s no amount of modeling that can account for this without a commit. Hope this clears some of it up.
That is not good news. Would it be possible to have a delegate that listens for a signal that can be sent from another delegate invoked but another flow?
Nope, remember a catch Signal requires a commit to the database. Might be possible to create some sort of custom REST endpoint in the delegate but now we’re getting into some kludgy solutions. Sorry, I can’t be of more help but this is a very unnatural approach to something that can be done more elegantly in an asynchronous fashion.
That’s what I was afraid of. What about receiving a signal call from inside of a delegate? I see you can send a signal from a REST call, is there some way to wait for one inside a delegate or something like that?
