topic 5.10 HistoricTaskInstanceQuery extension. in Alfresco Archive

5.10 HistoricTaskInstanceQuery extension.

gromar — Fri, 18 Jan 2013 13:50:00 GMT

Hello.I would like to extend HistoricTaskInstanceQuery with possibility to select tasks finished after due time. How can I manage it on the 5.10 tag? (I think new features could be added only to the 5.12-SNAPSHOT).The reason for 5.10 is that 5.11 has issues with database. When it is not possible to

Re: 5.10 HistoricTaskInstanceQuery extension.

frederikherema1 — Fri, 18 Jan 2013 14:01:05 GMT

You could just checkout the 5.10 tag and modify it locally (or fork on github), alter the source-code and build the engine-jar yourself. You can suggest the change to us, by applying the change to the current 5.12 master and creating a pull-request (or attaching a patch to a JIRA-issue).

Re: 5.10 HistoricTaskInstanceQuery extension.

gromar — Mon, 21 Jan 2013 18:20:39 GMT

In that case it would be better to upgrade process-monitor project to the latest activiti version.

I tried to upgrade from Activiti 5.10 -> 5.11. I have created new test which is failing with 5.11 but was totally OK with 5.10.

Could you please show me what I am doing wrong here?

Description:
TwoEnginesTest.java
Test puts process engine into defined state (generateLiveDB()),
deploys simple process:
[img]https://raw.github.com/gro-mar/activiti-crystalball/Activiti-5.11/simulator/src/test/process/org/activiti/crystalball/simulator/TwoEngines.png[/img]

and runs the test (starts deployed process).


 @Test
 public void test() {
  // prepare params
  Map<String, Object> params = new Hashtable<String, Object>();

  params.put( "tempDir", System.getProperty("tempDir", "target") );
     params.put( "runningDatabaseFile", LIVE_DB+".h2.db");


     // start process
  runtimeService.startProcessInstanceByKey(
    MONITOR_PROCESS_KEY, "GENERATOR-KEY-1", params).getId();
 }

In this one node process groovy script is called (starts new "simulation" process engine and runs simulation on the top of it):


 import org.apache.commons.io.*;
       import static org.junit.Assert.*;
 import java.util.List;
 import org.activiti.engine.IdentityService;
 import org.activiti.engine.identity.User;
 import org.springframework.context.support.ClassPathXmlApplicationContext;
 import org.processmonitor.simulator.*;

 // create copy of the running process engine database and set system property to this file

FileUtils.copyFile( FileUtils.getFile(runningDatabaseFile), FileUtils.getFile( tempDir+"/TwoEngines-simulationRunDB"+Thread.currentThread().getId()+".h2.db"))
System.setProperty("_SIM_DB_PATH", tempDir+"/TwoEngines-simulationRunDB"+Thread.currentThread().getId())
 
  ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext("/org/processmonitor/simulator/SimEngine-h2-context.xml")
  IdentityService identityService = appContext.getBean("identityService")
  IdentityService simIdentityService = appContext.getBean("simIdentityService")
  List<User> simUsers = simIdentityService.createUserQuery().list();
  List<User> users = identityService.createUserQuery().list();
  assertTrue("Copied identity service is not the same as source  identity service", simUsers.size() == users.size());

  SimulationRun simRun = appContext.getBean(SimulationRun.class)
  resultEventList = simRun.execute(new Date(), null)

  assertTrue("Simulation result event list is empty", resultEventList.size() > 0);

  appContext.close()

The problem is that


assertTrue("Simulation result event list is empty", resultEventList.size() > 0);

is failing because of various reasons:
Identity service is not the same as "live" process engine.
TaskService is not the same.
etc…

The same test without process deploy and start is not failing (see TwoEnginesWithoutProcessTest.java)

Both tests are passing with activiti-5.10 master branch

Could you help me please?'>.

Could you help me please?

Re: 5.10 HistoricTaskInstanceQuery extension.

frederikherema1 — Tue, 22 Jan 2013 08:26:41 GMT

Not really sure why you're using a process to spawn off a new process-engine to run the simulation in… Is the issue that is presenting occurring due to the simulation NOT working well on the 5.11? Or is the original process-spawning 5.11 engine causing issues?

Re: 5.10 HistoricTaskInstanceQuery extension.

gromar — Tue, 22 Jan 2013 09:06:07 GMT

Simulation is working well on 5.11. in the case when it is not called from process simulation node (see TwoEnginesWithoutProcessTest.java )

From my point of view the 5.11 engine is causing this issues - it is not possible to execute another process engine instance from the running process instance.

Both tests are passing with activiti-5.10 master branch .

Re: 5.10 HistoricTaskInstanceQuery extension.

frederikherema1 — Tue, 22 Jan 2013 09:28:13 GMT

This has to do with the way service-calls are handled from within a running process. In order to have the API-calls (rg, from a service-task) use the same transaction, some work has been done in the 5.11 release… So I presume the command-contexts of engine A is taken over by engine B. At least, that's what I suspect is the issue.

It's off course a highly unusual use case, to spawn a second engine from the first one. I get why you're using a separate engine for simulation (to not influence the production-engine), but not sure why the simulation should run in an engine, booted within another engine…

Re: 5.10 HistoricTaskInstanceQuery extension.

gromar — Tue, 22 Jan 2013 09:48:14 GMT

The reason: Only for presentation purposes. It is easier to communicate with business people process diagrams as code.

Question: How to fix this issue?

Re: 5.10 HistoricTaskInstanceQuery extension.

jbarrez — Tue, 22 Jan 2013 10:23:53 GMT

Ok, so the problem here is exactly how Fred describes it. By fixing transactions in 5.11, and introducing command context reuse, we've broken your use case (albeit it is a very, very exceptional use case 😉 )
The problem here is that the command context stack is cached thread local for further service invocations. You are using different services, but the thread local cache is the same for all these instances.

Luckily you can disable this behavior, by calling


  public void setContextReusePossible(boolean isContextReusePossible) {
    this.isContextReusePossible = isContextReusePossible;
  }

on CommandContextInterceptor.

You could override


public class StandaloneProcessEngineConfiguration extends ProcessEngineConfigurationImpl {

  protected Collection< ? extends CommandInterceptor> getDefaultCommandInterceptorsTxRequired() {
    return createDefaultCommandInterceptors(true);
  }

and pass true there.