Что такое UiPath: краткий обзор инструмента

UiPath — это инструмент для эмуляции действий пользователя с различными приложениями. При этом программирование действий в UiPath делается не с помощью написания кода, а в виде создания своеобразных блок-схем. Кроме того, UiPath позиционируется не как инструмент для автоматизации тестирования, а как средство для автоматизации бизнес-процессов, из чего следуют сразу 2 важных отличия от классической автоматизации:

наши тесты (или «процессы» в терминологии UiPath) будут работать на продакшене, а значит к ним предъявляются высокие требования;
нам придётся работать со сторонними приложениями и мы не сможем повлиять на их внутреннее устройство (например, добавить уникальный идентификатор для какого-то элемента управления).

Конечно, UiPath можно использовать и для обычной автоматизации тестирования, однако целесообразность этого мы рассмотрим позже в этой статье. А сейчас давайте поговорим о самом инструменте и его возможностях.

Общие сведения

UiPath существует в двух версиях: Community Edition и Enterprise. Community версия доступна всем бесплатно, достаточно зарегистрироваться на сайте UiPath, однако для этой версии отсутствует возможность получить помощь саппорта. Enterprise версия платная и включает в себя поддержку по e-mail (с недавнего времени поддержка ведется в том числе на русском языке).

Новые фичи сначала выпускаются для Community Edition. Некоторое время они таким образом тестируются на реальных пользователях, обкатываются, фиксятся, а затем становятся доступными для Enterprise версии продукта. Достоинство такого подхода в том, что Enterprise пользователи получают хорошо протестированный продукт (в том числе и реальными пользователями). Недостаток же в том, что Enterprise пользователи, которые платят деньги за инструмент, получают новые возможности последними, причем между выпусками Enterprise версий может пройти довольно большой срок (несколько месяцев).

Быстрое включение новых фичей в Community Edition иногда может иметь неприятный или забавный эффект. К примеру, мне довелось столкнуться с ситуацией, когда я создал новый проект в Community Edition, однако после закрытия больше не смог его открыть. Это было связано с тем, что в предыдущей версии продукта была включена экспериментальная фича, а в текущей версии её убрали, однако сделали это не совсем корректно. В результате можно было создать новый проект и пользоваться экспериментальными возможностями, однако после закрытия его невозможно было открыть снова.

Также есть особенности регистрации для разных стран. На момент написания этой статьи UiPath не поддерживается для некоторых стран (например, для Украины). Вы сможете зарегистрироваться на сайте, но не сможете скачать инструмент. Поэтому в таких случаях необходимо воспользоваться прокси-серверами других стран. После скачивания и установки для работы с UiPath прокси-сервер вам больше не понадобится (кроме случаев, когда вы захотите скачать новую версию).

UiPath состоит из трёх основных частей:

UiPath Studio — среда разработки, или попросту студия;
UiPath Robot (или Agent) — утилита для запуска процессов из командной строки, а также для настройки подключения компьютера к Оркестратору;
Orchestrator — централизованная система для управления процессами, версиями, тестовыми машинами, запусками и т.п.

В этой статье мы кратко рассмотрим эти три компонента.

Внешний вид студии и её возможности

Вот общий вид UiPath Studio:

В левой части находится панель навигации с тремя вкладками:

Project — доступ ко всем файлам и зависимостям (dependencies) проекта. В UiPath «код» хранится в XML-файлах с расширением .xaml. Зависимости — это .NET сборки (assemblies) или .xaml-библиотеки, разработанные специально для UiPath, которые используются в текущем проекте;
Activities — это набор действий, которые можно использовать в процессах. Тут отображаются как стандартные активити, включенные в UiPath, так и загруженные из интернета, а также наши собственные;
Snippets — примеры и небольшие кусочки псевдокода UiPath, которые можно добавлять в проект в случае необходимости (например, активити Delay, позволяющая приостановить выполнение процесса на заданное время).

По центру располагается рабочее пространство, где в других средах разработки мы обычно видим код на каком-либо языке программирования (подробнее об этом в следующем разделе статьи). Здесь тоже есть три вкладки, которые обычно скрыты и открываются по мере необходимости:

Variables — переменные, которые мы используем в наших тестах;
Arguments — аргументы, которые мы передаем снаружи (аналогично аргументам в языках программирования);
Imports — .NET сборки, которые мы используем в текущем файле.

В случае Imports необходимо кое-что уточнить. UiPath завязан на .NET платформу и позволяет использовать практически любые сборки (для их установки предназначено специальное приложение Manage Packages, которое можно вызвать из UiPath). Некоторые компоненты UiPath используют .NET сборки для внутренних нужд. Мы также можем использовать их для создания своих компонентов или просто для написания фрагментов кода на языках VB.NET или C# внутри UiPath проектов.

Справа располагаются прочие полезные панели:

Properties — свойства элемента, выделенного в данный момент (как и в других системах разработки);
Outline — структура проекта. Здесь можно посмотреть порядок вызова активитей (аналог Call Stack);
Output — консоль вывода (по аналогии с консольными приложениями мы можем выводить сообщения в консоль и затем просматривать их на этой панели).

Кроме этих панелей, в режиме отладки доступны:

Locals — локальные переменные;
Watch — список выражений/переменных/объектов, значения которых мы хотим видеть в любой момент;
Immediate — окно мгновенного вычисления выражений (аналог панели Expression в Eclipse).

Таким образом UiPath предоставляет достаточно неплохие возможности для отладки процессов.

Тем не менее необходимо иметь ввиду, что UiPath — бурноразвивающийся инструмент, а потому с ним всегда возможны сюрпризы. В текущем проекте мы столкнулись с тем, что в режиме отладки не могли получить доступ к свойствам объекта, как будто их не существовало. При этом мы могли вывести в консоль значения этих свойств с помощью обычной активити Log Message, а также работать с этим объектом в коде, т.е. проблема была именно в дебаггере UiPath-a.

Как выглядит «код» в UiPath

Как уже говорилось ранее, в UiPath мы не пишем код, а пользуемся своеобразным конструктором для построения схем. Эти схемы могут быть трёх видов: последовательность (Sequence), блок-схема (Flowchart) и конечный автомат (или стейт машина, State Machine).

Sequence

Sequence — это просто последовательность действий (кликнуть по кнопке, ввести текст в поле, вывести информацию в лог). Для создания новой последовательности нужно на панели инструментов кликнуть New – Sequence и ввести имя последовательности, которую вы хотите создать. После этого в дереве проекта слева у вас появится новый xaml-файл, в который можно добавлять активити с вкладки Activities. Кроме простых активностей (клик, ввод текста) могут быть и сложные: циклы, условия, вызов целых подпрограмм и т.п. Вот пример того, как выглядит sequence:

Здесь мы видим примеры простых активностей (Assign — присвоить значение переменной, Write Line — вывод строки в лог), цикла For Each и сложной активити Digitize Document, которая в свою очередь принимает в качестве параметра другую активити Google Cloud Vision OCR.

Обратите внимание, что в UiPath есть небольшая путаница в терминологии. Когда вы нажимаете на тулбаре New – Sequence, у вас на самом деле создается новый файл, который в дальнейшем везде называется Workflow. Sequence же — это отдельная активность, с помощью которой можно группировать другие активности (по аналогии с фигурными скобками в некоторых языках программирования). Например, на скриншоте выше блок Prepare Data — это sequence, внутри которого собраны 2 активности.

Flowchart

Flowchart — это блок-схема последовательности вызова различных действий:

Здесь вы видим те же последовательности действий, просто визуализированные по типу блок-схем. Каждый блок в этой блок-схеме — это та же последовательность, у которой есть вход и выход. Кроме того, на скриншоте есть активити Flow Descision (аналог инструкции IF в языках программирования) с названием Check Result и двумя вариантами исхода (True, False).

