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 de workflow 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, utilisez ces directives générales.

Utilisez les fonctionnalités de développement d’applications 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 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.

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.

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

Empêcher la logique métier conflictuelle ou en double

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. Voir le Vue d’ensemble de l’architecture pour savoir comment Studio de workflow fonctionne dans le Now Platform.

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

Déterminer si votre flux a besoin d’un déclencheur ou d’une entrée 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 que l’entrée pour les flux. Si vous avez besoin d’une entrée variable pour initier 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 rôle et conserver les informations utilisateur

Les rôles de flux simplifient les autorisations pour vos flux. Utilisez les rôles de flux pour préserver les informations de l’utilisateur 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 s’appliquent uniquement au flux. Elles ne s’appliquent pas à l’utilisateur qui a initié le flux.

Utiliser une logique de flux ou un déclencheur basé sur un calendrier 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 un calendrier. Pour suspendre un flux pendant une durée spécifique, utilisez la logique de flux Attendre pendant 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 dans 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, donc 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 en ligne ou dans les étapes de script au sein d’une action. Ajouter var to for (i=0 ; i< length ; i++) :for (var i=0 ; i< length ; i++)

Boucles Limit For Each et Do Until à 1 000 itérations

Les itérations avec 1 000 boucles ou plus peuvent entraîner des problèmes de mémoire en stockant les détails de l’exécution et les 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 de grandes quantités de traitement de données, envisagez de les regrouper en lots plus petits.
Pour les importations en bloc, envisagez les 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 la capacité de débogage est moindre.
Premier plan Les exécutions de QuickAPI s’exécutent dans la session de l’utilisateur en tant qu’utilisateur ayant appelé le flux.
Les exécutions de QuickAPI en arrière-plan s’exécutent dans un thread en arrière-plan et dans la session utilisateur « système ».

Utiliser les boucles « Exécuter jusqu’à » au lieu d’appeler des flux à partir d’eux-mêmes

La récursivité directe où un flux s’appelle lui-même n’est pas autorisée et des erreurs sont survenues. La récursivité indirecte où le flux A appelle le flux B, qui appelle le flux A est autorisée jusqu’à trois fois. Au lieu d’appeler un flux de manière 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 les 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 de flux en arrière-plan permet aux utilisateurs de continuer à travailler dans l’interface utilisateur pendant l’exécution du flux.

Éviter une 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 lesswitching entre les environnements

Le basculement constant entre les étapes d’instance et de serveur MID dans un flux peut entraîner des retards de traitement. Pour minimiser les risques de retards, limitez le basculement entre l’instance et le MID à 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. Veillez à 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 les flux d’une instance à une autre à l’aide du référentiel d’applications.

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

Si aucun des déclencheurs existants ne répond à vos besoins professionnels, 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. L’appel d’un flux secondaire plutôt que d’un flux évite la possibilité 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 mise en production plus récents sur des instances sur des versions plus anciennes

Studio de workflow ne prend pas en charge le déploiement de flux de versions plus récentes sur des instances exécutées sur des versions antérieures.

DANGER :

Le modèle de données de flux peut changer entre les mises en production, ce qui peut empêcher l’exécution de nouveaux flux ou produire des résultats inattendus lors de leur exécution sur des instances de version antérieure. Mettez à niveau vos instances pour qu’elles soient sur les mêmes versions avant de les déployer.

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. Les rapports de flux stockent les informations de configuration et d’exécution de la page Détails de l’exécution. Ces rapports sont utiles pour le 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 ne génère les détails d’exécution que lorsque vous testez manuellement un flux ou une action. À la place, vous pouvez utiliser des fichiers journaux, qui sont toujours disponibles lorsque la génération de rapports est désactivée.

Réduire la quantité de mémoire consommée dans les flux avec la boucle imbriquée

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 rapportez d’itérations, plus la mémoire requise est importante.

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 notamment les suivantes :

Déterminer si votre flux a besoin d’un déclencheur ou d’une entrée 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 initier 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 différentes valeurs d’entrée 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 pour accepter différents types d’enregistrements comme 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 lorsqu’un flux dépasse 25 actions. 50 est le nombre maximal d’actions spécifié par la propriété système sn_flow_designer.max_actions, mais limitez un flux à 25 actions pour de meilleures performances.

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

Appelez les 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 commence ou si vous souhaitez 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 d’attente pour 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 exécutent des fonctions similaires, tels que les flux secondaires pour les spokes du Centre d’intégration .

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

Plutôt que de forcer votre processus de gestion des erreurs à tenir dans 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 des erreurs pour identifier ces données d’enregistrement en tant que 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’un déclencheur ou d’une entrée 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 initier un flux à la place, créez un flux secondaire.
Ajouter des conditions pour spécifier quelles valeurs d’enregistrement démarrer votre flux: Le démarrage d’un flux uniquement lorsque cela est nécessaire 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, remaniez le flux pour inclure la condition d’attente dans le cadre du déclencheur d’enregistrement.
Créer des conditions uniques pour les déclencheurs d’enregistrement sur la même table: Pour éviter que les flux ne se chevauchent, créez des conditions uniques pour chaque flux en cours d’exécution sur la même table. Si plusieurs flux sur la même table ont le même filtre, il n’y a aucun moyen de connaître l’ordre d’exécution des flux. 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 mise à jour: Les déclencheurs d’enregistrement ignorent les enregistrements ajoutés ou mis à jour en appliquant un ensemble de mises à jour ou en important 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 en tant qu’options pour les déclencheurs d’enregistrement. Créez plutôt des flux qui utilisent le type de déclencheur d’application Catalogue de services.

Conditions d’attente

Suivez ces instructions générales lorsque vous créez des flux en attente d’une condition.

Utiliser des déclencheurs d’enregistrement au lieu de 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 Logique de flux de finde . Pour libérer des ressources système, vous pouvez également annuler tout flux dont les conditions de reprise ne peuvent jamais être remplies. Par exemple, annulez les flux en attente de mises à jour d’enregistrements d’incidents 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 les modifications apportées à un enregistrement d’incident, elle ne peut pas détecter les modifications apportées à 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 remontent pas à pas 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.

Éviter de définir des étapes qui dépendent d’une logique de flux Pour chaque: Flow Designer 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 (Pour chaque ).
Éviter 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 sous-flux à 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 d’un flux secondaire. Pour éviter que plusieurs flux ou flux secondaires ne remplacent les étapes de l’autre, 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’étape depuis l’extérieur 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 depuis l’extérieur 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.
Assurez-vous que chaque flux d’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. Spécifier des conditions de déclenchement uniques facilite la résolution des problèmes de flux en limitant le nombre d’exécutions de flux qui peuvent produire des changements d’enregistrement.
Utiliser des é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.
Utilisez 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 prendre une action de correction. Par exemple, vous pouvez modifier l’état ou l’affectation de l’enregistrement lorsqu’un flux atteint un état d’erreur.

Effectuer les opérations suivantes 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 des 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, ne disposez pas d’un chemin d’accès qui crée un enregistrement et d’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 le chemin de l’enregistrement de création.
Ne pas partager de données entre les 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 d’accès se terminera en premier pour fournir la valeur de sortie.

Flux dynamiques Logique de flux

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 exécutent des fonctions similaires, tels que les flux secondaires pour les spokes du Centre d’intégration .
S’assurer que les entrées de flux secondaire appelées dynamiquement correspondent aux entrées de flux du 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 de manière unique l’exécution du flux. 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 l’enregistrement de contexte approprié à 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 (chiffrées dans 2 sens).

Affectez des valeurs à l’aide des pastilles de données de mot de passe (chiffrées 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 à partir 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 non-password2 vers un champ password2.

Remarque :

Vous ne pouvez pas entrer manuellement de 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 des pastilles de données Password2 comme valeur pour les types de champ non valides. Le système présente un message d’avertissement lorsque le type du champ est incompatible.

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

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

Champs du corps de l’e-mail
Champs HTML
Champs du 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 formulaires en plusieurs parties REST
- Valeurs codées 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’une alerte est déposée pour toute pastille de données dans les 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 qui peuvent accéder aux données chiffrées, consultez Chiffrement Password2 avec KMF .

Actions de 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 de 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 commence à partir d’un déclencheur de tâche SLA. Vous ne pouvez pas activer un flux secondaire contenant une action de minuteur 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 pour 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 affiche l’état Terminé.
Affecter à chaque action de minuteur du pourcentage de SLA une valeur d’attente cumulative unique en pourcentage: Chaque action de minuteur du pourcentage de SLA calcule sa propre date/heure de fin planifiée à l’aide de sa valeur Attendre en pourcentage. Si vous créez plusieurs actions de minuteur du pourcentage de SLA, attribuez à chaque action sa propre valeur d’attente cumulative unique. Par exemple, créez trois actions distinctes avec des valeurs de pourcentage d’achèvement différentes, par exemple 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. Voir Création d’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 les 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.
Tenez compte 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 longues pour les flux interactifs où un utilisateur final doit entrer ou sélectionner une valeur.
Attention aux erreurs de script: Étant donné que toutes les actions de collecte de données utilisent une étape de script, des erreurs potentielles peuvent se produire lors de l’écriture de scripts. 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 script 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 d’entrées dynamiques à 40 valeurs d’entrée: Une entrée de type entrées dynamiques ne peut afficher qu’un certain nombre d’entrées avant que l’objet JSON ne devienne trop volumineux pour être stocké en mémoire. Limiter vos entrées dynamiques à 40 valeurs d’entrée minimise 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.
Limiter 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 dynamiques ne peuvent afficher que jusqu’à 5 000 éléments de tableau. Un choix dynamique ne peut afficher que jusqu’à 5 000 options de liste de choix, et un modèle dynamique ne peut afficher que jusqu’à 5 000 valeurs de modèle de champ. 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 qu’il renvoie à 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 l’introspection et l’extraction des données des 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 jusqu’à 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 s’attend à entrer ou à sélectionner une valeur.
Attention aux erreurs de script: Étant donné que toutes les actions de collecte de données utilisent une étape de script, des erreurs potentielles peuvent se produire lors de l’écriture de scripts. 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 affiche uniquement 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, sauf si vous savez que toutes les instances ont accès aux enregistrements sélectionnés. Les développeurs de spokes 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 le ServiceNow Store, vous devrez peut-être fournir les enregistrements par défaut comme données de démonstration.
Utiliser des variables de liste dans la logique de flux For Each: Vous pouvez utiliser une variable Liste pour spécifier les enregistrements à traiter dans la logique de flux For Each La logique de flux For Each ignore toute sys_id non enregistrée 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 des fonctions de transformation à des 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 au moment 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 dans plusieurs actions ou étapes, les fonctions de transformation doivent donc être appliquées à chaque inpuindividuelle.
Afficher les valeurs finales transformées 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 attendus: 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 Tester 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 faciles à maintenir.

É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 si elle est disponible.

Appeler les includes de script à 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 pour conserver le code commun dans un seul emplacement. Utilisez le constructeur de classe pour appeler votre include de script. Pour plus d’informations sur la création d’un script include, 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 la logique de données réutilisables ou complexes, telle que la modification du type de données des données sources. 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 la duplication des fonctionnalités d’action et 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 l’entrée ou la sortie attend.

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 affectant une valeur, JavaScript peut l’attacher à l’objet global, ce qui peut entraîner des valeurs variables persistantes en dehors de la portée locale et entraîner des erreurs.

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

Le script en ligne ne peut accéder qu’à la sortie d’enregistrements d’une action Rechercher des enregistrements à partir de Pour chaque logique de flux. Ajoutez une action Rechercher des enregistrements au flux pour générer la sortie d’enregistrements. Ajouter une logique de flux Pour chaque au flux afin de traiter chaque enregistrement dans la sortie des 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 saisie 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 saisie 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 Pour chaque à 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, donc 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 boucles 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 get 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 faciles à maintenir.

Minimiser 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 des 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 comportant tellement de niveaux enfants qu’il faut les faire défiler horizontalement pour les voir et les renseigner.
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 d’enregistrement: Lors de la création d’objets qui reçoivent ou transmettent des données d’enregistrement, examinez les entrées du 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 des données provenant des tables Incident et Élément de configuration. Vous pouvez créer un élément de chaîne pour le champ Brève description dans la table Incident et un élément de tableau de chaînes pour le champ Classe dans 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 dans Studio de workflow.

Scripting avec des données complexes

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

Utiliser les 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 elles sont automatiquement converties 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 précédente.
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 utilisateur 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 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 en tant que modèle afin de pouvoir le réutiliser.
Mappez la sortie d’action à la variable de sortie de script: Si 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 de 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 de l’action au tableau de contacts produit par votre étape Script.

Flow Designer et Domain Separation

Suivez ces instructions générales lorsque vous utilisez Séparation de domaine avec Studio de workflow.

S’assurer que les flux, les actions et les flux secondaires de locataire 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 afin de 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 enfants. 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 tous les domaines parents dans la hiérarchie. Studio de workflow n’affiche pas le contenu visible à partir des domaines Contient.
Attribuer 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 permet de s’assurer 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, par exemple Valider les incidents : TOP, Valider les incidents : ACME et Valider les incidents : INITECH.
Assurez-vous que les flux et les actions ne contiennent que des artefacts provenant du domaine actuel ou parent: Studio de workflow Empêche l’activation de tout flux contenant des artefacts indisponibles 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 ou de flux secondaires appartenant au domaine frère INITECH.
Modifier Studio de workflow le contenu dans le domaine auquel il appartient: Les utilisateurs d’un domaine parent ne peuvent pas voir les flux, les actions et les flux secondaires dans un domaine enfant. Ils doivent changer pour le domaine auquel ils appartiennent pour les modifier. Par exemple, un administrateur dans le domaine TOP ne peut pas voir les flux provenant du domaine ACME. L’administrateur doit basculer vers le domaine ACME pour les afficher et les modifier.

Déploiement

Évitez de déployer des flux de mise en production plus récents sur des instances sur des versions plus anciennes: Studio de workflow ne prend pas en charge le déploiement de flux de versions plus récentes sur des instances exécutées sur des versions antérieures.
DANGER :
Le modèle de données de flux peut changer entre les mises en production, ce qui peut empêcher l’exécution de nouveaux flux ou produire des résultats inattendus lors de leur exécution sur des instances de version antérieure. Mettez à niveau vos instances pour qu’elles soient sur les mêmes versions avant de les déployer.

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 lorsqu’une action ou un flux secondaire renvoie une erreur dans la section principale. Un flux arrêté ne peut pas exécuter d’actions ou de flux secondaires au-delà du point où il a renvoyé une erreur. L’ajout d’actions et de flux secondaires de gestion des erreurs à la section Gestionnaire d’erreurs garantit qu’ils les exécutent en cas d’erreur.
Informations sur l’état de l’erreur de capture: 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 ainsi que pour enregistrer les données qui peuvent nécessiter une correction.
Supprimer les messages d’erreur de flux secondaire: Vous pouvez activer le gestionnaire des erreurs pour un flux secondaire afin d’éviter que ses erreurs ne se répercutent en cascade vers un flux parent. Si vous laissez la section Gestionnaire d’erreurs du flux secondaire vide, vous vous assurez qu’il 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 à tenir dans 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 des erreurs pour identifier ces données d’enregistrement en tant que sortie de flux secondaire.

Évaluation de l’erreur d’action

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

Autoriser uniquement les étapes indépendantes à exécuter: Autorisez une étape à continuer à s’exécuter 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 son exécution peut être lente.
Identifier les défaillances d’étapes spécifiques: Vous pouvez utiliser l’état de l’étape pour identifier quand une étape spécifique échoue. 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 trouve une condition d’erreur correspondante. Mettre les conditions d’erreur générales en premier peut empêcher l’action de correspondre à des conditions d’erreur spécifiques.
Utiliser des étiquettes de condition d’erreur descriptive: 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. Les rapports de flux stockent les informations de configuration et d’exécution de la page Détails de l’exécution. Ces rapports sont utiles pour le 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 ne génère les détails d’exécution que lorsque vous testez manuellement un flux ou une action. À la place, vous pouvez utiliser des fichiers journaux, qui sont toujours disponibles lorsque la génération de rapports est désactivée.
Réduire la quantité de mémoire consommée dans les flux avec la boucle imbriquée: 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 rapportez d’itérations, plus la mémoire requise est importante.
Afficher les valeurs finales transformées 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 avec une priorité élevée: Utilisez une combinaison de priorités plutôt que de définir tous les flux sur une priorité élevée. Les threads des agents utilisent la priorité relative entre les flux pour sélectionner le travail. Si tous vos flux s’exécutent avec une priorité élevée, il n’y a alors aucun flux de priorité inférieure à faire attendre.
Évitez de définir la priorité du flux pour les flux qui doivent être mis en pause: Conservez la priorité moyenne par défaut des flux qui doivent être mis en pause, 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 le métier: Limitez la priorité élevée aux flux qui ont une valeur commerciale élevée, qui s’exécutent rarement et qui ont une courte durée d’exécution. Évitez de définir les flux à volume élevé 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 les threads de travail disponibles pour exécuter d’autres flux.
Utiliser la priorité basse pour les débits à volume élevé: Exécuter des flux à volume élevé avec une priorité basse afin que les autres flux sensibles au facteur temps puissent s’exécuter en premier. Les flux de faible priorité ne doivent pas être urgents.
Utiliser la priorité moyenne pour les flux sensibles au facteur temps: Utilisez la priorité de flux par défaut lorsqu’un flux a une certaine urgence de temps par rapport à d’autres flux.