multiInstanceLoopCharacteristics with an empty list

[harry11]

Hello,

I'm using a multiInstanceLoopCharacteristics with a List in my Activiti process. It works fine, except when the list is empty (the list is not null, it's just empty).
When the list is empty I have this error :

19 mai 2011 16:42:14 org.activiti.engine.impl.interceptor.CommandContext close
GRAVE: Error while closing command context
org.activiti.engine.ActivitiException: Invalid number of instances: must be positive integer value, but was 0
 at org.activiti.engine.impl.bpmn.behavior.ParallelMultiInstanceBehavior.createInstances(ParallelMultiInstanceBehavior.java:42)
 at org.activiti.engine.impl.bpmn.behavior.MultiInstanceActivityBehavior.execute(MultiInstanceActivityBehavior.java:82)
 at org.activiti.engine.impl.pvm.runtime.AtomicOperationActivityExecute.execute(AtomicOperationActivityExecute.java:40)
 at org.activiti.engine.impl.interceptor.CommandContext.performOperation(CommandContext.java:76)
…
‍‍‍‍‍‍‍‍‍

I think it should work when there is no instance in the list (and just skip the loop), shouldn't it ?

Regards,

[ronald_van_kuij]

The error says it should be a positive integer. 0 not being that (nor a negative integer) And knowing Joram, I think it is implemented correctly. If you doubt this look at the specs. To prevent this, just add an exclusive gateway in front of it that does the 0 size check and bypasses this specific node.

[harry11]

(Thank you for your answer, I fixed my problem this way, with gateways)

I can't find any information in the BPMN spec about the multiInstanceLoopCharacteristics semantic. I found in the Activiti user guide :

"A multi-instance activity is a way of defining repetition for a certain step in a business process. In programming concepts, a multi-instance matches the for each construct: it allows to execute a certain step or even a complete subprocess for each item in a given collection, sequentially or in parallel. "

For instance, in Java, when using the for each loop, the following code doesn't throw any exception :

List<String> list = new ArrayList<String>();
  for (String aString : list)
  {
   // doStuff
   assertEquals("Hello", aString);
  }
The loop is skipped.

Actually I think that "positive integer" usually refers to positives numbers + 0, and "strictly positive integer" doesn't include 0.

[ronald_van_kuij]

Actually I think that "positive integer" usualy refers to positives numbers + 0, and "strictly positive integer" doesn't include 0.

Not in xsd's 🙂 and java is java (not bpmn or xml).

But… I did scan the spec to and there is indeed no reference that it might not be a size of 0 and what the behaviour should be then. I might have missed something though… question for the experts…

[frederikherema1]

What is exactly the issue? It doesn't make sense to have an multi-activity be have zero instances executed (messes up the flow history as well)

[harry11]

What is exactly the issue? It doesn't make sense to have an multi-activity be have zero instances executed (messes up the flow history as well)

Well, sometimes, in my case, I need to have 0 instance executed.


No instance -> the loop is skipped.
That's the way the for each loop usually works, isn't it ?

[frederikherema1]

That's how it works in porgramming, true But the foreach was just mentioned in userguide to make analogy with the concept of looping over each item…

Only workaround I can think of is modeling a exclusive gateway around the MI-activity which checks the list's size for 0…

[harry11]

Right, the exclusive gateway trick is the solution I use.

I let this topic open since I think it needs to be checked, then added in the Activiti User Guide.

Thanks every one for your help 😉

[ronald_van_kuij]

What is exactly the issue? It doesn't make sense to have an multi-activity be have zero instances executed (messes up the flow history as well)

Why does it mess up the flow history? Because Activiti implements this in a specific way (it is Activiti specific anyway) ? That should be the argument. With multi instances there is an inner and outer part. The outer part could still be 'executed' e.g. So no problem with the history flow then.

But these are implementation issues. I'm more curious to whether it is allowd according to the spec to have a size of zero. I read about a default of 1 if you do not want it base on the size of something you pass in and do not provide an explicit number. Further more the explicit number you can provide must be an xsd:integer, so even a  -1 could be provided… A size of -1 is difficult, but a size of 0 not… So… food for thought

[frederikherema1]

Ronald, you're right, it won't mess up history since there have inner and outer executions (my bad) Spec doesn't seem to mention any limititations on the number of items in the collection…