Vue d’ensemble de l’architecture

Comprendre comment Studio de workflow fonctionne dans le ServiceNow AI Platform pour activer, déclencher et traiter les flux et les actions.

Un flux se compose d’un déclencheur et d’une ou de plusieurs actions. Le déclencheur spécifie quand démarrer le flux, qui peut être basé sur l’enregistrement, le calendrier ou l’application. Les déclencheurs basés sur les enregistrements exécutent un flux après la création, la mise à jour ou la suppression d’un enregistrement. Le flux peut utiliser l’enregistrement de déclenchement comme entrée pour des actions. Les déclencheurs basés sur le calendrier exécutent un flux à la date et à l’heure spécifiées. Le flux peut utiliser le temps d’exécution comme entrée pour des actions. Les déclencheurs d’application sont ajoutés lorsque l’application associée est activée. Par exemple, le MetricBase déclencheur est présent lorsque l’application MetricBase est active.

Traitement du flux

Le traitement du flux se produit dans cet ordre.

1. Lorsque les conditions de déclenchement du flux se produisent ou qu’une API appelle directement le flux, le système crée une entrée dans la file d’attente de l’événement pour démarrer le flux.
2. Le planificateur traite l’événement et démarre le flux en arrière-plan.
3. Le système élabore un plan de processus à partir du flux
4. Le système exécute le plan de processus en utilisant l'enregistrement qui a déclenché le flux
5. Le système stocke les détails de l’exécution dans un enregistrement de contexte.

1. Déclencheurs de flux de processus et appels API

Chaque fois que les conditions de déclenchement sont remplies ou qu’une API appelle directement un flux, Studio de workflow cela crée une entrée d’événement. Le système traite les déclencheurs après les opérations de base de données. Pour en savoir plus, consultez Ordre d’exécution des scripts et des moteurs. En règle générale, le fonctionnement des règles métier et l’ordre de fonctionnement du moteur de workflow qui s’exécutent de façon synchrone s’exécutent avant un flux déclenché.

2. Traiter les événements dans la file d’attente

Chaque événement de flux contient une référence au flux à démarrer et une référence à l’enregistrement de déclenchement ou à l’heure d’exécution. Le système traite ces événements à l’aide d’événements dans lesquels un planificateur passe périodiquement en revue les éléments actuels de la file d’attente des événements dans l’ordre dans lequel ils ont été ajoutés. En fonction des autres événements dans la file d’attente, le système peut ne pas démarrer immédiatement un flux. Les concepteurs de flux doivent s’attendre à un certain temps de latence entre le moment où les conditions de déclenchement se produisent et le moment où le flux démarre réellement.

3. Élaborer le plan de processus

Lorsqu’un Studio de workflow événement est retiré de la file d’attente, il élabore un plan de processus pour exécuter réellement le flux. Un plan de processus contient toutes les informations nécessaires à l’exécution d’un flux, telles que la séquence des actions ou des flux secondaires publiés, les valeurs d’entrée pour chaque flux secondaire ou action, les étapes d’action à exécuter pour chaque action et les données fournies par le déclencheur ou la sortie de flux secondaire.

Studio de workflow utilise un schéma de compilation juste-à-temps pour s’assurer que les plans de processus contiennent les derniers changements apportés aux flux, aux flux secondaires et aux actions. Si aucun changement n’est détecté, Studio de workflow utilise une copie en cache du plan de processus. Sinon, il élabore un nouveau plan de processus.

En vérifiant automatiquement les flux, les flux secondaires et les actions mis à jour avec les plans de processus, Studio de workflow vous pouvez appliquer des changements à partir d’ensembles de mises à jour et de mises à niveau sans avoir à modifier les flux actuels. Si vous déplacez les actions publiées vers une instance cible, chaque flux qui utilise l’action publiée sera automatiquement mis à jour la prochaine fois qu’il sera exécuté.

Avertissement :

Si vous modifiez les flux secondaires ou les actions utilisées dans les flux activés, ne modifiez pas les entrées et les sorties utilisées dans le flux secondaire ou l’action. La modification des entrées et des sorties peut entraîner des erreurs lors du prochain déclenchement du flux activé, car il n’a pas été configuré pour utiliser les nouvelles entrées et sorties. Les flux en cours d’exécution ne sont pas affectés par les changements apportés aux entrées ou aux sorties, car le flux utilise les flux secondaires compilés et les actions du plan de processus.

4. Exécuter le plan de processus

Studio de workflow Exécute le plan de processus en tant qu’utilisateur spécifié dans les propriétés du flux et l’exécute dans le périmètre de l’application de flux.

Lors de l’exécution d’un flux avec un déclencheur basé sur un enregistrement, Studio de workflow stocke l’enregistrement de déclenchement en mémoire en tant qu’instance représentée dans l’interface sous forme de pastille de données.

