RPA. Испытания программного робота на скорость при миграции данных

На днях на внутреннем мероприятии мы с коллегами обсуждали тему роботизации процессов на проектах внедрения СЭД. Новости и обзоры поставщиков RPA говорят, что программным роботом мы можем заменить API-коннектор. То есть использовать RPA для переноса больших объемов данных.

Скептики считают, что RPA — это «костыль», эрзац. И если обстановка требует полноценного взаимодействия приложений, RPA не справится и все равно потребуется API-коннектор.

Наши продавцы и специалисты из внедрения встречают задачу миграции данных в каждом проекте.

Характерная особенность миграции — большой объем и очень сжатый срок. Предприятие готово выделить для этого только 2-3 дня. Специалисты по внедрению готовятся очень внимательно, буквально по минутам планируют работу. Разработчики готовят утилиты.

Прозвучал закономерный вопрос: за какое время робот сможет перетащить хотя бы несколько тысяч записей из одной базы в другую?

В прошлой статье (ссылка) мы рассмотрели RPA от Automation Anywhere. В этот раз испытаем робота от другой известной студии — UiPath RPA. Испытывать будем на скорость работы: перенести 64 тысячи записей из одной базы в другую.

Для сравнения сделаем это несколькими способами:

• низкоуровневым API-коннектором на ЯП;
• роботом через встроенный API;
• роботом через промежуточный Excel-файл в форму-карточку конечной базы;
• роботом из формы-карточки источника в форму-карточку конечной базы;
• руками из карточки в карточку.

Результат может быть полезен для «подумать» разработчикам, администраторам и всем, кто ищет способ наладить взаимодействие разрозненного ПО, избежав глубокого программирования.

Дополнительно опишем некоторые особенности UiPath RPA, с которыми мы встретились в нашем мини-исследовании.

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

Итак, задача: перенести список контактов из базы-источника в конечную базу.
Количество записей — 64 000 шт. Каждая запись содержит Имя, Фамилию, Email, Организацию.
База-источник и конечная база — это простые базы MS Access с таблицей для хранения контактов и формой-карточкой для отображения индивидуального контакта.

Краткое описание каждого сценария

API-коннектор

Ожидается, что разработчик обладает компетенциями по API обеих систем и имеет доступ к базе данных. В нашем примере мы напишем коннектор на встроенном в MS Access языке VBA.
Названия полей в источнике и получателе могут не совпадать — в коде мы сами настраиваем, какие данные коннектор забирает из источника и куда их записывает в получателе.
Весь объем данных программа перенесла за 26 секунд.

Робот через API

Ожидается, что робота сможет настроить администратор действующей системы. Для этого нужно пройти курс обучения разработке RPA, у многих поставщиков обучение бесплатно.
Глубоких знаний DAO не требуется. Для работы с базами данных на «низком» уровне у RPA есть набор специальных команд — database activities. Требуемые настройки подключения студия UiPath выставляет сама с помощью визарда. Строчку SQL-запроса мы взяли прямо из конструктора запросов Access.

Главный момент — заголовки полей должны совпадать в начальной и в конечной базах. При этом порядок полей в запросе неважен.

Весь объем робот перетащил за 1 мин 52 сек. Хоть и дольше, чем API-коннектор, но порядок все же соизмерим.

Робот через Excel

Имеем, что из большинства СУБД можно экспортировать данные в какой-нибудь промежуточный формат — xls, xlsx, xml, html, csv. Робот UiPath умеет работать напрямую с такими файлами через встроенные Activities.

Ожидается, что разработчик RPA знаком с интерфейсом программы-источника, чтобы выгрузить данные в промежуточный файл. Также нужно знать и GUI программы-получателя данных. То есть с задачей справится обученный администратор.

Мы экспортируем список всех контактов в Excel-файл. Из Excel данные можно прочитать следующим образом:

• целиком в переменную типа DataTable (но нужно учитывать объем оперативной памяти и знать структуру данных этого типа);
• можно строчками (объема памяти потребуется меньше);
• а можно брать по одной ячейке за один раз (память практически свободна + сборка робота проще, DataTable не применяется). Мы сделаем по последнему варианту.

На стороне конечной системы робот открывает форму-карточку для новой записи и заполняет ее данными из Excel.

За 10 мин 24 сек робот мигрировал 64 записи. То есть ~173 часа уйдет на полный перенос. Причина такого замедления — время загрузки GUI в каждой операции.

Робот из карточки в карточку

Ожидается, что настроить такой перенос по силам обычному пользователю. Нужно только ознакомиться с упрощенным курсом RPA-разработки (1-2 дня изучения). Из всех методов роботизации этот самый простой в разработке.

Робот здесь выступает в роли продвинутого «кликера»: найти поле в карточке-источнике => взять его значение => найти поле в карточке-получателе => вставить значение => нажать «сохранить».

Карточки мы взяли стандартные. Такие формы-карточки Access генерирует автоматически вообще без программирования.
Время работы 9 минут 02 сек для 64 записей. То есть ~151 час на полный перенос.

Ручной перенос

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

Пользуемся мышкой и Ctrl+A, Ctrl+C, Ctrl+V, Alt + Tab и те же карточки.

Перенести 10 записей заняло 5 минут. То есть: ~533 часа на весь объем. И это только чистое время ручной работы. А еще человек должен отдыхать, отвлекаться на другие задачи и исправлять ошибки собственной невнимательности. Если робот заменяет человека в операциях с GUI, то процесс выигрывает в скорости в несколько раз.

Общие результаты сведем в таблицы ниже.

Сводные результаты

Особенности RPA

Несколько особенностей, которые встретились нам в этом испытании:

• при работе с Access под 64-битной системой необходимо установить 32-битный AccessDatabaseEngine.exe;
• в сценарии «Робот через Excel» процесс «спотыкался» на поле «Организации» в карточке-получателе. Поле в карточке и поле в самой таблице имеет тип «Поле с подстановкой». Когда обрамили операцию записи в это поле двухсекундными выдержками, процесс стабилизировался;
• визард UiPath Studio для подключения к базам данных вставляет лишние кавычки в строку настройки — это надо перепроверять;
• в поле с SQL-запросом текст не должен содержать возврат каретки, иначе UiPath Studio возвращает ошибку. Текст запроса должен быть одной строкой;
• очень удобно, когда на форме-карточке есть кнопки навигации по записям: следующая карточка/ предыдущая/ первая/ последняя. С такими кнопками собрать робота легче, и в работе он будет стабильнее. Это можно рассматривать как общую рекомендацию для разработки GUI. Например, Access в своих формах-карточках по умолчанию предоставляет такие средства;
• при настройке роботов нам не пришлось программировать в обычном понимании. Алгоритм собирается из блоков, как диаграмма. Блоки настраиваются в окне свойств. Концепция low code/no code в нашей задаче действительно сработала;
• с RPA доступен еще один сценарий переноса — через GUI на удаленном рабочем столе. Сам робот запущен локально, а с помощью CV и OCR выполняет действия в терминале. Данные можно передавать прямо через буфер обмена.

Остается вопрос экономической целесообразности. Но окупаемость сильно зависит от конкретного проекта внедрения и доступности ресурсов. С технической же стороны от RPA мы получили хорошие впечатления от производительности робота и удобства средств разработки.

Источник: Блог компании DIRECTUM на Habr