12 Replies Latest reply on May 24, 2010 5:58 AM by rebody

    JBPM-2414 and JBPM-2506

    swiderski.maciej

      Hi guys,

       

      I have done some work on two issues and would like to ask for your opinion on them:

      - variable declaration and history support https://jira.jboss.org/browse/JBPM-2506

      - for each functionality on fork https://jira.jboss.org/browse/JBPM-2414

       

      Thanks

        • 1. Re: JBPM-2414 and JBPM-2506
          rebody

          Hi Maciej,

           

          JBPM-2506 is very good, I will very glad to see that we could incloude this issue in jBPM-4.4.

           

          JBPM-2414 is useful, but as Ronald said that it is really difficult to understand and model.  So I want to wait for if somebody could give us other advice.  At least we need consider about how to configure the related joinActivity, because if somebody forget to set the multiplicity attribute, then the execution will wait forever.

          • 2. Re: JBPM-2414 and JBPM-2506
            swiderski.maciej

            HuiSheng Xu wrote:

             

            JBPM-2414 is useful, but as Ronald said that it is really difficult to understand and model.  So I want to wait for if somebody could give us other advice.  At least we need consider about how to configure the related joinActivity, because if somebody forget to set the multiplicity attribute, then the execution will wait forever.

            I think that problem with modelling was mainly regarding for-each as new activity.

             

            If it comes to join activity, it is not quite as you described. If you don't set multiplicity attribute on join then first incoming transition will trigger execution to move on.

             

            Let's have a discussion about it and try to find best possible solution for it. I think it is quite important functionality in many processes.

            • 3. Re: JBPM-2414 and JBPM-2506
              rebody

              Hi Maciej,

               

              You are right, if we forget to configure a multiplicity attribute, then the following path will execute many times.  And this situation is worse than dead wait.

               

              Actually, I like the WHILE node of BPEL.  But since I didn't know whether we could use GroupActivity in production environment,  I don't want to risk.

               

              Finally, I am agree this feature is very useful.  Even if we can't find the best solution, I will also vote yes on it.

               

              Thank you for your great work.

              • 4. Re: JBPM-2414 and JBPM-2506
                swiderski.maciej

                I did not test it completely but when working with following scenario:

                - fork with for each - 2 iterations

                - fork has one transition that goes to Task - assignee was based on for each variable

                - join does not have multiplicity attribute

                 

                What happened was that after first task completion the other one was not found since join decided to go on after first path reached the join activity. and task was deleted when processInstance was removed.

                 

                I agree with you that is could be serious in consequences.

                Perhaps we could try to define as much as possible scenarios to try it. In addition provide really good documentation for it in dev or user guide.

                • 5. Re: JBPM-2414 and JBPM-2506
                  rebody

                  Hi Maciej,

                   

                  I had a mistake again. The behaviour of BPEL WHILE is not equals the for-each.  The BPEL WHILE used a condition to decide when the process should keep looping or break. But the for-each is most like a dynamic parallel.  So your implementation may be the best solution.  And if we could use an expression to decide the multiplicity attribute of JoinActivity, that would be more convenient for other people to use this feature.

                  • 6. Re: JBPM-2414 and JBPM-2506
                    swiderski.maciej

                    Hi,

                     

                    thanks for valuable feedback.

                     

                    I will make sure that join activity supports multiplicity attribute as expression.

                     

                    What do you think about including it in 4.4, mainly to get response from users about currently available support and what's more would be needed.

                     

                    Will assign that issue to me.

                    • 7. Re: JBPM-2414 and JBPM-2506
                      swiderski.maciej

                      Hi,

                       

                      as suggested, I started to look into multiplicity attribute of join activity and found out that there is quite serious issue (if I got it right).

                      In general, please consider following scenario:

                      - there is a process with one fork that has three branches

                      - each of the branch points to another task activity

                      - join activity uses multiplicity attribute to continue flow as soon as two any branches will reach it

                      - after join there is a state activity

                       

                      So what will happen is that after two tasks will be completed execution will move on to state activity but the last task will still be active. So in case where some one would like to signal the execution (assuming that execution is now in state node) there will be an exception (execution[ForkJoingMultiplicity.7] is not active: inactive-concurrent-root) because signalling will be task instead of state activity.

                      In my opinion (in case of using multiplicity attribute of join) all not finished child execution should be terminated at the time of signaling join activity to prevent problems with active executions.

                       

                      Hope I described the issue good enough.

                       

                      Please find attached test case that should fail when using trunk version of join activity together with multiplicity attribute.

                       

                      I made a fix for it but just want to discuss that my understanding is correct.

                      • 8. Re: JBPM-2414 and JBPM-2506
                        rebody

                        Hi Maciej,

                         

                        In jBPM 3.x, they use discriminator and nOutOfM to decide how to solve the split executions that joined in the Join node.  Whether automaticly terminate the rest of splited execution is really a problem.  Maybe there could be a attribute to decide how we could handle that.  Please refer this issue JBPM-2720

                         

                        https://jira.jboss.org/browse/JBPM-2720

                        • 9. Re: JBPM-2414 and JBPM-2506
                          swiderski.maciej

                          Hi HuiSheng,

                           

                          Thanks for reference.

                           

                          I am wondering what we could gain with this new attribute?! Since either way execution must be ended regardless of if it has timer or not. Because if we leave such execution (with timer on transition) then such execution will be fired as soon as timer goes off.

                          Consider following scenario:

                          - for creates four branches all of them goes to a task

                          - multiplicity on join is set to 2

                          - users complete first two tasks meaning join will move on with the execution - join signals based on the multiplicity - 2 execution must be joined to continue

                          - next users complete two remaining tasks (from the fork that are still active)

                          - since multiplicity is set to 2 join will execute again - which in my opinion is wrong behavior

                           

                          My fix for this was ending all remaining forked execution only if multiplicity attribute was used so it does not break any other cases - as Ronald has pointed out in jira.

                           

                          What do you think about it? Maybe I am missing something ... so please correct me if I am wrong.

                          • 10. Re: JBPM-2414 and JBPM-2506
                            rebody

                            H Maciej,

                             

                            I think the point is whether we should achieve the discriminator design pattern.  In discriminator design pattern, the join node will end split executions when they arrived join node, it do not terminate them while the first of execution arrived join node.

                             

                            Indeed, it will increase the complex level of implements.  So I think we could terminate all other executions in jBPM 4.4.  And think about other scenarios in the future.

                             

                            By the way, I had met the wrong behaviour you mentained.  There were two managers in a department.  When a contact arrived, both of them need review it.  But if one of them is off the office, the process should not wait, the process will continue to the next step after one of them review it.  And if the other manager come back, he need review the contact again and let the process go to next step again.

                             

                            In my opinion, this process is totally strange, so we neednot achieve it in jPDL. 

                            • 11. Re: JBPM-2414 and JBPM-2506
                              swiderski.maciej

                              What I implemented is that join will terminate all left executions only when join activity will be completed, meaning that all or defined by multiplicity attribute execution have reached join node. So if I got it right this is what discriminator pattern is about?! (Please correct me if I am wrong).

                               

                              In my opinion, process that you described could be quite common so there is rather high probability that end users will encounter it. I would say that it needs to be fixed in 4.4.

                              • 12. Re: JBPM-2414 and JBPM-2506
                                rebody

                                Hi Maciej,

                                 

                                OK.  seems we could agree with each other.  It will be great if we could put this feature in the jBPM 4.4.