Directives générales pour Studio de workflow les flux, les flux secondaires et les actions

Vue d'ensemble de Studio de workflow

Intégrez la création, la configuration et la surveillance des workflows dans une expérience de page unique. Consolidez les playbooks, les flux, les actions, les tables de décision et les intégrations dans un seul environnement de conception.

Développement d'applications

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

Utilisez les options de développement d’application standard Now 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 des 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.

Flux

Les flux doivent être des collections de travail courtes, modulaires et réutilisables. S’ils prennent plus d’une heure à exécuter, ils sont probablement trop longs et peuvent être plus efficaces.

Les directives générales qui s’appliquent aux flux s’appliquent également aux flux secondaires.

Prévenir les conflits ou les doublons de logique métier

Les automatisations peuvent être créées avec Concepteur de flux, les règles métier, les workflows et le concentrateur d’intégration. Avant de commencer à utiliser Studio de workflow , assurez-vous de bien comprendre le fonctionnement des automatisations existantes Now Platform . Désactivez les automatisations avant de les remplacer par Studio de workflow des flux et des actions. Reportez-vous à la Vue d’ensemble de l’architecture section pour en savoir plus Studio de workflow sur le fonctionnement dans le Now Platformfichier .

Examinez la documentation des flux, des flux secondaires et des actions, le cas échéant.

Déterminer si votre flux a besoin d’une entrée de déclencheur ou de variable

Les flux s’exécutent toujours lorsque leurs conditions de déclenchement sont remplies et les déclencheurs fournissent toujours les mêmes données en tant qu’entrée pour les flux. Si vous avez besoin d’une entrée variable pour lancer un flux à la place, créez un flux secondaire.

Réutiliser la logique métier

Créez un ensemble d’opérations réutilisables en tant que flux secondaire qui peut ensuite être utilisé dans plusieurs flux.

Accorder des rôles de flux pour accéder aux données protégées par les rôles et préserver les informations utilisateur

Les rôles de flux simplifient les autorisations pour vos flux. Utilisez des rôles de flux pour préserver les informations des utilisateurs et accorder l’accès aux données, au lieu d’exécuter un flux en tant qu’utilisateur système. L’ajout de rôles de flux donne également accès à des données supplémentaires qu’un flux initié par l’utilisateur n’a généralement pas. Les rôles accordés ne s’appliquent qu’au flux. Elles ne s’appliquent pas à l’utilisateur à l’origine du flux

Utiliser une logique de flux ou un déclencheur basé sur une planification pour contrôler la synchronisation du flux

La logique de flux ou les déclencheurs basés sur le calendrier permettent d’optimiser les performances de vos flux. N’utilisez pas la méthode gs.sleep() pour attendre dans un flux. La méthode gs.sleep() empêche le thread d’effectuer d’autres tâches. Pour exécuter un flux à une heure précise, utilisez un déclencheur basé sur une planification. Pour mettre en pause un flux pendant une durée spécifique, utilisez la logique de flux Attendre une durée ou attendre une condition .

Éviter les dépendances

Les branches parallèles qui dépendent les unes des autres bloquent un flux lorsqu’une branche doit attendre la sortie d’une autre branche. Au lieu de créer des branches parallèles au sein d’un flux, appelez un flux secondaire et renvoyez les résultats au flux principal.

Compteurs de boucles de champ d’application

Les boucles de script n’ont pas un nombre maximum d’itérations, de sorte que les boucles s’exécutent à l’infini lorsqu’il n’y a pas de condition de sortie valide.

Pour vous assurer qu’il existe une condition de sortie valide, définissez les compteurs de boucles dans les scripts inclus ou dans les étapes de script au sein d’une action. Ajouter var à for (i=0 ; i< length ; i++) :for (var i=0 ; i< length ; i++)

Limite pour chaque boucle et Exécuter jusqu’à 1 000 itérations

Les itérations de 1 000 boucles ou plus peuvent entraîner des problèmes de mémoire en raison du stockage des détails d’exécution et des enregistrements de contexte.

Définissez le nombre maximal d’enregistrements sur Rechercher des enregistrements.
Évitez de modifier la propriété sn_flow_designer.max_iterations, qui est définie par défaut sur 1 000.
Pour les boucles imbriquées, chaque boucle possède son propre nombre maximal d’itérations.
Pour les grandes quantités de traitement de données, envisagez le traitement par lots en lots plus petits.
Pour les importations en vrac, envisagez des importations simultanées.

Utiliser QuickAPI pour des exécutions plus rapides (alternative de règle métier)

Les exécutions de QuickAPI sont beaucoup plus rapides, mais il y a moins de capacité de débogage.
Premier plan Les exécutions de QuickAPI s’exécutent dans la session utilisateur en tant qu’utilisateur qui a appelé le flux.
Les exécutions de QuickAPI en arrière-plan s’exécutent dans un thread en arrière-plan et sont exécutées dans la session utilisateur « système ».

Utiliser des boucles Do Until au lieu d’appeler des flux à partir d’elles-mêmes

La récursivité directe où un flux s’appelle lui-même n’est pas autorisée et des erreurs sont présentes. La récursivité indirecte où le flux A appelle le flux B, qui appelle le flux A est autorisé jusqu’à trois fois. Au lieu d’appeler un flux de façon récursive, utilisez la logique de flux Exécuter jusqu’à pour continuer à travailler sur les enregistrements jusqu’à ce qu’une certaine condition soit remplie.

Exécuter des flux en arrière-plan

L’exécution de flux en arrière-plan permet de libérer des threads d’interface utilisateur plutôt que de mettre en pause la session utilisateur jusqu’à ce que l’exécution du flux soit terminée. Par défaut, les flux s’exécutent de manière asynchrone en arrière-plan. L’exécution des flux en arrière-plan permet aux utilisateurs de continuer à travailler dans l’interface utilisateur pendant l’exécution du flux.

Éviter la logique de flux qui attend après la collecte d’une sortie volumineuse

L’utilisation d’une charge utile volumineuse immédiatement après sa récupération peut aider à éviter les problèmes de mémoire. Plutôt que de stocker une charge utile volumineuse en mémoire, ajoutez des actions pour traiter la charge utile. Plus tôt vous traitez une charge utile récupérée, plus vite le système peut libérer de la mémoire pour traiter d’autres actions.

