Несмотря на широкую распространенность платформы 1С в России и большое количество разработчиков – автоматизация различных процессов, связанных с этими решениями, может потребовать значительного времени и длиться месяцами.
Основная проблема связана с тем, что все доработки, реализуемые 1С-программистами устанавливаются в лучшем случае поверх чистой конфигурации от самого вендора, а в худшем – на целый пласт других доработок от других разработчиков.
Часто такие надстройки слетают при обновлении версии базовой конфигурации 1С, что требует как минимум их повторного включения, а чаще – повторной разработки с учетом изменения «внутренней кухни» конфигурации от вендора.
Рассказываем о том, как при помощи UI Framework избежать подобных проблем роботизации в 1С. Благодаря этому фреймворку UiPath можно роботизировать процессы, в которых участвует несколько приложений, систем и сайтов, гораздо быстрее, чем при помощи программирования в 1С. Подробности ищите в посте.
Статья написана при поддержке технического эксперта UiPath: Валентина Драздова.
Попытки обойти проблемы 1С «снаружи»
Некоторые разработчики не встраивают свои решения непосредственно в конфигурацию 1С, а создают отдельно стоящие приложения, которые обращаются непосредственно к 1С с использованием интерфейсов COM-объектов или взаимодействуют с сервером 1С через web-сервисы. Как правило, такой подход действительно устраняет проблему при обновлении конфигурации, так как обновление не влияет на внешнее ПО, а интерфейсы COM-объектов и веб-сервисов меняются крайне редко. Недостатком данного подхода является то, что от разработчиков требуется больше компетенций, чем просто программирование в 1С, а следовательно больше затрат на тестирование совместимости, что влечет за собой увеличение общей стоимости проекта.
Роботизация как ключ к быстром изменениям
С тех пор, как в Россию пришли решения на базе RPA – разработчики начали применять данную технологию для роботизации. Важным преимуществом RPA является то, что такие решения не требуют глубоких знаний в профессиональной разработке ПО, а также использования COM-объектов и web-сервисов, RPA-разработчику необходимо лишь показать, как эту задачу делает реальный человек. Таким образом роботизацией могут заниматься те, у кого есть экспертиза не в программировании, а в своем деле, которое требует автоматизации бизнес-процессов.
Вызовы для RPA со стороны 1C
Однако, несмотря на все предоставляемые преимущества, RPA-платформы часто не дают полностью роботизировать любой процесс в 1С. Мы решили разобраться в теме и выявили причины.
Практически все RPA-решения взаимодействуют с интерфейсами одними и теми же способами:
Ориентирование на селекторы (уникальные идентификаторы и структуру вложенности элементов в рамках окна). Это довольно надежный метод, так как он позволяет работать с приложениями даже в тех случаях, когда они не показываются на переднем плане.
Анализ экрана и поиск нужных элементов по изображению искомого элемента с заданной точностью – долгий и ненадежный метод, плохо работает в случае изменения цветовых схем операционной системы и приложений. Так же плохо работает в случаях, когда приложение уходит за рамки экрана или отображается на двух экранах одновременно.
Зашитые координаты кнопок и полей на окнах – самый простой и быстрый метод, но он не работает при использовании других разрешений экрана, ломается при любом изменении расположений элементов интерфейса;
1С – уникальная платформа, которая не следует «чужим» стандартам проектирования, а задает свои собственные. Интерфейс платформы отображается с использованием собственных средств вывода элементов, которые могут выдавать элементам произвольные идентификаторы, а также менять порядок вложенности элементов в зависимости от разных условий.
Многие RPA-разработчики возлагают надежды на веб-версию 1С, так как веб более структурирован и более предсказуем. Однако, даже веб-версия 1С не всегда работает так, как этого может ожидать RPA-разработчик. Точно так же, как в десктоп-версии 1С – в вебе от запуска к запуску могут отличаться идентификаторы, что приведет к некорректной работе робота. Кроме того, сам принцип функционирования веб-версии подразумевает периодическую перезагрузку тех или иных компонентов веб-содержимого, что также может сбить робота с толку. Например, робот может получить таблицу, «запомнить» ее идентификаторы и положение. Но, после фильтрации данных таблицы, ее первоначальные идентификаторы будут работать неправильно, а робот не сможет извлечь из нее информацию.
UI Framework – универсальная таблетка от UiPath
В отличие от множества других RPA-решений платформа UiPath предлагает использовать собственную разработку, которая называется UI Framework. Особенность фреймворка заключается в максимальной абстракции методов взаимодействия, что позволяет применять разные режимы поиска элементов интерфейса, в том числе и комбинации их вариантов для достижения наилучшего результата.
При работе с UI Framework разработчик RPA может выбирать индивидуально для каждого компонента каким именно методом робот будет его искать:
Default – режим «по умолчанию». Использует собственные алгоритмы для анализа элементов управления форм на основании тех самых идентификаторов. Данный метод подходит для большинства приложений.
AA – режим использования средств «Microsoft Active Accessibility». В данном режиме UiPath использует интерфейс «специальных возможностей» Windows, который позволяет людям с плохим зрением взаимодействовать с программами. В основном данный метод наиболее применим для старых приложений, реализованных на чистом WinAPI без применения современных технологий.
UIA – режим использования средств «Microsoft UI Automation». В данном режиме UiPath использует методы доступа, предоставляемые для современных» приложений Windows. Как правило, это приложения, использующие технологии WPF и универсальные приложения Windows (известные так же, как «приложения магазина Windows 8/Windows 10»).
Методики поиска UI Framework надежнее, чем способы с координатами или изображением. Однако, только одного корректного выбора UI Framework недостаточно. Например, на формах ввода документов 1С можно встретить следующую проблему – существует несколько полей, и ни одно поле не помечено специальными идентификаторами. Как результат – после выбора одного поля робот «видит» его в нескольких местах сразу:
Использование разных режимов работы с интерфейсами позволяет достичь более высоких результатов при определении тех или иных компонентов управления в 1С, однако, только их недостаточно, и именно здесь приходят на помощь дополнительные средства:
Поиск по тексту – если элемент управления содержит определенную надпись (или имеется неизменная часть формируемой надписи), RPA-разработчик может указать роботу от UiPath о том, что искомый компонент должен искать именно этот текст.
Якоря – В дополнении к параметрам искомого элемента управления можно добавить информацию об элементе, который находится рядом. Без данного средства крайне сложно реализовать ввод информации в текстовое поле 1С, так как идентификаторы у таких полей меняются постоянно, а текста в них либо нет (если это ввод нового документа), либо он непостоянен (если это получение информации). Якорь позволяет указать на то, что рядом (слева, сверху, по диагонали, итд) с искомым полем должен располагаться еще один элемент, например, надпись или кнопка, которые уже точно содержат фиксированный текст.
При этом UiPath позволяет добавить сразу несколько якорей – специально для тех случаев, когда у вас есть сразу несколько похожих полей на экране.
Поиск по изображению – иногда бывают такие случаи, что робот в 1С может найти два идентичных элемента, даже несмотря на то, что используются якоря. Как правило, такое может произойти, когда у вас имеется, например, поле «Поиск» и кнопка «Поиск». Так как 1С старательно жонглирует параметрами отображаемых элементов управления – робот может не увидеть чем является каждый компонент. В таких случаях имеет смысл включить дополнительную проверку по изображению: изображение кнопки точно будет отличаться от изображения поля.
Повторное использование действий
Скорость создания роботов для 1С явно меньше, чем для большинства других приложений. Чтобы сократить сроки разработки новых процессов, UiPath предоставляет возможности повторного использования существующих разработок.
Сформированные селекторы можно добавить в репозиторий объектов и использовать повторно, тем самым сокращая время на роботизацию одинаковых элементов.
Репозиторий объектов располагается на компьютере разработчика, что дает возможность применять добавленные селекторы во всех проектах, которыми он занимается. Если роботизацией занимается команда разработчиков - имеется возможность создания репозитория в специальной UI-библиотеке. UI-библиотеки можно распространять через оркестратор UiPath, благодаря чему все разработчики и роботы всегда будут иметь доступ к последней версии селекторов.
Помимо хранения репозитория объектов в UI-библиоетках можно создавать такие же последовательности, блок схемы и конечные автоматы, как и в обычных проектах. После публикации и использования - они будут доступны в виде набора готовых активностей. Например, если в нескольких проектах необходимо искать контрагента в 1С - можно выделить этот блок в библиотеку и просто вызывать его. В случае, если в 1С произойдет изменение интерфейса - разработчику достаточно изменить только библиотеку, а не десяток проектов, где необходимо выполнить это действие.
Адаптация к изменениям
При использовании корректного UI Framework, поиска по тексту, якорей и изображений RPA-разработчик может не беспокоиться о том, что в следующем обновлении поле или кнопка поменяет свое расположение – робот будет по-прежнему правильно находить нужные поля и кнопки.
Единственное, что может помешать роботу – изменение подписей у полей и кнопок, или изменение расположений элементов, которые являются якорями. Однако, в этом случае исправление робота занимает короткое время: разработчику необходимо открыть студию, найти нужный блок, где идет работа с полем или кнопкой, исправить якорь в соответствии с изменением интерфейса и опубликовать новую версию. Благодаря возможностям оркестратора UiPath новую версию получат все пользователи сразу после того, как администратор нажмет кнопку «Обновить до новой версии».
Во избежание подобных ситуаций рекомендуется использовать UiPath Test Suite, который позволяет выполнить тестирование совместимости роботов и обновленных интерфейсов до введения новой версии программ на продуктив. Помимо тестирования самих роботов, UiPath Test Suite позволяет вам тестировать любые другие приложения на предмет корректности работы сквозных процессах. Подробнее о UiPath Test Suite вы сможете прочесть в нашем блоге совсем скоро.
Computer Vision — дополнительная таблетка для сложных случаев
Несмотря на большие возможности поиска элементов управления в UI Framework – в платформе 1С существует гораздо больше проблем для RPA-разработчиков, чем изначально можно предположить. Например, одной из сложностей при роботизации 1С являются таблицы. Если с веб-версией таблиц роботы от UiPath справляются очень легко, то вот «волшебные» Windows-таблицы, которые умеют превращаться в деревья, иногда ставят UI Framework в тупик. Однако, там где нельзя получить доступ к данным напрямую техническим способом – имеется возможность использовать компьютерное зрение. Мы уже рассказывали о преимуществах компьютерного зрения при работе с удаленными рабочими столами. Однако, хотим лишь указать на то, что проблема с таблицами и прочими сложностями платформы 1С, отлично решается именно с использованием Computer Vision.
Кейс: как с помощью RPA заносить данные в 1С
В видео показан процесс обработки электронной почты, поступающей от сотрудников склада. Робот комбинирует позиции по контрагентам и договорам, после чего вводит информацию в 1С.
Еще несколько плюсов роботизации 1С с помощью UiPath
Роботы от UiPath ценны тем, что они не ограничивают вас в одном конкретном приложении. Если по поводу того, что «запрограммировать 1С надежнее, чем роботизировать» еще можно поспорить, то с фактом, что благодаря роботам вы можете роботизировать процессы, в которых участвует несколько приложений, систем и сайтов, гораздо быстрее, чем при помощи программирования в 1С – уже сложно не согласиться.
Отдельно стоит отметить движение UiPath в сторону citizen developers, а именно – предоставление бизнес-пользователям, далеким от программирования, возможности самостоятельно делать простых роботов, в том числе и для 1С. Таким образом, когда вашим сотрудникам понадобится роботизация – они смогут сделать ее самостоятельно в короткие сроки не ожидая долгих согласований от отдела разработки (или же привлечения сторонних организаций и фрилансеров).
VaalKIA
Если вам надо по кнопкам прощёлкать, при этом у вас есть доступ к конфигуратору 1С, то непонятно зачем вы занимаетесь таким трешем? Ваш кейс не понятен.
Drazd
Обратите внимание на то, что речь идет про роботизацию, а не программирование. Постараюсь объяснить детальнее, чтобы вам было понятней:
Когда у вас есть компетенции 1С-программиста (или есть такой человек в штате), у вас есть доступ к конфигуратору (не закрытый интегратором), и все, что вам нужно автоматизировать — это только 1С, тогда действительно — вам легче будет написать код в 1С, который будет делать все, что вам нужно.
Когда у вас нет экспертизы в разработке на 1С, нету доступа к редактированию кода, а процесс, который вы хотите автоматизировать, включает в себя не только работу с 1С, но и с другими системами (у которых может не быть внятного API) — возникает вопрос «как мне это сделать?». Ответ прост — использовать роботов (RPA). Вам не нужно быть экспертом в программировании, все что вам нужно — это просто показать роботу как делает свою работу человек: «Открыть 1С, Нажать сюда, потом сюда, ввести данные в эти поля, забрать значение отсюда, открыть другую систему, нажать туда, ввести сюда, итд».
И робот будет делать тоже самое. Робот не лезет ни в какие API, не трогает ваши базы данных, не требует от вас создания и контроля за техническими учетными записями — он просто работает с теми же программами, что и человек.
И вроде все прекрасно, но есть один нюанс — если роботы отлично справляются с большинством приложений/систем/сайтов, то вот с 1С возникают нюансы. И как учитывать эти нюансы — рассказано в данной статье. Надеюсь, теперь для вас более понятен смысл и посыл статьи.
VaalKIA
«Нет доступа к редактированию кода, потому что закрыто вендором»: нет, как только ввели расширения, то стало возможным писать код оставляя замочек на основной кофигурации, не трогая код вендора.
По компетенциям 1С частично соглашусь: хотя любой человек, который знает программирование, легко начнёт работу в 1С, (в противовес: это всё равно, что не смочь написать программу на Бейскике, такого человека и к скриптам подпускать нельзя), тем не менее, надо ещё знать конфигурацию, иначе можно понаделать бед. Однако, программистов 1С очень много и они не сильно дороги, что бы это было каким-то существенным препятствием, а вот иметь компетенции в скриптовании GUI — тоже надо и это тоже не бесплатно, и не понятно где их искать.
Ну и самое главное, я занимался работой через «нажимание» кнопок и скажу, по собственному опыту, что основной недостаток этих вещей, это отсутствие чёткой обратной связи, соответственно, такая программа может продолжить работать, хотя какой-то этап был пропущен или сглючил, в этом случае обычная программа остановится с ошибкой, а тут вам будет долбить по кнопкам обезьяна с админскими правами (или у вас на каждое действие, перезаходит пользователь с другими правами? Это очень медленно).
«Робот не лезет ни в какие API, не трогает ваши базы данных, не требует от вас создания и контроля за»
То есть, лезет — трогает, требует контроля, имея теже админские права, что и человек, которому доверили делать комплексные дела в программе. Это всё равно что админу, при возможности снять HDD и скопировать всю инфу при прямом доступе к железу, петь песни, что у него нет доступа к клавиатуре и монитору, поэтому он не увидит ваши данные.
По факту, учитывание контекста для UI скриптов, занимает столько сил и требует неординарного ума, что гораздо проще написать всё это в коде напрямую, либо постоянно скрипт находится в нерабочем состоянии, потому что-то ещё не учли.
Например, такая задача: создаём документ, сохраняем, переоткрываем переносим в него данные по полям из старого (без функционала «скопировать»), старый документ удаляем. Гарантируете, что будет полная копия всех документов и то что не перенеслось не было удалено и никакие поля не пропустили? Сравните количество телодвижений с программным подходом и такими вещами как транзакция.
P.S. Например, у меня была масса случаев, когда Ctrl+V не прошло, из-за того, что какой-то драйвер системным треем перехватил фокус на доли секунды и тому подобные вещи, хотя во всех точках до и после контроль показал, что фокус есть.
Drazd
Спасибо за такой комментарий, было интересно прочитать ваши сомнения по поводу RPA. На самом деле, с такими сомнениями приходится периодически сталкиваться, так что постараюсь помочь вам избавиться от них:
Действительно, технологий и решений, которые предоставляют возможность именно скрпитования GUI очень много и они, как правило, требуют определенных компетенций — не могу с вами не согласиться. Однако, обращу ваше внимание еще раз на то, что в статье идет речь про RPA, а это уже гораздо больше, чем «скриптование/кликер GUI». И особенно когда речь идет про UiPath.
Тут стоит отметить, что вся настройка робота осуществляется в графическом виде. При чем есть два режима:
И второй режим позволяет взять вашего специалиста, который прекрасно знает свою работу, обучить его (1-2 дня) и дать ему самому настроить робота, который будет делать за него его работу. Конечно, в особо сложных процессах нужна поддержка профессионального разработчика, но вовсе не обязательно, чтобы это был дорогой специалист с огромным опытом. Помимо прочего, если в компании есть IT-специалист, он может пройти бесплатно 1-недельный онлайн курс и стать полноценным RPA-разработчиком (имеются дополнительные углубленные курсы, но это уже по желанию, при необходимости).
Данное замечание нерелевантно для UiPath, о котором идет речь. Если робот не может найти нужную кнопку или не получил отклика от кнопки (не смог нажать), не нашел поля, надписи, или вообще не может определить нужное окно — возникнет ошибка. Эту ошибку можно обработать соответствующим try/catch блоком (да, в графическом режиме он тоже имеется), или же сделать глобальный обработчик ошибок. В общем это уже детали, но главное — дальше робот (сам) не пойдет и вбивать данные «в молоко» не будет.
Важно понимание, что робот — это не программа, которую написали на каком-то языке программирования, а эмулятор человека. Само собой, если у сотрудника, которого он эмулирует, имеется доступ к разным особо чувствительным функциям систем — теоретически робот тоже сможет ими пользоваться. Вот только как робота настроили — так он и работает, никаких шагов влево-вправо. Как указал выше — любое несоответствие ожидания-реальности ведет к возникновению ошибки и остановке выполнения процесса (с уведомлением админов).
Когда же мы программно работаем с API или пишем напрямую в базу данных — сохраняется вероятность того, что мы что-то упустим или недоделаем (если у нас нет высоких компетенций именно в данном API). В случае с роботами — мы не можем случайно пропустить работу с каким-то окном или полем, так как мы просто повторяем все операции за человеком, который делает это каждый день. Единственное, что может пойти не так — это когда этот человек забывает о «редком документе, который приходит раз в месяц, вот его надо еще через другое окошко регистрировать». Но такие случаи и при классической разработке встречаются довольно часто, так что это в целом проблема аналитики, а не разработки.
Странный кейс, если он происходит внутри одной системы. Предположу, что мы говорим о том случае, когда у вас есть документ в одной системе (допустим, клиент оставил заявку на вашем сайте) и на его основании надо сделать аналогичный документ в другой системе (или сразу нескольких системах), в нашем случае — в 1С.
Если такие действия обычно производятся человеком и результат его работы является корректным, то робот, который будет выполнять те же самые действия, что и человек — даст вам 100%-ый результат.
Если же это совсем новая задача/процесс, в котором у вас нет эксперта и у вас имеются прекрасные компетенции в программировании, вы прекрасно знаете API целевой системы — однозначно вы справитесь быстрее, чем если будете применять роботизацию. Но если вы не знаете API, не знаете как все внутри устроено, не уверены, что разные типы документов структурированы одинаково… Как показывает моя практика — изучение всей внутренней кухни какой-либо системы занимает в самом лучшем случае пару дней, но обычно это неделя, а в особых случаях — можно и месяц (суммарно) «убить» на изучение всех тонкостей. А еще надо написать код, отладить, желательно автотесты еще написать и прогнать их.
Настроить робота для такой задачи займет не больше дня (если считать именно разработку с авто-тестами, отладкой, прогоном на тестовом контуре; без них будет быстрей).
Здесь скорее речь о тех случаях, когда у вас все же нет такого человека в штате, брать человека в штат ради одной задачи странно, а нанимать фрилансера — небезопасно (кто будет поддерживать?), а иногда взаимодействие с фрилансерами может быть заблокировано договорными отношениями с интегратором (обращаться к нему по этой задаче будет дольше и дороже, чем роботизировать).
PS: Предлагаю вам зайти на сайт UiPath и скачать бесплатно комьюнити-версию полноценного продукта. Пройдите стартовый курс (займет не больше 4-х часов) и зацените сами на сколько это более удобное решение, чем «скриптинг GUI», с которым, как я понял, вам приходилось сталкиваться.
mikleh
Скажите пожалуйста, как инженер, как бы вы отнеслись к коллеге, у которого возникла задача из своей системы как-то взаимодействовать с веб-сайтом. При этом у него нет компетенции в области HTTP, и он решил эту задачу с помощью такого вот робота, который открывает страничку в браузере и эмулирует действия пользователя?
Drazd
Для того, чтобы хоть как-то отнестись к тому или иному решению — нужен бекграунд и детали.
Если у нас есть реальная потребность (включенная в план разработки) обмениваться информацией с веб-сайтом, у этого веб-сайта имеется открытое (в идеале документированное) API — естественно, такой коллега «получит по шапке».
Но есть другая ситуация, которых очень много по разным компаниям:
«Наша система» разработана полностью в соответствии с исходным планом/потребностями компании, но у нас есть один отдел, где у сотрудников появилась потребность (которой раньше не было) выгружать данные из «нашей системы», проводить с ними какую-то манипуляцию, загружать в другую систему/веб-сайт (или наоборот).
Казалось бы — есть опытные разработчики, которые могут автоматизировать данную работу для наших сотрудников, вот только есть нюансы:
Каждый из перечисленных пунктов замедляет/откладывает процесс автоматизации. Отдельным пунктом стоит то, что на разработку с тестированием, приемкой — уйдет примерно 2-4 недели работы программиста в лучшем случае.
А если мы воспользуемся роботами? Разработчик может прийти к сотруднику, включить средство записи действий UiPath, сотрудник выполнит свой порядок действий за несколько минут, расскажет про нестандартных ситуации… Разработчик возьмет записанный процесс, воспроизведет на своем компьютере, отладит его с учетом нестандартных ситуаций и уже к вечеру того же дня сможет показать сотруднику как робот делает его работу. Само собой, может понадобиться дополнительная отладка с учетом «я еще вспомнил» от сотрудника, но она пройдет довольно быстро, за еще 1-2 дня.
Вот тут мы уже включаем инженера, который не только «гайки крутит», но и экономику считает. И когда мы уже сравниваем условные 3 человеко-дня разработки робота против 10-20 человеко-дней разработки программного кода, то вывод напрашивается сам собой — наш коллега большой молодец. Вместо того, чтобы заниматься этой не очень то критичной проблемой месяц, он сделал ее за 3 дня и теперь может решить еще штук 5 таких же проблем до конца месяца.
Тут, к слову, важно понимание, что роботы — это не затычка для 1-2 задач, это полноценный инструмент для решения вот таких вот проблем с рутиной у сотрудников. Там, где разработка программного кода выходит дороже, чем выгода от этой разработки — спасают именно роботы, так как настраиваются они быстрее, и возврат инвестиций происходит так же в более короткие сроки.
mikleh
Ну вот другими словами у вас вполне обычная точка зрения: это костыли, костыли — это плохо, но иногда приходится.
Моя точка зрения: в 2021 все меньше и меньше мест, где эти костыли оправданы. Разве в какой-нибудь окологосударственной сфере можно столкнуться, или может в дремучем легаси, чтобы не было открытого интерфейса. Вот у вас даже в качестве примера зачем-то выбрана 1С, у которой API (да не один) и открытый и отлично документированный, а вы на нее роботов натравливаете.
Что касается экономического обоснования и экономии человеко-часов, то подход «тяп-ляп и в продакшен» действительно позволяет экономить и деньги и человекочасы. На первых порах. Очень недолго.
Drazd
Позвольте поинтересоваться, где мною хоть раз было написано про костыли? Костыль — это крайне ненадежное обходное решение, которое позволяет решить одну точечную проблему, но при этом ведет к потенциальному возникновению ряда других проблем в будущем.
Если же мы говорим про полноценную платформу роботизации, такую как UiPath — мы говорим о промышленном решении, которое работает в тысячах компаний по всему миру (и сотнях в России). При чем это не какие-нибудь шаражкины конторы, а очень большие солидные компании, в которых требования к качеству, безопасности на очень высоком уровне (например, NASA). Так что ваши слова про «костыли» — однозначно написаны без погружения в тему.
Осмелюсь предположить, что ваша точка зрения основывается на том, что все программы/системы в мире умеют дружиться друг с другом/имеют внятное апи и готовы к взаимной интеграции. Вот только это совсем не так. Как не стараются разработчики — у них никогда не получится сделать «Одно единое приложение, в котором будет работать сотрудник». Исключение, разве что, какая-нибудь касса или инфо-стенды (киоски).
Когда речь идет о реальной работе с реальными документами, реальными ситуациями — людям так или иначе приходится использовать несколько систем/программ/сайтов для достижения хорошего результата. И, как правило, эти системы либо вообще нельзя подружить, либо можно, но только за очень много денег и времени на разработку.
Так что, как бы вам не хотелось, реальный мир устроен немножко иначе, и пока он устроен так — подобную автоматизацию в короткие сроки можно делать только с помощью RPA. Других альтернатив (по крайней мере пока) лично мне неизвестно.
Мне придется вас разочаровать. Несмотря на то, что, вроде бы, количество 1С-программистов у нас в стране большое, на самом деле их реальный процент среди всех разработчиков довольно мал. Как я уже писал выше: RPA, UiPath — это не про «Давайте не будем писать код в 1С, а натравим робота», а про «давайте автоматизируем работу пользователя между несколькими разными приложениями, системами и сайтами».
А так как мы живем в России — среди этих систем очень часто оказывается 1С (и не всегда это основная система, требующая большого количества автоматизации). И проблема здесь в том, что многие RPA-разработчики в принципе не умеют программировать в 1С (а некоторые и вообще не знают как правильно с 1С работать в пользовательском режиме). Благодаря UiPath — им и не надо тратить время на изучение 1С, им надо просто сесть с бухгалтером и записать его действия. Всё. Вот только есть нюансы при роботизации 1С, о которых и рассказано в данной статье.
Если бы вы роботизировали хотя бы один полноценный процесс — вы бы понимали, что «Тяп-ляп» это про что угодно, но только не про UiPath. Рекомендую изучить матчасть, для начала хотя бы почитать другие статьи аккаунта RPAconsultant, а уже потом подумать над тем является ли это «тяп ляп». Иначе ваши слова звучат крайне непрофессионально.
Если вы изучите клиентов UiPath — вы увидите, что большие компании пользуются роботизацией годами, при чем число роботизированных процессов в каждой компании неуклонно растет. А это верный показатель того, что выгода сохраняется не «на первых порах», а надолго.
Если же у вас есть в этом сомнения — послезавтра пройдет митап, где будут выступать представители Российских компаний, в которых роботизация идет полным ходом и все ей полностью довольны. Буду рад видеть вас в слушателях: www.meetup.com/UiPath-RPA-Moscow/events/278450076
mikleh
Вы считаете допустимым в реальной работе какие-то интеграционные задачи в продакшене основывать на пользовательских интерфейсах, которые завтра по желанию разработчика сторонней системы кардинально изменятся? Что, бывают в реальной жизни ситуации когда кто-то гарантирует неизменность пользовательских интерфейсов? Ну тогда у нас с вами ну очень разное представление о продакшене. Возможно я излишне зануден.
Не надо быть 1С-программистом, чтобы прочитать вот это. Или у ваших разработчиков XML-файл определенной структуры сгенерировать не получится?
Drazd
Мир не черно-белый. Всегда есть оттенки серого. И профессионализм — это не готовность писать код для всего на свете, а умение выбирать правильный инструмент для конкретной ситуации. И здесь RPA — это не костыль, а полноценный альтернативный вариант решения проблемы.
Если мы продолжим следовать вашей логике, то точно так же завтра по желанию разработчика актуальные сегодня методы API могут объявить Deprecated и «приплыли».
Если уж мы говорим про промышленную эксплуатацию, то вам точно должно быть известно, что в любой уважающей себя компании перед тем как устанавливать новую версию ПО — ее проверяют на тестовом стенде. Всегда необходимо проверять корректно ли работает само ПО и все интеграции с ним (в том числе роботов) перед тем как устанавливать обновление на продуктив.
Для этих целей у UiPath есть Test Suite, который позволяет настроить большое количество разнообразных тестов для роботов, нацеленных на разные среды. Вот обновили вы ПО на тестовом контуре — просто запускаете тесты и видите результат: Либо все в порядке, либо вам отображаются сведения где именно что сломалось. С этой информацией можно оперативно исправить конкретные проблемы робота при работе с новой версией. И только после того, как вы убеждены в том, что все роботы работают корректно с новой версией ПО — его можно устанавливать на продуктив.
Ну а если вдруг в компании нет практики «Dev-Test-Prod», то здесь можно только пожать плечами и задаться вопросом — отсутствуют ли вообще проблемы при обновлении продуктива? Как показывает моя практика — такого волшебства не бывает.
Если же речь про публично доступные ресурсы, которые меняются без нашего участия и без нашего тестового контура, то, как правило, дается определенный срок, когда можно нажать кнопку «Перейти на старый дизайн». Роботов так же можно очень быстро научить «перед тем как выполнять работу убеждаться, что мы на старом дизайне, а если это не так — нажимать эту кнопку». Таким образом и роботы продолжают работу, и есть время на перепривязку к новому дизайну.
Во-первых об этом надо знать, во-вторых, опять же — вам легко сказать «определенной структуры», а дайте Junior-разработчику разбираться с этой «определенной структурой» и замерьте сколько он будет заниматься этим самым разбором.
И что-то мне подсказывает, что разбираться он будет дольше, чем настраивать робота. И да, разрабатывать роботов могут даже Junior-ы/вчерашние студенты, и эти роботы выполняют свою работу качественно, стабильно и без ошибок (само собой, большой опыт разработки всегда будет в плюс и матерый программист сделает робота лучше, чем вчерашний студент, но это уже другая тема)