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

[bardioc]

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 has a time start event, with the following definition of the time cycle as expression:

    <bpmn2:startEvent id="crd_start">
      <bpmn2:outgoing>crd_to_determine_contracts</bpmn2:outgoing>
      <bpmn2:timerEventDefinition id="TimerEventDefinition_1">
        <bpmn2:timeCycle xsi:type="bpmn2:tFormalExpression">#{myProcess.timeCycle}</bpmn2:timeCycle>
      </bpmn2:timerEventDefinition>
    </bpmn2:startEvent>
‍‍‍‍‍‍‍‍

and the value of this variable has changed, the automatic deployment process will not find this modification. The timeCycle in our case is backed by a database value that shall be retrieved here to determine when and how to start the process. We made it configurable by our business department.

Is there anything we can do here or do we have to disable the duplication check to make sure our process model is correctly deployed? The duplication check works quite well, as it makes sure, that in case the application is restarted, and no changes have been made, no unnecessary deployment occurs.

Regards,

Heiko

[trademak]

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,

[bardioc]

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

[trademak]

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,

[bardioc]

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

[trademak]

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,