1 2 Previous Next 17 Replies Latest reply on Feb 8, 2010 7:41 PM by nick.bauman

    Upgrade from JBPM3 to JBPM4 woes

      Hello,

      I'm looking into upgrading our process definitions and integration /
      embedding code written in JBPM3 to JBPM4. Our code does not use any
      application server like JBoss so we do not rely on container or third
      party integration.

      Needless to say I see quite a lot has changed now that version 4 has
      arrived. The JBPM3 technology was more of a classic Finite State
      Machine. JBPM4 seems to have a new layer of abstraction: I see no sign
      of any GraphElement, Node, State, Transition, ActionHandler,
      ExecutionContext etc etc. I'm having a hard time seeing where these
      things morphed into or whether the original FSM idiom is simply gone.
      Stuff like "Swimlane" and "Task" strikes me as quite the departure so
      I'm not holding much hope.

      Currently we have several dozen process definitions ranging from 10 to
      40 elements, the larger ones end up being around 1500 lines of XML. Is
      it even worth it to try and figure out where JBPM4 can fit into a
      migration strategy from JBPM3? I see some stuff that's named similarly
      in a package called org.jbpm...internal (that "internal" seems quite
      the red flag) that unfortunately isn't even close to the old code
      interface-wise.

      Specifically can anyone tell me where GraphElement, Node, State,
      Transition, ActionHandler, ExecutionContext may have gone or how
      they've changed?

      Thanks,

      Nick

        • 1. Re: Upgrade from JBPM3 to JBPM4 woes

          You can go through the following link

           

          http://docs.jboss.org/jbpm/v4/devguide/html_single/#d0e2292

           

          I think it will help you in migration from jbpm 3 to jbpm 4 and changes to apply for it.

           

          along with its Process conversion tool to convert jbpm 3 to jbpm 4

          • 2. Re: Upgrade from JBPM3 to JBPM4 woes
            Anand,

            Thanks I saw that. I'll probabaly use that at some point. I'm more interested in the integration code I have that interacts with the internals of the workflow engine: where GraphElement, Node, State, Transition, ExecutionContext may have gone or how they've changed?

            I've since figured out what happened with ActionHandler: It became ActivityBehavior. Another one: ContextInstance became ActivityExecution.

            These two changes weren't too hard to sort out. The hard questions begin to arise where our use of JbpmTemplate to integrate with Spring is utterly broken because of how JBPM4 integrates with Spring. Any tips on migration here would be helpful, too.

            • 3. Re: Upgrade from JBPM3 to JBPM4 woes
              kukeltje
              Thanks I saw that. I'll probabaly use that at some point. I'm more interested in the integration code I have that interacts with the internals of the workflow engine: where GraphElement, Node, State, Transition, ExecutionContext may have gone or how they've changed?

               

              As mentioned in some blogs (and some docs to, not sure), the way of interacting with jBPM changed a lot. Instead of knowing the internal model, you are supposed to interact with the engine through services.

               

              I've since figured out what happened with ActionHandler: It became ActivityBehavior. Another one: ContextInstance became ActivityExecution.

               

              This is only partly true. ActivityBehaviour is for implementing custom nodes (als you could in jBPM3). ActionHandlers were used in more places than this. ContextInstance can also not be 1:1 mapped toActivityExecution, but in some places it is the replacement (from my head)

               

              These two changes weren't too hard to sort out. The hard questions begin to arise where our use of JbpmTemplate to integrate with Spring is utterly broken because of how JBPM4 integrates with Spring. Any tips on migration here would be helpful, too.

               

              The JbpmTemplate has been broken for several years. It has never been compatible with 3.2 and to be honest, it provided little advantage (just like at the time the HibernateTemplate provided little advantage).

               

              Wanna use 4? Use the Spring integration provided by 4. Do *not* try to (ab)use the old spring template. Migration of this is unfortunately a manual task.

               

              Cheers,

               

              Ronald

              • 4. Re: Upgrade from JBPM3 to JBPM4 woes

                Thanks Ronald,

                 

                That's too bad. We're blazing a trail with what we can get compiling and passing tests, hoping your warnings aren't going to be showstoppers.

                 

                Well, we interact directly with the ProcessInstance on workflow start. We also have a couple of places where external timers work with processes in progress.

                 

                Specifically what we do in v3:

                 

                Node currentWaitState = pi.getRootToken().getNode();
                for (int i = 0; i < timedNodes.length; i++) {
                   if (timedNodes[i].equals(currentWaitState.getName())) {
                     // Can we get out of here?
                     if (currentWaitState.hasLeavingTransition(TIME_OUT)) {
                       pi.signal(TIME_OUT);
                       return;
                     }

                    // Misconfigured process definition
                     throw new RuntimeException("Workflow timed out on current state, but no corresponding timeout transition found.");
                   }
                }
                log.debug("Workflow departed any timed state.");

                 

                Not sure how we sort that atm for v4. v3 was much more "hackable", and I mean that in a good way. The model was pretty small and coherent: the only thing that didn't make a lot of sense was why you have Node and State. Should be just State is a non-transient and Node is a transient state. IOW a boolean would have worked, my $0.02.

                 

                Spring integration: What worked well with us was making various adaptors for Spring DI into a process defintion where JbpmTemplate was less than perfect.

                 


                • 5. Re: Upgrade from JBPM3 to JBPM4 woes
                  kukeltje

                  Nick,

                   

                  Not sure how we sort that atm for v4.

                   

                  Your example should still be possible. use e.g. the  getActiveActivities on the execution service to get 'nodenames'. Getting the transition of all kinds of 'nodes' is going to be an addition in 4.4. afaik.

                   

                  v3 was much more "hackable", and I mean that in a good way.

                  4 stil is, You can often cast to *Impl classes and do more. The major difference is that there is an official 'stable' public api and you should use services to interact with the engine, not the model itself

                   

                  So e.g.

                   

                  processInstance.signal()

                   

                  becomes

                   

                  executionService.signal(processInstance);

                   

                  The model was pretty small and coherent:

                   

                  Sure? Others think differently... I agree that once you were into it it was usable. But I've seen many do it wrongly.

                  the only thing that didn't make a lot of sense was why you have Node and State.

                   

                  This one is clear... Node had no default behaviour... just like custom in jBPM 4. State  was just a state, like in jBPM 4

                   

                   

                  Should be just State is a non-transient and Node is a transient state. IOW a boolean would have worked, my $0.02.

                   

                  Yes but that was because you could add 'custom behaviour' to state to. Should not have been so, then the difference would have been much more clear.

                   

                  Spring integration: What worked well with us was making various adaptors for Spring DI into a process defintion where JbpmTemplate was less than perfect.

                   

                   

                  Anything less then perfect (ok, exaggerated a little) should not be used or fixed. Nobody ever did fix the template.... why? Not used a lot? Scared? .... If I may ask why didn't you?

                   

                  Cheers,

                   

                  Ronald

                  • 6. Re: Upgrade from JBPM3 to JBPM4 woes

                    Ronald,

                     

                    Great tips, really appreciate!

                     

                    You can often cast to *Impl classes and do more

                     

                    I think I was poking around and saw that, but it didn't feel good to downcast. I'll have another look.

                     

                    We have been able to get pretty far with executionService too like you describe, too. The Node versus State discussion is my bad: I always saw State as being non-transient and Node as being transient: having written an FSM in both Java and JavaScript, I guess I have my own prejudices and they're showing. I used the concept of Guards on Transitions that held the decision logic instead of using Decision states. Nothing wrong with Decision States, mind you.

                     

                    Nobody ever did fix the template.... why? Not used a lot? Scared? .... If I may ask why didn't you?

                     

                    I think I just wasn't at a place where I felt we had it down and felt justified enough to change what's in the jar and submit a patch. There is quite a bit of resistance initially (technical debt incurrance being only one consideration) to going into 3rd party code unless you're really sure you know what you're talking about: to whit this conversation

                     

                    Thanks again,

                     

                    Nick

                    • 7. Re: Upgrade from JBPM3 to JBPM4 woes

                      I intervene in this discussion, because I am facing the opposite problems.

                      We was evaluating JBPM4 but we are not able to find useful example or info:

                      • most examples refers to JBPM3 syntax
                      • Exception handling present in JBPM3 are disappeared in JBPM4 and we need them using third-party Java classes

                      Actually, we are not able to implement even a simple "start - execute java - catch exception - end" process; we also open a thread:

                       

                      http://community.jboss.org/thread/146114

                       

                      but we get answer only from one user and no code sample to prove something is possible to solve the problem.

                      We are thinking to downgrade to JBPM3 or probably evaluate another product, if JBPM is going to do not handle such simple scenarios like this.

                      We suspected we are facing problems because we are newbies on JBPM, but the lack of answers of our questions are starting to reveal deficiency in the JBPM.

                       

                      I hope someone here is able to give us answers to our doubts. I am starting to ask to myself what do you call or manage inside JBPM tasks...

                       

                      A desperate JBPM user

                      • 8. Re: Upgrade from JBPM3 to JBPM4 woes

                        Flavio,

                         

                        I hear ya, man. I'm struggling with JBPM4 still.

                         

                        We have a way to do subworkflows that work ok for us in JBPM3 (we just can't allow the subworkflow to have a wait state, pretty big limitation but we've worked around it so far). As far as transactions are concerned, we actually DO NOT want ANY persistent store because we use clustered memory that reads from hardware devices in the field. IOW the process instance runs in an environment that is not the System of Record: what's going on in the field where the hardware is the "truth" and if our process defintion blows up, we simply go back to the field to read the correct state of the system. Since we have realtime requirements, using any kind of disk database is much too slow anyway.

                         

                        Alternatives? Writing a simple FSM isn't that hard, by the way. Its main purpose is to limit the amount of mutable state visible in your application. It accomplishes this by seperating what gets done from deciding what to do. What JBPM does for you on top of this is to give you all the integration and GUI tools to work with, and a community of people making it better and better.

                        • 9. Re: Upgrade from JBPM3 to JBPM4 woes
                          kukeltje

                          Actually, we are not able to implement even a simple "start - execute java - catch exception - end" process; we also open a thread:

                           

                          http://community.jboss.org/thread/146114

                           

                          but we get answer only from one user and no code sample to prove something is possible to solve the problem.

                          First, if there already *is* another thread, there is no need to highjack another one. And the answer that user is giving is GOOD. Java exceptions should normally not come to the process level... Changing the state from exceptionhandlers was also in jBPM 3 *not advised* and not used a lot (afaik)

                           

                          Code examples of how to use the suggestions made by the user are planty.. There are examples in the source, testcases etc... so...

                           

                          We are thinking to downgrade to JBPM3 or probably evaluate another product, if JBPM is going to do not handle such simple scenarios like this.

                           

                          It IS handling such simple scenarios, just not like you want it. You have made just 4 posts in this forum on just ONE day and you are already complaining? May I ask why that is?

                           

                          We suspected we are facing problems because we are newbies on JBPM, but the lack of answers of our questions are starting to reveal deficiency in the JBPM.

                          The lack of answers???? Wow, sorry but this really surprises me... the answers to your other topic are good. Might be that you do not directly understand where they are directing you. If that is the case, ask politely and were more then willing to help. And saying that a lack of answers is revealing the real deficiency is even a bigger surprise. If that realy is your feeling in a COMMUNITY (help from peers!!!!) forum after this short period, maybe it is beter for you to find another engine and move on... Sorry...

                           

                          I hope someone here is able to give us answers to our doubts. I am starting to ask to myself what do you call or manage inside JBPM tasks...

                          Again, answers to what? The answers in your other topic are spot on.... And by starting to wonder what you manage inside jBPM tasks, I think you should read the basic userguide and maybe some blogs on the internet... Personally (and without wanting to offend you) I get the feeling you blame us for your (at this moment) lack of understanding of jBPM.

                           

                          Peace...

                           

                          Ronald

                          • 10. Re: Upgrade from JBPM3 to JBPM4 woes

                            Sorry for the misunderstanding.

                            When I told about lack of answers I didn't mean in THIS forum. We already searched around and not from today, and that was my comment about.


                            My intent is not to "blame" anyone: for sure we (not just I) seem to have a lack of understanding of jBPM and I really hoped someone says me "You don't understand nothing at all: the things can be manged in this way".

                            It seems you're a veteran here, so it could be great if you can suggest us some specific reference to the examples, testcases, source and so on you was talking about, because we really was not able to find anything (our fault, I am the first to admit that).

                             

                            Peace

                            Flavio

                            • 11. Re: Upgrade from JBPM3 to JBPM4 woes

                              So in V4 the above looks like so?

                               

                              ActivityImpl currentWaitState = ((ExecutionImpl) pi).getActivity();
                              for (int i = 0; i < timedNodes.length; i++) {
                                 if (timedNodes[i].equals(currentWaitState.getName())) {
                                   // Can we get out of here?
                                   if (currentWaitState.hasOutgoingTransition(TIME_OUT)) {
                                     ((ExecutionImpl)pi).take(TIME_OUT);
                                     return;
                                   }

                                   // Misconfigured process definition
                                   throw new RuntimeException("Workflow timed out on current state, but no corresponding timeout transition found.");
                                 }
                              }
                              log.debug("Workflow departed any timed state.");

                              • 12. Re: Upgrade from JBPM3 to JBPM4 woes
                                kukeltje

                                No, what you do here is mimic the 3.x way in 4.... Casting should only be needed if the services do, at the time, not provide you the methods to do what you need to do. Think SERVICES!!! ;-)

                                 

                                In semi-pseudo code

                                 

                                      Set<String> anl = pi.findActiveActivityNames();
                                      
                                      for (String an : anl) {
                                        for (int i = 0; i < timedNodes.length; i++) {
                                          if (timedNodes[i].equals(an)) {
                                            Execution e = pi.findActiveExecutionIn(an);
                                        
                                            executionService.signalExecutionById(e.getId(), (TIME_OUT));
                                          }
                                        }
                                      }
                                

                                 

                                But may I ask what you are trying to achieve? Personally I would solve the usecase u seem to have (I think) is put timers on transitions. This would take care of all this automagically.

                                • 13. Re: Upgrade from JBPM3 to JBPM4 woes

                                  Ronald,

                                   

                                  This is really good to know, thanks for the pseudocode.

                                   

                                  I did see there were timers on transitions in the new JBPM4, but the goal is to get what we have in v3 nominally working and then evolving it toward the featureset / sweetspot of v4.

                                   

                                  At this time we have decided to back off the migration, deeming it too much risk. The final straw was the conversion tool barfing on our process defintions: they insisted that an activity without an action (we had them linked to the node-enter or exit event) was "invalid" when clearly they aren't. We found the place in the conversion tool where this assumption is made, so in theory it wouldn't be too bad a fix. But in the final analysis, because v4 is different enough from v3, we are now opening up the playing field at looking at other BPM workflow solutions in Java, including rolling our own.

                                   

                                  This note isn't to be taken as a knock against JBPM4. This is more about the confluence of timing, opportunity, reward and risk in our own world.

                                   

                                  Thanks again,

                                   

                                  Nick

                                  • 14. Re: Upgrade from JBPM3 to JBPM4 woes
                                    kukeltje

                                    nick.bauman wrote:

                                     

                                    At this time we have decided to back off the migration, deeming it too much risk...<snip>...But in the final analysis, because v4 is different enough from v3, we are now opening up the playing field at looking at other BPM workflow solutions in Java, including rolling our own.

                                    You are always free to make this choice. What does make me wonder though is how you asses the risk of something different but existint (jbpm 3 vs 4) in relation to something none existing. I've seen in my previous job that often the choice was made to role something ourselves (themselves I should say since I never supported it). Some time later it almost always backfired in multiple ways. And migrating from jBPM3 to another BPM solution almost certainly as difficult as migrating to jBPM4.


                                     

                                    This note isn't to be taken as a knock against JBPM4. This is more about the confluence of timing, opportunity, reward and risk in our own world.

                                    I understand I think... Well I understand it is not a knock against jBPM4, but in line with my previous remark, I do not understand. Why not 'just' continue with jBPM 3, maybe even extend it? A Basic FSM is indeed not difficult to develop, but adding all kinds of things around it, makes it more and more complex (have experience in this area with a workflow and forms solution)

                                     

                                    So I am truly honestly, openly interested in the ++/+/0/-/-- lists/ Balanced scrore card/SWOT-analysis leading to this without wanting to lure you back :-)

                                     

                                    Cheers,

                                     

                                    Ronald

                                    1 2 Previous Next