| unicaen_evenement.etat.default_code | en_attente | Code de l'état par défaut de tout nouvel événement |
| unicaen_evenement.evenement.max_events_per_run | 50 | Nombre maximum d'événements qui peuvent être traiter d'affilés |
| unicaen_evenement.evenement.max_time_execution | PT45S | Un événement en cours sera mis en echec après ce délais |
| unicaen_evenement.evenement.ttl | P3D | Un événement en attente passera dans l'état annuler si ce délai est dépassé |
| unicaen_evenement.evenement.skip_if_event_running | true | Interdire ou non plusieurs traitements d'événement den paralléle |
| unicaen_evenement.evenement.stop_on_failure | true | Arrête le traitement des événement après X echec |
| unicaen_evenement.evenement.max_allowed_failures | 10 | Nombre maximum d'échec autorisé |
| unicaen_evenement.evenement.handlers | [Evenement de test] | Tableaux de mapping entre les événements et leurs scripts d'execution |
**Quelques subtilité** :
- Les délais sont à fournir aux format php DateTime
- max_time_execution ne peut pas dépasser 10 min
- max_time_execution doit être afiné en fonction du paramétre php max_execution_time et du délais entre les crons :
Pour un traitement des événements toutes les 5min, il est recommandé de mêtre un max_time à 3
## Handlers
Le traitement des événements repose sur un système de "Handlers", c'est-à-dire de classe php qui s'occupe du traitement d'un événement
Chaque type d'événement doit correspondre à 1 et 1 seul Handler est implémenter l'interface [EvenementHandlerInterface.php](../src/Service/EvenementHandlerInterface.php)
La fonction supports() permet de définir des conditions d'execution d'un événement.
Le mapping entre l'événenement et son handler sont à définir dans le paramétre unicaen_evenement.evenement.handlers
```yaml
unicaen_evenement:
evenement:
# format : 'code_type_evenement' : 'defaultIndexName
handlers:
'test':'evenement_test_handler'
'send_mail':'send_mail_handler'
```
La clé doit correspondre au code du type d'événement et la valeur à l'index retournée par getDefaultIndexName()
La gestion du traitement des événements ce fait nécessairement par l'[EvenementManager.php](../src/Service/EvenementManager.php).
C'est lui qui est en charge de vérifier que les événements remplissent les conditions d'execution et de répartir le traitement des événements par les différents Handlers.
Ainsi lors de la définition d'un Handler, il n'est pas nécessaire de vérifier que l'événement est bien En Attente.
La fonction support des Handler permet de rajouter des conditions spécifiques à chaque Handler.
Par exemple pour send_mail_handler, de vérifier que l'on dispose bien d'une adresse de destinataire.
Changes for doc/modele.md: 76 added lines, 0 removed lines.
Original line number
Diff line number
Diff line
# unicaen/evenement-bundle
## Modéle de données
### Etats
Le systéme d'état permet de décrire si un événement est en attente de traitement, en cours ...
[EvenementInterface.php](../src/Model/EvenementInterface.php) donne l'ensemble de ses états.
Pour le moment, nous distinguons les 5 états suivants :
- "en_attente"
- "en_cours"
- "succes"
- "echec"
- "annule"
Il est cependant possible d'en rajouter ou de modifier leurs descriptions.
A noter que les 5 états précédents servent dans des constantes. Une sécurité permet d'éviter de les supprimer par erreurs depuis l'application, mais pas depuis la BDD.
### Types d'évènements
Les types d'événements permettent de décrire des actions a traiter par événement. Pour chaque action automatique, il faut définir un événement type avec :
- son code : identifiant textuel unique
- son libelle et une description
- des parametres éventuels : par exemple { "mail-to" } signifiera que l'événement de type test attendrons éventuellement un paramétre de destinataire de mail.
- Récursion : non réimplémenté pour le moment
Pour chaque nouveau type d'événement, il est important de définir un Handler pour implémenter le traitement des événements de ce type. (cf [configuration.md](configuration.md) > Handlers)
