Seamntic of async before on timer start event

Hi guys,

If i declare a timer start event as async before, what does it mean.
Are effectively two jobs created and executed or is it merged in one job?

What type does the job or jobs have? Timer start event or async-continue?

Best regards,

Markus

Hi @Markus,

if you will have asyncBefore on intermediate timer event, it will meant that first job for async behavior part will be created upon execution of which, timer jobs will be created. First job will be of class org.camunda.bpm.engine.impl.persistence.entity.MessageEntity and second of class org.camunda.bpm.engine.impl.persistence.entity.TimerEntity.

You could easily manipulate following test to try it out quickly org.camunda.bpm.engine.test.bpmn.event.timer.IntermediateTimerEventTest#testExpression.

Does that help you?
Askar

Hi Askar ,

Sorry I dont get it because I am not talking about a intermediate event but about a start event.
So my process is asyn before or in more detail my timer start event.

Take a look at the process model attached.

AsyncBeforeTimerEventProcess.bpmn (2.9 KB)

Best regards,

Markus

Hi @Markus,

sorry missed out start event, in this context first timer job will be created and then async execution. Take a look at org.camunda.bpm.engine.test.api.multitenancy.MultiTenancyTimerStartEventTest to adjust and quickly try out.

Cheers,
Askar

Ok,

Than i have two more questions.

  1. It is not able to set retry for both jobs. Am I right?
    Retry config is only used for timer start event but is not used for async execution.

  2. Is async-before on timer start event the best way to ensure that a new timer job is created even when process execution fails? If Timer event would not be async before, not follow up job is created when process ends in incident before a wait state was reached.

Best regards,

Markus

Hi @Markus,

let me just make sure I understand your use-case properly. You would like your process timer start event to be scheduled for retry with custom schedule if process has an incident, right?

I am not sure I understand why you need an asyncBefore. Could you take a look at org.camunda.bpm.engine.test.bpmn.async.FoxJobRetryCmdTest#testFailedTimerStartEvent and tell me if that’s close to your use-case?

Cheers,
Askar

Hi Askar,

No my use case is that I have a process started by a timer start event with a cycle configuration (P1D),
I want no retry for this process so that a Incident is created immediately for the process instance if its failed.

BUT furthermore I want that a new job is scheduled in every case so that new process instance is started on next day also if last process instance has an incident.

It is clear to you?

Best regards,

Markus

Hi Markus,

I think you don’t need any extras, at the moment of incident a new timer job instance with due date according to your schedule will be created.

Cheers,
Askar.

Hi Askar,

sorry for late reply.

I will evaluate again and maybe come back to you with a testcase.

Best regards,

Markus