RPA: роботизация процесса регистрации счета. Наиболее полное руководство

[mixsture]

1) вместо запуска конкретной версии 1с, используйте, пожалуйста, стартер. И тогда ваш робот не поломается при каждом обновлении платформы.
2) почему не воспользовались апи oData у 1с? это сразу дает вашей интеграции: гарантированный результат каждого действия, возможность читать и записывать любые данные в базе 1с. Подход RPA на задачах, где уже есть готовое апи — это дорого.
3) управление интерфейсом само по себе очень хрупкое:
а) Может сломаться при смене платформы 1с, но нечасто (иногда 1с меняет внешний вид элементов)
б) если брать «новые» конфигурации от 1с на управляемых формах, то проблем добавляется, т.к. там 1с сдвинулась в сторону адаптивности интерфейса к размеру формы. Поэтому любая кнопка может быть как в видимой части формы, так и прятаться в меню. А в видимой части формы элементы могут менять размер по ширине и взаимоположение (несколько элементов в строку могут разворачиваться в колонку при нехватке места).
в) сам windows может добавить вам проблем, запустив окно в развернутом на полный экран или обычном виде.

[seregei-azarov]

1) Да, согласен, использовать стартер более правильное решение. Я демонстрировал общий принцип запуска приложения. Со стартером все точно так же, только запускаем другой файл.
2) OData позволяет перенести данные, но возможности по запуску каких-то обработок очень ограничены. В нашем случае робот печатает счет, через OData это скорее всего не реализовать.
3) Все верно. Это основной недостаток RPA. Какие-то изменения в интерфейсе, непредусмотренное поведение программ может сломать работу процесса.
Типичная обработка таких ситуаций: во-первых, автоматический перезапуск процесса. Если, например, ошибка была связана временным зависанием программы или каким-то
неожиданно всплывшим окном, то это решит проблему. Если это не помогло, задача эскалируется специалисту. Робот отправляет сообщение о ошибке по электронной почте,
или специалист узнает о ошибке через интерфейс оркестратора, или как в моем примере, BPM-система ставит задачу специалисту проверить робота.
а) RPA подразумевает быстрое моделирование, поэтому при небольших изменениях интерфейса восстановить работу робота можно также быстро.
б) именно поэтому лучше использовать нажатия клавиш или указатели. В большинстве случаев изменение размеров, взаимного расположения, видимость на экране не повлияют на работу процесса.
в) если это будет мешать работе процесса, то можно после загрузки приложения открыть его на полный экран через соответствующее сочетание клавиш.

[comol85]

1) "перемещаясь между полями кнопкой tab" — не надо так делать… Такой "робот" сломается даже не через день…
2) в 1С есть несколько опций интерфейса, даже в обычных формах. Используя инструменты CV практически нет шансов написать робота для продакшн
3) про то что в 1С есть свой нормальный инструмент записи действий пользователя я уж и молчу…
4) можно же наверное как то обойтись и без кода на c#

Вообщем для решения этой задачи намного правильнее хотя бы COM воспользоваться — всё равно код пишите… Или всё таки использовать наивные средства 1С

[seregei-azarov]

1) Как правило порядок обхода полей на форме постоянен, поэтому прием с клавишей tab работает наиболее стабильно. Я имею в виду общий принцип. И говорю не в теории, а о реально работающих роботах в продакшн.
2) Если порядок полей непостоянен, например, он зависит от настроек функциональных опций – можно использовать указатели. Поиск по указателям – это не компьютерное зрение, если понимать под этим поиск области на экране по картинке, это поиск контрола по его атрибутам. Этот способ будет работать и в том случае, если измениться взаимное расположение полей, размер формы и т.д.
3) Инструмент записи действий пользователя предназначен для автоматизированного тестирования. Встанет вопрос как автоматически запускать код теста, как передавать параметры. И после 1С процесс переносит счет в Диадок, где нет этого инструмента. Думаю, что данный кейс с помощью RPA реализовать проще.
4) Совсем без кода этот процесс реализовать нельзя. Он нужен будет при передаче данных счета, для генерации имени файла. Но код тут простейший. Знания, необходимые для его составления, несоизмеримы с квалификацией, нужной для написания прямо интеграции или кода для автоматического тестирования в 1С.

[comol85]

1) После «как правило» начинается обычно самое интересное ;). Конечно он непостоянен — зависит от ролей, функциональных опций, кода формы и настроения разработчиков :). В 1С это 100% меняется. Если у тебя это в проде уже, то как раз самое время пофиксить пока что-нить не навернулось
2) Поиск по контролам в 1С не отработает… ну или отработает неверно. там используется внутренняя библиотека интерфейса, т.е. с точки зрения ОС часть контролов 1С это просто картинки, т.е. одна картинка.
3) Все инструменты использующиеся в RPA, изначально быль для автоматизированного тестирования ;). На выходе там простая xml, при запуске она передаётся в параметрах запуска, параметры в XML подменяешь и всё. Ну это хоть работать более-менее прилично будет. А так вместо контролов лучше бы по COM-у соединился как это в UiPath ребята обычно делают. Криво косо, но меньше рисков что контролом промахнёшься. Лучше уж пусть отвалится чем что-нить не то запишешь.
4) Ну обход коллекции и генерацию имени конечно можно сделать без кода обычно, загляни в академию UiPath — там примеры есть. Но не в этом суть, в коде нет ничего плохого… c# то зачем? Оно ни на js ни на питоне ни на своём псевдоязыке не даёт конструкции писать?