Considérations relatives à la conception pour Flow Designer

Développement d'applications

Lors de la conception d’une action ou d’un flux, utilisez ces considérations de conception comme guide.

Utilisez les options de développement d’applications standard Now Platform pour créer, gérer, protéger et déployer Concepteur de flux du contenu. Les concepteurs de flux et d’actions exécutent 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 à Concepteur de flux.
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 d’œuvres 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 les logiques métier conflictuelles ou dupliquées

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

Passez en revue la documentation sur les flux, les flux secondaires et les actions , si nécessaire.

Déterminez 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 lancer un flux, 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 pouvant 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 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 une planification pour contrôler la synchronisation du flux

La logique de flux ou les déclencheurs basés sur la planification permettent d’optimiser les performances de vos flux. N’utilisez pas la méthode gs.sleep() pour patienter 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 spécifique, 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 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’ayant pas un nombre maximum d’itérations, les boucles s’exécutent donc en continu lorsqu’il n’y a pas de condition de sortie valide.

Pour vous assurer qu’il existe une condition de sortie valide, 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++) :for (var i=0 ; i< length ; i++)

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

Les itérations de 1 000 boucles ou plus peuvent entraîner des problèmes de mémoire, car il est nécessaire de stocker les détails d’exécution et les enregistrements de contexte.

Définir 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 1000.
Pour les boucles imbriquées, chaque boucle a son propre nombre maximal d’itérations.
Pour les grandes quantités de données traité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.
Les exécutions QuickAPI de premier plan s’exécutent dans la session utilisateur en tant qu’utilisateur qui a appelé le flux.
Les exécutions 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 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. 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 des 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 façon 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 la traiter. Plus vite 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.

Minimisez l’envoûtement entre lesenvironnements

Le basculement constant entre les étapes d’instance et de MID Server 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 Server à une seule fois.

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

Des schémas de données complexes manquants peuvent entraîner des problèmes d’exécution. Assurez-vous d’inclure les enregistrements sys_complex_object 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 à 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 que les conditions de déclenchement du flux ne soient remplies et exécutent le flux de manière inattendue.

Éviter de déployer des flux de mise en production plus récents sur des instances de versions antérieures

Concepteur de flux ne prend pas en charge le déploiement de flux sur 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. 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 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 les 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 la génération de rapports est désactivée.

Réduire la quantité de mémoire consommée dans les flux grâce aux 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éterminez 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 lancer un flux, 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 pouvant 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 pour qu’il accepte 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é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 au démarrage, 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 lorsqu’elles sont toutes 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 patienter, puis utilisez la condition d’attente de condition pour attendre que chaque flux secondaire soit terminé (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 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 à 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 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éterminez 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 lancer un flux, créez un flux secondaire.
Ajoutez des conditions pour spécifier les valeurs d’enregistrement qui 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, qui consiste à le mettre en pause et à attendre qu’une condition d’enregistrement spécifique s’applique avant de reprendre. 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 cadre du déclencheur d’enregistrement.
Créer des conditions uniques pour les déclencheurs d’enregistrement dans la même table: Pour éviter que les flux ne se remplacent, créez des conditions uniques pour chaque flux s’exécutant sur la même table. S’il y a plusieurs flux dans 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 de 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 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 des tables Service Catalog par les déclencheurs de l’application Service Catalog: Flow Designer n’affiche plus les tables de Service Catalog en tant qu’options pour les déclencheurs d’enregistrement. Créez plutôt des flux qui utilisent le type de déclencheur de l’application Service Catalog.

Conditions d’attente

Suivez ces directives générales lors de la création de 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 fin 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 d’enregistrement d’incident où l’incident connexe 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 l’enregistrement appartient. 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 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 pas à pas vers un autre enregistrement, car ces champs appartiennent en réalité à l’enregistrement connexe. Évitez de créer des conditions d’attente qui reposent sur des variables de catalogue.

Flux avec étapes

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

Évitez de définir des étapes qui dépendent d’une logique de flux Pour chaque: Concepteur de flux vous empêche d’ajouter des étapes dans un bloc Pour chaque bloc. Vous ne pouvez ajouter des étapes qu’avant ou après un bloc Pour chaque .
Éviter d’avoir plusieurs flux avec des étapes sur la même table: Un champ Étape affiche toujours les informations d’étape fournies par le dernier flux à exécuter sur une table ou un enregistrement. Si plusieurs flux s’exécutent sur les mêmes enregistrements, les étapes définies dans un flux peuvent théoriquement remplacer les étapes d’un autre flux. Pour éviter que plusieurs flux remplacent les étapes les unes des autres, définissez des conditions de déclenchement uniques pour chaque flux.
Éviter de mettre à jour les champs d’étape: Si vous gérez des étapes avec un flux, évitez de mettre à jour directement les champs d’étapes avec des actions, des règles métier, des appels de script ou des workflows. 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 qui peuvent produire des changements d’enregistrement.
Utiliser les étapes d’erreur pour communiquer avec l’utilisateur: L’état d’erreur du flux n’affecte pas son exécution. 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 la phase d’erreur. Utilisez la logique de flux pour arrêter le traitement du flux ou prendre des mesures correctives. 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 en parallèle 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 distincts. Par exemple, n’ont pas un chemin d’accès qui crée un enregistrement et un autre 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 d’accès de l’enregistrement de création.
Ne pas partager de données entre les chemins d’accès: Concepteur de flux 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 exécutent des fonctions similaires, tels que les flux secondaires pour les spokes Centre d’intégration .
Assurez-vous 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 approprié lors de l’obtention de sorties de flux: Un enregistrement de contexte identifie l’exécution du flux de façon 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 reprises 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 lors de la conception de flux contenant des données de mot de passe (chiffrement bidirectionnel).

Attribuez des valeurs à l’aide des pastilles de données de mot de passe (chiffrement bidirectionnel) existantes.

Vous pouvez uniquement affecter une valeur à une variable password2 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. Concepteur de flux 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).

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

Concepteur de flux empêche de sélectionner les pastilles de données Password2 comme valeur pour les types de champs non valides. Le système présente 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é.

Concepteur de flux 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 du formulaire REST en plusieurs parties
- Valeurs codées par URL de formulaire
Champs SOAP
- En-têtes
- Enveloppe

Remarque :

vous ne pouvez pas utiliser de variables Mot de passe (2 façons chiffrées) comme conditions

Flow Designer effectue une vérification de validation lorsqu’un utilisateur enregistre, publie ou teste des actions et des flux. Cette vérification montre qu’une alerte pour toutes les pastilles de données déposées dans les types de champs restreints 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 de minuteur du pourcentage de SLA

Suivez ces instructions générales lors de la création de flux contenant des actions de minuterie 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 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 de pourcentage cumulée unique: Chaque action de minuteur du pourcentage de SLA calcule sa propre date/heure de fin planifiée à l’aide de sa valeur Attendre de pourcentage. Si vous créez plusieurs actions de minuteur du pourcentage de SLA, attribuez à chaque action sa propre valeur Attendre le pourcentage cumulatif. Par exemple, créez trois actions distinctes avec des valeurs de pourcentage d’achèvement différentes, telles que 25 %, 50 % et 75 % d’achèvement. Si vous réglez 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 des 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é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 récupèrent 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 Concepteur de flux, 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 a besoin de 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 scripting. 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 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.
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 dynamique 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’elle renvoie à 5 000. La limite de 5 000 éléments de tableau empêche l’instance de rencontrer 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 Concepteur de flux, 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 les données avant que le système ne les arrête. Si votre action de collecte de données a besoin de 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 dans lesquels 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 scripting. 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 script de sortie dynamique se produit, le message d’avertissement suivant peut apparaître.
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 obligatoire 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].
Éviter 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 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 le ServiceNow Store, vous devrez peut-être fournir des enregistrements par défaut comme données de démonstration.
Utiliser les variables de liste dans la logique de flux Pour chaque: Vous pouvez utiliser une variable Liste pour spécifier les enregistrements à traiter dans une logique de flux Pour chaque. La logique de flux Pour chaque ignore toute sys_id sans 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 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 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 pour 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 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 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

Concepteur de flux fournit une liste des 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.

Script includes d’appel à partir du script en ligne

Appelez un script include à 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 seul emplacement. Utilisez le constructeur de classe pour appeler votre script include. Pour plus d’informations sur la création d’un script include, consultez Script includes.

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

Créer des actions personnalisées ou des flux secondaires pour un code réutilisable plutôt qu’un script en ligne

Créez des actions personnalisées ou des flux secondaires pour une logique de données réutilisables ou complexes, telle que la modification du type de données sources. Vous pouvez également fournir des actions personnalisées ou des flux secondaires 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 création et de mise à jour d’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 pour 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 affectant une valeur, JavaScript peut l’attacher à l’objet global, ce qui peut entraîner la persistance des valeurs de variables en dehors de la portée locale et provoquer des erreurs.

Traiter les sorties des enregistrements avec la logique de flux Pour chaque et l’objet de données de flux

Le script ligne par ligne ne peut accéder qu’à la sortie des enregistrements d’une action Rechercher des enregistrements à partir de la logique de flux Pour chaque. Ajoutez une action Rechercher des enregistrements au flux pour générer la sortie d’enregistrements. Ajoutez une logique de flux Pour chaque au flux afin de traiter chaque enregistrement dans la sortie d’enregistrements. Créez une référence de script en ligne à la logique de flux Pour chaque à l’aide des objets fd_data et élément. 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 saisissez fd_data. Sélectionnez une suggestion pour créer des références aux données de flux et d’action.

Remarque :

Consultez les 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’ayant pas un nombre maximum d’itérations, les boucles s’exécutent donc en continu 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 àpour (i=0 ; i< longueur ; i++) et obtenir pour (var i=0 ; i< longueur ; 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 a 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 comportant tellement de niveaux enfants que vous devez les faire défiler horizontalement pour les afficher et les remplir.
Créer un objet distinct pour chaque type de données d’enregistrement: La plupart des Concepteur de flux 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 vous permet de savoir 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 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 qui contient toutes les informations dont vous avez besoin. Vous pouvez ensuite utiliser l’objet pour formater ou analyser des données au format Concepteur de flux.

Scripting avec des données complexes

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

Utilisez 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, Concepteur de flux convertit automatiquement ces données 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 a priori: 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 du 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 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 de contacts pour stocker plusieurs objets de contact. Enregistrez l’objet de contact en tant que modèle afin de pouvoir le réutiliser.
Mapper la sortie d’action à la variable de sortie du 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 de l’action au tableau de contacts produit par votre étape Script.

Flow Designer et Domain Separation

Suivez ces instructions générales lors de l’utilisation de Domain Separation avec Concepteur de flux.

Vérifiez que les flux, les actions et les flux secondaires des locataires sont exécutés correctement pour les domaines: Étant donné que les locataires ne peuvent pas remplacer Concepteur de flux le contenu, un administrateur de fournisseur de services (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 domaines 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 peuvent afficher uniquement Concepteur de flux le contenu disponible à partir de leur domaine actuel et de tout domaine parent de la hiérarchie. Concepteur de flux 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 Concepteur de flux du contenu, il est nécessaire qu’un administrateur SP dans le domaine SUPÉRIEUR nomme 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 dans un autre domaine. Par exemple, ajoutez le domaine au nom du flux, par exemple Valider les incidents : TOP, Valider les incidents : ACME et Valider les incidents : INITECH.
Assurez-vous que les flux et les actions contiennent uniquement des artefacts des domaines actuels ou parents: Concepteur de flux 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 au domaine qui appartient au domaine ACME, il ne peut pas contenir d’actions ou de flux secondaires appartenant au domaine frère INITECH.
Modifier Concepteur de flux 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 du domaine TOP peut voir les flux du domaine ACME, mais doit basculer vers le domaine ACME pour les modifier.

Déploiement

Éviter de déployer des flux de mise en production plus récents sur des instances de versions antérieures: Concepteur de flux ne prend pas en charge le déploiement de flux sur 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 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 cesse normalement de s’exécuter 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 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 ainsi que pour enregistrer les données qui peuvent avoir besoin d’être corrigées.
Supprimer les messages d’erreur du 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 la section Gestionnaire d’erreurs de flux secondaire vide, vous vous assurez qu’elle génère toujours l’état Terminé (erreur intercepté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 en tant que sortie de flux secondaire.

Évaluation de l’erreur d’action

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

Autoriser uniquement les étapes indépendantes à continuer à s’exécuter: Autoriser 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 échecs 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 d’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 de l’erreur s’arrête lorsque l’action trouve 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 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 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 les 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 la génération de rapports est désactivée.
Réduire la quantité de mémoire consommée dans les flux grâce aux 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

Tenez compte de 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 une combinaison 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 le travail. Si tous vos flux s’exécutent avec une priorité élevée, il n’y a aucun flux de priorité inférieure à faire attendre.
Évitez de définir la priorité des 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é élevée aux flux ayant une valeur commerciale élevée, s’exécutant rarement et ayant une courte durée d’exécution. É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écuter des flux de volume élevé avec une priorité faible afin que d’autres flux sensibles au facteur temps puissent s’exécuter en premier. Les flux de faible priorité ne doivent pas être sensibles au facteur temps.
Utiliser une priorité moyenne pour les flux sensibles au facteur temps: Utilisez la priorité de flux par défaut lorsqu’un flux présente une certaine urgence temporelle par rapport à d’autres flux.