tags:

views:

740

answers:

2

Is it possible in jboss jBpm to fetch all transitions that has been taken during one process execution?


The use case is: We would like to now all nodes, tasknodes, ... that 'users' has been through and which transition they took.

This to show a list of task instances that have been finished previously from the current active token/node till the start task.

Some not working ideas already explored:

  • Take the active tokens and their corresponding node and travel up the transitions through the arriving transitions. This does not work as multiple transitions can be incoming, so we do not know which transition has been taken.

Probably I should investigate the JBPM_LOG table, but I didn't found a proper way (API) to query this. Any suggestions to any online documentation would also be welcome.

Note: We are using jBpm version:3.3.1

A: 

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: http://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 =((HibernateSession)em).getHibernateSession().createQuery(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 =((HibernateSession)em).getHibernateSession().createQuery(csql.getQueryString(query));
     return (String) c.uniqueResult();
    }
Vanger
A: 

Is this for Processes that have already been completed or partially processed? 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.

Zoidberg
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
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