С платформы на платформу: трудности перевода
За последние два-три месяца IТ-компания iFellow реализовала несколько проектов миграции с зарубежных платформ RPA на отечественные.
Рассмотрим опыт переноса программных роботов с американской платформы UiPATH на российские платформы PIX, Primo и Sherpa, а также опыт миграции роботов с британской Blue Prism на Sherpa и Primo.
Для меня оказалось довольно неожиданным, что даже для нашей команды, где каждый сотрудник хорошо знает как минимум две платформы RPA, перенос кодовой базы программных роботов — это только половина всех трудозатрат. Остальные 50% приходятся на решение других задач, таких как реверс-инжиниринг кода, перенос пользовательских активностей и работа с оркестратором/мастером.
Если говорить о реверс-инжиниринге кода, то эта задача не слишком важна. Ее решение зависит от качества кода, который нужно будет перенести, и документации. Скажу больше: при некоторых условиях реверс-инжиниринг кода может повлечь за собой риски сохранения на новой платформе неудачных паттернов.
А вот перенос пользовательских активностей — задача очень важная, требующая навыка написания и тестирования кода. Переписывать код лучше до начала переноса программных роботов.
При этом, по нашему наблюдению, в зависимости от языка программирования, который будут использовать разработчики, трудозатраты на перенос пользовательских активностей могут различаться в несколько раз.
Еще более сложной является работа с оркестратором. В неизменном виде перенести его с зарубежной платформы RPA на российскую нельзя, тем не менее, если такая бизнес-задача стоит, можно попробовать до переноса аккуратно скорректировать сначала само решение, а затем — отдельные пользовательские активности.
И после этого наступает финальная стадия миграции — миграция решений с зарубежной RPA-платформы на российскую в No-Code-формате.
Мы сотрудничаем со всеми разработчиками импортонезависимых платформ RPA, регулярно вживую тестируем их решения, развернутые у нас на стенде, в том числе изучаем функционал их инструментов конвертации для переноса селекторов, объектов и паттернов проектирования. И мы видим, что часть задач с помощью конвертеров решается, а для другой части они не подходят.
К примеру, точно получится с помощью конвертеров перенести классический селектор xPath и объектную модель документа с платформы на платформу. Проблемы могут возникнуть только в старых приложениях, где вместо селекторов работают хэндлеры. Для их переноса требуется работа с кодом. Собственно, этот метод применяется для всех платформ, на которые мы мигрируем программных роботов.
С переносом объектов все просто. Стандартные объекты и стандартный функционал переезжают с любой платформы на любую. Нестандартные — кастомные или уникальные (редкие) — элементы конвертером не переносятся, так что все, что вы собирали вручную, вам придется пересобирать заново.
И третье, о чем хотелось бы сказать, — это перенос паттернов проектирования. Инструменты конвертации позволяют перенести стандартные последовательности, стандартные диаграммы, циклы/условия/операторы выбора и так далее, а также стандартные вызовы внешнего кода. Тут могут возникнуть трудности с реализацией паттерна state machine, имеющего индивидуальные особенности в разных платформах RPA. В полном объеме функционал state machine с помощью конверторов перенести нельзя, поскольку аналогичные паттерны в российских платформах просто отсутствуют.
