2009-08-14 1 views
0

Возможно ли в jboss jBpm получить все переходы, которые были выполнены во время выполнения одного процесса?В jBpm, как получить все переходы, которые были сделаны в потоке/процессе?


Использование случай: Мы хотели бы, чтобы теперь все узлы, tasknodes, ... это пользователей »прошли и который перехода они взяли.

Это, чтобы показать список экземпляров задач, которые были предварительно завершены с текущего активного токена/узла, до начала задачи.

Некоторые не работают идеи уже исследовали:

  • Возьмите активные маркеры и их соответствующий узел и путешествуют вверх переходы через прибывающих переходов. Это не работает, так как много переходов могут поступать, поэтому мы не знаем, какой переход был сделан.

Возможно, я должен исследовать таблицу JBPM_LOG, но я не нашел подходящего способа (API) для запроса этого. Любые предложения в любой онлайн-документации также приветствуются.

Примечание: Мы используем jBpm версия: 3.3.1

+0

Можете ли вы опубликовать (как ответ или как комментарий) свое решение проблемы, пожалуйста? – Vanger

+0

@ Вангар, я отправлю его, как только я его написал, возможно, где-то на следующей неделе. – HeDinges

ответ

0

Да, вы должны использовать jbpm_log таблицу, если вам нужно получить переходы. Чтобы получить все начатые узлы, вам нужна только таблица jbpm_taskInstance. Мы используем HQL для перехода всех процессов пользователя в процесс. У меня была задача «узнать, какой пользователь перехода выбрал для данного taskInstance». Это не очевидный способ сделать такую ​​вещь, но я не могу придумать что-то более ясное. В моем случае это не очень распространенное действие в приложении, поэтому оно реализовано в стиле «самый быстрый код». Очевидно, что 3 запроса для экземпляра одной задачи в вашем случае не подходят. Единственными документами, которые мне нужны были: http://docs.jboss.org/jbpm/v3/javadoc/ для справки по классам и пакетам Jbpm и списку классов дискриминатора: jbpm-jpdl.jar/org.jbpm.logging.log/ProcessLog.hbm.xml (есть описание объектов jbpm - сопоставление таблицы БД) Это код метода. КритерииSQL - это наша оболочка CriteriaParams. Как я уже сказал, это не лучший пример, но я также сохранил простые sql-запросы для Oracle DB, если вам это нужно.

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(); 
    } 
0

Это для процессов, которые уже были обработаны или частично обработаны? Если нет, тогда вы можете поместить обработчик действий на каждом выходе, который записывает имя перехода, ища его в текущем токене.

+0

Это для новой системы, так что да, это можно сделать, но у меня все же нет ограничения на необходимость создания всех потоков и будущих потоков с помощью специального обработчика действий. Аналогично, я мог бы зарегистрировать это в моем методе службы приложений. Мой предпочтительный способ по-прежнему использует стандартные функции jbpm.Но да, ваше решение должно работать нормально. – HeDinges

+0

У меня есть полная база данных JBPM здесь с производственного сайта, и кажется, что единственный способ - просеять через журнал. Тем не менее, в моей реализации JBPM я использовал JBPM как средство, чтобы выполнить работу с ворчанием рабочего процесса, в то время как я сохранил все свои данные о рабочем процессе в своих собственных таблицах, и это получилось хорошо. – Zoidberg

0

Мы используем SQL выбор, как это (вход в таблице JBPM_LOG должны быть включены в файл 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_ = <<<ID_OF_PROCESSINSTANCE>>> 
           order by pi.id_) 
         where rownum = 1) 
     order by l.date_) 
order by date_; 

Это использует подключения по предварительному - я не знаю, если эта работа ни на что кроме оракула.

Смежные вопросы