Minimiser les sorcellements entre lesenvironnements

Le va-et-vient constant entre les étapes d’instance et de Serveur MID dans un flux peut entraîner des retards de traitement. Pour minimiser le risque de retard, limitez le basculement entre l’instance et le MID Server à une seule fois.

Inclure les enregistrements sys_complex_object générés par le flux dans les ensembles de mises à jour

L’absence de schémas de données complexes peut entraîner des problèmes d’exécution. Assurez-vous d’inclure sys_complex_object enregistrements générés par le flux dans les ensembles de mises à jour. Plutôt que de créer manuellement des ensembles de mises à jour, envisagez de transférer des flux d’une instance à une autre à l’aide du référentiel d’applications.

Flux d’appels à partir d’un script lorsque vous avez besoin d’un déclencheur personnalisé

Si aucun des déclencheurs existants ne répond aux besoins de votre entreprise, vous pouvez créer un script pour démarrer un flux lorsque ses conditions de déclenchement personnalisées sont remplies. Plutôt que de créer un flux avec un déclencheur inutile, envisagez plutôt de créer un flux secondaire, qui n’a pas de déclencheur. Utilisez votre script pour fournir les entrées de flux secondaire nécessaires uniquement lorsque les conditions de votre script sont remplies. Appeler un flux secondaire plutôt qu’un flux évite que les conditions de déclenchement du flux soient remplies et que le flux s’exécute de manière inattendue.

Évitez de déployer des flux de version plus récents vers des instances de versions plus anciennes

Studio de workflow ne prend pas en charge le déploiement de flux vers des instances exécutées sur des versions antérieures. Parfois, le modèle de données du flux change entre les mises en production, ce qui peut empêcher l’exécution du flux ou produire des résultats inattendus.

Désactiver la génération de rapports de flux en production

Réduisez la quantité de mémoire requise pour exécuter les flux en désactivant la génération de rapports de flux. Le reporting de flux stocke les informations de configuration et d’exécution de la page Détails de l’exécution. Ces rapports sont utiles au dépannage, mais nécessitent la conservation d’une grande quantité de données à la fois en mémoire et dans la base de données. Par défaut, la génération de rapports de flux est désactivée et le système génère uniquement des détails d’exécution lorsque vous testez manuellement un flux ou une action. Au lieu de cela, vous pouvez utiliser des fichiers journaux, qui sont toujours disponibles lorsque les rapports sont désactivés.

Réduire la quantité de mémoire consommée dans les flux avec des boucles imbriquées

Lorsque la génération de rapports est activée, définissez com.snc.process_flow.reporting.iteration.lastn sur la valeur « 1 » pour réduire les quantités de mémoire consommées par les itérations de boucle précédentes. Plus vous signalez d’itérations, plus vous avez besoin de mémoire.

Flux secondaires

Les directives générales qui s’appliquent aux flux s’appliquent également aux flux secondaires.

Les raisons d’utiliser un flux secondaire au lieu d’un flux sont les suivantes :

Déterminer si votre flux a besoin d’une entrée de déclencheur ou de variable

Les flux s’exécutent toujours lorsque leurs conditions de déclenchement sont remplies. Les déclencheurs fournissent toujours les mêmes données que l’entrée pour les flux. Si vous avez besoin d’une entrée variable pour lancer un flux à la place, créez un flux secondaire.

Réutiliser la logique métier

Créez un ensemble d’opérations réutilisables en tant que flux secondaire qui peut ensuite être utilisé dans plusieurs flux.

Configurer des valeurs d’entrée différentes pour chaque appel

Configurez les valeurs d’entrée d’un flux secondaire différemment chaque fois que vous l’appelez. Par exemple, concevez un flux secondaire de manière à ce qu’il accepte différents types d’enregistrements en tant qu’exécution d’entrée. Réutilisez ce flux secondaire d’enregistrement générique au lieu d’écrire un flux spécifique pour chaque type d’enregistrement.

Améliorer les performances et la lisibilité des flux volumineux

Utilisez des flux secondaires quand un flux dépasse 25 actions. 50 est le nombre maximal d’actions spécifiées par la propriété système sn_flow_designer.max_actions, mais limitez un flux à 25 actions pour des performances optimales.

Transmettre des entrées et des sorties avec des flux secondaires

Appelez des flux secondaires si vous souhaitez transmettre des entrées et des sorties. Utilisez des flux secondaires si vous souhaitez spécifier les entrées disponibles pour un flux secondaire lorsqu’il démarre ou si vous voulez spécifier les sorties disponibles pour le flux parent après la fin d’un flux secondaire.

Déclencher plusieurs flux sur un seul événement par rapport à l’utilisation de flux secondaires parallèles

Utilisez des flux secondaires parallèles s’il existe des sorties interdépendantes ou si une action doit être effectuée lorsque toutes sont disponibles. Si ce n’est pas le cas, il est plus simple de déclencher plusieurs flux.
Pour configurer des flux secondaires parallèles, lancez chaque flux secondaire sans attendre, puis utilisez la condition attendre que chaque flux secondaire soit terminal (terminé, erreur, annulé)

Utilisez des flux dynamiques si vous avez plusieurs flux secondaires avec des fonctionnalités similaires

Les flux dynamiques vous permettent de compartimenter vos processus en appliquant un modèle pour gérer les entrées de plusieurs flux secondaires similaires. La compartimentation vous permet de distinguer les flux secondaires qui remplissent des fonctions similaires, tels que les flux secondaires pour les spokes Centre d’intégration .

Éviter la limite de 10 éléments dans le processus de gestion des erreurs

Plutôt que de forcer votre processus de gestion des erreurs à s’adapter à une limite de 10 éléments, appelez des flux secondaires, qui peuvent contenir beaucoup plus d’éléments. Vous pouvez également utiliser les sorties de flux secondaire pour déclencher l’automatisation dans d’autres flux.

Prendre des mesures correctives

Plutôt que de recréer la même séquence d’actions dans plusieurs flux, créez des flux secondaires réutilisables pour corriger les erreurs dans vos données d’enregistrement. Lorsqu’une erreur de flux laisse vos données d’enregistrement dans un état indésirable, utilisez des flux secondaires pour corriger ces enregistrements. Vous pouvez utiliser le gestionnaire d’erreurs pour identifier ces données d’enregistrement comme une sortie de flux secondaire.

Déclencheurs

Suivez ces instructions générales lors de la création de déclencheurs d’enregistrement.

Déterminer si votre flux a besoin d’une entrée de déclencheur ou de variable: Les flux s’exécutent toujours lorsque leurs conditions de déclenchement sont remplies. Les déclencheurs fournissent toujours les mêmes données que l’entrée pour les flux. Si vous avez besoin d’une entrée variable pour lancer un flux à la place, créez un flux secondaire.
Ajouter des conditions pour spécifier quelles valeurs d’enregistrement démarrent votre flux: Le démarrage d’un flux uniquement en cas de besoin consomme moins de ressources système que le démarrage d’un flux, sa mise en pause et l’attente de reprise du flux jusqu’à ce qu’une condition d’enregistrement spécifique s’applique. Au lieu de créer un flux qui commence par une action d’attente de condition, modifiez la conception du flux pour inclure la condition d’attente dans le déclencheur d’enregistrement.
Créer des conditions uniques pour les déclencheurs d’enregistrement sur la même table: Afin d’éviter que les flux ne se détachent les uns les autres, créez des conditions uniques pour chaque flux s’exécutant sur la même table. Si plusieurs flux sont sur la même table et le même filtre, il n’y a aucun moyen de connaître l’ordre dans lequel les flux s’exécutent. L’utilisation de conditions permet également d’optimiser les performances du flux en renvoyant un ensemble d’enregistrements plus précis et plus petit.
Ignorer les enregistrements ajoutés ou mis à jour par les ensembles d’importation et de mises à jour: Les déclencheurs d’enregistrement ignorent les enregistrements ajoutés ou mis à jour par l’application d’un ensemble de mises à jour ou l’importation d’un fichier XML. Ces opérations s’appliquent à l’ensemble de l’application ou de la table plutôt qu’à un enregistrement individuel.
Remplacer les déclencheurs d’enregistrement sur les tables de Catalogue de services par des déclencheurs d’application de Catalogue de services: Concepteur de flux n’affiche plus les tables de Catalogue de services comme options pour les déclencheurs d’enregistrement. Au lieu de cela, créez des flux qui utilisent le type de déclencheur de l’application Catalogue de services.

Conditions d’attente

Suivez ces conseils généraux lors de la création de flux qui attendent une condition.

Utiliser des déclencheurs d’enregistrement plutôt que des conditions d’attente pour démarrer les flux: Si vous souhaitez qu’un flux s’exécute uniquement lorsque certaines conditions d’enregistrement sont remplies, créez un flux avec un déclencheur d’enregistrement au lieu de démarrer et de mettre en pause un flux. Un flux en attente consomme plus de ressources système qu’un déclencheur de flux.
Annuler les flux dont les conditions de reprise ne peuvent jamais se produire: Empêchez vos flux d’attendre indéfiniment en spécifiant les conditions d’arrêt du flux à l’aide Terminer la logique de flux de fluxde . Pour libérer des ressources système, vous pouvez également annuler tout flux dont les conditions de reprise ne pourront jamais être remplies. Par exemple, annulez les flux en attente de mises à jour de l’enregistrement d’incident où l’incident associé est fermé.
Restreindre les conditions d’attente aux champs présents dans la table actuelle: L’action Attendre une condition peut uniquement surveiller les changements apportés aux champs de la table à laquelle appartient l’enregistrement. L’action ne peut pas détecter les changements apportés aux champs dans les enregistrements connexes ou les variables de catalogue. Par exemple, si une action attend que des changements soient apportés à un enregistrement d’incident, elle ne peut alors pas détecter les changements apportés à un enregistrement connexe, tel qu’un élément de catalogue ou un enregistrement de tâche de changement. Évitez de créer des conditions d’attente qui redirigent par point vers un autre enregistrement, car ces champs appartiennent en fait à l’enregistrement connexe. Évitez de créer des conditions d’attente qui reposent sur des variables de catalogue.

Flux ou flux secondaires avec étapes

Suivez ces instructions générales lors de la création de flux ou de flux secondaires avec des étapes.

Évitez de définir des étapes qui dépendent d’une logique de flux For Each: Concepteur de flux vous empêche d’ajouter des étapes dans un bloc For Each Vous ne pouvez ajouter des étapes qu’avant ou après un bloc For Each .
Évitez de créer des étapes pour les mêmes enregistrements dans différents flux ou flux secondaires: Un champ d’étape affiche toujours les informations d’étape fournies par le dernier flux ou flux secondaire à s’exécuter sur l’enregistrement d’une table. Si plusieurs flux ou flux secondaires s’exécutent sur les mêmes enregistrements, les étapes définies dans un flux ou un flux secondaire peuvent en théorie remplacer les étapes d’un autre flux ou flux secondaire. Pour éviter que plusieurs flux ou flux secondaires ne remplacent les étapes les uns des autres, définissez des conditions de déclenchement ou de démarrage uniques pour chaque flux ou flux secondaire.
Éviter de mettre à jour les champs d’étapes en dehors d’un flux ou d’un flux secondaire: Si vous gérez les étapes avec un flux ou un flux secondaire, évitez de mettre à jour directement les champs d’étape d’enregistrement en dehors du flux ou du flux secondaire. La mise à jour manuelle de la valeur d’un champ d’étape peut produire des résultats inattendus ou indésirables.
S’assurer que chaque flux sur une table a des conditions de déclenchement uniques: L’ajout de conditions de déclenchement uniques à chaque flux garantit que les flux ne s’exécutent que dans ces conditions et empêche les étapes d’un flux de remplacer les étapes d’un autre flux. La spécification de conditions de déclenchement uniques facilite le dépannage des flux en limitant le nombre d’exécutions de flux pouvant entraîner des changements d’enregistrement.
Utiliser les étapes d’erreur pour communiquer avec l’utilisateur: L’état d’erreur du flux n’affecte pas l’exécution du flux. Un flux continue de s’exécuter même s’il atteint une étape d’erreur. Utilisez un bloc de logique de flux conditionnel pour définir l’étape d’erreur et communiquer à l’utilisateur que l’état de l’étape actuelle est Erreur. Par exemple, si une approbation n’est pas approuvée dans la limite requise, vous pouvez communiquer une erreur à l’utilisateur.
Utiliser l’étape d’erreur pour arrêter le traitement d’un flux: Utilisez un bloc de logique de flux conditionnel pour identifier quand un flux entre dans l’étape d’erreur. Utilisez la logique de flux pour arrêter le traitement du flux ou effectuer une action de rattrapage. Par exemple, vous pouvez modifier l’état ou l’affectation de l’enregistrement lorsqu’un flux atteint un état d’erreur.

