I'm trying to create a workflow that has a parallel split and a loop: Path 1 to 3 contains a set of usertasks (lets call them the Foor, Bar, and Meh Tasks) that represents a set of important approvals that are relatively independent of each other and can happen in any order … say independent paperwork stuff from the company compliance team, legal team, etc (we know who needs to approve at compile time). Path 4 contains a loop that has a script/servicetask that calls invokes an external tool to submit a bunch of documents based on whenver any or all of the approvals tasks are complete. The tricky part is, the documents all have different approval needs (say document type A requires Bar and Meh approval, but document type B only needs Foo approval, etc; and there can be many many different document types, which we can probably only get at runtime) … and they want the submissions to happen as quickly as possible when each of the approval tasks complete.
The way I had thought to implement this was with a loop construct that has a receiveTask (lets call it Loop Wait) right after the serviceTask. Then whenever any of the user tasks have been completed, its java task listener can use an injected runtimeService to signal the Loop Wait execution. This way, all the docs with no approval restrictions get submitted, then the engine will wait and submit the other document types later as the approvals come in.
Plus, I'm also kind of stuck on release 5.6 for the moment :blush: … so I'm not quite sure if in 5.13 there is a better solution (intermediate signal event? but the docs make them out to be more of a global broadcast and not specific to a particular in-flight process)
> that this is a really bad idea … something to do with staying away from API calls in the task listeners? and something about transactions? Is > that right?
For 5.6, yes. We've fixed that in a later release.
You could indeed use a signal event. It might be a bit 'heavy weight' for the use case, but it will get the job done.