1 2 Previous Next 21 Replies Latest reply: Oct 28, 2010 6:45 PM by Mike M RSS

foreach activity

Alejandro Guizar Master

Stemming from a JBPM-2414 and JBPM-2506 I want to discuss JBPM-2414 separately. The original proposal in the jira issue showed a foreach activity separate from fork. At some point the collection iteration behavior got merged into fork for no reason other than "making it visible in the designer, now". In my view, the foreach and the fork behaviors respond to different needs and should not be merged.

 

As precedents, I can think of BPEL 2 and its flow and forEach activities. The former provides static parallelism of multiple activities. The latter provides dynamic parallelism of a single activity; nothing prevents this single activity from being a flow. Giving each activity a single responsibility makes its behavior concise and simple to describe.

 

I suggest we introduce a separate foreach activity instead of adding iteration semantics to fork. The binding and activity code that Maciej wrote is kept intact. Only one outgoing transition is allowed. The transition condition MAY refer to the variable specified in the var attribute. If the transition condition evaluates to false, the corresponding child execution does not leave the activity. If no child execution leaves the activity, an exception is thrown.

 

<foreach name="multiplier" var="item" in="#{items}">
  <transition to="task" name="to_task" expr="#{item.value &gt; 10}"/>
</foreach>

 

I am going to prepare a patch with this proposal and attach it to JBPM-2414 for your review.

  • 1. Re: foreach activity
    Walter Seymore Newbie

    This sounds perfect! Will it make it into the 4.4 release?

  • 2. Re: foreach activity
    Maciej Swiderski Master

    My first intention was to reuse Ronalds work but since we did not get it I tried to follow the guides (latest in jira discussion) to implement that behavior.

    Keeping them separate sounds like a good idea, although I have few questions:

    • is expr attribute mandatory?
    • what about joining these parallel executions - since one task can be completed before the others
    • how could we decide when the execution move further - something like multiplicity attribute of join
  • 3. Re: foreach activity
    Tim Johnson Newbie

    BPMN 2.0 introduces the multi-instance loop characteristic for activities. The expr attribute is similar to the completionCondition (this is what I meant in my comment on JBPM-2414), could the implementation also include support for the isSequential flag that controls sequential or parallel execution of the activity instances?

     

    Also can the ability to initiate additional activity instances be supported? This is described in workflow pattern 36 (http://www.workflowpatterns.com/patterns/control/new/wcp36.php). Could this be implemented with an event listener (<on event="end">) added to the foreach? For example: Three contracts are scheduled for drafting, during the execution of one of these activities an additional contract draft is deemed necessary, this is added by the event listener before the completeCondition expression is evaluated.

     

    The current patch in JBPM-2414 supports only multiple task instances, it would be great if your solution could support sub-processes.   

  • 4. Re: foreach activity
    Alejandro Guizar Master

    Maciej Swiderski wrote:


    • is expr attribute mandatory?
    • what about joining these parallel executions - since one task can be completed before the others
    • how could we decide when the execution move further - something like multiplicity attribute of join

    The expr attribute is not mandatory: if not present, child executions are created unconditionally.

     

    The separate foreach activity does not bring new problems for joining and proceeding further. The current join activity suffices for that purpose. Perhaps I'm missing something?

  • 5. Re: foreach activity
    Alejandro Guizar Master

    Tim Johnson wrote:

     

    BPMN 2.0 introduces the multi-instance loop characteristic for activities. The expr attribute is similar to the completionCondition (this is what I meant in my comment on JBPM-2414)   

    The expr attribute in the transition that leaves from foreach is not a completion condition. It is more of a creation condition. If the condition is not met for a particular element of the collection, the child execution that would correspond to that element is not created.

     

    In JBPM-2414 you suggested a completion condition be added to join. As Maciej noted, this is already provided by the  multiplicity attribute. As part of his work on JBPM-2720 he made multiplicity accept expressions in addition to literal numbers.

    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.

    Also can the ability to initiate additional activity instances be  supported? This is described in workflow pattern 36 (http://www.workflowpatterns.com/patterns/control/new/wcp36.php).  Could this be implemented with an event listener (<on  event="end">) added to the foreach? For example: Three contracts are  scheduled for drafting, during the execution of one of these activities  an additional contract draft is deemed necessary, this is added by the  event listener before the completeCondition expression is evaluated.

    In the interest of getting this done as soon as possible to release 4.4, let us not add new requirements. We can always revisit later.

    The current patch in JBPM-2414 supports only multiple task instances, it  would be great if your solution could support sub-processes.

    Any activity may follow foreach, not just tasks.

  • 6. Re: foreach activity
    HuiSheng Xu Master

    Hi Alejandro,

     

    Glad to hear that you are working on this feature.  Really want to see it could be included in the jBPM 4.4.

     

    BTW, when could we release the jBPM 4.4?  We had already closed 80 issues, is it enough?

     

    regards.

  • 7. Re: foreach activity
    Walter Seymore Newbie

    Hi Alejandro,

     

    Alejandro Guizar wrote:


    The expr attribute in the transition that leaves from foreach is not a completion condition. It is more of a creation condition. If the condition is not met for a particular element of the collection, the child execution that would correspond to that element is not created.

     

    In JBPM-2414 you suggested a completion condition be added to join. As Maciej noted, this is already provided by the  multiplicity attribute. As part of his work on JBPM-2720 he made multiplicity accept expressions in addition to literal numbers.


    I also thought the expression was a completion condition. Are you saying that the multiplicity attribute can be used in the same way? Let's say a rule execution determines that it should complete, would it be possible to write a multiplicity expression like this (pseudo code) "#{rule.result ? numberCompleted : items.size}"?

     

    Thanks

    Walter

  • 8. Re: foreach activity
    Maciej Swiderski Master

    fair enough. Now I have full picture of it.

     

    It is not big change after all, but make it more clear and it is more flexible since we can control both sides (creation and continuation). I think you covered all.

     

    There will be a need for slight update of the examples and docs.

  • 9. Re: foreach activity
    Alejandro Guizar Master

    The patch is ready for  review. Took a while to iron certain wrinkles out. Comments appreciated. I will reincorporate Maciej's documentation once we are past acceptance testing.

    HuiSheng Xu wrote:

     

    BTW, when could we release the jBPM 4.4?  We had already closed 80 issues, is it enough?

    More than enough, I would say. I'll try to commit this week to closing the remaining issues.

  • 10. Re: foreach activity
    Maciej Swiderski Master

    Walter Seymore wrote:


    I also thought the expression was a completion condition. Are you saying that the multiplicity attribute can be used in the same way? Let's say a rule execution determines that it should complete, would it be possible to write a multiplicity expression like this (pseudo code) "#{rule.result ? numberCompleted : items.size}"?

     

    Thanks

    Walter

    It is more like surrounding activities that needs to be executed in a loop than attaching loop characteristic to an activity. Meaning that there are two sides with separated responsibilities:

    • for each activity that is responsible for creating required activity instances based on outgoing transition and expr attribute
    • join activity that is responsible for continuing the flow based on number of incoming transitions and multiplicity attribute

     

    Answering to your question, yes, you can use any expression that is supported by juel. Currently all evaluation on multiplicity attribute is done by JUEL script engine.

  • 11. Re: foreach activity
    Alejandro Guizar Master

    Walter Seymore escribió:

     

    I also thought the expression was a completion condition. Are you saying that the multiplicity attribute can be used in the same way? Let's say a rule execution determines that it should complete, would it be possible to write a multiplicity expression like this (pseudo code) "#{rule.result ? numberCompleted : items.size}"?

    The multiplicity expression can be used as a completion condition, but I know what you mean. It has to return an integer instead of a boolean. While the expression can read the process variables, requiring a numeric result makes completion conditions that depend on variables besides the number of joined executions rather cumbersome.

     

    On the other hand, the foreach examples provided so far can be resolved without a boolean completion condition. Plus, the multiplicity attribute was already present since version 4.0 of the jPDL schema. Relying on it for version 4.4 gives us time to discuss if we will need a more generic completion condition.

  • 12. Re: foreach activity
    Maciej Swiderski Master

    I looked into the patch and to me it looks very good. It was missing some of the mentioned functionality:

    • condition on expression was not supported
    • verifying number of transition for foreach activity - exactly one transition must be given
    • troubles with evaluating expressions on child executions (wrong context)
    • if no transition conditions evaluated to true no exception was reported but for each activity was simple ended - bit different to what was described in the first post

     

    I have done required fixes and the patch can be found in jira. In addition I have added several test cases to check verify the implementation.

     

    Comments are more than welcome.

  • 13. Re: foreach activity
    Alejandro Guizar Master

    condition on expression was not supported

    Did this fail to pass your tests?

    verifying number of transition for foreach activity - exactly one  transition must be given

    Right. Good catch.

    if no transition conditions evaluated to true no exception was reported  but for each activity was simple ended

    This is an intentional deviation. I observed that the fork activity does not throw an exception if no concurrent executions leave the fork. I thought foreach should be consistent with that behavior.

  • 14. Re: foreach activity
    Maciej Swiderski Master

    Alejandro Guizar wrote:

     

    condition on expression was not supported

    Did this fail to pass your tests?

    Yeap, condition was not set on transition at all. So no evaluation was performed. I modified binding for for each activity.

     

    Alejandro Guizar wrote:

     

    if no transition conditions evaluated to true no exception was reported  but for each activity was simple ended

    This is an intentional deviation. I observed that the fork activity does not throw an exception if no concurrent executions leave the fork. I thought foreach should be consistent with that behavior.

    ok, I examined decision activity instead, since it has quite the same approach - conditions on transition.

1 2 Previous Next