State Machine

State Machine — это более сложный Flowchart. Вместо использования последовательностей тут используются состояния (State). В результате каждый шаг процесса может получать несколько возможных вариантов развития событий. Вот как в общем выглядит бизнес-процесс в UiPath, представленный в виде стейт машины:

Все эти схемы могут вызывать друг друга, а потому какой именно подход использовать — зависит от задачи, которую вы решаете. В одном проекте могут использоваться все эти подходы (Flowchart для общей структуры процесса, Sequence — для более мелких задач, State Machine — для специфических сложных мест).

Создание процессов

Как и многие инструменты автоматизации, UiPath предлагает 2 способа создания процессов: вручную и с помощью автоматической записи. Для автоматической записи действий пользователя на тулбаре есть кнопка Recording, которая позволяет записать действия в одном из режимов:

И так же, как в других системах автоматизации, запись обычно используется при изучении инструмента или для записи небольших фрагментов для временного пользования. Со временем становится удобнее и быстрее создавать процессы вручную. Для этого в редактор UiPath с панели Activities перетаскиваются необходимые компоненты и настраиваются их параметры, как и при написании кода.

Можно ли выполнять сложные задачи с помощью UiPath?

Один из первых вопросов, который возникает у опытных автоматизаторов, когда они видят UiPath, — это «а можно ли тут делать сложные вещи, такие как поиск дочерних объектов у элемента управления, ожидание появления контрола на экране, изменение определенного свойства контрола и т.п.?».

Да, всё это можно делать, для этого UiPath предоставляет все возможности, хотя необходимо время, чтобы научиться правильно ими пользоваться. Существуют активности типа Element Exists, Find Image, Wait Element Vanish, Wait Attribute и другие. У каждой из этих активностей есть дополнительные свойства, с помощью которых можно настраивать работу с контролами. Пример ниже показывает, как с помощью активности Find Element найти элемент с определенными свойствами (активный и видимый):

Конечно, бывают и более сложные случаи, когда нам нужно сначала найти набор дочерних объектов по каким-то признакам, а затем среди них выбрать один или несколько по другим признакам. В таких случаях, как и в языках программирования, мы комбинируем встроенные возможности UiPath и различные циклы, условия и т.п.

В некоторых случаях стандартных возможностей UiPath не хватает. Допустим, если нужно запустить стороннее приложение, то мы сможем это сделать без проблем, однако не сможем получить его exit code или же попросту дождаться, пока приложение отработает и завершится. Для решения подобных проблем UiPath предоставляет нам возможность написать код на языке VB.Net или C# и выполнить его внутри процесса с помощью специальной активити Invoke Code. С помощью этого подхода обычно можно решить многие проблемы.

Работа с библиотеками

Одна из специфических особенностей UiPath заключается в том, что для повторного использования «кода» он предлагает пользоваться .NET пакетами (packages). Выглядит это так: вы создаёте проект типа Library, создаёте в нём нужные вам Workflow для многократного использования, затем с помощью операции Publish создаёте пакет (файл .nupkg), у которого есть версия, как у любой библиотеки, а затем с помощью утилиты Manage Packages добавляете этот пакет в свой процесс и используете именно ту версию, которую вы добавили. Если в будущем вам понадобится обновить эту библиотеку, вам придется не просто создать новую версию пакета, но и обновить процесс, указав, что нужно использовать новую версию библиотеки.

Этот подход не очень удобен тем, кто работал в автоматизации тестирования. Мы знаем, что изменение коммон кода повлияет на работу всех тестов, и если мы допустим ошибку при внесении изменений в общий код, то это сразу затронет все тесты, которые этот самый код используют.

