1 2 Previous Next 24 Replies Latest reply on Mar 18, 2008 11:11 PM by kukeltje

    Deployment order of dependent process definitions

      It seems that if I have process definition 1, which refers to process definition 2 in a process-state node, I must ensure that I deploy 2 before 1, i.e. that sub-process resolution is done at deployment time. Failure to do that results in a an error "Can't create process instance when processDefinition is null"

      I can't see how this will be workable in a moderately complex scenario where consultants are able to modify and re-upload process definitions.

      Can we not defer sub-process definition resolution to runtime?

      Or have I got the wrong end of the stick :)

        • 1. Re: Deployment order of dependent process definitions
          kukeltje

          One 'wrong' end of the stick (maybe I should say 'other' although not many sticks have two 'useful' ends ;-) ) is

          I can't see how this will be workable in a moderately complex scenario where consultants are able to modify and re-upload process definitions.


          IMHO (and Toms' and many others), consultants are not the ones to deploy things. Read Tom's blogs to see what the point of view of jBPM is.

          • 2. Re: Deployment order of dependent process definitions

            OK - forget consultants or not consultants - it is not the point.

            The point is - are we expected to remember the deployment order of process definitions. This seems unworkable in a complex scenario, no matter who handles the deployment.

            Why can sub-process definition resolution not be left until runtime?

            • 3. Re: Deployment order of dependent process definitions
              kukeltje

              hey, you brought it up yourself ;-) It could ofcourse be left until runtime, but then the parent process won't run since the subprocess is not there. You have to react to that as well. IMO you do not want runtime errors because of this and thus want to have all processes deployed when you start some new instance. A CMDB would be great for this, either way right? Or do I mis something?

              If it is just the order, you could create a small ant script that deploys all the relevant processes in the correct order. This ant script could probably be generated from the CMDB. We try to automate as much of this as possible to prevent errors, deploy time or runtime

              • 4. Re: Deployment order of dependent process definitions

                 

                hey, you brought it up yourself ;-)


                ?? - I wasn't angry about anything. Apologies if that appeared to be the tone :)

                IMO you do not want runtime errors because of this and thus want to have all processes deployed when you start some new instance


                Can't we leave that decision to users rather than making it for them?

                A CMDB would be great for this, either way right? Or do I mis something?


                What's a CMDB?

                • 5. Re: Deployment order of dependent process definitions

                  I've just re-read the thread in its entirety. We're getting crossed wires. I'm about to re-post.

                  • 6. Re: Deployment order of dependent process definitions

                    Sorry, let's start again - we're actually agreeing, and it seems I did not express my original post adequately.

                    (PD = Process Definition)

                    I have PD 1 and PD 2.

                    PD 1 refers to PD 2 as a sub-process.

                    I deploy PD 2.
                    Then I deploy PD 1.

                    They are both now deployed.

                    Then I create a process instance from PD 1. It fails, saying that PD 2 does not exist. This is wrong(?)

                    Start from scratch.

                    I deploy PD 1.
                    Then I deploy PD 2.

                    They are both now deployed.

                    Then I create a process instance from PD 1. Everything works fine.

                    Of course, all PDs must be deployed at the time the process instance is created. But should it be necessary that I deploy them in the correct sequence?

                    • 7. Re: Deployment order of dependent process definitions
                      kukeltje

                      I did not think the tone of your post was 'angry' not at all. Sorry if you got the impression that I got the impression that...... well enough :-)

                      hhmmm. in you example you say PD2 is a sub process, you deploy it first, then yuou deploy the parent and the parent cannot find the sub if an instance is created??? Hmmm if that is true it is indeed strange.

                      We largely agree, but I *do* think that deploying in the order of all subs then parent is not wrong. Otherwise you could get a runtime error if you start (like in your first example, but I'd suspect that to happen in the second case... )

                      • 8. Re: Deployment order of dependent process definitions
                        hosierdm

                        I personally agree in general with what you are saying, but I think there is a slight problem with it. Deployed processes are versioned. Let's say you start with PD1 and PD2, PD2 is a subprocess of PD1. Each one is version 1, no problem. Then let's say you redeploy PD2, but forget to redeploy PD1 (PD1 is v1, PD2 is v2). The version 1 definition of PD1 is linked to version 1 of PD2, but if you resolve at runtime, PD1 will get an instance of PD2 version 2, which is not the correct definition of PD1. Essentially, resolving subprocesses at runtime invalidates the concept of process definition versioning. Furthermore, what if you had an instance of a super process that is currently active and then you deploy an update to one of its subprocesses before the instance reaches that subprocess? The process would not execute in the manner as expected when the instance was started.

                        I believe there was a discussion either in this forum or the developer forum about allowing a setting to tell jBPM to always just take the latest definition of a subprocess when executed; you should search for that thread and add your thoughts. I think it was related to what you're talking about here.

                        • 9. Re: Deployment order of dependent process definitions

                           

                          I did not think the tone of your post was 'angry' not at all. Sorry if you got the impression that I got the impression that...... well enough :-)


                          No worries - that's cleared up now :)

                          hhmmm. in you example you say PD2 is a sub process, you deploy it first, then yuou deploy the parent and the parent cannot find the sub if an instance is created??? Hmmm if that is true it is indeed strange.


                          Yes that's exactly my experience. Should I raise a JIRA for it if I can provide a simple test case that demonstrates it?

                          • 10. Re: Deployment order of dependent process definitions
                            kukeltje

                            please do. But I would expect a test case for this to be already available, maybe not with the behaviour we both expect, but at least available. Check that out first pelase

                            • 11. Re: Deployment order of dependent process definitions
                              kukeltje

                              please do. But I would expect a test case for this to be already available, maybe not with the behaviour we both expect, but at least available. Check that out first pelase.

                              CMDB= Configuration Management DataBase

                              • 12. Re: Deployment order of dependent process definitions

                                 

                                Furthermore, what if you had an instance of a super process that is currently active and then you deploy an update to one of its subprocesses before the instance reaches that subprocess? The process would not execute in the manner as expected when the instance was started.


                                When I say runtime, I mean process instantiation time. So when a process based on PD1 is started, all subprocess definitions are resolved then.

                                I did not mean resolving it when the token reaches the process state.

                                • 13. Re: Deployment order of dependent process definitions
                                  kukeltje

                                  Simon,

                                  So do you mean to alway use the latest version of a subprocess from whatever version of the parent process? David is right there is a discussion on this in the forum (me to lazy to search now, sorry ;-))

                                  If you do not mean this, I would not want this to happen when instantiating process. Then it would be a problem our customers run in to, I (and my employer) want this validation to happen when we deploy things. Well in advance of customers using it.

                                  • 14. Re: Deployment order of dependent process definitions

                                    Let's just take a step back here, and establish how it *does* work.

                                    When I deploy process PD1 that refers to PD2, it searches the database, finds the latest version of PD2, and hard-links to that version at deployment time.

                                    All process instances created from PD1 will link to the version of PD2 found when PD1 was deployed, regardless of how many times PD2 is updated.

                                    Is that right?

                                    So if I update PD2 and redeploy it, I need to re-upload PD1 to have jBPM link it to the latest PD2?

                                    I'm not saying whether that is good or bad - can you just confirm or deny that is how it works?

                                    I will look for the other thread now.

                                    1 2 Previous Next