JBossDeveloper

Great

Will do so today evening. It will not contain docs but as you mentioned will be incorporated bit later.

Cheers

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

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

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.

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

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.