-
15. Re: foreach activity
aguizar Jun 9, 2010 11:39 AM (in response to swiderski.maciej)Maciej, it seems like we have reached consensus. Can you commit, please? I have a few minor edits I would like to make but I'll apply them afterwards.
-
16. Re: foreach activity
swiderski.maciej Jun 9, 2010 11:59 AM (in response to aguizar)Great
Will do so today evening. It will not contain docs but as you mentioned will be incorporated bit later.
Cheers
Maciej
-
17. Re: foreach activity
walterjs Jun 10, 2010 4:10 AM (in response to swiderski.maciej)Maciej Swiderski wrote:
It is more like surrounding activities that needs to be executed in a loop than attaching loop characteristic to an activity.
Thanks Maciej,
This has cleared it up for me. It is better not to try and merge the two ideas as they are very different and can co-exist. We are working on adding loop characteristics to activities and will have a patch ready soon. I'll create a JIRA for it.
Thanks
Walter
-
18. Re: foreach activity
johntim Jun 15, 2010 5:10 AM (in response to swiderski.maciej)Could you describe what the notation will be for the foreach activity, also are there changes being made to the process editor to reflect the notation?
Thanks for all the work on this..
Tim
-
19. Re: foreach activity
johntim Jun 15, 2010 5:32 AM (in response to walterjs)Apologies for the confusion in my earlier posts. I had assumed the foreach was going to wrap an activity.
We have prototyped adding loop characteristics to a task using the following:
<task assignee="#{approval.getUserId()}" g="241,199,92,52" name="MITask">
<on event="start">
<event-listener class="com.sample.TaskStartListener"/>
</on>
<for-each expr="#{isComplete}" in="#{approvals}" var="approval"/>
<transition g="-8,-22" name="end" to="end"/>
</task>
This works well and does suggest additional task instances can be added during the lifetime of the activity. It would also support the BPMN multi-instance activity notation.
-
20. Re: foreach activity
swiderski.maciej Jun 16, 2010 3:33 AM (in response to johntim)Tim, here is a sample usage of foreach activity:
<foreach in="#{actors}" name="foreach1" var="item"> <transition name="to task1" to="task1"/> </foreach> <task name="task1"> <transition name="to join1" to="join1"/> </task> <join name="join1"> </join>
Please note that between foreach and join activities there can be any type of activity, including subprocess.
If it comes to designer support for this, I am working on it. Just while ago I supplied a patch for this for a review. Let's keep our fingers crossed that it will make to to next release.
I will try to find some more time to work on pending issues of GPD to have something released together with jBPM 4.4
-
21. Re: foreach activity
gubespam Oct 28, 2010 6:45 PM (in response to aguizar)Alejandro Guizar wrote:
could the implementation also include support for the isSequential flag that controls sequential or parallel execution of the activity instances?
Both fork and foreach are sequential. However, if you set the continue attribute to async in the following activities, execution can be made parallel provided the job executor is employing multiple threads.
They are sequential in the sense that jbpm only actually executes one transition at a time. However, when jbpm hits a "wait state" (ie. a custom activity that implements ExternalActivityBehavior, or a <state> activity), it will go back and begin executing the next transition. What is meant by sequential is that jbpm would not go back and begin executing the next transition until the first execution truly finishes (ie. reaches the <join>). I think, in order to do this, it would require a quite different implementation. I am judging this by looking at the ForEachAcitivity implementation as compared to the ForkActivity; they are both using the ACTIVE_CONCURRENT/ACTIVE_ROOT states for the root execution. If I am wrong in my understanding, please provide some more information. Thanks.