5 Replies Latest reply on Jul 21, 2009 4:30 AM by kukeltje

    Help with massive architectural problem: old jbpm processes

    donorschoose

      So as I understand it, running jBPM 3.1 processes cannot be migrated to new process definitions. This has, ironically, created a situation in which jBPM has become the single component in our architecture which prevents the evolution of the workflow process definitions. Allow me to elaborate.

      Note: I joined DonorsChoose after this architectural problem was baked into the code, so I'm searching for a way around/out of it now.

      DonorsChoose.org is a non-profit dedicated to funding projects and proposals created by teachers and funded by donations from the public. A given proposal is instantiated as a jBPM process instance.

      When DonorsChoose.org first chose jBPM, the idea was that using a workflow library would make it much easier to modify the workflow process definitions as the needs of the organization changed. In practice, however, it has made it far more difficult to evolve the workflow process definitons. In particular, we have frequently had the need to add a new transition or modify the process definition because of a change in the business process environment. However, even when we make a change to the process definition that doesn't delete any existing tokens, etc., old process instances still run using the old version of the definition. However, our processes often live for months or longer, and the whole point of changing the process is so we can update all the existing proposals in place.

      Given this, it has made it extremely difficult to modify the jBPM process definitions at all, and in fact what we've resorted to doing is hacking around this as touching the jBPM process definitions is unworkable for our application. It seems in retrospect we would have been much better off manually coding our workflows rather than trying to use jBPM.

      What I'm posting about is --- is there some way to deal with this situation? Is there a way to hack jBPM so we can do things like add transitions or other nondestructive modifications to process definitions which would apply to running instances?

        • 1. Re: Help with massive architectural problem: old jbpm proces
          kukeltje

          Donorchoose,

          Fist of all, using a workflow engine makes it easier to quickly develop process oriented applications. It does not necessarily make it easier to migrate.

          If you search the forums in a little detail, you will see that it is not impossible to migrate running instances, but that it is not something that is supported by the jBPM community. Small changes are not that difficult but require db manipulation. Just have a look at how the db structure is and it will become fairly obvious. It mainly boils down to changing foreignkeys.

          It surprises me you frequently have the need to add/change transitions etc... feels like a very 'ad-hoc' process. If business processes change that often, there is a more substantial underlying problem imo.

          • 2. Re: Help with massive architectural problem: old jbpm proces
            donorschoose

            It seems to me that not having tools to migrate running processes is a serious flaw. As for having to change our process --- that's really not a relevant remark. We have a very complex business process and it has been three years since DonorsChoose first chose jBPM. Throughout that period of course the business process has evolved. It doesn't change constantly, but it does change, and so far we've simply avoided even touching the jBPM graph because we haven't been able to migrate running processes. (When I say "we" I mean the team prior to my joining --- I'm hoping to rectify this).

            I did a quick search for "migrate running processes" and didn't find any guide to this process --- one of our engineers attempted to modify the DB in place but didn't find an easy way to do this. If anyone could point to documentation of the DB schema or a forum topic where someone discusses this, that would be most appreciated.

            • 3. Re: Help with massive architectural problem: old jbpm proces
              shekharv

              Check if this will help for now:
              http://www.google.com/search?client=safari&rls=en-us&q=jbpm+process+migration&ie=UTF-8&oe=UTF-8

              You can start from here and then see how it goes, but again this is not for the faint hearted.
              Having said that, it is not impossible, and totally depends on what kind of process you have.

              I have done simple test simulations where. data is converted using a driver program that put in very simple words, 're-runs' the process.

              Now this and portions of this might or might not be feasible in your case.

              But again, with the database structure being a lot more formal in the v3, you can attempt to repoint the tokens and make other changes. I have not done that personally at that level, so cannot comment on that approach, but, as Ronald mentioned, given enough understanding of the database, and your process being conducive, who knows, it might actually be possible.

              Regarding your comment about not having tools to migrate running processes, it is not a very straightforward problem to solve, especially something that can be branded as a 'tool' as ultimately most approaches have to be customized.

              Let us know what you find,

              • 4. Re: Help with massive architectural problem: old jbpm proces
                donorschoose

                Well before I read your post I managed to find this:

                http://calebpowell.blogspot.com/2009/06/jbpm-migrations-our-approach.html

                So it appears Caleb Powell's team has come up with a tool they're using internally. That's precisely the sort of tool we would need. Without this, our workflows are stuck 3 years out of date and getting worse.

                I left a note on his blog encouraging them to release the code. Perhaps if you guys prodded them as well we might be able to get that code open sourced. Even if the tool set is limited and/or semi-manual it would be a huge improvement over the current system of having no way of migrating running process instances at all.

                • 5. Re: Help with massive architectural problem: old jbpm proces
                  kukeltje

                  contact has already been made and they seem to be willing. But if you read a little more, you'd see that there also is a migration command in 3.2 by Bernd Ruckner/Camunda. That can be a start as well.