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

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 les logiques métier conflictuelles ou en double

Des automatisations peuvent être créées avec Concepteur de flux, des règles métier, des workflows et le Centre d’intégration. Avant de commencer à utiliser Studio de workflow , assurez-vous de bien comprendre comment fonctionnent les automatisations existantes ServiceNow AI 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 ServiceNow AI Platform.

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

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 plutôt 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.

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

Les rôles de flux permettent de garantir la simplification des autorisations pour vos flux. Utilisez les rôles de flux pour conserver 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 permet également d’accéder à 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 le délai 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 le calendrier. Pour mettre en pause un flux pendant une durée spécifique, utilisez la logique de flux Attendre pendant un certain temps 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 maximal d’itérations, les boucles s’exécutent donc à 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 inline ou dans les étapes de script d’une action. Ajouter var to for (i=0 ; i< longueur ; i++) :for (var i=0 ; i< longueur ; i++)

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

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

• Définissez le nombre maximal d’enregistrements sur Rechercher des enregistrements.
• Évitez de modifier la propriété sn_flow_designer.max_iterations, qui est définie par défaut sur 1 000.
• Pour les boucles imbriquées, chaque boucle a son propre nombre maximum d’itérations.
• Pour le traitement de grandes quantités 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 il y a moins de capacité de débogage.
• Premier plan Les exécutions de QuickAPI s’exécutent dans la session utilisateur en tant qu’utilisateur ayant appelé le flux.
• Les exécutions de QuickAPI en arrière-plan s’exécutent dans un thread d’arrière-plan et dans la session utilisateur « système ».

Utilisez des 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 génère des erreurs. 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 les flux en arrière-plan

L’exécution des 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 des flux en arrière-plan permet aux utilisateurs de continuer à travailler dans l’interface utilisateur pendant l’exécution du flux.

Évitez 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 les switching entre lesenvironnements

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.

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

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

DANGER :

Le modèle de données de flux peut changer d’une version à l’autre, ce qui peut empêcher l’exécution de flux plus récents ou produire des résultats inattendus lorsqu’ils s’exécutent 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. Le reporting de flux stocke les informations de configuration et d’exécution de la page Détails d’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 de l’exécution que lorsque vous testez manuellement un flux ou une action. Au lieu de cela, vous pouvez utiliser des fichiers journaux, qui sont toujours disponibles lorsque le reporting est désactivé.

Réduisez 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 générez de rapports sur des itérations, plus la mémoire est nécessaire.

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 :

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.

Réutiliser la logique métier

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

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

Configurez les valeurs d’entrée d’un flux secondaire différemment chaque fois que vous l’appelez. Par exemple, concevez un flux secondaire 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

Appeler des flux secondaires si vous souhaitez transmettre des entrées et des sorties. Utilisez des flux secondaires si vous souhaitez spécifier les entrées disponibles pour un flux secondaire lorsqu’il commence ou si vous souhaitez spécifier les sorties disponibles pour le flux parent une fois qu’un flux secondaire se termine.

Déclencher plusieurs flux sur un seul événement plutôt que d’utiliser des flux secondaires parallèles

• Utilisez des flux secondaires parallèles s’il existe des sorties interdépendantes ou si une action doit être entreprise 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 remplissent des fonctions similaires, tels que les flux secondaires pour les spokes du centre d’intégration .

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

Plutôt que de forcer votre processus de gestion des erreurs à 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 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 plutôt un flux secondaire.

Ajoutez des conditions pour spécifier quelles valeurs d’enregistrement démarreront votre flux

Le démarrage d’un flux uniquement lorsque cela est nécessaire consomme moins de ressources système que le démarrage, la 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 Attendre une condition, reconcevez 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 de la même table utilisent 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 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.

Utilisez 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 avec Logique de flux Terminer le flux. 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, annuler les flux en attente de mises à jour d’enregistrement d’incident où l’incident associé est fermé.

Restreindre les conditions d’attente aux champs présents dans la table actuelle

L’action Attendre une condition peut uniquement surveiller les changements apportés aux champs de la table à laquelle appartient l’enregistrement. L’action ne peut pas détecter les changements apportés aux champs dans les enregistrements connexes ou les variables de catalogue. Par exemple, si une action attend des changements 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 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

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 dans n’importe quel ordre, évitez de créer des dépendances de données entre des chemins séparés. Par exemple, n’ayez 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 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 terminera en premier pour fournir la valeur de sortie.

Logique de flux Flux dynamiques

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

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

S’assurer que les entrées de flux secondaire appelées dynamiquement correspondent aux entrées de flux de modèle

Le système génère une erreur et le flux principal ne peut pas s’exécuter correctement lorsque les entrées d’un flux dynamique et d’un modèle de flux ne correspondent pas.

Utiliser le contexte correct lors de l’obtention de sorties de flux

Un enregistrement de contexte identifie 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 au sein d’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

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 de 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 de pourcentage 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 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 Si pour envoyer une notification lorsque la minuterie du pourcentage de SLA affiche l’état Terminé.

Affecter à chaque action de minuteur de pourcentage de SLA une valeur cumulative unique Attendre une valeur en pourcentage

Chaque action de minuteur de pourcentage de SLA calcule sa propre date/heure de fin planifiée à l’aide de sa valeur d’attente en pourcentage. Si vous créez plusieurs actions de minuteur de pourcentage SLA, attribuez à chaque action sa propre valeur d’attente cumulative en pourcentage. 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.

Copiez 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éer une définition de SLA .

Entrées dynamiques

Prendre en compte les entrées dynamiques pour les intégrations tierces

Les entrées dynamiques vous permettent de créer des flux qui extraient dynamiquement des données à partir de sources externes. Dans les intégrations tierces, les entrées dynamiques peuvent fournir des valeurs de données relatives à un point de terminaison particulier. Pour plus d’informations sur la configuration d’intégrations tierces avec Studio de workflow, consultez Centre d’intégration.

Être conscient du temps nécessaire pour récupérer de grandes quantités de données

Par défaut, les entrées dynamiques disposent de 300 secondes pour collecter des données avant leur expiration. Si votre action de collecte de données a besoin de plus de temps, 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 longs pour les flux interactifs où un utilisateur final doit saisir ou sélectionner une valeur.

Attention aux 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 lors 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 scripting d’entrée dynamique se produit, le message d’avertissement suivant peut s’afficher.

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 restituer 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 réduit les risques de manque de mémoire et de 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 d’avoir des problèmes de performances lors de l’affichage 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 de données à partir 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 points de terminaison spécifiques. Pour plus d’informations sur la configuration d’intégrations tierces avec Studio de workflow, consultez Centre d’intégration.

Notez le temps nécessaire pour récupérer de grandes quantités de données

Par défaut, les sorties dynamiques disposent de 300 secondes pour collecter des données avant que le système ne les arrête. Si votre action de collecte de données a besoin de plus de temps, définissez la sn_flow_designer.sync_action_execution_timeout_in_seconds propriété système sur une valeur supérieure. Évitez les valeurs de délai d’expiration longues pour les flux interactifs où un utilisateur final s’attend à saisir ou à sélectionner une valeur.

Attention aux 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 lors 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 scripting de sortie dynamique se produit, le message d’avertissement suivant peut s’afficher.

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 comme 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 [Actif][est][vrai].

É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 Pour chaque

Vous pouvez utiliser une variable Liste pour spécifier les enregistrements à traiter dans la logique de flux Pour chaque. La logique de flux Pour chaque ignore tout sys_id non-enregistrement présent 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 sur plusieurs actions ou étapes, les fonctions de transformation doivent donc être appliquées à chaque inpuindividuel.

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 Inline

Suivez ces instructions générales pour créer des scripts inline réutilisables et faciles à gérer.

É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 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.

Appeler les includes de script à partir du script inline

Appelez un include de script à partir de votre script en ligne pour réduire la quantité de code que vous écrivez et également 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 include de script, reportez-vous à la section Script includes.

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

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

Créez des actions ou des flux secondaires personnalisés pour la logique de données réutilisables ou complexes, comme la modification du type de 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 actions et des fonctionnalités 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 le périmètre JavaScript approprié. 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 variables en dehors de la portée locale et provoquer des erreurs.

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

Le script Inline ne peut accéder qu’à la sortie d’enregistrements d’une action Rechercher des enregistrements à partir de la logique de flux Pour chaque. Ajoutez une action Rechercher des enregistrements au flux pour générer la sortie des enregistrements. Ajoutez 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 Inline à la logique de flux Pour chaque à 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 des suggestions de suggestion automatique pour générer des références aux données de flux et d’action.

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

Remarque :

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

Compteurs de boucles de champ d’application

Les boucles de script n’ont pas un nombre maximal d’itérations, les boucles s’exécutent donc à 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 portée dans les scripts inline ou dans les étapes de script d’une action. Ajoutez var tofor (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 à gérer.

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 est nécessaire de 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 Studio de workflow des 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 conception 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 d’incidents et d’éléments de configuration. Vous pouvez créer un élément de chaîne pour le champ Description brève de la table Incident et un élément de tableau de chaînes pour le champ Classe de la table Élément de configuration.

Créer des objets pour combiner différents types d’enregistrements

Si vous avez besoin d’informations provenant de plusieurs types d’enregistrements, créez un objet contenant toutes les informations dont vous avez besoin. Vous pouvez ensuite utiliser l’objet pour formater ou analyser des données dans Studio de workflow.

Scripting avec des données complexes

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

Utiliser des entrées de chaîne pour convertir des données complexes en une chaîne JSON

Lorsque vous mappez des données complexes à une entrée de chaîne, Studio de workflow celles-ci 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 toutes les données complexes créées par votre script. Les variables de sortie de 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 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 É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.

Concepteur de flux et Séparation de domaine

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

Assurez-vous que les flux, les actions et les flux secondaires des locataires sont correctement exécutés pour les domaines

Étant donné que les locataires ne peuvent pas remplacer Studio de workflow le contenu, un administrateur de fournisseur de service (SP) du domaine TOP doit les créer et les gérer pour s’assurer qu’ils s’exécutent correctement pour les domaines. Bien que vous puissiez créer des flux spécifiques à un domaine, les utilisateurs travaillant à partir de domaines situés plus haut dans la hiérarchie peuvent déclencher plusieurs flux de domaine enfant. Par exemple, un utilisateur travaillant dans le domaine TOP peut déclencher des flux dans des domaines enfants tels que ACME et INITECH.

Remarque :

Les auteurs de flux ne peuvent voir que Studio de workflow le contenu disponible à partir de leur domaine actuel et de tout domaine parent dans la hiérarchie. Studio de workflow n’affiche pas de contenu visible à partir des domaines Contient

Fournissez un nom unique pour 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 d’éviter qu’un flux destiné à un domaine ne duplique le nom d’un flux d’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 ne contiennent que des artefacts provenant des domaines actuels ou parents

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 d’un domaine enfant. Ils doivent changer pour le domaine auquel ils appartiennent pour les modifier. Par exemple, un administrateur du 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

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

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

DANGER :

Le modèle de données de flux peut changer d’une version à l’autre, ce qui peut empêcher l’exécution de flux plus récents ou produire des résultats inattendus lorsqu’ils s’exécutent 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 tirer parti 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

L’exécution d’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 leur exécution en cas d’erreur.

Capturer les informations sur l’état de l’erreur

L’objet État de l’erreur contient des informations sur l’action qui a généré une erreur. Vous pouvez utiliser ces informations pour identifier la cause de l’erreur et enregistrer les données qui peuvent nécessiter une correction.

Supprimer les messages d’erreur de flux secondaire

Vous pouvez activer le gestionnaire d’erreurs pour un flux secondaire afin d’éviter que ses erreurs ne se répercutent en cascade sur un flux parent. Si vous laissez vide la section Gestionnaire d’erreurs du flux secondaire, vous vous assurez qu’elle génère toujours l’état Terminé (erreur détectée ).

Utiliser des flux secondaires pour éviter la limite de 10 éléments

Plutôt que de forcer votre processus de gestion des erreurs à 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.

Utilisez 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 des erreurs d’action

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

Autoriser uniquement les étapes indépendantes pour continuer l’exécution

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 votre exécution peut être lente.

Identifier les défaillances d’étapes spécifiques

Vous pouvez utiliser l’état de l’étape pour identifier l’échec d’une étape spécifique. L’identification d’une étape spécifique peut être utile lorsque votre action contient plusieurs instances du même type d’étape. Vous pouvez également identifier une étape spécifique afin qu’un gestionnaire des erreurs de flux puisse prendre les mesures correctives appropriées à 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. 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 les conditions d’erreur que lorsque vous les modifiez.

Administrateur de flux

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

Réduisez la quantité de mémoire requise pour exécuter les flux en désactivant la génération de rapports de flux. Le reporting de flux stocke les informations de configuration et d’exécution de la page Détails d’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 de l’exécution que lorsque vous testez manuellement un flux ou une action. Au lieu de cela, vous pouvez utiliser des fichiers journaux, qui sont toujours disponibles lorsque le reporting est désactivé.

Réduisez 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 générez de rapports sur des itérations, plus la mémoire est nécessaire.

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 de l’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é de 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 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’existe aucun flux de priorité inférieure à faire attendre.

Évitez de définir une priorité de flux pour les flux qui doivent être mis en pause

Conservez la priorité moyenne par défaut pour les flux qui doivent être mis en pause, car un flux suspendu perd sa valeur de priorité lorsqu’il reprend son exécution.

Utilisez une priorité élevée pour les flux critiques pour le business

Limitez une priorité élevée aux flux à forte valeur commerciale, rarement exécutés et dont la durée d’exécution est courte. É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 le nombre de threads de travail disponibles pour exécuter d’autres flux.

Utilisez la priorité faible pour les flux à volume élevé

Exécutez des flux à volume élevé avec une priorité faible afin que les autres flux urgents puissent s’exécuter en premier. Les flux de faible priorité ne doivent pas être urgents.

Utilisez la priorité moyenne pour les flux urgents

Utilisez la priorité de flux par défaut lorsqu’un flux présente une certaine urgence de temps par rapport à d’autres flux.