1. A common workflow (say C) that performs a series of functions that are used by many other workflows 2. C sets several variables related to the logic it performs (result - success/fail, failure cause etc) 3. C has a wait state implemented using a receive task. C may look like this (the variables set after getting a response depends on whether the response was a success/failure response etc) start —> | Validate | –> | Send message | –> | Receive task (wait for response) | –> | set some variables | –> end
Let's say workflow X calls this:
start –> | setup inputs | –> | call C | –> | examine variables from C | –> | do stuff |
Since I call this workflow from many workflows, I don't want every workflow to have to deal with setting the input and output variables in order to simplify the manner in which C is consumed (the set of inputs and outputs that are sent to and received from C are fixed)
One way to do this would be to wrap a service task where I set the input and output variables and invoke the call activity programmatically. I couldn't find an equivalent of startProcessInstanceByKey (say callProcessInstanceByKey) to do this. I found the DefaultActivitiBehaviorFactory and see how to create a CallActivityBehavior but don't understand exactly how to use it from there.
Does the parent process that invokes the call activity go into a wait state when a callactivity is invoked or is it waiting there. I'm guessing that it would depend on whether Async is selected or not. If it was synchronous and if C is in a wait state when the workflow engine crashes, where will the calling workflow pick up and resume?
You could implement a service task with CallActivityBehavior as a foundation and make the changes for your requirements. When you use the CallActivityBehavior class as a foundation, then it will do exactly what the current call activity does for you, so yes the parent process will wait until the child process is completed.