(1) Timer Start Event with cycle "R10/PT10M" delivers 11 cycles instead of 10 - why? (2) How to avoid build/deploy-cycle for simple condition change?

[Dieter Rueffler]

Dear community,

I am experimenting with my first Camunda Process: A simple mail filter App without User-Tasks:

First step fetches mail, last step forwards mail.

4 interim XOR's do the trick of reduceing "SPAM" by simple mail-component-contains-key-expressions,

Right now I do have 2 questions I can not answer on my own: 

(1) Timer Start Event with cycle "R10/PT10M" delivers 11 cycles instead of 10 - why?

That's what I entered wiith the property editor

That is what happened inside my gmailer: 11 instead of 10 send events(!)

(2) How to avoid build/deploy-cycle for simple condition change?

To my opinion, changing the condition of a sequence following an XOR is simple.

Performing  a build/deploy-cycle in order to exchange  #{ variable contains "string1" } by #{ variable contains "string2" }  should not require a build/deploy-cycle

Is there something I can do in order to avoid build/deploys for simple changes of conditions?

• Apply a rules engine?
  
• apply some other kind of an engine?
  

Thanx for your help in advance!

Kind regards, Dieter

[webcyberrob]

Hi Dieter,

A couple of comments...

With regard to your 11 cycles, perhaps it should be interpreted as repeat 10 more times thus resulting in 11 cycles. I don't know if this is really the intent, but it could work that way.

In terms of a compile to change a condition, there are other choices. You could get the value from an external source. For example, the value could come from a data base table, a java virtual machine environment variable. It could even be a process instance variable where the value is set by the component which initiates the process instance. Hence you have much choice.

In addition, a little feedback on your process. Personally I prefer to use process flow constructs for process flow rather than business logic. What I mean is you really just have two paths, either send the email or dont. Hence I would model this with one decision gate. Thus could be a good example where a business rule task would determine of the email should be sent or not. Hence in your business rule task, you evaluate all the conditions you need to test. Note a rule task does not have to use a rule engine.

regards

Rob