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

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


    image

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


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


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

    Похожие публикации

    Комментарии 4

      0

      Добрый день! Очень полезная и интересная статья.
      Но, боюсь, с цифрами у вас что-то не то, особенно в части с Excel.
      Во первых путь миграции по одной записи категорически неверный, нужно делать через datatable. Аргумент что так проще странный, через datatable проще намного.
      Во вторых, даже вашим способом так долго работать не должно. Может быть вы поделитесь кодом, чтобы было понятно, о чем речь?

        0
        Про первое замечание. Брать по одной записи — это путь действительно не быстрый. Тут я отметил такие моменты (поделюсь собственными впечатлениями):

        • Начинающему разработчику RPA с отдельными ячейками Excel работать проще, чем со строчками Datatable. Сами данные и обращение к ним нагляднее: книга — лист — адрес ячейки. Медленно, но визуально и контролируемо. Datatable — это мощно и быстро в работе, но с ним надо немного поглубже познакомиться.
        • В данном кейсе «бутылочное горлышко» в другом месте. Медленным является графический интерфейс конечной системы: открытие карточки, сохранение, закрытие карточки. Тормозит не робот, а MS Access. Данные из Excel робот читает фоном, без графического интерфейса. Последовательно прочитать 1000 ячеек занимает меньше минуты. В общем процессе это по времени почти незаметно.

        Про второе замечание. Исходники и тестовые базы вышлю — будет интересно обсудить.
          0

          Даже начинающий RPA разработчик постарался бы оптимизировать код по скорости. Копирование по одной строке — самый очевидный кандидат. В обратном случае, он был бы вынужден в скором времени вернуться к предыдущей должности, судя по всему, секретарской.

          0
          Спасибо за полезный материал. RPA действительно сейчас на тренд для автоматизации бизнеса.
          Хочу не в качестве рекламы, а поделится кейсами RPA, которые помогли компаниям изменить внутренние процессы и сэкономить врем и деньги. Это случаи с разных индустрий как страхование, FMCG, банкинг rpa-uipath.chatbots.studio/ru/our-expertise
          Очень рекомендую ознакомится.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое