BPMN - How do I indicate that a "Call Activity" happens multiple times?

General Questions/Discussions
1

Hi ,

I need to indicate that a “call activity” will be called multiple times (will iterate through a list).

However, the “call activity” doesn’t seem to have a way to include the circular arrow that indicates looping.

Am I missing something?

Thanks, Filipe

2

Hi Filipe,

Currently we do not support modeling loop of call activity. I’ve forwarded your case to our engineers to investigate on it and I’ll keep you post once there are any feedback. Feel free to contact me for any help and wish you have a good day!

Best regards,
Rain Wong

3

Please see my other post below, this one is invalidated.

Other than what Rain mentioned above I think I may have found a possible work around here. Keep in mind though that I’m not 100% sure of the full standard compliancy. I read 13.2.6 (Loop activities) and 13.4.2 (Intermediate events) in the formal specification and based this idea on that.

So now I wonder if this could help you.

bpmn-loop

[s]So here’s the theory I based this on: according to the specification a loop is basically an activity type which (I quote): “Acts as wrapper for an inner activity that can be executed multiple times in sequence”. But I don’t think there’s anything stopping you from separating those activities as I’ve done above.

It’s not ideal, but may get the job done.[/s]

Food for thought?

4

Hey ShelLuser,

Thank you for giving it some thought.

I just think that something is not adding up. How come VP’s BPM modeler is missing this (apparently) simple feature? This is too big to have been missed. Do you agree?

Any other interested in pitching in?

5

First of all: I misread your initial question and fully glossed over your mentioning of the call activity and assumed you were referring to a task. A dumb mistake for sure considering the fact that regular tasks do support looping and Visual Paradigm fully supports the current formal standard to my knowledge.

When re-reading the BPMN specification then I don’t think this is an oversight at all. I think that using a loop within a call activity would actually violate the current standard.

Solely going by the specification: a loop applies to an activity. It is the activity itself that gets a looping behavior. Now mostly referring to tasks and sub processes.

But a call activity isn’t necessarily an activity. As its name implies it either calls a Global Task or a Process, and I think that the looping behavior should apply to those specific task elements, not the call activity itself.

I also noted that if you refer a call activity to a task which is looping then it will inherit the whole thing, including the looping symbol.

So quite frankly I don’t think there’s anything to fix here.

(edit): My opinion is also fueled by the definition of a call activity (see the specification): “The Cal Activity acts as a ‘wrapper’ for the invocation of a global Process or Global Task within the execution”.

6

hi.

I’m glad my question is more clear.

I’m going to make it even more clear with this diagram.

02 PM

I really need to be able to show in my model the first from the left.

Thanks

7

Best you can do at this time is using a work around, so a manual loop. A decision node should be able to handle that. But knowing VP there’s a good chance we’ll get an update soon :slight_smile: