Оригинал статьи на Habr опубликован 2 апреля 2019 года.
Эта обзорная статья о том, как использовать RPA для бизнес-процессов, которые включают в себя задачи, которые обычные люди выполнять не умеют, не хотят, или это занимает у них много времени и требует специальных знаний, такие как работу с FTP, базами данных или API.
Включение в процесс подобных действий приближает его создание к традиционному программированию и "скриптам", со всеми плюсами и минусами этого подхода.
Использование API даже в традиционных для роботизации задачах может значительно повысить скорость их выполнение, увеличить надежность и устойчивость, но при этому удаляет нас от реализации мечты о том, чтобы бизнес-пользователи сами создавали и поддерживали свои процессы, однозначно возвращает их разработку и поддержку в руки команды разработки.
Когда можно,и когда нужно добавлять в процесс действия на более низком уровне, я попробую рассказать в этой статье. Первая, вводная часть, содержит общие рассуждения, а вторая - конкретные примеры. Примеры приведены для платформы, с которой я хорошо знаком (UiPath), поэтому тем, кто предпочитает другие вкусы и цвета роботов — заранее просьба не обижаться.
Pro и Contra роботизации на низком уровне
Почему такие роботы полезны
1. Значительно ускоряется работа. Часто это самая главная причина, по которой мы задумываемся о низко-уровневом взаимодействии со внешними системами. Если мы можем заставить процесс в 10 раз быстрее, мы можем сэкономить на использовании дополнительных роботов, с их виртуальными машинами и лицензиями.
2. Повышается надежность, больше не нужно работать с причудливо-динамическими селекторами в UI, думать о том, как обойти капчу, бороться за точность распознания картинки в Citrix, на который нельзя поставить плагин, или сражаться с бесконечным скроллингом на странице новостей.
3. Работа с системами, не имеющими полноценного UI или не позволяющими получить через UI всю нужную информацию. Например, в моей практике был кейс, когда мы забирали данные по API из Shopify, передавали в ShipHero и отправляли во внутреннюю систему учета. Только последний шаг использовал пользовательского интерфейса.
Почему такие роботы вредны
1. Бизнес-пользователи перестают понимать, что делает наш роботизированный процесс и не могут его сами менять и поддерживать. Это не так актуально для Unattended роботов, но для Attended (цифровых помощников) это существенный минус, ведь мы хотим чтобы пользователи сами были авторами своих процессов.
2. Теряется видимость и понятность процесса для службы безопасности. Если с обычным роботом мы можем наглядно показать, что он делает те же самые действия, что и "органический" пользователь, возможно даже использовать в качестве документации должностные инструкции, то с использованием низкоуровневой интеграции мы вынуждены соглашаться на то, что наш процесс должен проходить те же длительные процедуры проверки и контроля, что и "большая" автоматизация.
3. Dito, в отношении команд, занимающихся интеграцией. Как только мы начинаем использовать API, мы попадаем в их вотчину и должны играть по их правилам.
4. Стоимость и риски "настоящего" программирования больше, чем у роботизации. Если человек может нажать на кнопку, на нее может нажать и робот. А вот может ли API древней недокументированной системы обеспечить нам нужные данные? Можно ли в база записать информацию напрямую или мы этим разрушим ее целостность? Нужен ли для этой задачи опытный специалист или хватит новичка-студента? Почему Slides.Duplicate в PowerPoint.Interop возвращает массив? Ответ на все эти интригующие вопрос может быть получен, но на это понадобится время.
Когда нужно и когда не стоит использовать программирование в роботах
Суммировать вышесказанное можно следующим образом:
Программирование стоит использовать, если вашему процесу не хватает производительности или UI системы не удобен для автоматизации, но при этом есть удобный API
Программирование не стоит использовать, если процессы будут разрабатывать или поддерживать бизнес-пользователи, а также если использование API затрудняет прохождение роботом процессов согласования
С чем и как имеет смысл работать через код?
Дальше я попытался привести несколько примеров работы с кодом, которые, так или иначе, мне приходилось реально использовать при создании роботов, а значит, они имеют место в жизни. Естественно, список не исчерпывающий, но, надеюсь, он иллюстративный.
Примеры все опробованы на последних релизных версиях действий на момент написания статьи.
Microsoft Office
Как не странно, один из первых кандидатов на работу через API - это Microsoft Office. Да, в UiPath есть прекрасная встроенная функциональность для работы с Excel (даже два вида, один с файлами напрямую, второй - через приложение). Есть и возможности работы с Word (пакет UiPath.Word.Activities, ставится через менеджер пакетов). Но, например, уже для работы с PowerPoint стандартных действий нет, а еще есть и Outlook или даже Visio с Project, которые еще вполне активно используются в больших компаниях. С Office вполне успешно можно подружить робота через пользовательских интерфейс, но в некоторых случаях это не очень удобно, так как не ко всем элементам UI можно получить доступ напрямую и приходится играть гаммы на клавиатуре. Например, действие Type Into с текстом k[tab]k[f10]JCDD (для английской версии Office) откроет данные графика со слайда PowerPoint для редактирования в Excel. Работают такие комбинации хорошо, но выглядят магией почище IDDKQD.
ProTip: Список доступных селекторов можно расширить, используя вместо фреймворка Microsoft Active Accessibility (MSAA), который выбран по умолчанию, Microsoft UI Automation (UIA). Переключитесь на него кнопкой F4 в UI Explorer и посмотрите, есть ли разница
Для работы с офисными файлами можно использовать сторонние библиотеки, например Xceed DocX или библиотеки Spire, такие как Spire.Presentation. При работе со сторонними библиотеками обращайте внимание на лицензию, она может не всегда подходить для вашей компании (например iTextSharp для PDF бесплатно распостраняется по AGPL, а PDFSharp - по MIT). Этот способ очень удобен, так как его можно применять даже если не машине не установлен Microsoft Office, а значит, он отлично подходит для Unattended роботов, работающих на виртуальных машинах.
Для сложной работы с офисными программами на помощь приходит Microsoft.Office.Interop. Он позволяет нам совершать действия внутри приложений, манипулировать данными и т.д. Особенностям работы с Office.Interop можно посвятить не одну статью, штука древняя и хрупкая, но для наших целей подойдет. Для того, чтобы Interop работал, нужно добавить соответствующие сборки в Imports.
Приведу пару примеров того, что можно сделать с помощью Office Interop:
Outlook
Функциональность Outlook намного шире, чем просто работа с почтой, это персональный информационный менеджер, там и календарь, и записная книжка, и адресная книга, в общем, полный комплект. Если с электронной почтой все, обычно, можно решить прямым обращением к серверу, если он представляет интерфейсы IMAP/POP3, то остальную информацию намного проще получить из самого Outlook. Для этого Interop подходит как нельзя лучше.
PowerPoint
С помощью PowerPoint можно не только создавать красивые презентации, но и использовать его для оформления документов, таких как коммерческие предложения или регулярные отчеты по проекту. Для этого в PowerPoint нужно показать данные из других источников, и, конечно, с этой задачей отлично справляется робот. Большая часть времени при создании слайдов PowerPoint уходит на то, чтобы красиво их оформить, поэтому это можно сделать заранее, а реальные данные подставлять, копируя шаблонные слайды и заменяя на них тексты.
Работа в Word
Хотя активности из набора Word Activities Pack реализуют базовые возможности Word, они не покрывают весь функционал библиотеки Xceed DocX, на которой они построены. Самый частый случай - это работа с таблицами, но есть и много других кейсов. В репозитории проекта достаточно разных примеров, чтобы понять, где эта или похожая библиотека будут полезна.
Web API (REST, SOAP)
REST/JSON сейчас, наверное, ключевая связка для того, чтобы обеспечить интеграцию с системами, представляющими API.
Поддержка REST, SOAP и JSON обеспечивается с помощью Web Activities Pack.
C REST все достаточно просто, как и должно быть: HTTP Request -> Deserialize JSON и вот у нас уже есть JObject с которым мы можем делать все, что захотим. Для того, чтобы передать данные вебсервису есть удобный редактор параметров.
А вот для SOAP встроенный фунционал, к сожалению, ограниченный, не все виды веб-сервисов поддерживаются, не все запросы корректно обрабатываются. В случае, если вас сервис не работает, приходится пользоваться одной из многочисленных оберток для HttpClient, например SimpleSOAPClient или писать свою (вариант работы с SOAP из C#).
Работа с FTP
Здесь в UiPath все просто, есть готовый набор действий для FTP, входящий в Community Activities, а с другой стороны, начиная с версии 18.2 FTP Activities Pack в статусе deprecated. Но вся функциональность там есть, даже SFTP поддерживается (набор базируется на SSH.NET), хотя, к сожалению не допилена работа с клиентским ключем.
Базы данных
С базами данных UiPath работает через .NET Data Provider. Для MS SQL и MS Access все просто, для остальных надо настроить ODBC, и если его еще нет, установить драйвер. Имейте в виду, что поскольку, на данный момент, платформа 32х-битная, то и драйвер нам нужно скачивать соответствующий и источник данных ODBC надо заводить такой же. Ниже пример для работы с MySQL
Настройки тестовой удаленной базы MySQL (драйвер отсюда):
и подключаемся к ней из действия
Дальнейшая работа с SQL-совместимой базой данных достаточно стандартна - делаем запросы, получаем DataTable.
SAP через BAPI
Если ваш SAP дает вам такую возможность, то можно попробовать вместо работы через UI автоматизировать интеграцию с SAP через BAPI. Как обычно, в UiPath есть для этого готовый набор действий, включающий в себя мастер настройки соединения с SAP. Программирования здесь почти нет, но это пример того, что стандартный путь интеграции не единственно возможный.
В заключение
Надеюсь, что с помощью этой статьи смог рассказать о тех аспектах использования роботов, про которые не так просто узнать на Академии или на Форуме. Буду рад, если статься кого-то заинтересует или поможет ответить на вопросы, связанные с разработкой роботов.