Priorité entre la recherche de données, l’affectation et les règles métier

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 2 minutes de lecture

    • Les scripts, les règles d’affectation, les règles métier, les workflows, les escalades et les moteurs prennent tous effet dans le cadre d’une opération de base de données, telle que l’insertion ou la mise à jour. Dans de nombreux cas, l’ordre de ces événements est important.

    Remarque :
    Le code client qui s’exécute dans le navigateur, en utilisant Ajax ou en JavaScript, s’exécutera toujours avant la soumission du formulaire au serveur.
    L’ordre d’exécution est le suivant :
    1. Règles métier Avant : scripts configurés pour s’exécuter avant l’opération de base de données avec un ordre inférieur à 1 000.
    2. Avant les moteurs. Les éléments suivants ne sont pas exécutés dans un ordre spécifique :
      • Moteur d’approbation (pour les tables de tâches et sys_approval_approver)
      • Moteur de règles d’affectation (pour les tables de tâches)
      • Moteur d’escalade
      • Moteur de politique de données
      • Moteur de normalisation de champ
      • Moteur de rôles : maintient les changements de rôle synchronisés avec sys_user_has_role table (pour les tables sys_user, sys_user_group, sys_user_grmember et sys_user_role)
      • Moteur de plan d’exécution (pour les tables de tâches)
      • Mettre à jour le moteur de version : crée une entrée de version lorsque sys_update_xml entrée est écrite (pour sys_update_xml table)
      • Insertions ou mises à jour de moteurs de recherche de données
      • Moteur de workflow (pour les workflows par défaut)
    3. Règles métier Avant : scripts configurés pour s’exécuter avant l’opération de base de données avec un ordre supérieur ou égal à 1 000.
    4. Opération de base de données (insérer, mettre à jour, supprimer).
    5. Règles métier « Après » : scripts configurés pour s’exécuter après l’opération de base de données avec une commande inférieure à 1 000.
    6. Après les moteurs. Les éléments suivants ne sont pas exécutés dans un ordre spécifique :
      • Moteur d'étiquette
      • Moteur d’écoute
      • Moteur de notifications de table
      • Moteur de rôles : maintient les changements de rôle en synchronisation avec sys_user_has_role table (pour les tables sys_user, sys_user_group, sys_user_grmember et sys_user_role)
      • Moteur d’indexation de texte
      • Mettre à jour le moteur de synchronisation
      • Moteur de workflow (pour les workflows différés)
      • Moteur de déclenchement (pour tous les Studio de workflow flux)
    7. Notifications par e-mail. Les actions suivantes sont exécutées en fonction du poids de l’enregistrement de notification :
      • Notifications envoyées lors d’une insertion, d’une mise à jour ou d’une suppression
      • Notifications basées sur les événements
    8. Règles métier Après (uniquement les enregistrements actifs). Scripts configurés pour s’exécuter après l’opération de base de données avec un ordre supérieur ou égal à 1 000.
    Remarque :
    Comme les règles métier After, les règles métier asynchrones exécutent leur logique après une opération de base de données. Contrairement aux règles métier Async , les règles métier asynchrones s’exécutent de manière asynchrone et s’exécutent en arrière-plan simultanément avec d’autres processus. Les règles métier asynchrones s’exécutent après que l’utilisateur a soumis le formulaire et après que le planificateur a exécuté le travail planifié créé à partir de la règle métier. Le système crée une tâche planifiée à partir de la règle métier après que l’utilisateur a soumis le formulaire, mais avant qu’une action ne soit entreprise sur l’enregistrement dans la base de données.