Журнал об электронном контенте, документах и бизнес-процессах
ИТ-директору Делопроизводителю Кадровику Бухгалтеру
Технологии проектирования и построения СЭД

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

  3 комментариев Добавить в закладки

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

Ещё материалы автора
Похожие записи
Комментарии (3)
Надежда Ердакова 20 декабря 2019 г. 11:02  

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

Альфия Шарафиева 23 декабря 2019 г. 13:08  

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

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

Сейчас обсуждают
Больше комментариев