Multi-Instance call activity: cannot resolve elementVariable during subsequent runs

[Gregor Tudan]

Hi,

I'm seeing strange behavior with a parallel multi-instance call-activity in camunda bpm 7.1.0-Final:

The first node in the subprocess is a serviceTask using the elementVariable.
When I run the process the first time, everything works as expected, but any subsequent call will compain about the element variable not being resolvable:

Server Error: Cannot instantiate process definition 553586de-4f95-11e4-a7af-00212844ce8e: Unknown property used in expression: #{askId}. Cause: Cannot resolve identifier 'askId'

Here's the call activiti:

<callActivity id="subCreateReport" name="Create Report" calledElement="createReportProcess">
      <extensionElements>       
          <camunda:in source="reportId" target="reportId"/>
          <camunda:in source="reportMonth" target="reportMonth"/>
      </extensionElements>
      <incoming>sid-A2B722F8-078C-4697-BC40-E277E18659AD</incoming>
      <outgoing>sid-7F003232-BA23-4DEC-B061-E75F76A2E601</outgoing>   
      <multiInstanceLoopCharacteristics id="sid-df18270c-be5b-4a4e-8011-b28678271343">
          <loopDataInputRef>reportItems</loopDataInputRef>
          <inputDataItem name="askId" />
      </multiInstanceLoopCharacteristics>
    </callActivity>

I tried setting variable exclicitly in a camunda:in statement, but that didn't work either.

Thanks, Gregor

[Gregor Tudan]

Over the weekend, I tried a few more things to get around this issue, without much success.

• using camunda:collection and camunda:elementVariable didn't change anything
• resolving the variable with camunda:in sourceExpression didn't work either
• using ${execution.getVariable("askId")} in the subprocess will resolve to an empty string
• experimenting with sequential and async attibutes on the call-activity didn't change anything notable
  

We are using the engine through the REST-Interface. After running the process once, we need to restart the engine, or any following executions will fail. I wasn't able to reproduce this issue in a unit test (by creating a for-loop starting the process multiple times).

The overall experience of the call-activity appears to be a little buggy - I used the exact same activity in a different process, where I can't get the subprocess working at all.

This is a huge blocker for us, so any help is highly appreaceated!

Thanks, Gregor

[thorben....@camunda.com]

Hi Gregor,

The correct configuration should be (so you need to map the loop variable to a variable of the called process using a camunda:in element):

<callActivity id="subCreateReport" name="Create Report" calledElement="

createReportProcess">
      <extensionElements>       
          <camunda:in source="reportId" target="reportId"/>
          <camunda:in source="reportMonth" target="reportMonth"/>

          <camunda:in source="askId" target="askId"/>

      </extensionElements>
      <incoming>sid-A2B722F8-078C-4697-BC40-E277E18659AD</incoming>
      <outgoing>sid-7F003232-BA23-4DEC-B061-E75F76A2E601</outgoing>   
      <multiInstanceLoopCharacteristics id="sid-df18270c-be5b-4a4e-8011-b28678271343">
          <loopDataInputRef>reportItems</loopDataInputRef>
          <inputDataItem name="askId" />
      </multiInstanceLoopCharacteristics>
    </callActivity>

Could you try to write a unit test using the template in [1]? That test would have to consist of the calling and the called process. You would instantiate the calling process once and create a number > 2 of instances of the called process. In that called process, you could add assertions whether the variable is set or not.
Then it is more easy for us to understand the problem and support you in solving it.

Thanks and best regards,
Thorben

[1] https://groups.google.com/forum/#!topic/camunda-bpm-users/7fB4rxWEpVY

[Gregor Tudan]

Hi Thorben,

thanks for looking into this!
I tried exclicitly passing the variable as you sugested, but that doesn't fix it. The problem might me related to the REST-Interface,  as I couldn't reproduce it in a unit test (see above). I still can't figure out why this works on the first invocation....

Thanks, Gregor

[thorben....@camunda.com]

Hi Gregor,

From what you wrote above, I understood that you tested the called process by explicitly instantiating it multiple times from a for loop. However, this won't reproduce the problem because I think it is related to the engine's implementation of multi-instance. Thus, it is important that you write a test that uses both, calling and called process (and as described in my last post).

Based on this, I am quite certain that this is not an issue with the REST API but rather with multi-instance handling in the engine.

Please correct me, if I am having a misunderstanding here.

Cheers,
Thorben

[Gregor Tudan]

Hi Thorben,

I tested this calling the main process. I've attached my (passing) unit test.

Thanks again,

Gregor

Am Freitag, 10. Oktober 2014 17:57:11 UTC+2 schrieb Gregor Tudan:

[thorben....@camunda.com]

Hi Gregor,

Thanks for sharing your test case and now I understand your reasoning.

Based on that I have the following questions:
1. In what way does the process in which you see the problem differ from the process in the test case? If possible, please share the process models.
2. In what way, in detail, do you interact with the engine? You write that you use the REST API. How does the request you make look like in detail? Is my understanding correct that you issue multiple REST requests and while the first succeeds (and invokes a number of instances of the called process), the subsequent requests fail? In what way do the requests differ?

Cheers,
Thorben

[Gregor Tudan]

OK, I guess I figured it out, though the problem isn't quiet where I suspected it to be. It look's like we tripped over a I reported earlier: https://app.camunda.com/jira/browse/CAM-2869

As the user guide states, delegates are shared globally. But the injections are not reset after invocation. So if you set a field to the expression "${var}" and invoke the delegate, it will try to resolve that variable even if it is executed in a completely different (sub-) process where that variable won't exist.

I had to "reset" the fields (which is harder than I thought) by adding a field input mapping of ${null} in any task using that delegate in order to get around the issue.

Cheers, Gregor

Am Freitag, 10. Oktober 2014 17:57:11 UTC+2 schrieb Gregor Tudan: