Terminate Active ProcessInstance in jbpm 5.2 using Local Task Service

[sridhar532]

Hi All,

My Process after launching creates three parallel human tasks and stays active in those task for the user to Claim / Complete. Is it possible to Terminate my Active ProcessInstance  before the users performs Claim / Complete Operation.  Am using Local-JTA in jbpm 5.2 for Launching / Claim my process. When i try to abort the processInstance using  ksession.abortProcessInstance(processInstanceId); am receiving the below error.

Hibernate: select sessioninf0_.id as id1_0_, sessioninf0_.lastModificationDate as lastModi2_1_0_, sessioninf0_.rulesByteArray as rulesByt3_1_0_, sessioninf0_.startDate as startDate1_0_, sessioninf0_.OPTLOCK as OPTLOCK1_0_ from SessionInfo sessioninf0_ where sessioninf0_.id=?

Hibernate: select processins0_.InstanceId as InstanceId0_0_, processins0_.lastModificationDate as lastModi2_0_0_, processins0_.lastReadDate as lastRead3_0_0_, processins0_.processId as processId0_0_, processins0_.processInstanceByteArray as processI5_0_0_, processins0_.startDate as startDate0_0_, processins0_.state as state0_0_, processins0_.OPTLOCK as OPTLOCK0_0_ from ProcessInstanceInfo processins0_ where processins0_.InstanceId=?

Hibernate: select workitemin0_.workItemId as workItemId2_0_, workitemin0_.creationDate as creation2_2_0_, workitemin0_.name as name2_0_, workitemin0_.processInstanceId as processI4_2_0_, workitemin0_.state as state2_0_, workitemin0_.OPTLOCK as OPTLOCK2_0_, workitemin0_.workItemByteArray as workItem7_2_0_ from WorkItemInfo workitemin0_ where workitemin0_.workItemId=?

Hibernate: select * from ( select task0_.id as id17_, task0_.allowedToDelegate as allowedT2_17_, task0_.taskInitiator_id as taskIni25_17_, task0_.priority as priority17_, task0_.activationTime as activati4_17_, task0_.actualOwner_id as actualO26_17_, task0_.createdBy_id as createdBy27_17_, task0_.createdOn as createdOn17_, task0_.documentAccessType as document6_17_, task0_.documentContentId as document7_17_, task0_.documentType as document8_17_, task0_.expirationTime as expirati9_17_, task0_.faultAccessType as faultAc10_17_, task0_.faultContentId as faultCo11_17_, task0_.faultName as faultName17_, task0_.faultType as faultType17_, task0_.outputAccessType as outputA14_17_, task0_.outputContentId as outputC15_17_, task0_.outputType as outputType17_, task0_.parentId as parentId17_, task0_.previousStatus as previou18_17_, task0_.processId as processId17_, task0_.processInstanceId as process20_17_, task0_.processSessionId as process21_17_, task0_.skipable as skipable17_, task0_.status as status17_, task0_.workItemId as workItemId17_ from Task task0_ where task0_.workItemId=? ) where rownum <= ?

Feb 14, 2012 9:42:53 PM org.drools.persistence.SingleSessionCommandService rollbackTransaction

SEVERE: Could not commit session

java.lang.RuntimeException: javax.persistence.TransactionRequiredException: No active JTA transaction on joinTransaction call

at org.jbpm.task.service.TaskServiceSession.doOperationInTransaction(TaskServiceSession.java:990)

at org.jbpm.task.service.TaskServiceSession.taskOperation(TaskServiceSession.java:433)

at org.jbpm.task.service.local.LocalTaskService.skip(LocalTaskService.java:220)

at com.jbpm.util.SyncWSHumanTaskHandler.abortWorkItem(SyncWSHumanTaskHandler.java:296)

at org.drools.persistence.jpa.processinstance.JPAWorkItemManager.internalAbortWorkItem(JPAWorkItemManager.java:76)

at org.jbpm.workflow.instance.node.WorkItemNodeInstance.cancel(WorkItemNodeInstance.java:249)

at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.setState(WorkflowProcessInstanceImpl.java:257)

at org.jbpm.process.instance.ProcessRuntimeImpl.abortProcessInstance(ProcessRuntimeImpl.java:362)

at org.drools.impl.StatefulKnowledgeSessionImpl.abortProcessInstance(StatefulKnowledgeSessionImpl.java:287)

at org.drools.command.runtime.process.AbortProcessInstanceCommand.execute(AbortProcessInstanceCommand.java:42)

at org.drools.command.impl.DefaultCommandService.execute(DefaultCommandService.java:36)

at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:345)

at org.drools.command.impl.CommandBasedStatefulKnowledgeSession.abortProcessInstance(CommandBasedStatefulKnowledgeSession.java:131)

