- Notes de publication
- Démarrage
- Paramétrage et configuration
- Projets d'automatisation
- À propos de la publication de projets d'automatisation
- Conception d'automatisations
- Gérer les package d’activités
- Configuration des paramètres du projet d'activité
- Signature de paquets
- Gouvernance
- Import des entités
- Modern Design Experience
- Lier un projet à une idée dans Automation Hub
- Utilisation du gestionnaire de données
- Dépendances
- Types de workflows
- Comparaison de fichiers
- Meilleures pratiques d'automatisation
- Intégration du contrôle de code source
- Débogage
- Analyseur de workflow
- À propos de l'analyseur de workflow
- ST-NMG-001 - Convention d'affectation de noms des variables
- ST-NMG-002 - Convention d'affectation de noms des arguments
- ST-NMG-004 - Duplication du nom complet
- ST-NMG-005 - La variable remplace une autre
- ST-NMG-006 - La variable remplace l'argument
- ST-NMG-008 - Longueur de variable dépassée
- ST-NMG-009 - Ajouter un préfixe aux variables DataTable
- ST-NMG-011 - Ajouter un préfixe aux arguments Datatable
- ST-NMG-012 - Valeurs par défaut de l'argument
- ST-NMG-016 : longueur d'argument dépassée
- ST-DBP-002 - Nombre élevé d'arguments
- ST-DBP-003 - Bloc d'interception vide
- ST-DBP-007 - Plusieurs couches de l'organigramme
- ST-DBP-020 - Propriétés de sortie non définies
- ST-DBP-023 : Workflow vide
- ST-DBP-024 - Vérification de l’activité de persistance
- ST-DBP-025 - Condition préalable à la sérialisation des variables
- ST-DBP-026 - Utilisation de l’activité Délai
- ST-DBP-027 - Pratiques exemplaires de persistance
- ST-DBP-028 - Condition préalable à la sérialisation des arguments
- ST-MRD-002 - Valeurs par défaut des noms d'activités
- ST-MRD-004 - Activités inaccessibles
- ST-MRD-005 - Séquences redondantes
- ST-MRD-007 - Clauses If imbriquées
- ST-MRD-008 - Séquence vide
- ST-MRD-009 - Activités profondément imbriquées
- ST-MRD-011 - Utilisation de la ligne d'écriture
- ST-MRD-017 - Incomplet si (Incomplete If)
- ST-USG-005 - Arguments d'activité codée en dur
- ST-USG-009 - Variables inutilisées
- ST-USG-010 - Dépendances inutilisées
- ST-USG-014 - Restrictions sur les paquets (Package Restriction)
- ST-USG-020 - Nombre minimum de messages consignés
- ST-USG-024 - Non utilisé, sauvegardé pour plus tard (Unused Saved for Later)
- ST-USG-025 - Utilisation abusive de la valeur enregistrée (Saved Value Misuse)
- ST-USG-026 - Restrictions d'activité (Activity Restrictions)
- ST-USG-027 - Packages requis
- ST-USG-028 - Restreindre l'invocation des modèles de fichier
- ST-USG-027 - Balises requises
- ST-USG-034 – URL Automation Hub
- Variables
- Arguments
- Noms d'espace importés
- Automatisation Attended basée sur déclencheur
- Enregistrement
- Éléments de l'interface utilisateur
- À propos des éléments d'interface utilisateur
- Propriétés des activités de l'interface utilisateur
- Exemple d'utilisation des méthodes de saisie
- Méthodes de sortie ou de capture de données d'écran
- Exemple d'utilisation de méthodes de sortie ou de capture de données d'écran
- Génération de tables à partir de données non structurées
- Capture relative de données
- Flux de contrôle
- Sélecteurs
- Réf. d’objets
- Capture de données
- Automatisation des images et des textes
- À propos de l'automatisation des images et des textes
- Activités liées à la souris et au clavier
- Exemple d'utilisation de l'automatisation de la souris et du clavier
- Les activités de type texte
- Exemple d'utilisation d'automatisation de texte
- Activités de type OCR
- Activités de type image
- Exemple d'utilisation de l'automatisation d'image et d'OCR
- Automatisation des technologies Citrix
- Automatisation de RDP
- Automatisation de Salesforce
- Automatisation SAP
- Automatisation VMware Horizon
- Journalisation
- Outil ScreenScrapeJavaSupport
- Protocole Webdriver
- Suite de tests - Studio
- Extensions
- Résolution des problèmes
- À propos de la résolution des problèmes
- Prise en charge et limitations de Microsoft App-V
- Résolution des problèmes rencontrés avec Internet Explorer x64
- Problèmes rencontrés avec Microsoft Office
- Identification des éléments d'IU dans PDF avec options d'accessibilité
- Réparation de la prise en charge d'Active Accessibility
- Automatisation des applications exécutées sous un autre utilisateur Windows
- La validation des projets volumineux hérités depuis Windows prend plus de temps que prévu
Guide de l’utilisateur de Studio
À propos de l'analyseur de workflow
L'Analyseur de flux de travail (Workflow Analyzer) est un analyseur de code statique qui garantit que votre projet répond à des normes de qualité et de fiabilité élevées. Un analyseur de code statique vérifie les incohérences sans exécuter réellement le projet, par opposition aux analyseurs dynamiques qui interviennent au cours de l’exécution.
L'analyseur de workflow utilise un ensemble de règles pour vérifier diverses incohérences sans rapport avec l'exécution du projet. Les règles sont basées sur les Bonnes pratiques d'automatisation et tiennent compte du nommage des variables et des arguments, des séquences ou flux de travail vides, des restrictions sur les paquets, etc. L'analyseur n'identifie pas les erreurs d'exécution ou de compilation.
Il est disponible dans l'onglet Conception (Design) du ruban, les boutons Analyser le fichier (Analyze File) et Analyser le projet (Analyze Project). Le premier effectue une analyse dans le fichier actuellement activé dans le panneau Concepteur (Designer), tandis que le second analyse tous les fichiers dans le projet d'automatisation.
ST-
. UIAutomation.Activities, Excel.Activities, Testing Activitieset Mail.Activities ont également leurs propres règles, identifiables par le préfixe.
Vous pouvez également créer des règles personnalisées. Pour plus d'informations, consultez la section Création de règles de l'analyseur de workflow (Build Workflow Analyzer Rules) dans le guide du développeur.
Les règles peuvent également être configurées lors de la création d'une politique Studio dans Automation Ops. Pour plus d'informations, consultez le guide Automation Ops.
ST-NMG-001
:
ST
: révèle que la règle est intégrée à Studio.NMG
- montre que la règle fait partie de la catégorie Naming Rules . Les règles faisant partie de la catégorie Project Anatomy Rules ont l'abréviationANA
, celles faisant partie de Design Best Practices laDBP
, etc.-
001
: est le numéro de la règle.
Chaque règle comporte une étendue à laquelle elle s'applique :
- Activité (Activity) : les règles sont appliquées au niveau de l'activité, tout en vérifiant les variables, les arguments et les propriétés. La Conventions d'affectation de noms des variables (Variables Naming Convention) est l'une de ces règles.
- Workflow (Workflow) : les règles effectuent des vérifications dans un fichier projet unique, par exemple Variables inutilisées (Unused Variables).
- Projet (Project) : les vérifications sont effectuées au niveau du projet.
Les règles comportent un certain nombre d'actions pouvant être définies :
- Erreur (Error) : génère une erreur dans le panneau Liste d'erreurs (Error List).
- Avertissement (Warning) : génère un avertissement dans le panneau Liste d'erreurs (Error List).
- Information (Info) : génère un message dans le panneau Liste d'erreurs (Error List).
- Logs détaillés (Verbose) : crée des fichiers journaux volumineux.
Consultez la page Niveaux de journalisation (Logging Levels) pour en savoir plus sur la journalisation à l'aide de Studio.
Le projet ou le fichier est analysé selon un ensemble de règles disponibles dans la fenêtre Paramètres du projet (Project Settings) :
- Dans le panneau Projet (Project), cliquez sur l'icone , puis sélectionnez Analyseur de workflow (Workflow Analyzer).
- Dans le ruban, cliquez sur le bouton Analyser le fichier (Analyze File), puis sélectionnez Paramètres d'analyseur de workflow (Workflow Analyzer Settings) depuis la liste déroulante.
Par défaut, les règles de l’analyseur de workflow sont organisées par code dans la fenêtre, et les règles activées sont affichées en premier.
Utilisez la zone de recherche en haut de la fenêtre pour rechercher des règles par nom ou par code. Pour filtrer les règles par étendue et par action par défaut, cliquez sur le bouton à droite du champ de recherche.
Configurer les règles
Vous pouvez activer/désactiver une règle en cochant/décochant la case à sa gauche, ou modifier l'action par défaut à l'aide de la liste déroulante à sa droite.
Certaines règles ne nécessitent aucune configuration supplémentaire, tandis que d'autres contiennent des paramètres que vous pouvez configurer, tels que des seuils à ne pas dépasser ou des listes d'éléments spécifiques autorisés ou interdits. Notez que lorsque vous configurez des règles qui contiennent des champs de texte (par exemple, Utilisation inappropriée de SecureString (SecureString Misusage) ou Restrictions de package (Package Restrictions), le texte ne doit pas être saisi entre guillemets.
Rétablir les paramètres par défaut
Une fois que des modifications ont été apportées aux valeurs par défaut des règles, qu'il s'agisse de Regex ou de seuils, les valeurs par défaut peuvent être rétablies . Il suffit pour cela de faire un clic droit sur la règle, puis de sélectionner Rétablir les paramètres par défaut (Reset to Default).
La validation du fichier ou du projet est effectuée à chaque déclenchement de l'Analyseur de workflow (Workflow Analyzer). Les options de validation sont disponibles dans le bouton Analyser le fichier (Analyze File) du ruban, Valider le fichier (Validate File) et Valider le projet (Validate Project).
Cette action vérifie si les variables, les arguments, les expressions et les importations sont correctement configurés. L'action Valider le fichier (Validate File) peut être déclenchée à l'aide du raccourci F8, tandis Valider le projet (Validate Project) peut l'être à l'aide de Maj + F8. Vous pouvez annuler la validation à tout moment.
Le ou les fichiers qui contiennent des erreurs sont marqués dans le panneau Projet (Project) avec un point rouge, et les erreurs sont affichées dans les panneaux Liste d'erreurs (Error List) et Sortie (Output).
.xaml
et met en évidence l'élément qui a provoqué l'erreur, qu'il s'agisse d'une activité, d'un argument ou d'une variable.
.xaml
sont validés, vous ne pouvez pas déboguer, exécuter ou publier le projet. Les conditions de point d'arrêt ne sont pas évaluées.
Une fois déclenché, l'Analyseur de workflow (Workflow Analyzer) utilise l'ensemble de règles configuré pour vérifier le projet ou le fichier, puis consigne les erreurs trouvées dans la Liste d'erreurs (Error List), conformément à l'action de la règle.
Le panneau Liste d'erreurs (Error List) filtre les éléments par Erreurs (Errors), Avertissements (Warnings) et Messages (Messages). Le menu déroulant de l'étendue est utile pour le filtrage des erreurs par projet, fichier actuel ou un fichier spécifique de l'automatisation. En outre, les éléments peuvent être filtrés par ID de règle.
Cliquez sur un avertissement ou une erreur trouvé pour afficher la recommandation de la règle et un lien vers la page de documentation de chaque règle.
En plus des violations de règles, le panneau Liste d'erreurs affiche également les erreurs qui peuvent se produire lors de l'exécution de l'analyse du flux de travail. Lorsque l'analyseur de flux de travail ou l'une des règles configurées ne fonctionne pas, l'erreur, ainsi que des détails sur sa cause, est enregistrée dans la description.
UiPath.Studio.CommandLine.exe
contient un ensemble de paramètres permettant de vérifier des fichiers ou des projets par rapport à certaines règles, même dans les configurations du pipeline CI/CD.
UiPath.Studio.CommandLine.exe
est disponible dans le dossier d'installation :
- Pour les installations par machine, le chemin par défaut est
%ProgramFiles%\UiPath\Studio\
- Pour les installations par utilisateur, le chemin par défaut est
%LocalAppData%\Programs\UiPath\Studio
UiPath.Studio.CommandLine.exe
ne nécessite pas de licence Studio.
Par défaut, toutes les règles de l'Analyseur de workflow sont activées lors de l’installation de Studio, à l’exception des règles suivantes :
Vous pouvez configurer des règles :
- Dans la fenêtre Paramètres d'analyseur de workflow (Workflow Analyzer Settings), activez ou désactivez les règles en cochant la case en regard de chacune d’elles,
- À partir du fichier
RuleConfig.json
, chemin d’accès%LocalAppData%\UiPath\Rules
. Trouvez une règle spécifique, modifiez son paramètre, et modifiez le paramètreIsEnabled
en le faisant basculer surfalse
pour désactiver la règle. Si le chemin n’est pas accessible, vous pouvez également placer le fichierRuleConfig.json
dans un emplacement personnalisé et inclure le chemin vers le fichier dans la commande. Pour plus d'informations, consultez Analyser les fichiers et les projets (Analyze Files and Projects).
Les règles sont organisées en fonction de leur ID unique, visibles également dans Paramètres d'analyseur de workflow (Workflow Analyzer Settings).
([A-Z])
Regex. Cela signifie que les noms de variables doivent être en majuscules. Toutes les autres règles ont été désactivées dans cet exemple.
Paramètre | Description |
---|---|
RuleId | ID de la règle. |
IsEnabled | Indique si la règle est activée ou désactivée. Si définie sur « null », la valeur du paramètre ParDéfautActivée (DefaultIsEnabled) est appliquée. |
DefaultIsEnabled | Indique si la règle est activée ou désactivée par défaut. |
DefaultErrorLevel | Le niveau par défaut du message de journal (Erreur (Error), Avertissement (Warning), Info, Détaillé (Verbose)). |
Paramètres | Paramètres supplémentaires que la règle peut contenir (par exemple, Nom ou Valeur). |
ErrorLevel | Le niveau du message de journal. Si définie sur « null », la valeur du paramètre NiveauErreurDéfaut (DefaultErrorLevel) est appliquée. |
Analyser des fichiers et des projets
UiPath.Studio.CommandLine.exe
.
Les commandes d'analyseur de workflow suivantes sont disponibles :
analyze
: Analyse l'ensemble du projet. Requiert le chemin d'accès au fichierproject.json
.analyze-file
: Analyse un fichier unique. Requiert le chemin d'accès au fichier.xaml
.
Les arguments suivants sont disponibles pour les commandes d'analyseur de workflow :
Argument |
Description |
---|---|
|
Pour analyser un fichier, indiquez le chemin d'accès à
.xaml . Pour analyser l'ensemble du projet, indiquez le chemin d'accès au fichier project.json .
|
|
Chemin d'accès au fichier
RuleConfig.json . Spécifiez ce chemin uniquement si le fichier de configuration de règle ne se situe pas dans l'emplacement par défaut (%LocalAppData%\UiPath\Rules ).
|
|
Affiche les arguments disponibles pour chaque commande. |
|
Vérifiez la version de
UiPath.Studio.CommandLine.exe .
|
UiPath.Studio.CommandLine.exe analyze-file -p "C:\BlankProcess\Main.xaml"
analyse un seul fichier dans un projet, Main.xaml
. La sortie de la commande renvoie un dictionnaire codé json avec les informations suivantes pour chaque violation de règle :
FilePath
: chemin d'accès au fichier analysé.ErrorCode
: ID de règle.ActivityDisplayName
: le nom d'affichage de l'activité (null
si non applicable).Item
- Nom et type de l’élément (par exemple, une activité ou une variable) où le message d’erreur a été généré.ErrorSeverity
: valeur du paramètreDefaultAction
, qui est le message de journal configuré pour chaque règle, soit Avertissement (Warning), Erreur (Error), Information (Info) ou Logs détaillés (Verbose).Description
: Description de la règle.-
Recommendation
etURL
: modifications recommandées pour résoudre le problème, ainsi que le lien de documentation contenant plus d'informations.
RuleConfig.json
placé dans un emplacement personnalisé, ajoutez l’emplacement à la commande. En reprenant la commande précédente à titre d’exemple, pour configurer des règles avec le fichier situé dans C:\CustomFolder\RuleConfig.json
, exécutez la commande comme suit : UiPath.Studio.CommandLine.exe analyze-file -c "C:\CustomFolder\RuleConfig.json" -p "C:\BlankProcess\Main.xaml"
.
echo %errorlevel%
après l’exécution. Si aucun message n'affiche l’Erreur ErrorSeverity
, le code 0
est retourné. Sinon, le code 1
est retourné.
.xaml
vide, une erreur est affichée.
Les identificateurs uniques universels (GUID) utilisés comme préfixes pour une entrée sont générés à chaque exécution et s'appliquent uniquement au résultat actuel.
Pour configurer Studio afin d'exporter les résultats de chaque analyse de workflow vers le dossier du projet, accédez au mode Backstage de Studio (Studio Backstage View) > Paramètres (Settings) > Conception (Design) et activez l'option Exporter les résultats de l'analyseur (Export Analyzer results).
\.local\.analysis\
du dossier du projet, dans un fichier dont le nom est constitué de l'horodatage de l'analyse suivi soit de project_analysis_results.json
(lorsque l'option Analyser le projet est utilisée) ou file_analysis_results.json
(lorsque l'option Analyser le fichier est utilisée).
.local
est masqué. Vous pouvez activer l'affichage des éléments masqués à partir des paramètres de l'explorateur de fichiers Windows.
Les fichiers contiennent les informations suivantes sur chaque règle activée :
RuleId
– l'identifiant de règle.RuleName
- Le nom de la règle.Parameters
- Les paramètres dans la règle pouvant être personnalisés, le cas échéant.Severity
- L'action de la règle, si la règle est violée.ErrorsDescription
- Liste des messages d’erreur générés par la règle, le cas échéant.
Application de l'analyseur de workflow avant l'exécution, la publication ou la transmission/l'enregistrement
Vous pouvez empêcher l’exécution, la publication, la transmission/l'enregistrement dans des projets de référentiels distants qui contiennent l'analyseur de workflow en activant les options suivantes depuis le mode Backstage de Studio > Paramètres (Settings) > Conception (Design) :
- Appliquer l’Analyseur avant la publication : chaque fois que l’exécution ou le débogage d’un fichier ou d’un projet est lancé, l’Analyseur de workflow vérifie toutes les règles avec l’action
Error
, et l’exécution n’est autorisée que si aucune erreur n’est trouvée. - Appliquer l'Analyseur avant la publication : chaque fois que la publication est lancée, l’Analyseur de workflow vérifie toutes les règles activées indépendamment de leur action et la publication n’est autorisée que si l’action
Error
ne trouve aucune violation de règles. - Appliquer l'analyseur avant la transmission/l'enregistrement (Enforce Analyzer before Push/Check-in) : chaque fois que l'envoi d'un projet vers un référentiel distant est initié (Commit et Push pour GIT, Check in pour SVN et TFS), l'analyseur de workflow vérifie toutes les règles activées quelle que soit leur action, et l'opération est autorisée uniquement s'il n'y a pas de violation de règle avec l'action
Error
.
Error
ne constate pas de violation des règles), les résultats de l’analyse du workflow sont inclus dans le package publié .nupkg
dans le fichier project_analysis_results.json
situé dans \lib\net45\.analysis\
. Le fichier contient les informations suivantes sur chaque règle activée :
RuleId
– l'identifiant de règle.RuleName
- Le nom de la règle.Parameters
- Les paramètres dans la règle pouvant être personnalisés, le cas échéant.Severity
- L'action de la règle (si la règle est violée).ErrorsDescription
- Liste des messages d’erreur générés par la règle, le cas échéant.