В случае с библиотеками ситуация иная. Предположим, что у нас есть 2 процесса AddAccount и EditAccount, которые используют воркфлоу ReadAccountDataFromDatabase из общей библиотеки. Сначала мы создали процесс AddAccount и в нем используем ReadAccountDataFromDatabase версии 1.0.1. А затем мы создали новый процесс EditAccount, для которого мы несколько раз меняли воркфлоу ReadAccountDataFromDatabase, в результате его текущая версия 1.0.4. Какое-то время эти процессы могут успешно работать (так как используют разные версии общей библиотеки), и это может показаться хорошим подходом, но вот пришло время нам обновить первый процесс. Прежде всего мы обновляем библиотеку до последней версии 1.0.4 и выясняем, что эта новая версия несовместима с нашим старым процессом.

Так как изменения, которые ломают нам первый процесс, могли быть сделаны очень давно (предположим, еще в версии 1.0.2), может быть очень сложно определить, почему и какие изменения были сделаны. Кроме того, внося новые изменения и создавая библиотеку версии 1.0.5, мы снова можем внести изменения, которые поломают уже второй процесс, но узнаем мы об этом возможно через недели или месяцы.

Еще одно неудобство: в случае возникновения проблемы внутри библиотеки, вы не сможете в режиме Debug пройти пошагово все инструкции внутри вызываемой библиотеки. Вам придется открыть проект с этой библиотекой и искусственно воссоздать проблему.

Если вы не хотите использовать подход с пакетами, который предлагает UiPath, вы можете вызывать активити из библиотек не с помощью подключения пакетов, а с помощью активити InvokeWorkflowFile. В этой активити можно указать как абсолютный, так и относительный пусть к файлу воркфлоу, таким образом перейдя к привычной схеме работы с коммон кодом. Однако такой подход не является нормальным для UiPath, потому неизвестно, с какими проблемами вы столкнетесь в будущем.

Robots (Agents)

Robot — это утилита командной строки, с помощью которой можно запустить процесс с различными параметрами. Еще одно назначение Робота — настройка подключения к Оркестратору. Для этого необходимо запустить утилиту UiPath.Agent.exe, после чего щелкнуть на значке робота в трее и выбрать пункт меню Orchestrator Settings. Все значения, которые нужно ввести в открывшемся окне, можно получить в Оркестраторе.

Роботы бывают трёх типов:

Attended — чтобы запустить на таком роботе процесс, необходимо открыть активную сессию на компьютере (залогиниться на компьютер или же подключиться к нему через Remote Desktop). Этот тип используется для процессов, за которыми следит человек, а возможно и частично взаимодействует с ними (например, вводит текст капчи, когда это необходимо);
Unattended — этот робот сделает всё сам, нужно лишь, чтобы компьютер был включен, а логин произойдёт автоматически (логин и пароль для таких роботов указываются в Оркестраторе). Этот тип используется в тех случаях, когда процесс работает без помощи человека;
Development — этот тип роботов умеет всё, что два предыдущих, и используется для разработки.

По умолчанию UiPath предоставляет 2 Attended, 1 Unattended и 2 Development лицензии. Если нужно больше — их можно заказать за отдельную доплату.

Orchestrator

Orchestrator (cloud.uipath.com) — это онлайн-система для менеджмента процессов. Отсюда их можно запускать на различных компьютерах, настраивать запуск по расписанию, просматривать логи выполненных и работающих в данный момент процессов. Здесь же можно хранить настройки (так называемые Assets) для разных роботов.

Когда мы публикуем в UiPath Studio новую версию процесса или библиотеки, мы можем автоматически опубликовать их на Оркестратор, или же сохранить локально .nupkg файл, а затем вручную загрузить в Оркестраторе (такой подход может использоваться в тех случаях, когда для разработки и запуска используются разные Оркестраторы).

Как у любой системы, у Оркестратора есть свои достоинства и недостатки, однако их рассмотрение выходит за рамки этой статьи. В целом можно сказать, что Оркестратор справляется с поставленными задачами, хотя и встречаются неприятные моменты, баги, недоработки и т.п. Однако, как и Студия, Оркестратор постоянно развивается, так что всегда есть надежда, что подобные недостатки будут устранены в будущих версиях.