Procédez comme suit dans une logique de flux parallèle

Éviter de créer des dépendances de données entre les chemins d’accès: Étant donné qu’un flux peut exécuter les chemins d’accès dans n’importe quel ordre, évitez de créer des dépendances de données entre des chemins d’accès distincts. Par exemple, vous n’avez pas un chemin d’accès qui crée un enregistrement et un autre chemin d’accès qui met à jour le même enregistrement. Le chemin d’accès de l’enregistrement de mise à jour peut s’exécuter avant celui de création.
Ne pas partager de données entre des chemins d’accès: Studio de workflow vous empêche de faire glisser des pastilles de données entre les chemins d’accès, car le système ne peut pas déterminer quel chemin se terminera en premier pour fournir la valeur de sortie.

Logique de flux de flux dynamiques

Utilisez des flux dynamiques si vous avez plusieurs flux secondaires avec des fonctionnalités similaires: Les flux dynamiques vous permettent de compartimenter vos processus en appliquant un modèle pour gérer les entrées de plusieurs flux secondaires similaires. La compartimentation vous permet de distinguer les flux secondaires qui remplissent des fonctions similaires, tels que les flux secondaires pour les spokes Centre d’intégration .
S’assurer que les entrées de flux secondaire appelées dynamiquement correspondent aux entrées de flux de modèle: Le système génère une erreur et le flux principal ne peut pas s’exécuter correctement lorsque les entrées d’un flux dynamique et d’un modèle de flux ne correspondent pas.
Utiliser le contexte correct lors de l’obtention de sorties de flux: Un enregistrement de contexte identifie l’exécution du flux de manière unique. Si vous exécutez un flux dynamique plusieurs fois, vous avez le choix entre plusieurs enregistrements de contexte. Lorsque vous utilisez le flux dynamique plusieurs fois dans un flux, assurez-vous de choisir le bon enregistrement de contexte à partir de la bonne exécution chaque fois que vous obtenez des sorties de flux.

Pastilles de données Password2

Suivez ces instructions générales lors de la conception de flux contenant des données de mot de passe (chiffrement bidirectionnel).

Attribuez des valeurs à l’aide de pastilles de données de mot de passe (chiffré dans 2 sens) existantes.

Vous ne pouvez affecter une valeur à une variable password2 qu’en sélectionnant une pastille de données password2 existante. La sélection de valeurs dans d’autres types de champs n’est pas prise en charge. Studio de workflow Présente un message d’avertissement lorsque des types de pastilles de données non valides sont sélectionnés.

Message d’avertissement affiché lors du glissement d’une pastille de données autre que password2 vers un champ password2.

Remarque :

Vous ne pouvez pas saisir manuellement des valeurs de mot de passe (chiffré dans 2 sens).

Utiliser des variables de mot de passe (chiffré dans 2 sens) uniquement pour les types de champs valides

Studio de workflow empêche de sélectionner les pastilles de données Password2 comme valeur pour les types de champ non valides. Le système affiche un message d’avertissement lorsque le champ est d’un type incompatible.

Avertissement affiché lors du glissement d’un champ password2 vers un champ non autorisé.

Studio de workflow permet uniquement de faire glisser des pastilles de données Password2 dans les types de champs suivants :

Champs du corps de l’e-mail
Champs HTML
Champs de mot de passe 2
Variables d’entrée PowerShell
Champs REST
- Variables
- Corps de la charge utile REST
- Paramètres de requête
- En-têtes
- Valeurs de formulaire REST en plusieurs parties
- Valeurs codées par l’URL de formulaire
Champs SOAP
- En-têtes
- Enveloppe

Remarque :

vous ne pouvez pas utiliser de variables de mot de passe (chiffré dans 2 sens) comme conditions

Concepteur de flux effectue un contrôle de validation lorsqu’un utilisateur enregistre, publie ou teste des actions et des flux. Cette vérification montre qu’il existe une alerte pour les pastilles de données déposées dans des types de champ restreints et empêche l’exécution de l’action ou du flux. Mettez à jour l’action ou le flux pour supprimer la pastille de données non valide, puis réessayez l’action.

Configurer des modules de chiffrement pour le déchiffrement

Seuls les utilisateurs disposant d’un accès valide au module de chiffrement peuvent déchiffrer et afficher le contenu des variables password2. Pour spécifier l’algorithme de chiffrement et les rôles pouvant accéder aux données chiffrées, consultez Chiffrement Password2 avec KMF .

Actions du minuteur du pourcentage de SLA

Suivez ces instructions générales lors de la création de flux contenant des actions de minuteur du pourcentage d’accord sur les niveaux de service (SLA).

Ajouter des actions de minuteur du pourcentage de SLA uniquement aux flux avec un déclencheur de tâche SLA: Une action de minuteur du pourcentage de SLA ne peut s’exécuter que lorsque le flux démarre à partir d’un déclencheur de tâche SLA. Vous ne pouvez pas activer un flux secondaire contenant une action de minuterie du pourcentage de SLA.
Créer une logique de flux conditionnelle pour les valeurs d’état attendues: Utilisez la valeur du champ État comme condition de la logique de flux. Créez une logique de flux pour les valeurs d’état attendues telles que Terminé, Réparation et Ignoré. Par exemple, ajoutez un bloc de logique de flux If pour envoyer une notification lorsque le minuteur du pourcentage de SLA a l’état Terminé.
Attribuer à chaque action de minuteur du pourcentage de SLA une valeur cumulée d’attente de pourcentage unique: Chaque action de minuteur du pourcentage de SLA calcule sa propre Date/Heure de fin planifiée à l’aide de sa valeur Attendre le pourcentage. Si vous créez plusieurs actions de minuteur du pourcentage de SLA, attribuez à chaque action sa propre valeur cumulée d’attente de pourcentage. Par exemple, créez trois actions distinctes avec des pourcentages d’achèvement différents, tels que 25 %, 50 % et 75 % d’achèvement. Si vous définissez les trois actions sur la même valeur de pourcentage d’achèvement, par exemple 25 %, les minuteurs se terminent en même temps.
Copier les flux existants pour effectuer des personnalisations: Réduisez le temps de développement en copiant les flux SLA par défaut et en personnalisant les copies avec votre propre logique. Sélectionnez un flux personnalisé à exécuter à partir de la définition de SLA. Reportez-vous à la section Créer une définition de SLA .

Entrées dynamiques

Prendre en compte les entrées dynamiques pour les intégrations tierces: Les entrées dynamiques vous permettent de créer des flux qui extraient dynamiquement des données à partir de sources externes. Dans les intégrations tierces, les entrées dynamiques peuvent fournir des valeurs de données relatives à un point de terminaison particulier. Pour plus d’informations sur la configuration d’intégrations tierces avec Studio de workflow, consultez Centre d’intégration.
Être conscient du temps nécessaire pour récupérer de grandes quantités de données: Par défaut, les entrées dynamiques disposent de 300 secondes pour collecter des données avant d’expirer. Si votre action de collecte de données nécessite plus de temps pour collecter des données, définissez la sn_flow_designer.sync_action_execution_timeout_in_seconds propriété système sur une valeur plus élevée. Toutefois, n’utilisez pas de valeurs de délai d’expiration long pour les flux interactifs dans lesquels un utilisateur final doit saisir ou sélectionner une valeur.
Méfiez-vous des erreurs de scripting: Étant donné que toutes les actions de collecte de données utilisent une étape de script, des erreurs potentielles peuvent se produire à partir du script. Lorsque vous utilisez des scripts pour générer des variables JSON pour vos entrées dynamiques, vous pouvez rencontrer des erreurs qui empêchent les entrées de recevoir les valeurs JSON dont elles ont besoin. Lorsqu’une erreur de scripting d’entrée dynamique se produit, le message d’avertissement suivant peut s’afficher.
Figure 1. Message affiché pour l’erreur de scripting
Limiter les entrées de type entrées dynamiques à 40 valeurs d’entrée: Une entrée de type entrées dynamiques ne peut restituer qu’un certain nombre d’entrées avant que l’objet JSON ne devienne trop volumineux pour être stocké en mémoire. En limitant vos entrées dynamiques à 40 valeurs d’entrée, vous minimisez les risques de manquer de mémoire et de rencontrer des comportements inattendus tels que des erreurs de rendu ou la troncature des données.
Limitez la sortie JSON à 5 000 éléments de tableau pour les modèles dynamiques et les choix dynamiques: Les entrées de choix dynamique et de modèle dynamique ne peuvent afficher que jusqu’à 5 000 éléments de tableau. Un choix dynamique ne peut afficher que 5 000 options de liste de choix maximum, tandis qu’un modèle dynamique ne peut afficher que 5 000 valeurs de modèle de champ maximum. Si votre action de collecte de données collecte des données pour un modèle dynamique ou un choix dynamique, limitez le nombre maximal d’éléments de tableau renvoyé à 5 000. La limite de 5 000 éléments de tableau empêche l’instance d’avoir des problèmes de performances lors du rendu des choix ou des valeurs de champ.

Sorties dynamiques

Utiliser des sorties dynamiques pour les intégrations tierces: Utilisez des sorties dynamiques pour faire une introspection et extraire des données de systèmes externes pendant la conception du flux. Par exemple, vous pouvez spécifier des points de terminaison de service ou des actions d’appel qui interagissent avec des API de point de terminaison spécifiques. Pour plus d’informations sur la configuration d’intégrations tierces avec Studio de workflow, consultez Centre d’intégration.
Notez le temps nécessaire pour récupérer de grandes quantités de données: Par défaut, les sorties dynamiques disposent de 300 secondes pour collecter des données avant que le système ne les arrête. Si votre action de collecte de données nécessite plus de temps pour collecter des données, définissez la sn_flow_designer.sync_action_execution_timeout_in_seconds propriété système sur une valeur supérieure. Évitez les longues valeurs de délai d’expiration pour les flux interactifs où un utilisateur final attend de saisir ou de sélectionner une valeur.
Méfiez-vous des erreurs de scripting: Étant donné que toutes les actions de collecte de données utilisent une étape de script, des erreurs potentielles peuvent se produire à partir du script. Examinez tous les scripts utilisés pour générer des variables JSON, car des erreurs de script peuvent empêcher les sorties de recevoir les valeurs JSON dont elles ont besoin. Lorsqu’une erreur de scripting de sortie dynamique se produit, le message d’avertissement suivant peut s’afficher.
Figure 2. Message affiché pour l’erreur de scripting

Liste. Données [Table]

Ajouter un qualificatif de référence pour filtrer les enregistrements de liste: Filtrez les enregistrements que la variable de liste affiche en tant qu’options valides en ajoutant un qualificatif de référence. Le qualificatif de référence agit comme un filtre de liste requis et fait en sorte que la variable de liste n’affiche que les enregistrements qui correspondent aux conditions de qualificatif de référence. Par exemple, pour afficher uniquement les enregistrements d’incidents actifs, ajoutez la condition de qualificatif de référence [Active][is][true].
Évitez de sélectionner des enregistrements par défaut pour les actions destinées à ServiceNow Store: Évitez de sélectionner des enregistrements par défaut pour une liste, à moins de savoir que toutes les instances ont accès aux enregistrements sélectionnés. Les développeurs de spoke n’ont généralement pas accès aux données des clients qui installent leur action personnalisée. Si vous souhaitez publier une action personnalisée sur ServiceNow Store, vous devrez peut-être fournir des enregistrements par défaut en tant que données de démonstration.
Utiliser des variables de liste dans la logique de flux Pour chaque: Vous pouvez utiliser une variable Liste pour spécifier les enregistrements à traiter dans la logique de flux Pour chaque. La logique de flux For Each ignore toute sys_id de non-enregistrement présente dans les données. Par exemple, si la variable Liste contient une adresse e-mail, la logique de flux l’ignore.

