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