Особенности UiPath как инструмента для автоматизации бизнес-процессов

Как уже говорилось в начале статьи, UiPath позиционируется не как инструмент для автоматизации тестирования, а как средство для автоматизации бизнес-процессов. Да, UiPath поддерживает различные типы приложений и платформ (разные браузеры и десктоп-приложения), причем вам не нужно делать каких-либо специальных настроек в UiPath для распознавания элементов управления, обычно он всё делает сам. Однако в целом UiPath нацелен немного на другие задачи, например:

поддержка работы с офисными файлами. Для простых задач вам не нужно искать способы работы с PDF-файлами, разбираться, как открыть и корректно закрыть Excel документ, отправить e-mail или сохранить файл. Вам нужно лишь использовать подходящую активити для вашей задачи;
работа с чеками и счетами (receipts and invoices) также частично автоматизирована, нужно лишь правильно настроить все компоненты;
распознавание текста (OCR) предоставляет возможность выбрать один из доступных для этого движков (Microsoft, ABBYY, Google), а работа с изображениями происходит очень быстро (например, поиск одной картинки внутри другой).

Кроме того, одна из задач UiPath — сделать автоматизацию простой для тех, кто не знаком с программированием. Тут сложно судить, насколько компания добилась в этом успеха, так как в других коммерческих инструментах тоже есть средства записи/воспроизведения, и они обычно не рекомендуются для реальных проектов. В UiPath для простых задач мы можем обходиться без кода, просто перетаскивая блоки (активити), однако даже для задач средней сложности уже необходимо понимать, что такое условия, циклы, исключения, типы данных, форматы файлов (xml, json), in- и out-параметры.

Недостатки UiPath

Недостатков у UiPath вагон и маленькая тележка. Вот основные нюансы, которые не нравятся лично мне:

невозможность переключиться на написание кода вместо визуального редактора (как это сделано в других инструментах: TestComplete, QTP, Ranorex);
нерациональное использование рабочего пространства в редакторе. Одна инструкция типа вывода строки в лог (Log Message) по высоте занимает места как 3-4 строки кода. Соответственно, на экране одновременно видишь небольшой кусок «кода». Сюда же можно отнести способ представления информации. Если в том же Log Message выводишь длинную строку, её всю просто не увидишь на экране, так как её длина ограничена небольшим прямоугольничком;
закомментированная инструкция помещается внутрь другого прямоугольника, в результате занимая в 2 раза больше места; закомментировать несколько инструцкий одновременно невозможно;
в случае исключения невозможно быстро перейти на то место, где исключение возникло (например, кликнув по сообщению в логе), приходится искать вручную (в режиме отладки это решается с помощью кнопки Focus на тулбаре, которая позволяет перейти в текущее место выполнения);
организация доступа к общему «коду» в виде пакетов тоже неудобна, особенно если возникает ошибка где-то внутри библиотеки, отлаживать просто нереально (я пробовал включать опцию Include Sources при создании пакета, никакого эффекта);
невозможность переименовать скриншоты, дать им осмысленные имена;
формат файлов .xaml. Ну, тут понятно, что лучше бы это был код (пусть даже на том же Visual Basic), но есть и другие нюансы: резолвить конфликты в системе контроля версий невозможно. И ещё кое-какие мелочи;
отсутствие Application Map, селекторы (или локаторы в терминах selenium) прописываются для каждой инструкции отдельно. В лучшем случае можно использовать активити Application Scope, но это не решает проблему глобально, только внутри отдельного xaml-файла;
непонятно, как работать с кастомными элементами управления. В нашем проекте есть .NET Desktop приложение, там кастомный комбобокс, UiPath не может применить для него Select Item. Наверное, можно как-то дернуть нативный метод, но я пока не знаю как;
на мой взгляд разработка процессов происходит медленнее, чем разработка/поддержка аналогичного кода на любом языке/инструменте. Таскание вот этих прямоугольников, работа с их настройками занимают больше времени, чем написать аналогичный код;
невозможность прохода построчно кода (активити Invoke Code) в режиме отладки и ещё кое-что;
невозможность просматривать файлы проекта в простом текстовом режиме. Мы можем добавить в папку проекта любые файлы (txt, json, csv и другие), однако не сможем просмотреть их содержимое внутри UiPath даже просто в виде текста. Файл проекта называется project.json, этот файл относится ко всему проекту, однако при двойном клике на нём у меня открывается студия (с ней ассоциирован этот тип файлов), хотя мне достаточно было бы просмотреть его, как обычный текстовый файл;
сложность настройки Оркестратора. В нашей вики есть 2 статьи по настройке Оркестратора и запуску процессов через него. Первая статья содержит 22 шага, вторая 14 (собственно, добавление нового робота в Оркестратор — это повод для целой отдельной статьи).

