Comments 23
Да, знаю про этих ребят — они тоже делают открытый софт (правда по лиц. MPL-2.0), но они выбрали графический путь как и Ui Path со всеми вытекающими. Надеюсь, что у них получится превзойти платные альтернативы.
А появился их OpenRPA на несколько месяцев позже (это можно сравнить по репозиториям). Но, действительно, возникает путаница из-за того, что название они выбрали такое же.
Есть идея обновить название на OpenRPA Python. Буду благодарен услышать Ваши комментарии по этому поводу. Спасибо!
Лошадь при этом все равно надо будет кормить, а легаси-системы — поддерживать. И RPA тоже поддерживать. При изменении в легаси затраты на переналадку системы удваиваются.
Буду считать RPA злом, уж извините.
Пишите туториал, интересно
А как можно скачать и протестировать данную RPA платформу?
Пишите туториал — посмотрел на репозиторий — проведена неплохая работа по документированию, но для "Хелло-Уорлд", кажется примера нет. Так что ждем! Спасибо !
Да, интересно. Туториал действительно не помешал бы
Опубликовал следующую статью. Как и обещал, первая статья-туториал: habr.com/ru/post/509644
Enjoy :)
Спасибо!
Мне кажется, нужно было привести примеры задач, которые решает OpenRPA и способы их решения, или взять одну задачу, где задействовано несколько элементов платформы и эту задачу разобрать по косточкам, причем максимально понятно для непрограммиста. Одна из целей RPA — дать непрограммисту максимально юзер-френдли решение для автоматизации рутинных задач с кастомизацией логики против кастомизации кода, отсюда все эти гуи и высокоуровневый скриптинг, если вы решили идти другим путем, то это решение для автотестеров скорее, программистам это все не особо надо, а непрограммисты выберут способ попроще.
В любом случае, хочется живой пример, раскрывающий суть решения и его мощь, ну и раз уж есть еще одна такая платформа, то зря не упомянули ее, надо показать отличия, чтобы не путали. Я почти уверен, что большинство просмотров статьи связано с ожиданием что-то прочесть про ту платформу, отсюда так мало комментов, люди закрывают статью, тут голый текст и ссылка на что-то, что они уже, как им кажется, знают.
А название, как вариант — OSRPA. RPA OS, если сделаете целую операционку.)
Проблема 2: Крайне дорогая лицензионная политика продажи этих решений
есть бесплатный UIPath community edition с учебной академией, кучей роликов на ютубе и большими коммьюнити. Точнее он платный, если годовой оборот( или выручка, не помню уже) компании несколько миллионов $
Опускается достаточно важный факт, что Ui Path является бесплатным только в случае установки на 1 компьютер — не более. И бесплатная версия не содержит оркестратор (а для промышленных роботов это достаточно существенный компонент, да и роботов гораздо больше чем 1).
Как вариант тут можно тоже рассматривать всякие конструкции. Например, можно использовать UI Path community версию для написания одного робота, а администрировать его бесплатным оркестратором pyOpenRPA :)
Спасибо!
И бесплатная версия не содержит оркестратор (а для промышленных роботов это достаточно существенный компонент, да и роботов гораздо больше чем 1).
уже содержит, но облачный. В принципе, одного робота для автоматизации 3-5 «рутин» достаточно, на мой взгляд. разделить выполнение по дням недели, как самый простой вариант, или по рабочим часам.
А за популяцию RPA огромный + :)
Особенно явно это проявляется при использовании библиотеки pywinauto для управления десктопным GUI приложением. В этой области была проведено дополнение функциональности библиотеки до того функциональность уровня, который предлагается в лучших RPA платформах (селекторы для GUI приложений, разрядонезависимость, студия создания селектора и др.).
За ссылку на статью спасибо. Но вот здесь немного недопонял. В pywinauto чего-то не хватает? А почему issue не завели? Селекторы там как раз есть — это WindowSpecification, весь верхнеуровневый интерфейс на них построен. Разрядонезависимость — тоже не очень понятно. pywinauto поддерживает 32/64-битные приложения и Python'ы.
Ниже отвечаю на Ваши вопросы:
В pywinauto чего-то не хватает?
pywinauto и pyOpenRPA — это принципиально разные продукты с принципиально разным назначением и поставленными задачами. В pywinauto всего хватает для решения поставленных перед ним задач (+ в карму от меня за этот проект :) ).
pywinauto — это отличная библиотека, которая предоставляет необходимую функциональность для решения своей задачи (работы с GUI). В pyOpenRPA используются возможности pywinauto, а также добавляются новые возможности, которые решают уже другую задачу (упрощают процесс разработки роботов новыми функциями).
В случае pyOpenRPA речь идет про единый пакет функциональности для RPA (GUI, WEB, MOUSE, KEYBOARD, IMAGE, и т.д.), где GUI — это лишь одна из составляющих.
И цель у pyOpenRPA другая, а именно: обеспечить полноценный бесплатный аналог топовых дорогостоящих RPA платформ (UiPath, Blueprism, Automation Anywhere, WinAutomation), а это уже более широкая тема, в которую, в частности, входит GUI.
А почему issue не завели?
А зачем создавать issue в pywinauto, если я не исправляю дефекты pywinauto, а разрабатываю новые возможности pyOpenRPA? pywinauto и pyOpenRPA — это принципиально разные продукты с принципиально разным назначением и поставленными задачами (см. выше).
Селекторы там как раз есть — это WindowSpecification, весь верхнеуровневый интерфейс на них построен
Поддерживаю тезис. Для pyOpenRPA я дообогащаю функциональность селекторов, доведя ее до уровня топовых дорогостоящих RPA платформ (UiPath, Blueprism, Automation Anywhere, WinAutomation). Для pywinauto это и не нужно, потому что у нее изначально нет цели становиться платформой RPA.
Разрядонезависимость — тоже не очень понятно. pywinauto поддерживает 32/64-битные приложения и Python'ы
Поддерживаю тезис. В pyOpenRPA я упростил работу с разной разрядностью, если в рамках одного проекта робота нужно управлять приложениями разных разрядностей. Это было сделано, опять же, для того, чтобы догнать, и перегнать топовые и дорогостоящие RPA платформы (UiPath, Blueprism, Automation Anywhere, WinAutomation)
Еще раз спасибо за разработку библиотеки pywinauto! Ее существование помогло в достижении RPA целей!
Спасибо за разъяснение. И хотя с вашей точки зрения в pywinauto нет серьёзных issues, я всегда смотрю, что можно было бы улучшить или расширить. На статус RPA платформы, конечно, претендовать нет смысла. Но может быть какие-то улучшения в WindowSpecification или для работы с приложениями разной разрядности могли бы попасть в pywinauto? Просто мы потихоньку занимаемся ре-факторингом и наводим порядок в архитектуре (консистентность ключевых слов и properties, и так далее), в том числе удобство реализации новых бэкендов (под Linux и macOS почти готовы, но могут быть и под Windows новые бэкенды в будущем). В общем, я хочу сказать, предложения по расширению pywinauto тоже приветствуются, а не только баг репорты.
RPA дает скорость внедрения, небольшой TOC автоматизации процесса и возможность решать нестандартные задачи.
Оставим за кадром скорость внедрения, предположим что платформа идеально подходит под задачи нашего бизнеса (ха-ха, конечно, но допустим).
А вот с точки зрения TOC и ROI, на мой взгляд, все грустно.
По опыту, для того, чтобы сделать на кастомной разработке автоматизацию, нужен автор этой автоматизации == автору платформы, или существенные усилия со стороны этого автора по документированию, отладке и поддержке платформы.
Если идем по первому сценарию, то про масштабирование можно забыть, силы у человека не бесконечны, плюс все умрет с его уходом на другую должность/работу (или еще хуже, будет на него завязано). Можно сделать несколько процессов, но их поддержка и развитие съедят весь ресурс.
Если по второму, то нужны люди, людям нужны зарплаты, и не очень понятно, как можно получить хоть какую-то экономическую эффективность автоматизации, без продажи самой платформы. Стоимость одного хорошего разработчика в Москве существенно выше чем стоимость лицензий на нескольких готовых роботов, которые поддерживаются, улучшаются и т.д. вендором. А нам еще нужен тестировщик, аналитик, тех писатель, в какой-то момент PM, следить за всем этим безобразием.
И это мы еще на нашей платформе даже процессы не пишем, а только платформу разрабатываем (опять же предположим, что разрабатываем идеально, без багов, проблем и опозданий).
Отсюда же проблема с нестандартными задачами — как только мы выходим за рамки комфорта нашей разработки (любимые всеми нами VDI, ML, CV и OCR требуют отдельных усилий) — у нас не будет ни ресурсов, ни времени, ни сил на то, чтобы это реализовать.
Когда-то, много лет назад, я делал кастомные CMS, а потом мне пришлось поддерживать сайт сделаный на чужой кастомной CMS. Это был очень полезный опыт, меня он многому научил и сэкономил много нервов и времени моим клиентам. Уверен, что опыт разработки своего RPA-решения очень поможет его автору и желаю успехов во всех его начинаниях!
Отказываемся от платных RPA платформ и базируемся на OpenSource (OpenRPA)