power automate - хорошее решение роботизации, но на текущий момент имеет множество ограничений (гораздо больше ограничений, чем у Ui Path). Про сравнение с pyOpenRPA не говорю, потому что у последнего максимальные возможности и гибкость. Для решения локальных одиночных задач power automate должно хватить. Для создания инфраструктуры из одновременно работающих десятков роботов - будут ощутимые сложности.
Спасибо за хорошую и качественную статью! На тему программной роботизации RPA рекомендую решение pyOpenRPA.
Открытый код, максимальная производительность, никакого vendor lock-in, максимальная совместимость с топовыми библиотеками AI, ML, OCR, VOICE, BIG DATA в рамках всей экосистемы Python!
Очень хороший вопрос! Я бы сказал так, что речь необязательно про Продуктовую модель. Дело всё в том, что у Продуктовой модели есть свои плюсы и минусы. Ровно как и у проектной модели. Но при этом, и там, и там можно выделять те самые MVP, что скажется позитивно в обоих случаях.
В призме своего опыта я бы сказал так, что определять модель, в первую очередь надо оглядываясь на уровень зрелости и развития компании. И от того, как эти модели воспринимают остальные сотрудники. У меня перед глазами не так далеко пример внедрения методологии SAFe в крупной компании. Сама методология нормальная, и она позволяет извлечь множество пользы, но из-за разностороннего восприятия этой модели сотрудниками внутри компании, получается не то, что хотелось бы. Также и с продуктовой/проектной моделью, как мне кажется.
@conopus Спасибо за предложение. Прекрасно знаю про этот Framework. Рекомендую погрузиться подробнее в pyOpenRPA. Если вы используете Robot Framework, то будете приятно удивлены еще более простой структуре pyOpenRPA. К сожалению Framework, про который Вы говорите, обладает рядом технических ограничений, которые препятствуют гибкому и динамичному развитию архитектуры роботизации. В качестве одной из причин могу назвать, что для Robot Framework требуется создание специальных библиотек-прослоек для использования. Для pyOpenRPA этого делать не нужно. С pyOpenRPA это, и доп. возможности, и доп. быстродействие. Разве не к этому мы все стремимся? Для pyOpenRPA открыть весь набор библиотек Python - никаких библиотек-прослоек, которые тоже умеют сбоить!
Если будет интересно, то могу в качестве отдельной статьи подготовить сравнительный обзор.
Ничего не мешает фиксировать все зависимости корпоративной архитектуры в некотором едином пространстве, в том числе и Ui зависимости. И тесты/автотесты точно также делаются на все виды зависимостей.
По поводу регрессионного тестирования могу дополнить, что наибольшую эффективность (по моему опыту) показывают запуск тестовых версий роботов на псевдозаявках — лучше любого отслеживания зависимостей.
Добрый вечер! На текущий момент мы в своих проектах Роботов лезем в продукты MS Office через com объекты (выходим на уровень VBA). Есть определенные неудобства в связи с тем, что касаемся VBA, но после написания обёрток на 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 целей!
Добрый день! Да, изучал эту библиотеку. У нее, к сожалению, нет функциональности по влезанию в GUI декстопных приложений. В ней можно управлять этими приложениями только косвенно через клавиатуру/мышку/картинки работать.
Спасибо за комментарий! учебная академия: да, ролики на youtube: да, большое комунити: да, бесплатный: к сожалению, не совсем так
Опускается достаточно важный факт, что Ui Path является бесплатным только в случае установки на 1 компьютер — не более. И бесплатная версия не содержит оркестратор (а для промышленных роботов это достаточно существенный компонент, да и роботов гораздо больше чем 1).
Как вариант тут можно тоже рассматривать всякие конструкции. Например, можно использовать UI Path community версию для написания одного робота, а администрировать его бесплатным оркестратором pyOpenRPA :)
Спасибо за развернутый комментарий! Некоторые тезисы субъективны и являются характеристикой личного отношения, но в целом этот коммент для меня очень полезен, так как на текущий момент я активно работаю над методичкой «IT4Business», в которой я привожу многие наиболее популярные тезисы IT, рассматриваю их плюсы и минусы.
Абсолютно согласен — тема с координатами иногда супер актуальна. Собственно про нее я тоже буду писать, когда зайдет речь о манипуляции мышь + клавиатура (кнопки, hotkeys и т.д.)
По поводу GUI окон еще могу добавить, что иногда спасает 2-й способ адресации — uia. То есть, если win32 не видит тех полей/кнопок, которые мне нужны, то достаточно часто их видит uia. Буду рад, если где-то это вам пригодится! :)
Опен РПА - они ранее про нее писали: https://vk.com/wall-204555031_1879
power automate - хорошее решение роботизации, но на текущий момент имеет множество ограничений (гораздо больше ограничений, чем у Ui Path). Про сравнение с pyOpenRPA не говорю, потому что у последнего максимальные возможности и гибкость. Для решения локальных одиночных задач power automate должно хватить. Для создания инфраструктуры из одновременно работающих десятков роботов - будут ощутимые сложности.
Спасибо за хорошую и качественную статью! На тему программной роботизации RPA рекомендую решение pyOpenRPA.
Открытый код, максимальная производительность, никакого vendor lock-in, максимальная совместимость с топовыми библиотеками AI, ML, OCR, VOICE, BIG DATA в рамках всей экосистемы Python!
Очень хороший вопрос! Я бы сказал так, что речь необязательно про Продуктовую модель. Дело всё в том, что у Продуктовой модели есть свои плюсы и минусы. Ровно как и у проектной модели. Но при этом, и там, и там можно выделять те самые MVP, что скажется позитивно в обоих случаях.
В призме своего опыта я бы сказал так, что определять модель, в первую очередь надо оглядываясь на уровень зрелости и развития компании. И от того, как эти модели воспринимают остальные сотрудники. У меня перед глазами не так далеко пример внедрения методологии SAFe в крупной компании. Сама методология нормальная, и она позволяет извлечь множество пользы, но из-за разностороннего восприятия этой модели сотрудниками внутри компании, получается не то, что хотелось бы. Также и с продуктовой/проектной моделью, как мне кажется.
Спасибо!
Ахаха, "влажные фантазии" - шикарный термин! :) Про десяток заявок абсолютно согласен. Прорабатываем вопрос по комплексным заявкам!
@conopus Спасибо за предложение. Прекрасно знаю про этот Framework. Рекомендую погрузиться подробнее в pyOpenRPA. Если вы используете Robot Framework, то будете приятно удивлены еще более простой структуре pyOpenRPA. К сожалению Framework, про который Вы говорите, обладает рядом технических ограничений, которые препятствуют гибкому и динамичному развитию архитектуры роботизации. В качестве одной из причин могу назвать, что для Robot Framework требуется создание специальных библиотек-прослоек для использования. Для pyOpenRPA этого делать не нужно. С pyOpenRPA это, и доп. возможности, и доп. быстродействие. Разве не к этому мы все стремимся? Для pyOpenRPA открыть весь набор библиотек Python - никаких библиотек-прослоек, которые тоже умеют сбоить!
Если будет интересно, то могу в качестве отдельной статьи подготовить сравнительный обзор.
Спасибо!
По поводу регрессионного тестирования могу дополнить, что наибольшую эффективность (по моему опыту) показывают запуск тестовых версий роботов на псевдозаявках — лучше любого отслеживания зависимостей.
Рад, что тема резонансная. Значит потенциал, действительно, огромный. Будем работать в этом направлении еще активнее!
Добрый вечер! На текущий момент мы в своих проектах Роботов лезем в продукты MS Office через com объекты (выходим на уровень VBA). Есть определенные неудобства в связи с тем, что касаемся VBA, но после написания обёрток на 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 целей!
Опускается достаточно важный факт, что Ui Path является бесплатным только в случае установки на 1 компьютер — не более. И бесплатная версия не содержит оркестратор (а для промышленных роботов это достаточно существенный компонент, да и роботов гораздо больше чем 1).
Как вариант тут можно тоже рассматривать всякие конструкции. Например, можно использовать UI Path community версию для написания одного робота, а администрировать его бесплатным оркестратором pyOpenRPA :)
Спасибо!
Спасибо!
По поводу GUI окон еще могу добавить, что иногда спасает 2-й способ адресации — uia. То есть, если win32 не видит тех полей/кнопок, которые мне нужны, то достаточно часто их видит uia. Буду рад, если где-то это вам пригодится! :)