1 2 Previous Next 21 Replies Latest reply on Oct 28, 2010 6:45 PM by gubespam

    foreach activity

    aguizar

      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
          walterjs

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

          • 2. Re: foreach activity
            swiderski.maciej

            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

              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
                aguizar

                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
                  aguizar

                  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
                    rebody

                    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
                      walterjs

                      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
                        swiderski.maciej

                        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
                          aguizar

                          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
                            swiderski.maciej

                            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
                              aguizar

                              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
                                swiderski.maciej

                                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
                                  aguizar

                                  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
                                    swiderski.maciej

                                    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