Using getActiveActivityIds() with a parrallel gateway

[donovanmuller]

Hi,

I'm experiencing an issue using runtimeService.getActiveActivityIds() on a process that contains a parallel gateway.
The attached screenshot shows my test process.

Basically, I have a receiveTask before the gateway. After starting a process instance, I call getActiveActivityIds() with the process instance id, it returns this receiveTask as expected.
Once I signal (runtimeService.signal() with process instance id) the first receiveTask, it continues into the parallel gateway (where there is a receiveTask on one fork and a scriptTask on the other fork) the scriptTask is executed and the receiveTask waits as expected.
If I now call getActiveActivityIds() with the process instance id, I get a blank list back. I was expecting to get the second waiting receiveTask back.
If I now signal (using the process instance id) the second waiting receiveTask, the process continues as expected.

Why does getActiveActivityIds() not return the second waiting receiveTask when in the parallel gateway?

Thanks

[frederikherema1]

If there second signal works as expected, that means that there was indeed a receive-taks waiting in a (sub)execution of the process-instance. So in theory, the active activity list shouldn't be null.

When calling runtimeService.getActiveActivityIds(), the active activity in the given execution are returned (if execution is active) and the ones that are active in it's child-executions (ant recessively in all it's children). The only way the receive-task is not seen as an "active" activity is that the  sub-execution is not active… I'll look a bit deeper into this issue.

[frederikherema1]

I created a unit-test for the problem you're describing (trunk - 5.10-SNAPSHOT):


### Eclipse Workspace Patch 1.0
#P activiti-engine
Index: src/test/java/org/activiti/engine/test/api/runtime/RuntimeServiceTest.java
===================================================================
— src/test/java/org/activiti/engine/test/api/runtime/RuntimeServiceTest.java (revision 3512)
+++ src/test/java/org/activiti/engine/test/api/runtime/RuntimeServiceTest.java (working copy)
@@ -197,6 +197,21 @@
     assertEquals(1, activities.size());
   }
  
+  @Deployment(resources={
+    "org/activiti/engine/test/api/oneReceiveTaskProcess.bpmn20.xml"})
+  public void testFindActiveActivityIdsReceiveTask() {
+    ProcessInstance processInstance = runtimeService.startProcessInstanceByKey("oneReceiveTaskProcess");
+   
+    List<String> activities = runtimeService.getActiveActivityIds(processInstance.getId());
+    assertNotNull(activities);
+    assertEquals(1, activities.size());
+   
+    runtimeService.signal(processInstance.getId());
+    activities = runtimeService.getActiveActivityIds(processInstance.getId());
+    assertNotNull(activities);
+    assertEquals(1, activities.size());
+  }
+ 
   public void testFindActiveActivityIdsUnexistingExecututionId() {
     try {
       runtimeService.getActiveActivityIds("unexistingExecutionId");     
Index: src/test/resources/org/activiti/engine/test/api/oneReceiveTaskProcess.bpmn20.xml
===================================================================
— src/test/resources/org/activiti/engine/test/api/oneReceiveTaskProcess.bpmn20.xml (revision 0)
+++ src/test/resources/org/activiti/engine/test/api/oneReceiveTaskProcess.bpmn20.xml (revision 0)
@@ -0,0 +1,31 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<definitions
+  xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
+  xmlns:activiti="http://activiti.org/bpmn"
+  targetNamespace="Examples">
+
+  <process id="oneReceiveTaskProcess" name="The One Receive Rask Process">
+ 
+    <startEvent id="theStart" />
+    <sequenceFlow id="flow1" sourceRef="theStart" targetRef="firstReceive" />
+   
+    <receiveTask id="firstReceive" name="First Receive" /> 
+   
+    <sequenceFlow sourceRef="firstReceive" targetRef="fork" />
+   
+    <parallelGateway id="fork" />
+    <sequenceFlow sourceRef="fork" targetRef="receivePayment" />
+    <sequenceFlow sourceRef="fork" targetRef="shipOrder" />
+   
+    <receiveTask id="receivePayment" name="Receive Payment" /> 
+    <sequenceFlow sourceRef="receivePayment" targetRef="theEnd" />
+   
+    <manualTask id="shipOrder" name="Ship Order" />
+    <sequenceFlow sourceRef="shipOrder" targetRef="theEnd" />
+   
+   
+    <endEvent id="theEnd" />
+   
+  </process>
+
+</definitions>



Seems like it runs green (I replaced the scriptTask with a manual-task, but they behave the same when it comes to process-flow). When are you actually calling the "getActiveActivities()"? I presume not in the script-task but in your code that is consuming the API, right after the first signal() call?

Just a suggestion: try to use a parallel gateway to join the two parallel executions again, see http://activiti.org/userguide/index.html#bpmnParallelGateway. if this makes no difference, can you pour your process into a failing test-case?

[donovanmuller]

Hi,

Thanks for the quick reply.
I have run your test case and it fails (Activiti 5.9):

assertEquals(1, activities.size()); –> junit.framework.AssertionFailedError: expected:<1> but was:<0>

I added another test case modifying your process but with no gateway in and it passed successfully. So definitely something fishy when the receiveTask is "in" a gateway.

I'm using Activiti as an embedded workflow engine in a spring app that is exposed as a RESTful web service.
There are two separate calls to resume the process (when a receiveTask is waiting) and to get the current active activities (hence the use of getActiveActivities())
So the calls to signal() and getActive…() are not directly below each other in code. Would this affect it?

I will try your other suggestion regarding the gateway now…

[frederikherema1]

It would only affect something if the call to getActiveActivityIds() was made from within the process (JavaDelegate, execution listener, …) which is not recommended. So your approach is perfectly fine.

The failing test on 5.9 indicates that there is a fix comitted on trunk regarding parallel gateways. Not sure for what issue though…

[donovanmuller]

Here is a test project that demonstrates the failing test.

One more confusing thing is, I have added a simple groovy scriptTask to just print to the console after each receiveTask.
The scriptTask prints as expected after the first receiveTask but does not print after the second receiveTask (regardless of whether these is a gateway or not), any idea why that would happen?

Thanks for the help

[frederikherema1]

The test doesn't actually signal the second task, maybe that's why the second println doesn't show through.

Confirmed with your tests, 5.9 fails and 5.10-SNAPSHOT is successful. So you rather wait for 5.10 final or use a snapshot for now to overcome the issue.

[donovanmuller]

Sorry, stupid mistake on my side.
I've added a second signal to the test case but now the process with the "return" gateway, as per your suggestion, fails when trying to signal the second receiveTask with:
SEVERE: EXCEPTION: org.activiti.engine.ActivitiException: this activity doesn't accept signals

Any ideas why this would happen?

When is 5.10 final expected?

[frederikherema1]

5.10 is scheduled for 1st of August (https://jira.codehaus.org/browse/ACT/fixforversion/18341).

Make sure all your sequence-flows are valid in the processes you're testing.