-
1. Re: foreach activity
walterjs Jun 8, 2010 3:21 AM (in response to aguizar)This sounds perfect! Will it make it into the 4.4 release?
-
2. Re: foreach activity
swiderski.maciej Jun 8, 2010 4:12 AM (in response to aguizar)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
johntim Jun 8, 2010 11:03 AM (in response to aguizar)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 Jun 8, 2010 4:49 PM (in response to swiderski.maciej)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 Jun 8, 2010 6:03 PM (in response to johntim)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 Jun 8, 2010 10:00 PM (in response to aguizar)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 Jun 9, 2010 3:33 AM (in response to aguizar)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 Jun 9, 2010 4:43 AM (in response to aguizar)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 Jun 9, 2010 4:47 AM (in response to rebody)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 Jun 9, 2010 4:50 AM (in response to walterjs)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 Jun 9, 2010 5:36 AM (in response to walterjs)Walter Seymore escribió:
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 Jun 9, 2010 10:00 AM (in response to aguizar)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 Jun 9, 2010 10:14 AM (in response to swiderski.maciej)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 Jun 9, 2010 11:00 AM (in response to aguizar)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.