at ComplexProcessTest.abortProcess(ComplexProcessTest.java:316)

at org.apache.jsp.pages.test.testTaskComplete_jsp._jspService(testTaskComplete_jsp.java:72)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:386)

at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:313)

at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:260)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)

at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:859)

at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)

at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)

at java.lang.Thread.run(Unknown Source)

Caused by: javax.persistence.TransactionRequiredException: No active JTA transaction on joinTransaction call

at org.hibernate.ejb.AbstractEntityManagerImpl.joinTransaction(AbstractEntityManagerImpl.java:458)

at org.hibernate.ejb.AbstractEntityManagerImpl.joinTransaction(AbstractEntityManagerImpl.java:431)

at org.jbpm.task.service.TaskServiceSession.doOperationInTransaction(TaskServiceSession.java:986)

... 32 more

java.lang.RuntimeException: javax.persistence.TransactionRequiredException: No active JTA transaction on joinTransaction call

at org.jbpm.task.service.TaskServiceSession.doOperationInTransaction(TaskServiceSession.java:990)

at org.jbpm.task.service.TaskServiceSession.taskOperation(TaskServiceSession.java:433)

at org.jbpm.task.service.local.LocalTaskService.skip(LocalTaskService.java:220)

at com.jbpm.util.SyncWSHumanTaskHandler.abortWorkItem(SyncWSHumanTaskHandler.java:296)

at org.drools.persistence.jpa.processinstance.JPAWorkItemManager.internalAbortWorkItem(JPAWorkItemManager.java:76)

at org.jbpm.workflow.instance.node.WorkItemNodeInstance.cancel(WorkItemNodeInstance.java:249)

at org.jbpm.workflow.instance.impl.WorkflowProcessInstanceImpl.setState(WorkflowProcessInstanceImpl.java:257)

at org.jbpm.process.instance.ProcessRuntimeImpl.abortProcessInstance(ProcessRuntimeImpl.java:362)

at org.drools.impl.StatefulKnowledgeSessionImpl.abortProcessInstance(StatefulKnowledgeSessionImpl.java:287)

at org.drools.command.runtime.process.AbortProcessInstanceCommand.execute(AbortProcessInstanceCommand.java:42)

at org.drools.command.impl.DefaultCommandService.execute(DefaultCommandService.java:36)

at org.drools.persistence.SingleSessionCommandService.execute(SingleSessionCommandService.java:345)

at org.drools.command.impl.CommandBasedStatefulKnowledgeSession.abortProcessInstance(CommandBasedStatefulKnowledgeSession.java:131)

at com.jbpm.core.test.ComplexProcessTest.abortProcess(ComplexProcessTest.java:316)

at org.apache.jsp.pages.jbpm.testTaskComplete_jsp._jspService(testTaskComplete_jsp.java:72)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)

Is it possible to abort the processInstance using any other way ?

[damian.pooley]

I am getting the same exception (junit tests) and I am sure that it is because of the setup in persistence configuration.

Before I used the LocalTaskService I downloaded and managed to deploy the Human Task Service war. The points to note in its persistence.xml are:

<persistence-unit name="org.jbpm.task" transaction-type="RESOURCE_LOCAL">

<non-jta-data-source>java:/jdbc/jbpm-ds</non-jta-data-source>

...

<property name="hibernate.transaction.manager_lookup_class" value="org.hibernate.transaction.JBossTransactionManagerLookup" /> <!-- Jboss 5-->

I recently moved to jbpm 5.2 and have started using the LocalTaskService and need to setup the task persistence-unit correctly (and so I can use a test version in vanilla junit tests too).

I have reverted to where I was getting the same exception as above after making sure that my set up was the same as the test files from here: https://community.jboss.org/people/bpmn2user/blog/2011/11/14/jbpm5--local-human-task-example.

I have a test case that does exactly the same as theirs and it works. However, when I try to do taskService.claim(...) I get the "No active JTA transaction on joinTransaction call" exception.

My calls in sequence (loading a previous session by its id) are:

1. statefulKnowledgeSession.startProcess
2. taskService.getTasksAssignedAsPotentialOwner
3. taskService.claim
   1. exception is thrown here.
   2. last sql statement was:Hibernate: select task0_.id as id71_3_, task0_.allowedToDelegate as allowedT2_71_3_, task0_.taskInitiator_id as taskIni25_71_3_, task0_.priority as priority71_3_, task0_.activationTime as activati4_71_3_, task0_.actualOwner_id as actualO26_71_3_, task0_.createdBy_id as createdBy27_71_3_, task0_.createdOn as createdOn71_3_, task0_.documentAccessType as document6_71_3_, task0_.documentContentId as document7_71_3_, task0_.documentType as document8_71_3_, task0_.expirationTime as expirati9_71_3_, task0_.faultAccessType as faultAc10_71_3_, task0_.faultContentId as faultCo11_71_3_, task0_.faultName as faultName71_3_, task0_.faultType as faultType71_3_, task0_.outputAccessType as outputA14_71_3_, task0_.outputContentId as outputC15_71_3_, task0_.outputType as outputType71_3_, task0_.parentId as parentId71_3_, task0_.previousStatus as previou18_71_3_, task0_.processId as processId71_3_, task0_.processInstanceId as process20_71_3_, task0_.processSessionId as process21_71_3_, task0_.skipable as skipable71_3_, task0_.status as status71_3_, task0_.workItemId as workItemId71_3_, user1_.id as id66_0_, user2_.id as id66_1_, user3_.id as id66_2_ from Task task0_ left outer join OrganizationalEntity user1_ on task0_.taskInitiator_id=user1_.id left outer join OrganizationalEntity user2_ on task0_.actualOwner_id=user2_.id left outer join OrganizationalEntity user3_ on task0_.createdBy_id=user3_.id where task0_.id=?

While trying out the struck through lines I had 2 persistence units (jpa and task). Unit test was unable to find the TransactionManager in jndi when it was set for jboss. Switching that to BMT resulted in database deadlocks only for process definitions with userTasks when it was trying to do startProcess.

The https://community.jboss.org/people/bpmn2user/blog/2011/11/14/jbpm5--local-human-task-example needs to be updatd to run through more use cases.

Debugging through TaskServiceSession the real exception is: org.jbpm.task.service.PermissionDeniedException: User '[User:'Administrator']' was unable to execution operation 'Claim' on task id 1 due to a no 'current status' match. (whatever that means!)

However there seems to be a strange thing happening in transactionStarted = beginOrUseExistingTransaction(), and it returns false after having found the local-JTA ...

} else if ("local-JTA".equals(transactionType)) {
      try {
       UserTransaction ut = (UserTransaction) new InitialContext().lookup( "java:comp/UserTransaction" );
       if (ut.getStatus() == javax.transaction.Status.STATUS_NO_TRANSACTION) {
        ut.begin();
        em.joinTransaction();
        return true;
       }
       return false; // <-- ends up here. ut.begin() called in own code. bitronix says 1 transaction going on.
      } catch (Throwable t) {
          throw new RuntimeException(t);
         }
     }

will delve deeper > weekend.

[rahulamt]

I was having the same problem. But I think it was because of the transaction timeout issue. I reperformed the claiming activity, the error was gone.

But I have another issue.

In my web application I am having two tabs for the inbox. One for the tasks pending with the user and other for the tasks of the roles(whose status is ready and can be claimed). Basically these two are user inbox and role inbox respectively. The issue is even when I am claiming the task in the database the task status is not changed. Its ready only. So its not coming in the user inbox(owned tasks) instead coming in the role inbox only. When I am claiming the task again. I get an error saying the status of the task is not matched and sometimes I get the above error.

When I digged dipper into the task, I found that the after I claim the task the task status is not persisted in the database and in the hibernate cache for that particular task object the status is different(Reserved). So while getting the tasks from the database I get the claimed task in the role inbox not in the user inbox.

The similar issue I found with the complete task API.

I am using the following code for completing the task

public static void completeTask(long taskId, Map data, String userId) throws InterruptedException {
  //connect();

  tService.start(taskId, userId);
  ContentData contentData = null;
  if (data != null) {
   ByteArrayOutputStream bos = new ByteArrayOutputStream();
   ObjectOutputStream out;
   try {
    out = new ObjectOutputStream(bos);
    out.writeObject(data);
    out.close();
    contentData = new ContentData();
    contentData.setContent(bos.toByteArray());
    contentData.setAccessType(AccessType.Inline);
   } catch (IOException e) {
    e.printStackTrace();
   }
  }
  tService.complete(taskId, userId, contentData);
  //responseHandler.waitTillDone(5000);
}

If I pass a null Map object to the above method I am getting the similar issue. The task status is not changed. Its still reserved only.

[rahulamt]

The only logical explaination for the issue of status not changing after claiming, I can give is that the assumption is made that "Whenever someone claims a tasks, that particular task should not be persisted becuase the immediate action the person, who has claimed, will perform is of completing that task and that tooo in the same transaction boundary". If the transaction boundaries are changed means claim transaction/operation is complete(here task is not persisted in db.) then there will be issues.

[rahulamt]

Please refer the solution provided in the following discussion.

https://community.jboss.org/message/762472#762472