topic Re: Auto deployment with duplicateFilter check does not work with expression based timer start event in Alfresco Archive

Auto deployment with duplicateFilter check does not work with expression based timer start event

bardioc — Fri, 21 Nov 2014 10:47:06 GMT

Hello,I've come across an issue with process models having a time based start event with an expression and which are deployed via auto deployment feature. The DeployCmd.java uses 'deploymentsDiffer' to determine differences and decides whether a new deployment is necessary or not. However, if one ha

Re: Auto deployment with duplicateFilter check does not work with expression based timer start event

trademak — Fri, 21 Nov 2014 15:41:20 GMT

Hi Heiko,

Interesting point. Are you restarting the Engine? Wouldn't that mean that the "old" process definition gets the new value of the #{myProcess.timeCycle} expression?

Best regards,

Re: Auto deployment with duplicateFilter check does not work with expression based timer start event

bardioc — Sat, 22 Nov 2014 15:41:10 GMT

Hello Tijs,

whenever the value within the database has been changed, which is returned by the getTimeCycle() method, the whole application server is restarted. However during this restart, the getTimeCycle() of the start timer event is not called again.

Apparently, it is only called when the process model is deployed, not when the engine is started.

What do you think? Should a timer start event expression be evaluated every time the process engine starts or only at deployment? When designing the processes, we thought the former was the case, but it seems the latter is.

Regards,

Heiko

Re: Auto deployment with duplicateFilter check does not work with expression based timer start event

trademak — Sun, 23 Nov 2014 19:41:45 GMT

Hi Heiko,

When the application server is restarted the BPMN XML is read again and all expressions are read again.
But this is a specific case because there's a timer job that's already created for the first deployment.
It would be possible to write some custom logic to change the timer job based on the new value in the database.

Best regards,

Re: Auto deployment with duplicateFilter check does not work with expression based timer start event

bardioc — Sun, 23 Nov 2014 21:57:26 GMT

Hey Tijs,

I think I don't fully understand what you wrote …

> When the application server is restarted the BPMN XML is read again and all expressions are read again.

As far as I found out is, that the BPMN XML may be read again, and the expressions may be read again too, but according to break points we set in our getTimeCycle()-method, it is not called again, thus the job entry in ACT_RU_JOB keeps the old information. It is only called, when the process model somehow changes (because of the auto deployment feature …) More importantly, even after the timer fired, the new value is not used.

I think this is something nobody would expect. I for myself would expect, that in case a timer start event is using an expression, this expression is evaluated at least at start of the process engine. It would be a good feature to have a runtime service to update the timer start events programmatically too.

Nevertheless, I need a solution to make sure, that all timer start events using expressions are updated. Can you lead me to an example of such custom logic you are referring to?

Thank you,

Heiko

Re: Auto deployment with duplicateFilter check does not work with expression based timer start event

trademak — Tue, 25 Nov 2014 09:30:59 GMT

Hi Heiko,

What I mean is that the start event timer is a specific case, because when the process definition is deployed for the first time it will create a job in the Activiti database with the expression value at the point in time. Then when you restart the Engine, the BPMN XML is parsed again, but due to the duplication filter, no new timer job will be inserted into the database. And this behaviour is correct because otherwise you would have two timer jobs.

The behaviour you are looking for is that the timer job is updated with the new expression value when the Engine is restarted. So you could write logic to update the timer job yourself. I don't have an example for this custom logic, it's the first time I encountered such a use case.

Best regards,