Несмотря на все перечисленные выше недостатки, UiPath развивается и что-то в нём постоянно улучшается. Например, несколько месяцев назад я писал комментарий к статье (укр.), где тоже перечислял эти недостатки, однако тогда был ещё один существенный минус: очень слабые средства отладки. Спустя пару месяцев отладка в UiPath улучшилась в разы и теперь у меня к ней практически нет претензий. Так что есть надежда, что и эти минусы однажды будут устранены.

Кому полезен UiPath?

Есть 2 основных вопроса, которые задают люди, не работавшие ранее с UiPath:

мне понадобится знание этого инструмента в будущем?
я буду тупеть, перетаскивая эти квадратики вместо написания божественного кода?

Прежде всего отвечу на второй вопрос: тупеть вам не придётся, скорее даже наоборот. Так как UiPath имеет ограничения, вам нужно будет искать для своих задач решения, зачастую нестандартные. Код вы тоже будете писать, Visual Studio будет вашим лучшим другом, так как многие задачи проще решить кодом, чем стандартными средствами UiPath. Ну и, наконец, вопросы планирования и проектирования никуда не деваются. Просто в случае с UiPath придётся немного изменить свои подходы, переключиться на иной способ разработки.

Относительно того, понадобится ли знание этого инструмента в будущем… На данный момент есть 2 похожих инструмента (Blueprizm, Workfusion), а некоторые инструменты автоматизации поддерживают похожие способы разработки тестов (TestComplete, QTP). Возможно, в будущем вам придётся с чем-то похожим столкнуться. Но даже если нет, то для автоматизатора UiPath — не более чем очередной инструмент со своими особенностями.

Если же вы рассматриваете автоматизацию как промежуточный этап в своей карьере и хотите в будущем переключиться на разработку, то не стоит тратить время на UiPath, лучше сконциентрируйтесь на том языке программирования, с которым хотели бы работать в дальнейшем.

Заключение

Когда 8 месяцев назад мне предложили работать в проекте, где используется UiPath, у меня были небольшие сомнения, но я решил попробовать. Всё же что-то совершенно новое, а это всегда интересно. Первые 2-3 месяца у меня бомбило буквально от всего, каждый день использования этого инструмента преподносил очередной сюрприз, от которого хотелось биться головой о стену. Но время шло, я привыкал, вникал, понимал. Сегодня я использую UiPath как любой другой инструмент, а пукан разрывает не чаще раза в месяц, что в принципе достаточно приемлемо.

Честно говоря, если бы я выбирал инструмент для работы на ближайшие несколько лет, я бы вряд ли остановил свой выбор на UiPath, особенно когда речь идет о работе в команде, нужно учитывать бюджет и думать о будущей поддержке того, что создаешь. Однако иногда выбор инструмента зависит не от нас, и в этом случае все равно можно работать и делать что-то полезное и интересное.