Chaque fois que vous ajoutez une action à un flux, Concepteur de flux ajoute une pastille de données pour stocker ses résultats. Le nom de la pastille de données indique sa séquence dans le flux et son type de données. Les concepteurs de flux utilisent des pastilles de données de résultat d’action pour fournir une entrée pour d’autres flux, actions ou flux secondaires. Les concepteurs de flux peuvent utiliser la valeur de séquence dans le nom de la pastille de données pour s’assurer qu’ils sélectionnent la pastille de données correcte comme valeur d’entrée. Lorsqu’un flux exécute une action, il génère la valeur d’exécution de la pastille de données au fur et à mesure de son utilisation.

5. Stocker les détails d’exécution du flux

Studio de workflow Stocke les détails de l’exécution du flux dans un enregistrement de contexte de flux qui contient ces informations.

• État du résultat du flux
• Durée d’exécution du flux
• Messages du journal de flux
• Configuration du flux et valeurs d’exécution

Chaque fois qu’un flux s’exécute, Studio de workflow ajoute une entrée à la liste des exécutions de flux . Chaque entrée a son propre enregistrement de contexte et sa page de détails d’exécution correspondante.

Remarque :

Un contexte d’exécution de flux s’exécute dans un seul thread. Toutefois, il peut arriver que vous souhaitiez exécuter des flux dans des contextes distincts, même si cela peut consommer davantage de ressources de votre instance. Pour exécuter des flux secondaires dans des contextes de flux distincts au sein du même flux, consultez Flux dynamiques.

Un flux peut avoir l’un de ces états de résultat.

État	Description
Terminé	Le flux s’est terminé avec succès.
En cours	Le flux est en cours d’exécution. Par défaut, une règle de quota de transaction empêche les flux de s’exécuter au-delà d’une heure.
En attente	Le flux attend qu’un autre événement se produise. Par exemple, un utilisateur doit mettre à jour une tâche ou une approbation, ou un enregistrement doit atteindre un état spécifique. Lorsqu’il est à l’état En attente, le flux est mis au repos et sérialisé dans un enregistrement de contexte.
Annulé	Le flux a été annulé par un utilisateur.
Erreur	Le flux a rencontré une erreur et s’est arrêté en cours d’exécution. Par exemple, une action n’a pas de valeur d’entrée ou une règle de transaction de quota a arrêté le flux.

Cycle de vie du flux, du flux secondaire et de l’action

Studio de workflow Utilise le flux ou l’état de l’action pour décrire l’état actuel des changements de configuration.

État du flux et du flux secondaire et état d’activation

Le champ État indique si un plan de processus est associé au flux ou au flux secondaire.

État du flux	Description
Modifié	Indique que des changements non enregistrés sont apportés à un flux ou à un flux secondaire. Les flux ou les flux secondaires modifiés n’ont pas été enregistrés.
Brouillon	Indique qu’il existe des changements enregistrés à un flux ou à un flux secondaire qui n’ont pas été stockés dans un plan de processus. Les flux de brouillon ont été enregistrés, mais pas activés. Les flux secondaires de brouillon ont été enregistrés, mais pas publiés.
Publié	Indique qu’il existe un plan de processus stocké pour le flux ou le flux secondaire. Les flux publiés ont été activés ou désactivés.

Le champ Actif indique si le système exécute un flux ou un flux secondaire.

Actifs	Description
Vrai	Indique que le flux ou le flux secondaire est actif et s’exécute lorsqu’il est déclenché ou appelé. Le flux a été activé ou le flux secondaire a été publié. Les flux actifs s’exécutent lorsque les conditions de déclenchement sont remplies ou lorsqu’ils sont appelés. Les flux secondaires actifs s’exécutent lorsqu’ils sont appelés.
Faux	Indique que le flux est inactif et ne s’exécute pas lorsqu’il est déclenché ou appelé. Un flux inactif n’a jamais été activé ou a été désactivé. Un flux secondaire inactif n’a jamais été publié.

Lorsque vous utilisez des flux, vous pouvez :

• Enregistrer un flux : crée un brouillon du flux.
• Activer un flux : active le déclencheur de flux et transforme le flux en plan de processus.
• Désactiver un flux : désactive le déclencheur de flux et empêche l’exécution de nouveaux flux. Les flux en cours d’exécution continuent de s’exécuter.

Lorsque vous utilisez des flux secondaires, vous pouvez :

• Enregistrer un flux secondaire : crée un brouillon du flux secondaire. Si le flux secondaire est modifié après sa publication, il passe à l’état Brouillon. Tous les flux actifs qui utilisent le flux secondaire exécutent uniquement le flux secondaire publié.
• Publier un flux secondaire : vous permet d’activer un flux contenant le flux secondaire. La publication ajoute le flux secondaire à la liste des flux secondaires disponibles dans un flux.

