Deleting processing instance from API doesn't work

[ddossot]

Using Activity 5.13.

$ curl -v -X DELETE -u admin http://.../activiti-rest/service/runtime/process-instances/1401

HTTP/1.1 204 No Content
‍‍‍‍‍

Then:

$ curl -v -u admin http://.../activiti-rest/service/runtime/process-instances/1401

HTTP/1.1 200 OK
{
    "id": "1401",
    "url": "http://.../activiti-rest/service/runtime/process-instances/1401",
    "businessKey": null,
    "suspended": false,
    "processDefinitionId": "process:2:1206",
    "processDefinitionUrl": "http://.../activiti-rest/service/repository/process-definitions/process%3A2%3A1206",
    "activityId": "checkRequest",
    "variables": []
}
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Logs are clean: what am I doing wrong?

Alternatively in what tables should I manually delete rows to get rid of this instance?

[ddossot]

There was other strange behaviours like all edits to workflows in the Modeler were silently lost.

But I found out the root cause of the issue: I was using a different database for storing my JPA annotated entities. If I move these tables inside the database used by Activiti, everything works fine.

The surprising thing is that my entities were correctly hydrated from the other DB and most of Activiti was working, just some features were not working, but not reporting error either.

I guess the question is: is it possible to use two data sources, one for Activiti and one for custom entities persistence? I imagine the answer is yes and that I did something wrong with the configuration, but having an authoritative answer would be nice.

[frederikherema1]

If you're using 2 different sources (data-base connections), you should make sure you use JTA with two-phased-commit or something similar. If you're using JPA-integration, we're assuming that the same transaction is used for both activiti and JPA. If this is not the case, it's possible that rollbacks of activiti don't force a rollback of your data. This is not purely activiti-related, but related to any app that uses 2 different DB's in a single "atomic" block of work.

About the first issue, this is the actual implementation…


@Delete
  public void deleteProcessInstance() {
    if(!authenticate()) {
      return;
    }
    ProcessInstance processInstance = getProcessInstanceFromRequest();
    String deleteReason = getQueryParameter("deleteReason", getQuery());
   
    ActivitiUtil.getRuntimeService().deleteProcessInstance(processInstance.getId(), deleteReason);
    setStatus(Status.SUCCESS_NO_CONTENT);
  }
Very straight-forward call to the JAVA-API. We also have test-coverage for this. I'm guessing there is something wrong with the way transaction are handled in your rest-app…

/**
   * Test deleting a single process instance.
   */
  @Deployment(resources = {"org/activiti/rest/api/runtime/ProcessInstanceResourceTest.process-one.bpmn20.xml"})
  public void testDeleteProcessInstance() {
    ProcessInstance processInstance = runtimeService.startProcessInstanceByKey("processOne", "myBusinessKey");
    ClientResource client = getAuthenticatedClient(RestUrls.createRelativeResourceUrl(RestUrls.URL_PROCESS_INSTANCE, processInstance.getId()));
    client.delete();
    assertEquals(Status.SUCCESS_NO_CONTENT, client.getResponse().getStatus());
   
    // Check if process-instance is gone
    assertEquals(0, runtimeService.createProcessInstanceQuery().processInstanceId(processInstance.getId()).count());
  }