Execution order, execution time, error handling & retries
Main idea execution order
For actions you can choose the order in which they should be executed.
Actions will only be started if the previous one is completed
Unless, the action takes longer than 1 minute to complete and there is no retry mechanism (see Actions for more details on actions with retry mechanisms). In that case a timeout error is added to the event log and the next action will be executed.
Actions will only wait for the previous action itself, not for any depending triggers to be completed.
A triggers is executed in the order it was triggered. However, due to performance optimisations, it could be that an action of a later trigger is executed earlier.
Therefore, if the order of actions is important, you should always combine them in a single trigger.
However, we guarantee that for the same event, the conditions will be evaluated the same.
So when you have multiple triggers listening to a status change, and one of these triggers will manipulate some custom fields, then we guarantee that the conditions are evaluated before these manipulations take place.
Example:
Visitor with process step = step 1
Event: status change
Trigger 1 fired:
condition: process step = step 1
action1.1: change process step to step 2
Trigger 2 fired
condition: process step = step 1 >> this condition will always be evaluated before the execution of 1.1 and thus be evaluated as step 1
action2.1: send text message
When are conditions evaluated?
The trigger will always be fired after the action (and consequently subactions) is finished.
Thus, conditions are always evaluated for their state after the process that triggered the event is finished
Special cases that are not supported
It is not possible to take into account the result of a trigger for actions in the UI.
E.g. Disable automatic dispatch with a trigger could result in unwanted behavior: It could happen that still some extra visitors are dispatched before the trigger that disables dispatch is executed.
E.g. Don’t allow a visitor to register with a trigger could result in unwanted behavior: It could happen that the visitor registers just before the trigger that changes him to blocked is executed.
E.g. Use pincode in confirmation screen of an self-service kiosk screen. The pincode will not yet be created before the SSK final screen is shown.
Example
Use case: send pin code after dispatch
Bad configuration: send sms will be executed before pincode is added to ACS
Trigger 'A' : On dispatch
Change status > this will trigger 'B'
Send sms with pincode
Play buzzer sound
Trigger 'B': On status change
add person with pincode to ACS
Good configuration: send sms will be executed after pincode is added to ACS
Trigger 'A' : On dispatch
Change status > this will trigger 'B'
Play buzzer sound
Trigger 'B': On status change
add person with pincode to ACS
Send sms with pincode
Retry mechanisms
For next actions there are retry mechanisms in place.
Visitor actions
API call retry - time since initial request (both Cloud and Local)
first after 2 minutes
second after 6 minutes
third after 14 minutes
fourth after 30 minutes
fifth after 62 minutes
ANPR retry - time since initial request
first after 15 seconds
second after 45 seconds
third after 2 minute
fourth after 4 minutes
fifth after 8 minutes
sixth after 16 minutes
Asset actions
Cloud API call retry - time since initial request
first after 2 seconds
second after 6 seconds
third after 14 seconds
fourth after 30 seconds
fifth after 62 seconds
Status codes for which we retry
Peripass will do a retry if:
The HTTP response of the API call is not in the 2xx range (= the range that indicates a successful call)
There is a time-out
Warning: Retry in case of timeout
Peripass will also do a retry in case of timeouts. Be aware that there might be a risk that duplicate data is created in this case. We still choose to do a retry in case of timeouts, as the most common use case for actions in Peripass is updating data, for which the risk of creating duplicate data does not exist.
Error handling
When an action could not be executed, an error is added to the event log (found under configuration).