Here is the chapter dedicated to the configuration of an event of type “Minutor“. There are several types of these, each with their own specificities and use cases.
To understand this chapter, the “start” of a timer defines when the process arrives at the timer event, and the “trigger” of a timer defines when it is finished.
Timer types
1. The intermediate timer
This timer is used to mark a stop time in the execution of the process (or of the branch on which it is positioned). Activity 2 will only be started when the timer time condition has been met, i.e. when the timer has been triggered.
This condition can take the form of a specific date (example: Thursday, January 01, 2015 at 3:00 pm) or a duration from which the timer must be started (example: 1 week after its start).
2. The border timer
A border timer starts only when the activity on which it is positioned starts. This timer can be set to :
- all types of tasks (human, service, script, …),
- all sub-processes,
- all the calling tasks.
If the activity on which it is positioned ends before it is triggered, it will be considered “deleted” and cannot be triggered afterwards.
Information Border timers also have their own attribute: the character interrupting or non-interrupting.
a. The non-stop timer
A non-stop edge timer will have no effect on the activity on which it is positioned if triggered.
This type of timer is widely used in the case of reminder mail generation because it does not stop the current activity.
Given its non-interruptive nature, a number of repetitions can therefore be configured so that it can be triggered several times (a reminder every three days, for example).
We are talking about a cyclic timer here.
b. The interrupting timer
An interrupting timer, when triggered, will end the activity on which it is positioned.
Setting a Timer
Three data can be configured for a timer:
- the period
- the triggering date
- the number of repetitions
These data are configurable independently of each other, the “checkboxes” allow to activate or not the property.
In the rest of this chapter, the following two pictograms will be used for the temporal representation of timers :
| Icon | Meaning |
 | Starting the timer |
 | Triggering the timer |
 | Timeline |
The date
The triggering date is the date on which the timer will be triggered. If the triggering date is earlier than the start date of the timer, then the timer will be triggered instantly.
The chosen date can be set from IteropDesign but also refer to an execution variable. The types of variables accepted will be :
- Date
- Date and Time (Date Time)
- Text field
Be careful, if the variable is not filled in when the timer is started, there will be an execution error.
If the chosen date is in the format Text Field, then it will have to follow the formatting of a standard date, whose pattern is: “yyyyy-MM-dd’T’HH:mmZ”. If the date is incorrectly formatted, there will be an execution error.
Example: leJanuary 01, 2015 at 13h02 should have as formatting: 2015-01-01T13:02+0000
Prefer the use of Date and Date Time using “Parse date” type transformations in the timer configuration instead of variablesText field.
The period
The period of a timer corresponds to the time difference between its start and its triggering. If no date is set, the reference of the period will be the one of the timer start. If a date is configured, a new option becomes available: a date “From” or “Before the“.
In case the date is “From“, the timer will be triggered after this date will be shifted by the period thus configured.
In case the date is “before “, the timer will be triggered before the reference date, shifted by the configured period.
The offset is an integer, and therefore, can be configured with a runtime variable of type Integer.
The configuration of a period is mandatory in the case of a cycle type timer.
Temporal representation of a timer with only one configured period of time
Temporal representation of a timer with a configured date “from” with a given time period
The number of repetitions
The edition of the number of repetitions is only accessible if the timer is on edge, and non-interrupting.
Editing this type of timer can cause infinite loops in the process in case the configuration is badly done!
If the timer has a fixed number of repetitions, then it will be considered as a cyclic timer and the period will then also have to be configured. The cycle can be infinite, so you have to enter the value “-1” in the configuration of the number of repetitions.
The cyclic timer is not “retroactive”. That is to say that if an earlier date is filled in, and the set of cycles does not reach a trigger date later than the start date (meaning that all possible dates are earlier than when the process arrives on the timer) then it will never be triggered.
In the case of a timer of this type, the period cannot be less than 10 seconds. If this period is shorter, the runtime motor will replace this value by 10 seconds.
Summary of the different possibilities
Period: ❌
Date: ✅
Type of date: ❌
Number of rehearsals: ❌
Period: ❌
Date: ✅ Prior to start-up date
Type of date: ❌
Number of rehearsals: ❌
Period: ✅
Date: ❌
Type of date: ❌
Number of rehearsals: ❌
Period: ✅
Date: ✅
Date type : ✅ from
Number of rehearsals: ❌
Period: ✅
Date: ✅
Date type : ✅ before
Number of rehearsals: ❌
Period: ✅
Date: ✅ Prior to start-up date
Date type : ✅ from
Number of rehearsals: ❌
Period: ✅
Date: ❌
Type of date: ❌
Number of repetitions : -1
Period: ✅
Date: ✅
Date type : ✅ from
Number of repetitions : ✅ 3
Period: ✅
Date: ✅
Date type : ✅ before
Number of repetitions : ✅ 3
