Lire et examiner la documentation Automation Anywhere

Fermer les contenus

Contenus

Ouvrir les contenus

Normes et consignes de conception des robots Robot

  • Mis à jour le : 12/26/2019
    • 11.3.x
    • Exploration
    • Enterprise

Normes et consignes de conception des robots Robot

Guide avancé pour le développement des robots et l'établissement de consignes et de normes associées aux développement des robot :.

Cette rubrique présente une introduction aux normes et consignes communes relatives à la conception de robot :. En évitant ces erreurs courantes et en appliquant ces processus et considérations à vos normes de conception de robot :, vous créerez des robot : épurés et plus faciles à lire, à tester et à entretenir. La plupart de ces consignes optimisent l'utilisation efficace des ressources de production ou réduisent les durées de maintenance et les erreurs.

Considérations relatives à la conception de Robot

  • Meilleures pratiques

    Il est généralement préférable de limiter les Automation AnywhereTaskBots : à moins de 500 lignes de code, soit de préférence quelques centaines de lignes.

  • Ventilation des processus : Processus métier géants > robots géants

    La réussite d'un processus métier via le développement de robot : repose pour l'essentiel sur une stratégie bien définie et bien pensée. Si, en raison de son envergure, un processus métier nécessite plus de 8 ou 10 sous-tâches, ou si l'une des tâches comporte des milliers de lignes, il est nécessaire de réexaminer l'approche robotique appliquée au processus.robot :

    Évaluez vos processus métier. Partez de ces conclusions pour créer votre approche robotique associée.robot :

    • Est-il possible de simplifier le processus métier lui-même ? Identifiez toutes les étapes superflues ou circulaires.

    • Identifiez les ruptures et glissements logiques contenus dans vos processus.

    • Est-il possible de diviser certaines parties du processus métier en des robots distincts ?

  • Réduction des répétitions

    Le principe DRY (Don't Repeat Yourself) et la règle de trois reviennent en fait à limiter les répétitions.

    Créez une boucle qui contient un seul appel, au lieu d'appeler le même petit nombre d'étapes séparément.

    Utilisez des variables le cas échéant.

    Ventilez les bits répétés de logiques et de commandes dans des sous-tâches. La répétition d'un ensemble de commandes dans une tâche complique les procédures de maintenance. Il est nécessaire de correctement localiser et mettre à jour toutes les instances à actualiser.

  • Plan de maintenance

    En cas de changement d'une règle codée dans un ensemble de tâches répliqué, la personne responsable de la gestion du code doit actualiser la règle comme il se doit à tous les endroits où elle apparaît. Cette procédure sujette aux erreurs entraîne souvent des problèmes.

    Placez l'ensemble des commandes et des règles dans un seul et même emplacement. Il est plus facile de les modifier si elles se trouvent au même endroit.

  • Conception guidée par les tests

    Il est facile de tester les petites tâches individuellement dans le cadre d'un essai unitaire. Les tâches sans dépendance peuvent faire l'objet de tests automatisés. Il est plus facile d'assurer la maintenance et les tests de tâches réparties en sous-tâches par fonctions distinctes, même celles exécutées une fois au début d'une séquence.

  • Gestion des erreurs réseau

    Lorsque vous créez des robots qui utilisent une connexion réseau, veillez à prévoir des mesures permettant de gérer de manière adéquate les délais de mise en réseau. Supposons qu'un incident réseau se produise alors qu'un robot : attend la réponse d'une page Web (l'ouverture d'une boîte de dialogue Enregistrer sous, par exemple). Comment souhaitez-vous que le robot : réagisse ? Doit-il réessayer ou abandonner l'opération en affichant un message ?

Présentation des sous-tâches

Une sous-tâche est appelée par la tâche parente qui a besoin de son service. Les sous-tâches sont également appelées tâches d'assistance ou tâches utilitaires, car leur seule fonction est d'aider la tâche appelante.

Conseil :

Les sous-tâches doivent avoir être de petite taille et se limiter à une seule responsabilité ou quelques-unes seulement.

Il est impossible de partager des fichiers Excel, texte (.csv ou .txt) ou des fichiers de navigateur (enregistreurs Web) entre plusieurs tâches distinctes pendant une même session. Il est donc nécessaire d'inclure des sous-tâches de manière à ne pas interrompre les sessions.

Cette méthode présente les avantages suivants :

  • Le code associé aux tâches de production est plus court.

  • Si des changements sont nécessaires, il suffit de localiser, d'analyser et de mettre à jour les sous-tâches. La maintenance des robot : est donc plus facile.

  • Les possibilités de réutilisation des sous-tâches sont optimales.

    Si elles sont correctement configurées, il est possible de rendre les sous-tâches réutilisables pour accroître leur productivité. Les sous-tâches peuvent être appelées par un nombre illimité d'autres tâches, y compris d'autres robots.

  • L'autonomie des sous-tâches peut être optimisée.

    Les sous-tâches ne sont pas totalement indépendantes. Elles s'exécutent suite à l'appel d'une tâche parente. Il est néanmoins possible de minimiser les dépendances vis à vis d'autres tâches.

Considérations relatives aux sous-tâches

  • Principe de responsabilité unique

    Attribuez une tâche ou une responsabilité à chaque sous-tâche.

    Il est utile de fractionner en sous-tâches une tâche de grande envergure. Cependant, regrouper des tâches de petite taille dans une seule et même sous-tâche peut encore entraîner des erreurs de maintenance. Les modifications apportées à une petite tâche risquent d'affecter les autres petites tâches contenues dans la sous-tâche de plus grande taille.

    Il est préférable de créer plusieurs sous-tâches, chacune avec une fonction spécifique. Par exemple, lorsqu'une tâche gère l'impression, le déplacement et l'enregistrement de fichiers PDF, fractionnez-la. Attribuez à chaque sous-tâche sa propre responsabilité : la première imprime, la seconde déplace et la troisième enregistre le fichier PDF.

  • Découplage des dépendances

    Si possible, définissez des sous-tâches qui ne dépendent pas d'informations fournies par des tâches appelantes. Les informations requises constituent une dépendance. Identifiez la dépendance et incluez-la dans la sous-tâche. La sous-tâche devient alors autonome, peut accepter des tests unitaires et être appelée par d'autres tâches sans avoir recours à des dépendances supplémentaires.

    Par exemple, si une sous-tâche de connexion ne peut être appelée que si la tâche appelante fournit une URL, la sous-tâche a une dépendance. Toutes les tâches parentes qui appellent la sous-tâche doivent fournir une URL. Tout changement d'URL oblige à modifier plusieurs tâches. Si la sous-tâche de connexion inclut l'URL, elle est découplée de la tâche parente. Si l'URL change, seule la sous-tâche doit être mise à jour.

  • Dépendances bidirectionnelles

    Si des sous-tâches ne peuvent être modifiées sans changer les tâches appelantes, elles sont en fait dépendantes et ne non pas réellement découplées. S'il est impossible de modifier les tâches appelantes sans modifier toutes les sous-tâches, les tâches ne sont pas réellement découplées mais ont des dépendances bidirectionnelles. Du fait de ces dépendances croisées, il est presque impossible d'effectuer des tests unitaires.

  • Limitation du nombre de sous-tâches

    Bien que toutes les consignes précédentes constituent d'excellents principes pour la conception de robots, un nombre excessif de sous-tâches a tendance à entraîner des erreurs de maintenance et des confusions. Pour être gérables, les sous-tâches ne doivent pas être trop nombreuses.

    Un robot robot : qui comporte 30 sous-tâches ou des milliers de lignes sans sous-tâches, révèle probablement un processus métier de trop grande envergure pour un robot :. Subdivisez les processus de grande taille en plus petits constituants, puis encapsulez chacun de ces éléments dans leur propre robots.

Exemple de sous-tâche

Par exemple, supposons qu'un robot : doive imprimer un document Bloc-notes en tant que fichier PDF. La tâche peut se présenter comme suit :

Imprimer le Bloc-notes au format PDF.

Dans cet exemple, il est nécessaire d'imprimer trois fois un fichier sous forme de document PDF. Sur la machine de génération d'exemples, le pilote d'impression PDF s'appelle Pdf995.

Recommandations :

  • Comme le pilote d'impression PDF en production portera probablement un nom différent, vérifiez s'il est envisageable d'utiliser une variable.

  • Il est possible que cette tâche passe en production et soit exécutée à de multiples reprises, sa conversion en sous-tâche est donc recommandée.

Étude de l'exemple en tant que sous-tâche :

Tâche d'assistance à la création de fichiers PDF.

Si cet ensemble de commandes doit un jour être modifié, seule cette tâche d'assistance devra être mise à jour et testée à nouveau.

Envoyer le commentaire