[Design of JBoss jBPM] - Re: first cut of the new history
by tom.baeyens＠jboss.com
the bigger picture is this:
in jbpm 3 we have a flat log table.
biggest problem with that is that it contains references to the runtime data (tokens and process instances). because of that reason, the runtime data cannot be deleted and it keeps growing.
now in jbpm 4, we'll have a history schema that does not reference the runtime data (it can reference process definition data as that data remains in the db). as a result, now process instance data is deleted once it is no longer needed. e.g. executions and variables get deleted when they go out of scope. and the full process instance is deleted when it ends.
the runtime data tables stay clean and healthy this way. the reporting and other monitoring is done on a separate set of tables. so this also makes the whole system more performant.
so in jbpm 4 we will not have a flat log file, but a fully fledged schema that contains the history information of what happened when in the process executions.
so an extra advantage is that the history schema is designed to be easy queryable. it can contain some de-normalized duplications of information. (e.g. startTime, endTime and duration fields).
internally, the architecture remains almost the same: runtime execution still generates history events (previously called processlogs). there is a pluggable history session that captures these history events. and the rest is described above.
does this help ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209890#4209890
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209890
17 years, 2 months
[Design of JBoss jBPM] - Re: email templates
by pete.muir＠jboss.org
Ronald - the work is mostly done, it should work in most cases. There have been some issues raised that in some situations the bootstrap we do doesn't work. The remaining work is more polish/edge cases than anything else. Currently you need to import all of Seam core and mail as we haven't done the modularisation of Seam yet. Please let me know if you have patches for this and I will try to look at them.
As for why we didn't use velocity - well for a start we would have used freemarker ;-) But really, Seam is about allowing you do to stuff without having to learn 101 ways of doing things so, as we already used JSF for the view layer, we wanted to allow people to reuse this knowledge.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209839#4209839
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209839
17 years, 2 months
[Design of JBoss jBPM] - Re: blobs, clobs, text and bytes
by tom.baeyens＠jboss.com
on 2) : as long as we can postpone db specific handling, that will make development much easier and our progress much faster. db-specific things means that we would need a set of mappings for each db. that means that we would have to maintain and synchronize between all those copies.
so i'ld like to keep the same mappings for all the dbs. and if we need to apply a small modification for one particular db, it should be possible to apply this change automatically from the single original source mapping files.
on 3): cause that results in incorrect behaviour in a cluster. 2nd level cache of hibernate is only used for process definition caching as that can be assumed to be static information that (after deployment) will not change.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209830#4209830
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209830
17 years, 2 months
[Design of JBoss jBPM] - console roles
by tom.baeyens＠jboss.com
yesterday during the meeting with the sa's one of the interesting feedbacks was : we have JON for operators (or linux propellorheads as burr called them :-) and we have our own GWT console that is targetted as different roles.
in the past it has been difficult to isolate those roles in the web application. as typically powerusers want to navigate from any place to any place. so it becomes difficult to offer e.g. only the task mgmt part to a task-clerk. or to embed the operator part of our console (looking and retrying failed jobs, number of optimistic locking exceptions) in JON.
our formost interest is to ship a project to the community that can get us adoption. so it definitely requires a console to be included that can show off the jbpm capabilities.
features like task lists, process monitoring, analythics and operational functions are targetted at different audiences. but how can we structure our own console towards these different roles without crippling the powerusers that want to do it all and navigate conveniently.
so how can we make parts of this web app exposed to a single target role ? and how can we leverage these components in let's say JON/JOPR and maybe Guvnor.
thoughts ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209829#4209829
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209829
17 years, 2 months