CallActivity on a different Business Item
Hey all,
I need to be able to make a synchronous call from one workflow operating on Asset A to another workflow to operate on Asset B.
- Using Call Activity, is there any way to specify a different Business Item? Or synthetically create an item bean?
- Alternately, using startWorkflowInstances, what is the best way to simulate a synchronous call? Is polling the only way? If so, what is the most groovy/flowable way to do it?
Tom Friesen
Posted 3 years ago · Edited 1 year ago·Last reply 3 years ago
11 comments
Gnanasekaran
·3 years ago · EditedThanks for the solution @george.cheung.collibra.com!
I have a similar use case, but only difference is that i would call the child workflow multiple times for a list of assets from the main workflow.
In this case, would the message send back from the one of the child workflows resumes the execution of the main workflow (OR) the main workflow waits for all the child workflows to send the message and then resume the execution?
georgecheung
·3 years ago · EditedIf there are plans to use multiple instances of the main workflow (on separate assets), I would recommend using Messages instead of Signals.
If there are multiple instances running - and all are in the waiting the signal state - then any time the corresponding signal is thrown - all of those instances will pick it up and resume - which may not be ideal.
Messages require the workflow instance id so that the specific starting workflow instance is identified so that particular instance can resume.
Messages can be thrown using the method:
workflowInstanceApi.messageEventReceived(MessageEventReceivedRequest)In the
MessageEventReceivedRequestis where you would need to specify the Message and the workflow instance id.@tom.friesen @bart.vanderlocht
georgecheung
·3 years ago · EditedIf there are plans to use multiple instances of the main workflow (on separate assets), I would recommend using Messages instead of Signals.
If there are multiple instances running - and all are in the waiting the signal state - then any time the corresponding signal is thrown - all of those instances will pick it up and resume - which may not be ideal.
Messages require the workflow instance id so that the specific starting workflow instance is identified so that particular instance can resume.
Messages can be thrown using the method:
workflowInstanceApi.messageEventReceived(MessageEventReceivedRequest)In the
MessageEventReceivedRequestis where you would need to specify the Message and the workflow instance id.@tom.friesen @bart.vanderlocht
arthurburkhardt
·3 years ago · EditedThat sounds super awesome, is there any examples/sample workflows/documentation on those features?
I know there is the official flowable doc, but I’m not finding any easily digestible tutorial yet.
georgecheung
·3 years ago · EditedHere is an example:
MessageEvent-Main.txt (6.5 KB)
MessageEvent-Child.txt (4.5 KB)
(The forum doesn’t allow for zip files or bpmn files to be uploaded, so you would need to download and renamed to .bpmn extension)
Both the Main and the Child workflow would need to be set to Asset Level and enabled.
The Main workflow has a start form where the user has to select the asset to run the child workflow and has to enter in a message to pass to the child workflow.
The child workflow runs on the selected asset, and then a task appears to the current user with the message from the main workflow, and gives the current user a form to respond to the main workflow. Once that task is completed - it sends the message and the main workflow resumes with a user task with the message from the child workflow.
The workflow has loggers in there so you can see what is being started and the values being used.
The Child workflow can not be started on its own as its missing variables being passed in from the main workflow.
Hope this helps.
Alexandra Jorgenson
Admin3 years ago · Edited@tom.friesen, also one of our Sales Engineers (@pawel.karnas) says this:
These are good/interesting questions.
I don’t know if there is a simple way to do this.
We can’t specify or create a different Business Item, so you should use startWorkflowInstances, but to find out that this child workflow is over, the parent one can wait for a (message) event. This event should be thrown by a child workflow.
Other solution would be to split this parent workflow into 2 separate workflows. The parent1 can use startWorkflowInstances to start a child workflow. Then this child workflow can start the parent2 workflow and continue the flow.
Alexandra Jorgenson
Admin3 years ago · Edited@tom.friesen, also one of our Sales Engineers (@pawel.karnas) says this:
These are good/interesting questions.
I don’t know if there is a simple way to do this.
We can’t specify or create a different Business Item, so you should use startWorkflowInstances, but to find out that this child workflow is over, the parent one can wait for a (message) event. This event should be thrown by a child workflow.
Other solution would be to split this parent workflow into 2 separate workflows. The parent1 can use startWorkflowInstances to start a child workflow. Then this child workflow can start the parent2 workflow and continue the flow.
Tom Friesen
OP3 years ago · EditedLooks like we all converged on the same solutions! Thanks for the follow-up, @kristen.freer!
bartvanderlocht
·3 years ago · EditedYou could achive this using the SignalThrowEvent and SignalCatchEvent.
bartvanderlocht
·3 years ago · EditedYou could achive this using the SignalThrowEvent and SignalCatchEvent.
Tom Friesen
OP3 years ago · EditedThanks, @bart.vanderlocht ! I hadn’t considered signals. (I ended up splitting the workflow in two, and having the second half catch a workflow completion event. Will try this the next time!)