Hyland Connect

ami · ‎03-01-2017

Hi,

I am facing an interesting problem using Boundary timer with Cycles parameter. To have a look at my process definition, REFER: 'Boundary Timer continues execution.png'

The problem with this definition is, Once we reach to 'User Task-2 (for User-2)', we will let Boundary timer execute just for one time.
Once Boundary timer is executed, User-2 immediately completes it's action, which was assigned in 'User Task-2 (for User-2)' But but but the problem here is, Boundary timer still stays there in act_ru_job table and continues it's execution until configured cycles gets finished.

Ideally, once user completes the action, Boundary timer should stop it's execution, which happens with most of my process definition, but there is some issue that I'm trying to find about this process definition.

Now, I was trying to play with my Definition, and what do I do is, I tried replacing Inclusive gateway with Parallel gateway, which resulted in same erroneous output, and then I replaced it by Exclusive Gateway and what do I see is, once it is executed and followed by activity - User completing it's action, resulted in - the boundary timer's job is removed from Runtime table. I wonder how does this work correctly?

Can anybody help me find out issue with this Definition?

Thanks,
Ami Dave

gdharley · ‎03-09-2017

Hello Ami,

I spent a little (too much) time crawling through the code that manages state transfers between activities.
There is certainly a defect here, but it is very deep in the code and will require some real though to find a good solution.

The problem (in a nutshell) is a result of the fact that you join the flow from the notification (timer boundary event branch) back into the main flow.

This means, as soon as the first timer fires, a new "Concurrent" execution is created.

Concurrent executions are not removed until all flow lines are complete (i.e. in your example until Uster Task 2 is complete and the join is reached).

Because the execution is not deleted, the job's associated with the execution are also never deleted.

As far as I can tell in the few hours I spent yesterday, the execution is destroyed and marked inactive, but never actually deleted until the last concurrent execution completes. At that time, the whole set are deleted.

I have not (yet) tested, but I expect the version 6 engine will likely resolve this behavior as the PVM is no longer used and the mechanism used to track concurrent executions is completely overhauled.

That said, as a work around, have the flow path from the timer go to an end event after it completes it's processing. This way, there will be no concurrent executions and things will behave as you expect.

Hope this helps,

Greg

‌

View answer in original post

ami · ‎03-08-2017

Hi Greg,

Thanks so much for reply.

But may I know that Is it chargeable to engage you guys and get a fix to it?

Thanks,

Ami Dave

gdharley · ‎03-08-2017

Hi Ami,

Please email me at the address above to discuss costs for engaging our companies services. I dont think this is the correct forum for such a discussion.

Greg

gdharley · ‎03-09-2017