Règles d'approbation

Fournir une valeur par défaut: Créez ou sélectionnez une règle d’approbation comme valeur par défaut.

Fonctions de transformation

Appliquer les fonctions de transformation aux types valides de pastilles de données pour l’entrée: Assurez-vous de vérifier le type de pastille de données pour l’entrée avant d’appliquer une fonction de transformation. L’application d’une fonction de transformation à un type de pastille de données non valide entraîne l’omission de la transformation par le système. Une erreur se produit également si les fonctions de transformation produisent des résultats que le système ne peut pas analyser. Par exemple, lors de la transformation d’une chaîne en date, le système génère une erreur si la transformation ne produit pas de date valide.
Confirmer les fonctions de transformation appliquées pour plusieurs entrées avec la même pastille de données: Une fonction de transformation crée une nouvelle valeur lors de l’exécution pour une entrée spécifique et ne modifie pas la pastille de données d’origine. Si vous utilisez la même pastille de données sur plusieurs actions ou étapes, les fonctions de transformation doivent donc être appliquées à chaque input individuel.
Afficher les valeurs transformées finales dans les détails de l’exécution du flux: Seule la valeur transformée finale, et non la valeur de chaque transformation appliquée, apparaît dans les détails d’exécution du flux.
Tester les fonctions de transformation pour vérifier qu’elles produisent les résultats escomptés: Assurez-vous que vos fonctions de transformation produisent les valeurs d’exécution attendues pour les pastilles de données. Pour plus d’informations, consultez Test d’un flux et Tester une action.

Scripts alignés

Suivez ces instructions générales pour créer des scripts en ligne réutilisables et maintenables.

Écrire un script en ligne pour une petite logique non réutilisable

Utilisez le format de script en ligne ou modifiez les données pour des entrées et des cas d’utilisation spécifiques. Pour une logique réutilisable, créez plutôt une action ou un flux secondaire.

Examiner les fonctions de transformation disponibles

Studio de workflow Fournit une liste de fonctions de transformation standard pour les conversions de données et les opérations de formatage. Plutôt que d’écrire et de gérer une solution de script personnalisée, sélectionnez une fonction de transformation existante le cas échéant.

Includes de script d’appel à partir du script en ligne

Appelez un include de script à partir de votre script en ligne pour réduire la quantité de code que vous écrivez et également pour maintenir le code commun dans un emplacement unique. Utilisez le constructeur de classe pour appeler votre include de script. Pour en savoir plus sur la création d’un include de script, reportez-vous à la section Script includes.

var si = new MyScriptInclude();
si.functionOne();

Créer des actions ou des flux secondaires personnalisés pour le code réutilisable plutôt que pour le script en ligne

Créez des actions ou des flux secondaires personnalisés pour une logique de données réutilisables ou complexes, telles que la modification du type de données source. Vous pouvez également fournir des actions ou des flux secondaires personnalisés pour les concepteurs de flux qui ne sont pas à l’aise avec le code.

Éviter de dupliquer l’action et la fonctionnalité de flux

Évitez d’écrire un script en ligne qui duplique les fonctionnalités d’action et de flux. Par exemple, plutôt que d’écrire un script en ligne pour effectuer des opérations d’enregistrement, utilisez les actions de base de référence Créer et mettre à jour un enregistrement.

Éviter les changements de type de données

Évitez les erreurs d’exécution en vérifiant que votre script en ligne fournit des informations dans le même type de données que celui attendu par l’entrée ou la sortie.

Créer des variables en les déclarant avec le mot clé var

Utilisez le mot-clé var pour déclarer des variables afin qu’elles restent dans la portée JavaScript appropriée. Lorsque vous créez une variable en lui attribuant une valeur, JavaScript peut l’attacher à l’objet global, ce qui peut entraîner la persistance des valeurs de variable en dehors de la portée locale et provoquer des erreurs.

Traiter les sorties d’enregistrements avec la logique de flux For Each et l’objet de données de flux

Le script aligné ne peut accéder qu’à la sortie d’enregistrements d’une action Rechercher des enregistrements à partir de la logique de flux Pour chaque. Ajoutez une action de recherche d’enregistrements au flux pour générer la sortie d’enregistrements. Ajoutez une logique de flux For Each au flux pour traiter chaque enregistrement dans la sortie d’enregistrements. Créez une référence de script en ligne à la logique de flux For Each à l’aide des objets fd_data et item. Par exemple, cette référence suppose que la logique de flux Pour chaque est le deuxième élément de votre plan de flux fd_data._2__for_each.item.

Utilisez les suggestions de suggestion automatique pour générer des références aux données de flux et d’action.

Créez des références aux données de flux et d’action à l’aide de l’objet fd_data. L’éditeur de script affiche des suggestions de suggestion automatique pour les données de flux et d’action existantes lorsque vous tapez fd_data. Sélectionnez une suggestion pour créer des références aux données de flux et d’action.

Remarque :

Reportez-vous aux données d’enregistrement dans une logique de flux For Each à l’aide de l’objet item .

Compteurs de boucles de champ d’application

Les boucles de script n’ont pas un nombre maximum d’itérations, de sorte que les boucles s’exécutent à l’infini lorsqu’il n’y a pas de condition de sortie valide.

Pour vous assurer qu’il existe une condition de sortie valide, utilisez des compteurs de boucle de champ d’application dans les scripts en ligne ou dans les étapes de script au sein d’une action. Ajouter var àfor (i=0 ; i< length ; i++) et obtenir for (var i=0 ; i< length ; i++)

Données complexes

Suivez ces instructions générales pour créer des structures de données réutilisables et maintenables.

