Вкалывают «роботы». А счастлив ли человек?

Нередко в нашей работе требуются данные, выгрузить которые в нужном объёме напрямую из базы данных АС не представляется возможным, или же очень труднореализуемым процессом. На помощь приходят различные программы-«роботы» (кликеры, парсеры, скраперы – как их только не называют), имитирующие действия пользователей. И, казалось бы, слоган «Мы работаем — вы отдыхаете» как никогда актуален, но так ли это на самом деле?

Рассмотрим отрицательные стороны самых простых решений и инструментов на примере парсеров HTML-страниц с помощью VBA, C# и кликеров, написанных на AutoIT и C#.

Начать хотелось бы с языков C# и VBA для парсинга HTML. Самым главным минусом С# является обязательное наличие опыта программирования, так как порог вхождения достаточно высок. Также, в силу того, что язык программирования не адаптирован для решения задач «на коленке», трудозатраты на написание рабочего кода digital-аудитором могут быть нецелесообразными, особенно если выгрузка разовая. Язык VBA в свою очередь для таких задач более прост, но за простотой кроется и ограниченность в возможностях.

Что же касается самого языка HTML, а если конкретно HTML-страниц, то проблемы могут начаться, например, когда вместо стандартного метода submit в элементе INPUT реализована JavaScript-функция, которую стандартными средствами вызвать достаточно сложно либо вовсе невозможно. Ещё одним препятствием работы даже самого оптимального и отлаженного «робота» является изменение кода страниц после обновления АС или в принципе разная структура страниц, визуально одинаковых для пользователя.

Зачастую, учитывая вышеизложенное, в условиях ограниченного времени наиболее подходящим вариантом является не разбор «доступных внутренностей» АС, а прямое повторение действий пользователя путём программного нажатия на различные кнопки и окна на экране. Но и тут не всё так сказочно и гладко, как хотелось бы. Во-первых, если отталкиваться от позиции элемента на экране, можно нарваться на такие неожиданности, как несвоевременное появление нужного окна, постоянное изменение его позиции относительно рабочего стола. Или тот факт, что на разных мониторах позиции элементов разные, и для запуска выгрузки на разных машинах потребуется подгонка кода под конкретный компьютер. Во-вторых, используя в качестве инструмента для кликера язык C#, возникает вопрос опыта программиста, трудозатрат, а также доступности ПО для разработки (Visual Studio 20xx). Ситуацию может исправить специально разработанный для имитации действий пользователя язык сценариев AutoIT. Проблему с позициями на экране этот инструмент помогает решить наличием возможности доступа к свойствам окна и расположенных на этом окне элементов. Правда, из личного опыта стало известно, что, например, если АС написана на платформе .NET, то всё достаточно неплохо, но если базовая платформа – Java, то доступа к элементам нет, только — к окнам. В связи с этим появляется необходимость использования позиций экрана или, где это возможно, имитации нажатия клавиш и их сочетаний.

Приведем один из примеров. В одном из наших проектов изначально для нажатия кнопки мы использовали следующий код:

WinActivate($winName) Local $winPos = WinGetPos($winName) MouseMove($winPos[0]+12, $winPos[1]+44) MouseClick(“left”, $winPos[0]+12, $winPos[1]+44, 1)

Здесь берётся окно ($winName) и его позиция на экране, относительно которой задаются координаты нажатия на кнопку. Этот код исправно работал пока окно появлялось в одном месте. Но на мониторе с другим разрешением координаты сдвигаются и в результате клик мышью происходит мимо. Каждый раз проводить калибровку – не очень удобный вариант. Поэтому было решено использовать горячие клавиши (к счастью, такая возможность была), и код стал проще и короче:

WinActivate($winName) Send(“^{S}”) ; Аналог CTRL+S

Если бы горячие клавиши в АС не поддерживались, то можно было бы попробовать следующий вариант:

WinActivate($winName) Send(“{TAB 3}”) Send(“{ENTER}”)

В нашем случае удалось немного стабилизировать работу выгрузки, но это не всегда возможно сделать в конкретной АС.

Конечно, у всех озвученных средств несомненно есть сильные стороны, многие из них, возможно, перекрывают все освещённые мною в статье недостатки. В реальности же при наличии задачи выгрузки, ограниченной во времени, платой за простоту и скорость решения выступает наличие других ограничений. Ведь как бы «робот» не работал, за ним всё равно должен следить человек, и автоматизация, на деле, оказывается полу-, а то и четверть-автоматизацией.

Существуют различные средства, более совершенные, требующие более высокого уровня компетенций и дополнительного времени на разработку. При этом результат не всегда может быть близок к желаемому. Поэтому вопрос «вкалывают «роботы», а счастлив ли человек?» остаётся открытым.

11
2 комментария

Прискорбно, когда из собственной АС приходится таким способом доставать данные. Обычно так вытаскивают данные из чужих проектов, опубликованных в Интернет. :-)

Ответить
Автор

Спасибо за ваше замечание! Да, порой тоже над этим задумываемся! :-)

Ответить