Pull to refresh

Comments 23

Да, знаю про этих ребят — они тоже делают открытый софт (правда по лиц. MPL-2.0), но они выбрали графический путь как и Ui Path со всеми вытекающими. Надеюсь, что у них получится превзойти платные альтернативы.


А появился их OpenRPA на несколько месяцев позже (это можно сравнить по репозиториям). Но, действительно, возникает путаница из-за того, что название они выбрали такое же.


Есть идея обновить название на OpenRPA Python. Буду благодарен услышать Ваши комментарии по этому поводу. Спасибо!

Сама концепция напоминает тезис «для того, чтобы перевозить грузы быстрее, чем гужевой тягой, давайте посадим лошадь в кузов автомобиля».
Лошадь при этом все равно надо будет кормить, а легаси-системы — поддерживать. И RPA тоже поддерживать. При изменении в легаси затраты на переналадку системы удваиваются.
Буду считать RPA злом, уж извините.

А как можно скачать и протестировать данную RPA платформу?

Пишите туториал — посмотрел на репозиторий — проведена неплохая работа по документированию, но для "Хелло-Уорлд", кажется примера нет. Так что ждем! Спасибо !

Да, интересно. Туториал действительно не помешал бы

Очень рад, что тема для вас интересна. По документирования всей этой истории — сейчас активно этим занимаюсь. К концу лета ожидаю, что по части документирования (RUS + ENG) вопросов возникнуть не должно.

Опубликовал следующую статью. Как и обещал, первая статья-туториал: habr.com/ru/post/509644

Enjoy :)
Все равно остаются проблемы:
— отказоустойчивость;
— система управления такими автоматизациями;
— система управления данными;
— система управления исключениями;
— транзакционность;
— центр компетенции;
— «Энтерпрайзность»;
— отладка решений;
— сертификация безопасности таких приложений.

Автоматизации можно и в макросах написать или Autoit. На сегодняшний момент алгоритм подключения коннекторов и внешних механизмов никак не изменился. Везде одно и то же.

А значит ключевыми остаются вопросы:
— Скорость разработки
— Скорость ввода продукции в прод
— Система и контроль версий(но тут проще)
— Модульность, переиспользование, фишки, плюшки
— подключение и интеграция внешних библиотек
и т.д.

Все делать на питоне… то еще ГМО. Роботизацией, а уж тем более RPA — это сложно назвать.

Однако, смотр в OpenSource — это хороший задел!
Да, среди разработчиков известных монстр-Вендров очень много тех, кто может и хочет кодить в этих продуктах. Но чрезмерное использование кода — приводит к мысли, что что-то ты делаешь неправильно.

Говорить, о том, что не можешь что-то использовать в сценариях — тоже глупо, т.к. тебе ничего не мешает установить последний релиз бесплатной визуальной студии и написать любую активность под свои потребности, хотя Invoke кода в продуктах и так хватает, а значит, скорее всего не хватает возможностей и компетенции именно в этом продукте. И на питоне проще, т.к. только его и знаешь…

На самом деле можно долго обсуждать, что круче платное и полноценное решение или бесплатное «на коленках решение».

P.S. не в коем случае не хотел обидеть. Только конструктивная лирика.

Всех благ в твоем начинании!
Спасибо за развернутый комментарий! Некоторые тезисы субъективны и являются характеристикой личного отношения, но в целом этот коммент для меня очень полезен, так как на текущий момент я активно работаю над методичкой «IT4Business», в которой я привожу многие наиболее популярные тезисы IT, рассматриваю их плюсы и минусы.

Спасибо!

Мне кажется, нужно было привести примеры задач, которые решает OpenRPA и способы их решения, или взять одну задачу, где задействовано несколько элементов платформы и эту задачу разобрать по косточкам, причем максимально понятно для непрограммиста. Одна из целей RPA — дать непрограммисту максимально юзер-френдли решение для автоматизации рутинных задач с кастомизацией логики против кастомизации кода, отсюда все эти гуи и высокоуровневый скриптинг, если вы решили идти другим путем, то это решение для автотестеров скорее, программистам это все не особо надо, а непрограммисты выберут способ попроще.


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


А название, как вариант — OSRPA. RPA OS, если сделаете целую операционку.)

Проблема 2: Крайне дорогая лицензионная политика продажи этих решений

есть бесплатный UIPath community edition с учебной академией, кучей роликов на ютубе и большими коммьюнити. Точнее он платный, если годовой оборот( или выручка, не помню уже) компании несколько миллионов $
Спасибо за комментарий! учебная академия: да, ролики на youtube: да, большое комунити: да, бесплатный: к сожалению, не совсем так

Опускается достаточно важный факт, что 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 чего-то не хватает?
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 тоже приветствуются, а не только баг репорты.

А как бы вы соотнесли позиционирование вашего проекта и Robot Framework? С тем, что делает robocorp.com?
Поддержу Furriest — писать свой RPA без целей его массового применения это, к сожалению, как показывает практика, тупиковый путь.
RPA дает скорость внедрения, небольшой TOC автоматизации процесса и возможность решать нестандартные задачи.

Оставим за кадром скорость внедрения, предположим что платформа идеально подходит под задачи нашего бизнеса (ха-ха, конечно, но допустим).

А вот с точки зрения TOC и ROI, на мой взгляд, все грустно.
По опыту, для того, чтобы сделать на кастомной разработке автоматизацию, нужен автор этой автоматизации == автору платформы, или существенные усилия со стороны этого автора по документированию, отладке и поддержке платформы.

Если идем по первому сценарию, то про масштабирование можно забыть, силы у человека не бесконечны, плюс все умрет с его уходом на другую должность/работу (или еще хуже, будет на него завязано). Можно сделать несколько процессов, но их поддержка и развитие съедят весь ресурс.

Если по второму, то нужны люди, людям нужны зарплаты, и не очень понятно, как можно получить хоть какую-то экономическую эффективность автоматизации, без продажи самой платформы. Стоимость одного хорошего разработчика в Москве существенно выше чем стоимость лицензий на нескольких готовых роботов, которые поддерживаются, улучшаются и т.д. вендором. А нам еще нужен тестировщик, аналитик, тех писатель, в какой-то момент PM, следить за всем этим безобразием.
И это мы еще на нашей платформе даже процессы не пишем, а только платформу разрабатываем (опять же предположим, что разрабатываем идеально, без багов, проблем и опозданий).

Отсюда же проблема с нестандартными задачами — как только мы выходим за рамки комфорта нашей разработки (любимые всеми нами VDI, ML, CV и OCR требуют отдельных усилий) — у нас не будет ни ресурсов, ни времени, ни сил на то, чтобы это реализовать.

Когда-то, много лет назад, я делал кастомные CMS, а потом мне пришлось поддерживать сайт сделаный на чужой кастомной CMS. Это был очень полезный опыт, меня он многому научил и сэкономил много нервов и времени моим клиентам. Уверен, что опыт разработки своего RPA-решения очень поможет его автору и желаю успехов во всех его начинаниях!
Only those users with full accounts are able to leave comments. Log in, please.