Как стать автором
Обновить
41.68
Рейтинг
Directum
Цифровизация процессов и документов

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

Блог компании Directum Программирование *Администрирование баз данных *

Введение


На днях на внутреннем мероприятии мы с коллегами обсуждали тему роботизации процессов на проектах внедрения СЭД. Новости и обзоры поставщиков 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, то процесс выигрывает в скорости в несколько раз.
Общие результаты сведем в таблицы ниже.

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


image

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


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


Остается вопрос экономической целесообразности. Но окупаемость сильно зависит от конкретного проекта внедрения и доступности ресурсов. С технической же стороны от RPA мы получили хорошие впечатления от производительности робота и удобства средств разработки.
Теги:
Хабы:
Всего голосов 4: ↑4 и ↓0 +4
Просмотры 2K
Комментарии Комментарии 4

Информация

Дата основания
Местоположение
Россия
Сайт
www.directum.ru
Численность
501–1 000 человек
Дата регистрации