État de l’action

L’interface Studio de workflow n’affiche pas l’état de configuration des actions. Pour afficher le statut de l’action, accédez à la table Types d’actions [sys_hub_action_type_definition] et affichez le champ État de brouillon .

Statut du brouillon de l’action	Description
Brouillon	Indique qu’il existe des changements à une action qui n’ont pas été publiés. Les actions en mode brouillon ne sont disponibles pour les flux que lorsque l’option Afficher les actions en mode brouillon est activée. Vous ne pouvez pas activer un flux contenant des actions de brouillon.
Publié	Indique que l’action a été publiée. Les actions publiées sont disponibles pour tous les flux et permettent aux flux d’être activés.

Lorsque vous utilisez des actions, vous pouvez :

• Enregistrer une action : crée un brouillon de l’action qui n’est disponible pour les flux que lorsque l’option Afficher les actions en mode brouillon est activée. Si l’action est modifiée après avoir été publiée, l’action passe à l’état Brouillon. Tous les flux actifs qui utilisent l’action exécutent uniquement l’action publiée.
• Publier une action : vous permet d’activer un flux contenant l’action. La publication ajoute l’action à la liste des actions disponibles dans un flux. Seules les actions dans un état publié s’exécutent pendant l’exécution du flux.

Développement d'applications

Lors de la conception d’une action ou d’un flux, utilisez ces directives générales.

Utilisez les fonctionnalités de développement d’applications standard ServiceNow AI Platform pour créer, gérer, protéger et déployer Studio de workflow du contenu. Les concepteurs de flux et d’action effectuent généralement les tâches de développement d’application suivantes :

• Créez une application personnalisée pour stocker les flux et les actions.
• Définissez les autorisations d’application pour partager ou restreindre l’accès aux données d’application.
• Accorder aux développeurs d’applications l’accès à Studio de workflow.
• Publiez des applications personnalisées dans le référentiel d’applications pour déployer des flux et des actions sur d’autres instances.

Évitement des collisions

Studio de workflow Permet d’éviter les collisions. L’évitement des collisions empêche un utilisateur de modifier un objet en cours de modification dans un autre ensemble de mises à jour. Par exemple, l’utilisateur A modifie un flux dans un ensemble de mises à jour particulier. L’utilisateur B, qui travaille dans un ensemble de mises à jour différent, tente d’ouvrir le même flux. Dans cette situation, le système détecte une collision et alerte l’utilisateur B. L’utilisateur B peut alors choisir d’annuler ou de continuer. Sélectionner Annuler renvoie l’utilisateur B à la page d’accueil Studio de workflow . La sélection de Continuer ouvre le flux en mode lecture seule.

Pour que la prévention des collisions fonctionne, les deux utilisateurs doivent se trouver dans le même périmètre d’application et il doit s’agir d’un périmètre d’application autre que global. En outre, l’application en cours de modification doit être liée au contrôle de source. Pour plus d’informations, voir Prévention des collisions.

Sécurité

Contrôlez l’accès aux processus et aux Studio de workflow enregistrements.

• Les administrateurs peuvent accorder aux utilisateurs l’accès aux flux en Studio de workflow créant une application et en affectant des utilisateurs en tant que développeurs avec l’autorisation de développement délégué. Le développement délégué permet aux administrateurs de contrôler si les concepteurs de flux peuvent accéder à des fonctionnalités normalement réservées aux utilisateurs administrateurs, telles que l’affectation de rôles d’utilisateur, la création de contrôles d’accès ou la création de scripts. Pour plus d’informations, consultez Autorisations des développeurs.
• Les administrateurs peuvent accorder l’accès aux Studio de workflow flux en affectant directement aux utilisateurs le rôle d’utilisateur flow_designer, qui comprend le rôle d’affichage des détails d’exécution du flux.
  Avertissement :

  Accorder directement le rôle de flow_designer à un utilisateur revient à lui donner le rôle d’administrateur, car Studio de workflow il peut exécuter des flux en tant qu’utilisateur système, qui a accès à toutes les tables et à toutes les opérations de base de données.
• Les concepteurs de flux et d’action peuvent utiliser les paramètres d’accès à l’application standard pour gérer la façon dont leur contenu interagit avec d’autres applications.

Limite d’action

Par défaut, les flux ne peuvent pas comporter plus de 50 actions. Pour modifier le comportement par défaut, augmentez la valeur de la sn_flow_designer.max_actions propriété système. Toutefois, tenez compte de l’impact sur les performances qu’un flux important peut avoir sur votre instance.

Options de déclenchement pour les mises à jour d’enregistrements

