Screen Scraping или API: когда RPA действительно еще нужен

У screen scraping плохая репутация, и чаще всего заслуженно. Когда программный робот кликает по экранным формам вместо того, чтобы получать данные через интерфейс, это редко бывает чистым решением. Тем не менее в среднем бизнесе есть процессы, где именно это единственный путь. Решающий вопрос не в том, выглядит ли метод устаревшим, а в том, есть ли у целевой системы пригодный интерфейс.

Что такое screen scraping и чем он отличается от интеграции через API?

Screen scraping обозначает автоматизированное считывание и управление приложением через его экранный интерфейс: робот перемещает указатель мыши, заполняет поля и считывает значения с экрана, точно так же, как это делал бы человек. Интеграция через API обходит интерфейс и обращается напрямую к интерфейсу данных системы.

Microsoft формулирует это различие в документации Power Automate предельно кратко: через API приложению говорят, что делать, через интерфейс ему это показывают (Виды автоматизации процессов, Microsoft Learn). Лишь один из этих способов является соглашением. Интерфейс — это обещание производителя, что поля и форматы останутся неизменными. Экранная форма таким обещанием не является.

API или screen scraping: что рекомендуют сами производители

Рекомендация однозначна, и исходит она от самих производителей RPA. Microsoft советует выбирать автоматизацию на основе API для каждого приложения с доступным API-коннектором, поскольку интерфейсы должны оставаться стабильными даже при изменении приложения.

По данным производителя, Power Automate охватывает более 380 приложений с готовыми API-коннекторами, к которым добавляются самостоятельно созданные коннекторы для любой системы с доступным API (Microsoft Learn). Таким образом, автоматизация через интерфейс — это не равноценная альтернатива интеграции через API, а задокументированный аварийный выход. Тот, кто сразу хватается за робота, покупает затраты на обслуживание, которые никто не заказывал.

Почему обслуживание screen scraping обходится дороже

Расплатой за это становятся затраты на обслуживание, и они хорошо задокументированы. Автоматизации через интерфейс зависят от селекторов, то есть от технического описания того, где находится элемент управления и как он называется. Если это описание меняется, робот больше не находит элемент, и выполнение прерывается.

Для неконтролируемых десктоп-потоков Microsoft перечисляет шесть факторов, которые могут сделать селектор непригодным: разрешение экрана и масштабирование DPI, обновления приложения, версия операционной системы, размер окна, состояние элемента и права вошедшего пользователя (Устранение неполадок неконтролируемого выполнения, Microsoft Learn). Ни один из этих пунктов не связан с бизнес-процессом. Процесс остается таким же правильным, автоматизация спотыкается об упаковку.

UiPath описывает ту же проблему с другой стороны: классические селекторы опираются на жесткие атрибуты и иерархии, поэтому уже измененная подпись, динамический ID элемента или новая тема останавливают автоматизацию. Сам производитель оценивает связанные с этим затраты на обслуживание как высокие (О семантических селекторах, UiPath Docs). При интеграции через API ни одной из этих проблем не существует. Интерфейсу нет дела до разрешения экрана.

Когда screen scraping действительно правильный выбор?

Screen scraping — правильное средство, когда у системы нет пригодного интерфейса и управлять ею можно только через экран. Microsoft четко формулирует это условие в лицензионной документации: RPA нужен для приложений, для которых не существует ни готового коннектора, ни API, на основе которого можно было бы построить собственный.

На практике это относится к пяти ситуациям:

• Старые отраслевые системы без API: исторически сложившееся отраслевое ПО, никогда не предназначавшееся для интеграции.
• Терминальные и Citrix-приложения: если приходит только изображение экрана, технически не за что зацепиться, кроме самой формы.
• Интерфейс заблокирован: некоторые производители лицензируют API-модуль отдельно или вовсе не предоставляют его небольшим клиентам. Тогда вопрос становится коммерческим, а не техническим.
• API не покрывает процесс: интерфейс, который только читает данные, не помогает с необходимой операцией записи.
• Переходный период перед заменой: если систему заменят через год-два, чистая интеграция часто уже не окупается. Робот, сознательно построенный как одноразовое решение, в этом случае становится более честной инвестицией.

Последний пункт регулярно упускают из виду: этот подход — легитимная переходная технология. Проблемой он становится только тогда, когда мост превращается в постоянное состояние и уже никто не помнит, зачем он там стоит. Сам вопрос выбора инструмента мы разобрали в нашем практическом сравнении n8n и Power Automate.

Тогда в расчет нужно включить и лицензионные расходы, которые отпадают при варианте с API. В Power Automate каждой машине, неконтролируемо выполняющей десктоп-потоки, требуется лицензия Process, а для Microsoft 365 дополнительно лицензия Unattended (Microsoft Learn). С точки зрения лицензирования робот — это еще один пользователь. Компоненты лицензий UiPath мы разобрали в статье лицензии UiPath для среднего бизнеса.

Как проверить, действительно ли интерфейса нет?

Перед любым решением о внедрении RPA стоит проверка, которая обычно занимает полчаса и регулярно делает робота ненужным. Часто интерфейс есть, просто он называется иначе. Прояснить это помогают четыре вопроса:

• Что говорит документация производителя? API-модули часто появляются в технической документации задолго до того, как попадают в коммерческое предложение.
• Есть ли экспорт данных? самый непритязательный интерфейс — это запланированный экспорт в CSV или XML. Он стабилен, задокументирован и ничего не стоит.
• Возможен ли доступ к базе данных только для чтения? для отчетности этого зачастую вполне достаточно.
• Сколько стоит модуль интерфейса? как разовая затрата он часто дешевле, чем три года обслуживания робота.

Если решение все же принимается в пользу робота, обоснование должно быть зафиксировано письменно. Для одной муниципальной администрации мы представили именно такую проверку в июле 2026 года и не рекомендовали делать RPA основой стратегии автоматизации: да как точечное дополнение, нет как основа. Инструмент был не плох, он просто не подходил для задачи. Эта проверка и есть подлинное содержание консалтинга по интерфейсам и интеграции.

Часто задаваемые вопросы

В чем разница между screen scraping и web scraping?

Web scraping считывает содержимое веб-страниц, как правило через исходный HTML-код, и для этого не нужен видимый интерфейс. Screen scraping управляет приложением так, как его видит человек, и охватывает настольные программы, терминальные и Citrix-сессии.

Разрешен ли screen scraping?

Технически да, с точки зрения договора зависит от условий. Некоторые производители ПО исключают автоматизированное управление в своих условиях использования или привязывают его к дополнительным лицензиям. Перед созданием робота следует проверить лицензионные условия целевой системы, в сомнительных случаях — с юридической консультацией.

Действительно ли screen scraping ломается при каждом обновлении?

Нет, но риск нельзя устранить программным путем. Обновление, которое меняет только бизнес-логику, оставляет робота нетронутым. Как только смещаются подписи, структура окна или ID элементов, селекторы хватаются за пустоту. Тот, кто использует RPA, поэтому закладывает обслуживание в план заранее, а не рассматривает его как внештатную ситуацию.

Решают ли проблему селекторы на основе ИИ?

Они смягчают ее, но не устраняют. Такие производители, как UiPath, работают над селекторами, которые распознают элемент по его значению, а не по положению. Это снижает затраты на обслуживание, но не меняет того факта, что автоматизация зависит от интерфейса, стабильность которого никто не гарантирует по договору.