Авторы: Лебедев А., Назарова Е.

Нужда в использования средств роботизации возникает в силу различных причин: необходимость для новых приложений обмениваться данными с приложениями, которые не имеют API, быстрая интеграция разнородных приложений, автоматизация рутинных процессов с минимумом затрат и т.д.

Традиционно роботы или RPA (Robotic process automation) строятся на базе готовых фреймворков. Здесь лидерами выступают, на наш взгляд, продукты от UiPath, Automation Anywhere, Blue Prism, NICE. Это зарекомендовавшие себя платформы, позволяющие делать качественные решения. Однако и недешёвые. Нужно заплатить за лицензии по количеству будущих рабочих мест, заплатить за настройку под вашу конкретную задачу и запуск в эксплуатацию. В некоторых случаях можно обойтись дешевле. Мы обошлись, и готовы поделиться опытом.

Некоторое время назад в одном из банков началась Agile-трансформация. Новые подходы к разработке приложений для нужд банка. Чтобы показать остальным дорогу, сформировали пилотные команды для разработки новых продуктов.

В банке есть традиционные ключевые системы для ведения учетно-операционной деятельности. Работа с продуктами новых команд была реализована в виде микросервисов, которые должны обмениваться данными с ключевыми системами. И разработка в командах довольно быстро стартовала. Но незадача в том, что в эти темпы совершенно не укладывались традиционные подходы к релизной политике ключевых систем. И API для новых микросервисов стоял в плане на перспективу.

Получается, как у Печкина, «я вам посылку принес, но я вам её не отдам». В этих условиях к нашей команде автотестирования и обратились представители пилотных команд с идеей использования автотестов UI схожих процессов для создания роботов.

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

Инструментарий использовали традиционный и бесплатный: Java для разработки, сборка через Maven. Для работы с браузером использовали Selenium (приложение, куда требовалось вводить данные имеет вэб-интерфейс).

Основные отличительные черты робота в сравнении с UI-автотестом того же процесса – необходимость корректной обработки ошибочных ситуаций и исключений, интеграция в качестве подсистемы через файловый обмен.

Для работы робота был выделен виртуальный сервер, техническая доменная учетная запись и создан отдельный пользователь в системе, куда вводились данные. С полномочиями, как у живого сотрудника, который выполняет аналогичные действия.

На этом сервере установили агента Jenkins, позволяющего запускать робота. Отчет о работе робота формировался как в виде лога выполнения, так и в виде Allure Report. И то и другое доступно в Jenkins и не требует специального разрешения для доступа к сетевым ресурсам.

Работа робота строилась так: во входную папку на сетевом ресурсе помещается файл с данными для ввода в систему и через Jenkins запускается робот; он сравнивает записи входного файла по ключевому полю со служебным файлом, где хранятся все уже обработанные записи, и отбирает только те, что еще не обрабатывались. Далее массив записей обрабатывается в цикле. Причем на каждом шаге обработки каждой записи обрабатываются исключения и ошибки (try…catch) и «падения» процесса отмечаются в результирующем файле. При этом обработка входного массива не прекращается, просто переходим к следующей записи. В итоге, когда обработка всего массива завершена, входной файл удаляется, в выходном присутствуют все обработанные записи с результатом и временем выполнения. В Allure Report выводятся как информация о выполнении обработки по каждой записи, так и общий список с результатами обработки каждой записи. Это позволяет легко оценить результат и локализовать проблемы, если они есть.



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

В системе создали еще несколько пользователей. Параллельное выполнение реализовали с помощью потоков (Thread). Весь массив входных записей распределяется поровну между потоками, в каждом из которых обработка ведется под своим пользователем. Результаты пишутся в один файл и отчёт получается также единый. Это удобно. При этом запущен одиночный Selenium Server, вполне справляющийся с параллельным запуском нескольких браузеров (по количеству работающих пользователей). Мы работали с браузером Chrome, соответственно использовался chromedriver.

Это удивительно, но за девять месяцев эксплуатации проблемы были только из-за некорректных входных данных. Технические проблемы возникли только на этапе ввода в эксплуатацию и связаны были с согласованием кодировок в логе и расширением используемой памяти при запуске Selenium Server (поставили 1G).

Через какое-то время, для этой же Agile-команды, был разработан еще один робот. Его особенность в том, что он не запускается по требованию, а работает непрерывно, сканируя входную папку. При появлении входящего файла, он берет его в обработку. Соответственно, агент Jenkins не используется. Если процесс выполнен успешно, входной файл перемещается в папку с успешно обработанными файлами, в противном случае – в папку с ошибочными файлами. В отличие от предыдущего робота, Allure Report отсутствует, но логи выполнения записываются в отдельный файл для анализа в случае каких-либо проблем. И еще одна особенность – браузер принудительно закрывается по окончании обработки и стартует, когда пользователю требуется войти в систему.

Таким образом, в ряде случаев при создании RPA можно обойтись заметно более дешёвым способом, используя инструменты автотестирования.