Réduire le nombre de niveaux enfants dans la hiérarchie: Plus une structure de données comporte de niveaux enfants, plus il est difficile d’afficher et de sélectionner une variable de données dans la hiérarchie. Bien que vous puissiez créer des structures de données avec n’importe quel nombre de niveaux enfants, il devient difficile de naviguer et de comprendre les structures de données avec plus de sept niveaux enfants. Pour une expérience utilisateur optimale, évitez de créer des structures de données qui ont tellement de niveaux enfants que vous devez les faire défiler horizontalement pour les voir et les remplir.
Créer un objet distinct pour chaque type de données d’enregistrement: La plupart des Studio de workflow données sont des données d’enregistrement, qu’elles proviennent d’une instance ou d’un système externe. Cette méthode de conception garantit que vous savez ce que contient l’objet et d’où proviennent les données.
Recréer les structures de données des enregistrements: Lors de la création d’objets qui reçoivent ou transmettent des données d’enregistrement, examinez les entrées de dictionnaire de base de données de ces enregistrements et créez des structures de données d’objet correspondantes. Par exemple, supposons que vous souhaitiez qu’un objet contienne les données des tables Incident et Élément de configuration. Vous pouvez créer un élément de chaîne pour le champ Brève description de la table Incident et un élément de tableau de chaînes pour le champ Classe de la table Élément de configuration.
Créer des objets pour combiner différents types d’enregistrements: Si vous avez besoin d’informations provenant de plusieurs types d’enregistrements, créez un objet contenant toutes les informations dont vous avez besoin. Vous pouvez ensuite utiliser l’objet pour formater ou analyser des données au format Studio de workflow.

Scripting avec des données complexes

Gardez ces instructions générales à l’esprit lorsque vous créez un script avec des données complexes.

Utiliser des entrées de chaîne pour convertir des données complexes en une chaîne JSON: Lorsque vous mappez des données complexes à une entrée de chaîne, Studio de workflow celle-ci est automatiquement convertie en chaîne JSON. Au lieu d’écrire un script, vous pouvez ajouter une entrée de chaîne à une étape REST et la mapper aux données complexes d’une action ou d’une étape antérieure.
Enregistrer vos objets en tant que modèles: Enregistrez vos objets en tant que modèles afin de pouvoir les réutiliser dans d’autres actions, flux et étapes de script.
Créer des variables d’entrée de script pour accéder aux données antérieures: Créez une variable d’entrée de script pour toutes les données auxquelles vous souhaitez accéder à partir de l’entrée d’action ou d’une étape antérieure. Mappez la variable d’entrée de script à la pastille de données d’entrée ou d’étape. Par exemple, mappez la variable d’entrée de script à une liste d’enregistrements d’utilisateurs que vous avez consultés lors d’une étape précédente.
Créer une variable de sortie de script pour stocker des données complexes: Créez une variable de sortie de script pour stocker toutes les données complexes créées par votre script. Les variables de sortie du script doivent correspondre aux valeurs définies dans le script. Par exemple, créez un tableau d’objets contacts pour stocker plusieurs objets de contact. Enregistrez l’objet de contact comme modèle afin de pouvoir le réutiliser.
Mappez la sortie d’action à la variable de sortie de script: Lorsque vous souhaitez qu’une action personnalisée génère des données complexes, ajoutez une sortie d’action et mappez-la à la pastille de données pour votre variable de sortie d’étape Script. Par exemple, créez un tableau de contacts et chargez le modèle d’objet de contact que vous avez enregistré précédemment. Mappez la sortie d’action au tableau de contacts produit par votre étape de script.

Flow Designer et Domain Separation

Suivez ces instructions générales lors de l’utilisation de Séparation de domaine avec Studio de workflow.

S’assurer que les flux, actions et flux secondaires des locataires sont exécutés correctement pour les domaines: Étant donné que les locataires ne peuvent pas remplacer Studio de workflow le contenu, un administrateur de fournisseur de service (SP) du domaine TOP doit les créer et les gérer pour s’assurer qu’ils s’exécutent correctement pour les domaines. Bien que vous puissiez créer des flux spécifiques à un domaine, les utilisateurs travaillant à partir de domaines situés plus haut dans la hiérarchie peuvent déclencher plusieurs flux de domaine enfant. Par exemple, un utilisateur travaillant dans le domaine TOP peut déclencher des flux dans des domaines enfants tels que ACME et INITECH.
Remarque :
Les auteurs de flux ne peuvent voir que Studio de workflow le contenu disponible à partir de leur domaine actuel et de tout domaine parent de la hiérarchie. Studio de workflow n’affiche pas le contenu visible à partir de Contient les domaines.
Attribuez un nom unique à chaque flux, action et flux secondaire: Étant donné que tous les domaines partagent Studio de workflow du contenu, demandez à un administrateur SP dans le domaine TOP de nommer de manière unique chaque flux, action et flux secondaire. Cela garantit qu’un flux destiné à un domaine ne duplique pas le nom d’un flux d’un autre domaine. Par exemple, ajoutez le domaine au nom de flux tel que Valider les incidents : TOP, Valider les incidents : ACME et Valider les incidents : INITECH.
S’assurer que les flux et les actions ne contiennent que des artefacts des domaines actuels ou parents: Studio de workflow empêche l’activation de tout flux contenant des artefacts non disponibles pour le domaine actuel ou parent. Par exemple, si vous créez un flux spécifique à un domaine qui appartient au domaine ACME, il ne peut pas contenir d’actions ni de flux secondaires appartenant au domaine frère INITECH.
Modifier Studio de workflow le contenu dans le domaine auquel il appartient: Bien que les utilisateurs d’un domaine parent puissent voir les flux, les actions et les flux secondaires dans un domaine enfant, ils doivent les modifier dans le domaine auquel ils appartiennent. Par exemple, un administrateur dans le domaine TOP peut voir les flux du domaine ACME, mais doit basculer vers le domaine ACME pour les modifier.

Déploiement

Évitez de déployer des flux de version plus récents vers des instances de versions plus anciennes: Studio de workflow ne prend pas en charge le déploiement de flux vers des instances exécutées sur des versions antérieures. Parfois, le modèle de données du flux change entre les mises en production, ce qui peut empêcher l’exécution du flux ou produire des résultats inattendus.

Gestion des erreurs de flux

Suivez ces instructions générales pour bénéficier des avantages offerts par la gestion des erreurs de flux.

Éviter d’ajouter des éléments de gestion des erreurs à la section principale du flux: Un flux s’arrête normalement lorsque l’exécution d’une action ou d’un flux secondaire renvoie une erreur dans la section principale. Un flux arrêté ne peut exécuter aucune action ni aucun flux secondaire au-delà du point où il a renvoyé une erreur. L’ajout d’actions de gestion des erreurs et de flux secondaires à la section Gestionnaire des erreurs garantit qu’ils les exécutent en cas d’erreur.
Capturer les informations sur l’état des erreurs: L’objet État de l’erreur contient des informations sur l’action qui a produit une erreur. Vous pouvez utiliser ces informations pour identifier la cause de l’erreur et enregistrer les données qui peuvent nécessiter une correction.
Supprimer les messages d’erreur de flux secondaire: Vous pouvez activer le gestionnaire d’erreurs pour un flux secondaire afin d’éviter que ses erreurs ne se répercutent en cascade sur un flux parent. Si vous laissez vide la section Gestionnaire des erreurs du flux secondaire, vous vous assurez qu’elle génère toujours l’état Terminé (erreur détectée).
Utiliser des flux secondaires pour éviter la limite de 10 éléments: Plutôt que de forcer votre processus de gestion des erreurs à s’adapter à une limite de 10 éléments, appelez des flux secondaires, qui peuvent contenir beaucoup plus d’éléments. Vous pouvez également utiliser les sorties de flux secondaire pour déclencher l’automatisation dans d’autres flux.
Utiliser des flux secondaires pour prendre des mesures correctives: Plutôt que de recréer la même séquence d’actions dans plusieurs flux, créez des flux secondaires réutilisables pour corriger les erreurs dans vos données d’enregistrement. Lorsqu’une erreur de flux laisse vos données d’enregistrement dans un état indésirable, utilisez des flux secondaires pour corriger ces enregistrements. Vous pouvez utiliser le gestionnaire d’erreurs pour identifier ces données d’enregistrement comme une sortie de flux secondaire.

Évaluation de l’erreur d’action

Suivez ces directives générales pour bénéficier des avantages offerts par l’évaluation des erreurs d’action.

Autoriser uniquement les étapes indépendantes à continuer d’exécuter: Autoriser l’exécution d’une étape si elle ne renvoie pas les données requises par une étape ultérieure. Si une étape fournit les données nécessaires pour les étapes ultérieures, vous savez que les étapes ultérieures ne peuvent pas s’exécuter correctement.
Éviter plus de 10 conditions d’erreur: Bien qu’il n’y ait pas de limite au nombre de conditions d’erreur que vous pouvez créer, chaque condition d’erreur nécessite une évaluation. Plus votre action doit évaluer de conditions d’erreur, plus l’exécution de votre action est potentiellement lente.
Identifier les défaillances d’étapes spécifiques: Vous pouvez utiliser l’état de l’étape pour identifier l’échec d’une étape spécifique. L’identification d’une étape spécifique peut être utile lorsque votre action contient plusieurs instances du même type d’étape. Vous pouvez également identifier une étape spécifique afin qu’un gestionnaire des erreurs de flux puisse prendre les mesures correctives appropriées pour la défaillance.
Placer les conditions d’erreur spécifiques avant les conditions d’erreur générales: L’évaluation des erreurs s’arrête lorsque l’action détecte une condition d’erreur correspondante. Donner la priorité aux conditions d’erreur générales peut empêcher l’action de correspondre à des conditions d’erreur spécifiques.
Utiliser des étiquettes de condition d’erreur descriptives: Identifiez une condition d’erreur sans avoir à la modifier. Par défaut, vous ne pouvez voir que les conditions d’erreur lorsque vous les modifiez.

Administrateur de flux

Désactiver la génération de rapports de flux en production: Réduisez la quantité de mémoire requise pour exécuter les flux en désactivant la génération de rapports de flux. Le reporting de flux stocke les informations de configuration et d’exécution de la page Détails de l’exécution. Ces rapports sont utiles au dépannage, mais nécessitent la conservation d’une grande quantité de données à la fois en mémoire et dans la base de données. Par défaut, la génération de rapports de flux est désactivée et le système génère uniquement des détails d’exécution lorsque vous testez manuellement un flux ou une action. Au lieu de cela, vous pouvez utiliser des fichiers journaux, qui sont toujours disponibles lorsque les rapports sont désactivés.
Réduire la quantité de mémoire consommée dans les flux avec des boucles imbriquées: Lorsque la génération de rapports est activée, définissez com.snc.process_flow.reporting.iteration.lastn sur la valeur « 1 » pour réduire les quantités de mémoire consommées par les itérations de boucle précédentes. Plus vous signalez d’itérations, plus vous avez besoin de mémoire.
Afficher les valeurs transformées finales dans les détails de l’exécution du flux: Seule la valeur transformée finale apparaît dans les détails d’exécution du flux, et non la valeur de chaque transformation appliquée.

Priorité du flux

Suivez ces considérations de conception lors de la définition de la priorité du flux.

Évitez de définir tous les flux pour qu’ils s’exécutent à une priorité élevée: Utilisez un mélange de priorités plutôt que de définir tous les flux sur une priorité élevée. Les threads de travail utilisent la priorité relative entre les flux pour sélectionner une tâche. Si tous vos flux s’exécutent à une priorité élevée, il n’y a pas de flux de priorité inférieure à faire attendre.
Évitez de définir la priorité des flux pour les flux qui doivent être mis en pause: Conservez les flux qui doivent être mis en pause à la priorité moyenne par défaut, car un flux qui s’interrompt perd sa valeur de priorité lorsqu’il reprend son exécution.
Utiliser une priorité élevée pour les flux critiques pour l’activité: Limitez la priorité haute aux flux qui ont une valeur commerciale élevée, qui s’exécutent rarement et qui ont une exécution courte. Évitez de définir des flux de volumes élevés sur une priorité élevée, car cela limite le nombre de threads de travail disponibles pour exécuter d’autres flux. Un flux de priorité élevée de longue durée peut également réduire le nombre de threads de travail disponibles pour exécuter d’autres flux.
Utiliser une priorité basse pour les flux à volume élevé: Exécutez des flux à volume élevé avec une priorité faible afin que d’autres flux sensibles au temps puissent s’exécuter en premier. Les flux de faible priorité ne doivent pas être urgents.
Utiliser une priorité moyenne pour les flux sensibles au temps: Utilisez la priorité de flux par défaut lorsqu’un flux présente une certaine urgence temporelle par rapport à d’autres flux.