Programmatically calling a callActivity in Java

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-23-2015 04:24 PM
I have the following scenario:
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?
Thx
Raghavan
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?
Thx
Raghavan
Labels:
- Labels:
-
Archive
1 REPLY 1

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
12-24-2015 03:02 AM
Hi Raghavan,
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.
Best regards,
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.
Best regards,
