Yes, you need to use jbpm_log table if you need to get transitions. To get all proceeded nodes you only need jbpm_taskInstance table. We use HQL to get all user's transition in process.
I had a task about "to know wich transition user choosed for given taskInstance". It's not a obvious way to do such thing, but I cannot invent something more clear. In my case it's not a very common action in app so it's realized in "fastest-to-code-it" way.
Obviously 3 queries for single task instance in your case is not a good choose. The only docs I needed were: docs.jboss.org/jbpm/v3/javadoc for help on Jbpm classes and packages and discriminator's class list: jbpm-jpdl. Jar/org.jbpm.logging.
Log/ProcessLog.hbm. Xml (has desciption about jbpm objects - DB table mapping) This is the method's code. CriteriaSQL is our CriteriaParams wrapper.As I said it isn't best example but I also have saved plain sql queries for oracle DB if you needs it.
Yes, you need to use jbpm_log table if you need to get transitions. To get all proceeded nodes you only need jbpm_taskInstance table. We use HQL to get all user's transition in process.
I had a task about "to know wich transition user choosed for given taskInstance". It's not a obvious way to do such thing, but I cannot invent something more clear. In my case it's not a very common action in app so it's realized in "fastest-to-code-it" way.
Obviously 3 queries for single task instance in your case is not a good choose. The only docs I needed were: docs.jboss.org/jbpm/v3/javadoc/ for help on Jbpm classes and packages and discriminator's class list: jbpm-jpdl. Jar/org.jbpm.logging.
Log/ProcessLog.hbm. Xml (has desciption about jbpm objects - DB table mapping) This is the method's code. CriteriaSQL is our CriteriaParams wrapper.As I said it isn't best example but I also have saved plain sql queries for oracle DB if you needs it.
Private String getTaskTransition(LFTaskInstance instance) { CriteriaSQL csql = new CriteriaSQL(new CriteriaParams()); String query = "SELECT l " + " FROM org.jbpm.taskmgmt.log. TaskCreateLog l " + " WHERE l. TaskInstance = " + instance.getId(); Query c =((getcreateQuery(csql.
GetQueryString(query)); TaskCreateLog logEntry = (TaskCreateLog) c.uniqueResult(); int index = logEntry.getIndex(); Long token = logEntry.getToken().getId(); //Find bottom log index of transition which greater then log index of current instance creation String subQuery = "SELECT min(jbpmLog. Index) " + " FROM org.jbpm.graph.log. TransitionLog as jbpmLog " + " where jbpmLog.
Token = trLog. Token AND " + //reference to query below " jbpmLog. Index > " + index; //Find transition name from its Definition by log index of made transition query = " SELECT trans.
Name FROM org.jbpm.graph.def. Transition as trans " + " WHERE trans.Id = " + " (SELECT min(transition. Id) " + " FROM org.jbpm.graph.log.
TransitionLog trLog " + " WHERE trLog. Token = " + token + " and trLog. Index = (" + subQuery + "))"; c =((getcreateQuery(csql.
GetQueryString(query)); return (String) c.uniqueResult(); }.
If not, then you could put an action handler on every exit transition that records the name of the transition by looking for it in the current token.
It's for a new system, so yes this could be done,but I still rather not have the constraint of having to design all flows and future flows with a specific action handler. Similarly, I could log this in my application service method. My preferred way is still using the standard jbpm functionalities.
But yes, your solution should work fine. – HeDinges Aug 14 '09 at 10:56 I have a full JBPM database here from a production site and it appears that the only way would be to sift through the log. However, in my JBPM implementation I used JBPM as a means to do the workflow grunt work, while I stored all my data regarding the workflow in my own tables and it has worked out well.
– Zoidberg Aug 14 '09 at 11:24.
We use sql select like this (logging into table JBPM_LOG must be enabled in file jbpm.cfg. Xml): select distinct * from (select level, l. Date_, pd1.
Name_ p1, n1. Name_ n1, pd2. Name_ p2, n2.
Name_ n2 from juser. Jbpm_log l, juser. Jbpm_node n1, juser.
Jbpm_node n2, juser. Jbpm_processdefinition pd1, juser. Jbpm_processdefinition pd2, juser.
Jbpm_token t, juser. Jbpm_processinstance pi, juser. Jbpm_token t2 where l.
Class_ = 'T' and n1. Id_ = l. Sourcenode_ and n2.
Id_ = l. Destinationnode_ and n1. Processdefinition_ = pd1.
Id_ and n2. Processdefinition_ = pd2. Id_ and t.
Id_ = l. Token_ and t. Processinstance_ = pi.
Id_ and pi. Superprocesstoken_ = t2. Id_ connect by prior pi.
Id_ = t2. Processinstance_ start with pi. Id_ = (select id_ from (select pi.
Id_ from juser. Jbpm_processinstance pi, juser. Jbpm_token t where pi.
Superprocesstoken_ = t. Id_ connect by prior t. Processinstance_ = pi.
Id_ start with pi. Id_ = >> order by pi. Id_) where rownum = 1) order by l.
Date_) order by date_; This uses connect by prior - I don't know if this work on anything other than oracle.
I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.