Jeff, Burr, Martin, Afaict, you are the guys closest to our customers. Next week, we'll be discussing migration between jBPM 3 and 4 in the team. We would appreciate your input. If we had unlimited resources, we'ld simply provide DB, process-XML and API backwards compatibility, but given that our resources are limited and the improvements numerous, here are my initial thoughts on how we currently think to handle migration: Probably DB migration will be too hard to supply in a decent manner. So we'll probably target that users will be able to use jBPM 3 and jBPM 4 in parralel. That way they can start deploying new processes to jBPM 4 and let jBPM 3 processes fade out. For each process in jBPM 3, they could migrate the process to jBPM 4 (see below), redeploy and start new executions in jBPM 4. Although from the user client code perspective this will be hard or impossible. We also anticipate that we'll have to supply a process translation tool that can translate jPDL 3 process XML files to jBPM 4 process XML files. Most of the process file will be converted. But probably there will be some things in jBPM 3 that we will not support in the exact same way in jBPM 4. So some converted processes might not be complete or might not execute exactly the same way as in jBPM 3. API will be different. Only migration docs. The good news is that with the arrival of jBPM 4, we'll start to ship a more limited API that is more decoupled from the engine internals so that it will remain much more stable from then onwards. Feedback from our jBPM Community Day in Dublin was very clear: Migration is one of the biggest concerns for our users. So here are my questions: What aspect of migration will be the biggest challenge for our customers ? Which aspects of migration will be showstoppers for ourcustomers ? Suppose that we ship the above migration strategy and a really really really important client wants to migrate his DB really really really badly. Would we a) be able to say no. b) provide him with skeleton code that the client can use as a basis to write their own DB migration in code. c) let our consultants work out the DB migration for the first customer that wants to pay for it and then add it to the jBPM codebase.

Jeff, Burr, Martin, Afaict, you are the guys closest to our customers. Next week, we'll be discussing migration between jBPM 3 and 4 in the team. We would appreciate your input. If we had unlimited resources, we'ld simply provide DB, process-XML and API backwards compatibility, but given that our resources are limited and the improvements numerous, here are my initial thoughts on how we currently think to handle migration: Probably DB migration will be too hard to supply in a decent manner. So we'll probably target that users will be able to use jBPM 3 and jBPM 4 in parralel. That way they can start deploying new processes to jBPM 4 and let jBPM 3 processes fade out. For each process in jBPM 3, they could migrate the process to jBPM 4 (see below), redeploy and start new executions in jBPM 4. Although from the user client code perspective this will be hard or impossible. We also anticipate that we'll have to supply a process translation tool that can translate jPDL 3 process XML files to jBPM 4 process XML files. Most of the process file will be converted. But probably there will be some things in jBPM 3 that we will not support in the exact same way in jBPM 4. So some converted processes might not be complete or might not execute exactly the same way as in jBPM 3. API will be different. Only migration docs. The good news is that with the arrival of jBPM 4, we'll start to ship a more limited API that is more decoupled from the engine internals so that it will remain much more stable from then onwards. Feedback from our jBPM Community Day in Dublin was very clear: Migration is one of the biggest concerns for our users. So here are my questions: What aspect of migration will be the biggest challenge for our customers ? Which aspects of migration will be showstoppers for ourcustomers ? Suppose that we ship the above migration strategy and a really really really important client wants to migrate his DB really really really badly. Would we a) be able to say no. b) provide him with skeleton code that the client can use as a basis to write their own DB migration in code. c) let our consultants work out the DB migration for the first customer that wants to pay for it and then add it to the jBPM codebase.

I don't get this: > the underlying DB should IMO be considered an implementation detail of > the iBPM engine. If that is not the case in jBPM3 it needs to get fixed > in jBPM4. jBPM4 should not expose any direct access to the DB. I'd say > there is no DB migration needed. > The whole state of my processes is in the database. Of course no direct access should be exposed,

Maybe we can discuss If I need to migrate existing process instances (I would tend to say yes),

From a business perspective, any solution other than a "weekend migration"

Agreed, It depends on how you look at it. In some use cases, it is conceptually correct to see tasks, processes, etc as being part of the domain model. The main advantage then of having direct access to a Hibernate sessions allows to create queries that take in account own domain models and the bpm model. eg. give me all the tasks involving documents with author X. With jBPM, this is easy *and* accessible for average developers (who know Hibernate). IMO, it is impossible to create an API that covers all these kinds of use cases. It will be too complex and still be restrictive for some. In my experience, people tend always tend to need that functionality that is not supported out of the box (and the next customer finds another one ...) But now for the compatibility isues, my opinon: - When frameworks change, people understand that some code will need to be rewritten. People understand that there is a price for the newer features. eg. Hibernate code configured with XML -> annotations. I do believe that there should be a 'compatibility mode', which means that jBPM3 process definitions should be able to run on the jBPM4 engine. If this is feasible, I think it will solve most of the people's problem with upgrading. - DB conversions is, I think, more needed: some of the people I have worked with have processes that an run up to 5 years. So for me conversion of DB state is the most important. Regards Joram On Thu, Oct 30, 2008 at 10:46 AM, Ronald van Kuijk <ronald(a)jbpm.org&gt;wrote: > Bernd Rücker schreef: > >> I don't get this: >> >> >> >>> the underlying DB should IMO be considered an implementation detail of >>> the iBPM engine. If that is not the case in jBPM3 it needs to get fixed >>> in jBPM4. jBPM4 should not expose any direct access to the DB. I'd say >>> there is no DB migration needed. >>> >>> >> >> The whole state of my processes is in the database. Of course no direct >> access should be exposed, >> > What we should *not forget* is that there are users out there that use hql > (or even sql) via the hibernate session which can be retrieved from a jBPM > session. They do this since the api does not support everything but a > kitchensink. e.g. retrieval of taskinstances or processintstances based on > values of variables is not possible in jBPM. Implementing this and keeping > it performant requires many indexes. The jBPM database is in fact (as the > docs say) not optimized (index wise) for all kinds of usecases, so a dba > should tune this. Besides that, jBPM supports injecting a hibernate session > to be used for the tables, so direct access is always 'exposed' . > > Maybe we can discuss If I need to migrate existing process instances (I >> would tend to say yes), >> > If we don't, but allow just convert processdefinitions, run old instances > in jBPM 3 and new instances in jBPM 4, all kinds of BAM/BI implementation by > customers will break (they have to adapt for querying 2 databases) > Retrieving tasklists will be more difficult, signalling instances etc.... So > I tend to say yes as well. > > Ronald > > _______________________________________________ > jbpm-dev mailing list > jbpm-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbpm-dev > _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev