Au cours des dix dernières mises à jour, Flow Designer s’est développé pour devenir le moteur d’automatisation qu’il est aujourd’hui. En dépit des grandes avancées déjà réalisées, la version Utah intègre des fonctionnalités supplémentaires à Flow Designer qui méritent d’être mises en avant.
Découvrons Les Nouveautés Dans Flow Designer
Conversion des actions en sous-flux
Vous travaillez sur un flux massif – vous êtes sur le point d’atteindre la ligne d’arrivée quand une idée vous vient. Vous vous dites : « Wow, une grande partie de ce nouveau flux pourrait être utilisée ailleurs ». Vous pensez qu’il devrait peut-être s’agir d’un sous-flux – une entité appelable et réutilisable que d’autres développeurs pourraient utiliser et maintenir plus facilement. Cependant, tout est presque terminé et cela demanderait beaucoup de travail après coup, alors vous passez à autre chose.
Levez la main si vous êtes passé par là ! C’est le cas pour moi ! Heureusement, ce problème appartient au passé.
Utah permet aux développeurs de sélectionner des actions successives dans un flux et, d’un simple clic, de les transformer en un tout nouveau sous-flux. Ce n’est pas seulement une bonne chose pour la maintenance, mais aussi pour les performances de votre instance. Les sous-flux contribuent à la vitesse d’automatisation du système, car ils compartimentent le travail en réduisant la capacité du flux principal.
Conception des procédés d’automatisation des activités facultatives
Depuis la sortie de Process Automation Designer, la plateforme a de plus en plus progressé et ne dépend plus de Jelly pour les modifications de l’interface utilisateur (UI) . Cependant, les utilisateurs expérimentés de PAD qui souhaitaient créer des activités optionnelles n’avaient que Jelly pour effectuer ces changements. Dorénavant, par défaut, les concepteurs de PAD peuvent ajouter des activités optionnelles à la fois globales et orientées vers les lignes.
Cela permet de donner plus d’autonomie aux personnes chargées de l’exécution et de garder une trace de ce qu’elles doivent faire pour aider leurs demandeurs.
Priorités des flux
Pour terminer, ils ont ajouté une fonctionnalité que l’on retrouve pour d’autres fichiers d’application sur toute la plateforme – des moyens de hiérarchiser et d’ordonner l’importance des flux. Sur la plateforme ServiceNow, il n’y a qu’un nombre limité de threads par nœud et, avant Utah, ils étaient tous traités de manière FIFO ( First In First Out).
Que vous construisez des scripts clients, des règles commerciales, etc., la plupart des éléments de ServiceNow permettent aux développeurs d’ordonner leur traitement. Maintenant – cette même grâce est offerte pour les flux aussi bien.
Par défaut, tous les flux construits ont une priorité moyenne. La priorité basse est réservée aux choses qui sont sensibles au temps, où la priorité haute devrait être utilisée rarement dans les moments de grande valeur commerciale.