Les concepteurs de flux peuvent spécifier la fréquence à laquelle un flux peut mettre à jour un enregistrement particulier avec l’option Exécuter le déclencheur . Utilisez l’option Une fois lorsque vous souhaitez qu’un flux ne s’exécute qu’une seule fois. La première fois qu’un enregistrement est mis à jour, le flux s’exécute, mais aucune autre mise à jour d’enregistrement ne déclenche le flux. Utilisez l’option Toujours lorsque vous souhaitez que le flux s’exécute à chaque mise à jour d’un enregistrement et qu’il n’y a pas déjà de flux actif en cours d’exécution. Par exemple, vous pouvez définir un flux qui affecte un enregistrement d’incident à exécuter une seule fois et définir un flux qui notifie la liste de surveillance des incidents pour qu’il s’exécute toujours. Le champ Exécuter le déclencheur n’est disponible que pour ces types de déclencheurs.

• Créé ou mis à jour
• Mises à jour

Prévention de la récursivité directe et limite de récursivité indirecte

Pour éviter les pannes d’instance et la consommation de ressources système, Studio de workflow ignore toute demande de démarrage d’un flux ou d’un flux secondaire résultant d’une récursivité directe. La récursivité directe se produit dans ces conditions.

• Une action appelle le même flux dont elle fait partie. Par exemple, une étape de script effectue un appel d’API à un flux.
• Une action ou un flux secondaire produit un résultat correspondant au déclencheur de flux. Par exemple, un flux qui s’exécute lorsqu’un enregistrement d’incident est mis à jour contient une action Mettre à jour l’enregistrement qui met à jour un enregistrement d’incident.

Studio de workflow limite également le nombre de fois où un flux peut être démarré à partir d’une récursivité indirecte. Une récursivité indirecte se produit dans ces conditions.

• Le même flux est appelé plusieurs fois dans une chaîne d’appels de flux secondaire. Par exemple, si le flux secondaire A appelle le flux secondaire B et que le flux secondaire B appelle le flux secondaire A, l’appel de l’un ou l’autre flux secondaire produit une récursivité indirecte.
• Le même flux est déclenché plusieurs fois dans une chaîne de flux secondaires. Par exemple, supposons que deux flux soient déclenchés par la création d’enregistrement. Supposons que la création de l’enregistrement A déclenche le flux A et crée également l’enregistrement B. En outre, la création de l’enregistrement B déclenche le flux B et crée l’enregistrement A. La création de l’un ou l’autre type d’enregistrement produit une récursivité indirecte.

Par défaut, le système arrête de déclencher les exécutions de flux lorsque le nombre d’exécutions atteint la limite de récursivité indirecte de trois exécutions. Les administrateurs peuvent modifier la limite en définissant la propriété com.glide.hub.flow_engine.indirect_recursion_limit système sur une valeur entière supérieure ou égale à un. Le système ignore toute valeur de propriété inférieure à une et utilise à la place une limite de un. Tenez compte de l’impact sur les performances que l’augmentation de la limite de récursivité indirecte peut avoir sur votre instance.

Remarque :

Par défaut, une règle de quota de transaction empêche les flux de s’exécuter au-delà d’une heure.

Test de flux et d’action

Le test d’un flux contourne les conditions de déclenchement et l’exécute immédiatement. Le test d’un flux avec un déclencheur basé sur les enregistrements nécessite la sélection d’un enregistrement spécifique qui servira de déclencheur. Les concepteurs de flux doivent générer des échantillons d’enregistrements appropriés avant les tests. Pour plus d’informations sur le test d’un flux, reportez-vous à la section Tester un flux.

Pendant la phase de conception, vous pouvez tester les actions non publiées en définissant Afficher les actions en mode brouillon sur le flux. Si vous effectuez un test avec des actions de brouillon, suivez ces directives.

• Concevez des flux et des actions sur une instance de non-production. Déployez uniquement des flux actifs et fonctionnels sur votre instance de production.
• Laissez Afficher les actions en mode brouillon défini sur vrai jusqu’à ce que votre action brouillon soit à l’état final. Une fois finalisée, publiez chaque action, définissez Afficher les actions en mode brouillon sur faux et activez le flux.
  Avertissement :

  La désactivation de l’option Afficher les actions en mode brouillon avant la publication de vos actions supprime toutes les actions en mode brouillon de votre flux.
• Toute modification apportée à un flux actif ou à une action publiée le fait revenir à l’état de brouillon. Si le flux est déclenché, le système n’exécute que le flux activé et les actions publiées, et les détails d’exécution du flux affichent uniquement ce qui a été exécuté. Lorsqu’il existe un brouillon d’un flux actif, le déclencheur et les actions répertoriés dans les détails d’exécution du flux peuvent être différents de ceux répertoriés dans le flux brouillon.