Async send receive tasks
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-27-2013 11:41 AM
Hi,
I read the post at:
http://bpmn20inaction.blogspot.com/2012/12/implement-parallel-execution-in-activiti.html.
This is a great post, and I was able to figure this out and implement it. We are evaluating jBPM and Activiti as potential solutions right now. I really like Activiti, but in this "true parallelism" case there seems to be the need for extra receive nodes (e.g. the "Wait for response" nodes). In jBPM I'm able to avoid creating two nodes for each asynchronous task, by implementing a class that implements WorkItemHandler, and starting my own thread in a WorkItemExecuter. The resulting BPM diagram looks a lot cleaner (has half the amount of nodes).
Is there a possible way in Activiti to do sort of the same thing – where there is only the need for one node?
Basically I want the ability to "release" the token on one of the parallel paths, so that the other parallel path can get executed. Meanwhile on other threads or servers, work is being executed. When the work is done, essentially a callback asynchronously would continue the flow. In jBPM I was able to accomplish the callback by using the "WorkItemManager.completeWorkItem" method.
Thanks!
I read the post at:
http://bpmn20inaction.blogspot.com/2012/12/implement-parallel-execution-in-activiti.html.
This is a great post, and I was able to figure this out and implement it. We are evaluating jBPM and Activiti as potential solutions right now. I really like Activiti, but in this "true parallelism" case there seems to be the need for extra receive nodes (e.g. the "Wait for response" nodes). In jBPM I'm able to avoid creating two nodes for each asynchronous task, by implementing a class that implements WorkItemHandler, and starting my own thread in a WorkItemExecuter. The resulting BPM diagram looks a lot cleaner (has half the amount of nodes).
Is there a possible way in Activiti to do sort of the same thing – where there is only the need for one node?
Basically I want the ability to "release" the token on one of the parallel paths, so that the other parallel path can get executed. Meanwhile on other threads or servers, work is being executed. When the work is done, essentially a callback asynchronously would continue the flow. In jBPM I was able to accomplish the callback by using the "WorkItemManager.completeWorkItem" method.
Thanks!
Labels:
- Labels:
-
Archive
8 REPLIES 8
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-30-2013 06:01 AM
Yes, we could definitely implement something similar. It's only not considered a best practice in most application servers to start creating new threads yourself like this. But I can understand that sometimes this kind of logic could be helpful. Could you create a JIRA for this?
Thanks,
Thanks,
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-30-2013 01:38 PM
Hi Tijs,
Thanks for your response. I created ACT-1800 for this (I filed it as a "New Feature").
I got to thinking though, and perhaps there is a way to do this (only use a single node) with camel routes.
In the blog example routes are created that look something like:
++++++++++++++
from("activitiarallelProcessTest:servicetask1?copyVariablesToProperties=true").setHeader("destination", constant("activitiarallelProcessTest:receivetask1")).to("seda:asyncQueue1a");
from("seda:asyncQueue1a?concurrentConsumers=100").to("bean:longTask?method=runLongTask(10000)").to("seda:receiveQueue1");
from("seda:receiveQueue1").recipientList(header("destination"));
+++++++++++++++
However, maybe what I want could be accomplished by allowing the "destination" to be set to the next node in the flow, regardless of what node type it is. In other words, the next node could be a gateway or a another task node… This way you wouldn't have to create another receive node. I tried setting the destination to a gateway to bypass creating the receive node, but that didn't work… Can you think of a way to forward to a non-receive node type like I described?
++++++++++++
I do agree that it's not the best practice to start creating new threads. If when this is implemented, there was a way to decouple via message queues, and have a message consumer be the point that essentially triggers the "WorkItemManager.completeWorkItem" call, then that would avoid the spinning up a many active threads. In other words a thread would be briefly created that puts a message in the queue, but it would almost instantly be destroyed. Then a message consumer (perhaps a fixed pool of listener threads) would be waiting for the "workCompleted" message, which would then notify the engine…
Thanks for your response. I created ACT-1800 for this (I filed it as a "New Feature").
I got to thinking though, and perhaps there is a way to do this (only use a single node) with camel routes.
In the blog example routes are created that look something like:
++++++++++++++
from("activitiarallelProcessTest:servicetask1?copyVariablesToProperties=true").setHeader("destination", constant("activitiarallelProcessTest:receivetask1")).to("seda:asyncQueue1a");
from("seda:asyncQueue1a?concurrentConsumers=100").to("bean:longTask?method=runLongTask(10000)").to("seda:receiveQueue1");
from("seda:receiveQueue1").recipientList(header("destination"));
+++++++++++++++
However, maybe what I want could be accomplished by allowing the "destination" to be set to the next node in the flow, regardless of what node type it is. In other words, the next node could be a gateway or a another task node… This way you wouldn't have to create another receive node. I tried setting the destination to a gateway to bypass creating the receive node, but that didn't work… Can you think of a way to forward to a non-receive node type like I described?
++++++++++++
I do agree that it's not the best practice to start creating new threads. If when this is implemented, there was a way to decouple via message queues, and have a message consumer be the point that essentially triggers the "WorkItemManager.completeWorkItem" call, then that would avoid the spinning up a many active threads. In other words a thread would be briefly created that puts a message in the queue, but it would almost instantly be destroyed. Then a message consumer (perhaps a fixed pool of listener threads) would be waiting for the "workCompleted" message, which would then notify the engine…
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-04-2013 05:50 AM
I agree that a single element in the BPMN process definition would be better than what we have now. But that would also be the solution I'm thinking of. We should introduce an enhanced camel service task that waits for the response to come back from Camel. So pretty much a combined service and receive task.
Best regards,
Best regards,
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-14-2013 11:33 AM
Hi Tijs,
Yes, the enhanced camel service task sounds like a good idea. Do you know how far ahead in Activiti's roadmap that might be?
Thanks
Yes, the enhanced camel service task sounds like a good idea. Do you know how far ahead in Activiti's roadmap that might be?
Thanks
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-21-2013 10:22 AM
We just released 5.14, so I'm thinking of 5.15. Could you create a JIRA issue for this?
Best regards,
Best regards,
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-28-2013 07:42 PM
Hi Tijs,
I previously created this JIRA issue:
http://jira.codehaus.org/browse/ACT-1800
It references this forum post in the description.
Thanks!
I previously created this JIRA issue:
http://jira.codehaus.org/browse/ACT-1800
It references this forum post in the description.
Thanks!
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-21-2014 09:28 AM
The Jira and discussions on the topic do not match. In forum a camel task is discussed but in Jira there is no notion of Camel.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-21-2014 09:33 AM
I remember from this discussion that we do not want to block the user thrad to wait for something.
http://forums.activiti.org/content/start-process-synchronously-and-return-results-back
Otherwise I am eager to implement that part. We and I guess many others desperately need it.
It will also help camel component to return values back to camel more elegantly.
http://forums.activiti.org/content/start-process-synchronously-and-return-results-back
Otherwise I am eager to implement that part. We and I guess many others desperately need it.
It will also help camel component to return values back to camel more elegantly.