RRPA Framework - библиотека с открытым исходным кодом на Python, предназначенная для разработки RPA-роботов.
Client RRPA App - демонстрационная реализация клиентского приложения на основе фреймворка RedRPA.
Server RRPA App - демонстрационная реализация серверного приложения на основе фреймворка RedRPA.
- Проект RedRpa
- Состав проекта
- Описание
- Ядро. SDK. Язык сценариев
- Ядро. SDK. Компилятор
- Ядро. SDK. REX
- Ядро. SDK. Red Virtual Machine
- Ядро. SDK. Набор библиотек языка RSL
- Ядро. Криптография
- Ядро. Работа с сетью
- Ядро. Политики взаимодействия
- Внешние модули. Машинное зрение
- Внешние модули. Модуль взаимодействия с Windows
- Внешние модули. Модуль взаимодействия с Web - окружением
- Правила именования
- Демонстрация работы
В проекте реализованы:
-
RRPA - Framework.
1.1. Сетевые протоколы и менеджер работы с сетью.
1.2. Шифрование (RSA, AES512) и хэширование (ГОСТ 34.11).
1.3. Комплект средств разработки сценариев (SDK - Scenario Development Kit).
-
Компилятор языка сценариев RSL (Red Scenario Language) RSLc.
-
Набор стандартных библиотек языка RSL.
-
Виртуальная машина (RVM - Red Virtual Machine).
1.4. Модуль машинного зрения на основе нейронной сети (OpenCV + Tensorflow + Tesseract OCR).
1.5. Модуль взаимодействия с Web - окружением (Selenium Web Driver).
1.6. Модуль взаимодействия с Windows (WinAPI + PyWin32).
-
-
Клиентское приложение.
-
Серверное приложение.
Структура библиотеки представляет из себя "связку" Ядра (Core) и внешних модулей (External Modules). Ядро в свою очередь будет состоять из внутренних модулей и включать в себя основные абстракции для обеспечения гибкости, расширяемости и взаимозаменяемости внешних и внутренних модулей, а также платформо-независимые и независящие от внешних библиотек механизмы, обеспечивающие функционирование фреймворка (шифрование, хеширование, сетевые функции, компилятор, виртуальная машина, логирование и система исключений).
Подсистема внешних модулей будет включать в себя платформо-зависимые и реализуемые с помощью сторонних библиотек механизмы:
- модуль для взаимодействия с Windows,
- модуль взаимодействия с Web-окружением,
- модуль компьютерного зрения.
Ниже представленна грамматика языка RSL в расширенной форме Бэкуса-Наура.
SCENARIO := LINES
LINES := LINE | LINES
LINE := SPECIAL_INSTRUCTION | FUNC_DEFINITION | EXPR, ENDLINE
EXPR := ASSIGMENT | FUNC_CALL
SPECIAL_INSTRUCTION := LOOP | RETURN
ASSIGMENT := OBJECT, ASSIGMENT_OPERATION, (EXPR | LITERAL | OBJECT)
FUNC_CALL := OBJECT, FUNC_CALL_ARG_LIST
FUNC_DEFINITION := FUNC_DEFINITION_HEADER, FUNC_DEFINITION_BODY
FUNC_DEFINITION_HEADER := function, TEXT, FUNC_DEF_ARG_LIST
FUNC_DEF_ARG_LIST := SUBEXPR_START, {(FUNC_DEF_ARG[ARG_DELIMITER])}, SUBEXPR_END
FUNC_DEF_ARG := OBJECT
FUNC_DEFINITION_BODY := BODY
FUNC_CALL_ARG_LIST := SUBEXPR_START, {(FUNC_CALL_ARG[ARG_DELIMITER])}, SUBEXPR_END
FUNC_CALL_ARG := STANDART_CALL_ARG
RETURN := return, [RETURN_ARG], ENDLINE
RETURN_ARG := STANDART_CALL_ARG
STANDART_CALL_ARG := FUNC_CALL | OBJECT | LITERAL
LOOP := LOOP_HEADER, LOOP_BODY
LOOP_HEADER := loop, SUBEXPR_START, LOOP_HEADER_ARG, SUBEXPR_END
LOOP_HEADER_ARG := NUMBER | FUNC_CALL | OBJECT
LOOP_BODY := BODY
BODY := BODY_START, BODY_LINES, BODY_END
BODY_LINES := {BODY_LINE}
BODY_LINE := SPECIAL_INSTRUCTION | EXPR, ENDLINE
OBJECT := RESERVED_NAMES | USER_OBJECT
USER_OBJECT := TEXT
LITERAL := ", TEXT, " | NUMBER
TEXT := {CHARACTER}, {NUMBER} | TEXT
NUMBER := [SIGN]{DIGIT} | [SIGN]{DIGIT}, ., {DIGIT}
SUBEXPR_START := (
SUBEXPR_END := )
BODY_START := {
BODY_END := }
ARG_DELIMITER := ,
ASSIGMENT_OPERATION := =
ENDLINE := ;
SIGN := -
RESERVED_NAMES := стандартные функции (CV_scan, click_on_object...)
CHARACTER := алфавит(a,b...)
DIGIT := цифры(0,1,2...)
Основными конструкциями языка являются:
SPECIAL_INSTRUCTION- "специальные" встроенные инструкцииloop,return(цикл, и возврат значения из функции соотвественно).FUNC_DEFINITION- ключевое словоfunction, используемое для определения функций в пользовательском коде.EXPR- так называемое "выражение". Под выражение понимается либо операция присвоенияa = foo(),a = 5.
Все имена (функции, переменные) в грамматике языка представлены в конструкцией OBJECT.
RSL также поддерживает числовые (целые и с плавающей точкой) и строковые литералы.
Пример сценарий на языке RSL:
function foo(a, b){
b = a = 42;
return b;
}
c = 3;
loop(2){
c = foo(c, 1);
}
RSLC - Red Scenario Language Compiler.
Компиляция состоит из 6 этапов:
- Лексический анализ.
- Синтаксический анализ.
- Семантический анализ.
- Процесс связывание имён.
- Трансляция.
- Линковка.
| Этап компиляции | Выходные данные |
|---|---|
| Лексический анализ | Массив лексемм (токенов) / список лексических ошибок |
| Синтаксический анализ | Абстрактное синтаксическое дерево (далее - AST) / список синтаксических ошибок |
| Семантический анализ | AST / список семантических ошибок |
| Процесс связывание имён | AST + секции импорта и инициализации / список ошибок процесса связывания имён |
| Трансляция | Секция пользовательского кода |
| Линковка | REX - Red Executable |
REX - является исполняемым файлом Red Virtual Machine. Структура файла являет собой секции (по-умолчанию 4).
- Секция информации.
- Секция импорта.
- Секция инициализации.
- Секция пользовательского кода.
Секция информации содержит в себе метаданные о исполняемом файле (хэш остальных секций, номер версии, стандарт реализации) и генерируются после создания всех остальных секций.
Секции импорта и инициализации генерируются в процессе компиляции на этапе связывания имён - предназначение этих секций довольно очевидно (они содержат данные о подключаемых модулях, и их инициализации соотвественно).
Секция пользовательского кода содержит скомпилированный код языка RSL (что тоже довольно очевидно). Секции представлены в виде json - структуры.
RVM принимает на вход файлы формата REX и анализирует их. Первоначально производится контроль целостности файла путем сравнения хэшей. Если хэши совпадают производится импорт требуемых модулей из секции импорта выполняемого REX.
Далее секции импорта, инициализации и пользовательского когда передаются на выполнение. В данном случае выполнением занимается Python, так как RSL по-умолчанию транслируется именно в него.
На данный момент в фреймворке реализованы три библиотеки языка RSL:
- Универсальная (на основе машинного зрения) - позволяет работать с любыми приложениями.
- Web - позволяет взаимодействовать с Web - приложениями.
- General - набор общих функций, не связанных с автоматизацией напрямую.
В библиотеку по умолчанию включены реализации двух алгоритмов шифрования: AES и RSA. Оба этих алгоритма используются в сетевом модуле для защищенной передачи данных. Общая идея описана ниже:
- Алиса генерирует RSA – ключи и отправляет публичный ключ Бобу по незащищенному каналу связи.
- Боб получив публичный ключ RSA, генерирует сессионный AES – ключ, шифрует его с помощью полученного RSA – ключа и отправляет Алисе (уже по защищенному RSA каналу связи).
- Алиса получает зашифрованный AES – ключ, расшифровывает его с помощью приватного RSA – ключа и сохраняет у себя.
- Далее «общение» между ними происходит по защищенному, с помощью двух алгоритмов (RSA + AES) каналу связи.
Хэш-функцией по-умолчанию в данной реализации является ГОСТ 34.11 "Стрибог" в реализации Олега Казимирова на языке C. Для имлементирования в программу на языке Python была написана небольшая DLL-обертка.
За основу взята оптимизированная реализация, на предвычисленных таблицах значений.
Для работы с сетью были реализованы "менеджеры":
- Менеджер клиентских подключений.
- Менеджер серверных подключений.
- Сетевой менеджер.
Как нетрудно догадаться клиентский и серверный менеджеры предназначены для клиента и сервера соответсенно. Сетевой менеджер является абстракцией более высокого уровня абстрагируя данные термины при работе с ним.
В «зону ответственности» этих самых менеджеров входят:
- Контроль целостности передаваемых данных.
- Установка соединения между пользователями сети.
- Инициализация защищенного канала.
- Шифрование/дешифрование потока данных.
Для инициализация защищенного канала будет использоваться связка криптоалгоритмов RSA + AES. Шифрование/дешифрование потока данных как следствие также будет использовать данную связку. Для контроля целостности будет использоваться хэш-функция "Стрибог", описанная ранее в пункте Хэширование.
Для обеспечения гибкости и настраевомости данных менеджеров используются классы политик, а именно у менеджеров есть два вида политик:
- Политика передача данных уровня приложения.
- Политика передачи данных транспортного уровня.
См. более подробно в пункте "Политики взаимодействия".
Все вышеописанное подводит нас к некой унификации формата передаваемых данных.
Для стандартизации передаваемых данных был разработан протокол RDTP - Red Data Transfer Protocol, описывающий структуру передаваемых данных:
- Тип операции.
- Данные.
- Хэш.
В «разрезе» протокол представляется в виде строковых символов, разделенных двоеточием по частям, описанным ниже (Тип операции:Данные в строковом формате:Хеш).
Перед вычислением хэша, и как следствие перед непостредственной транспортировкой, секция данных подвергается кодированию в base64. Это требуется для устранения ситуаций когда в передаваемых данных могут присутствовать недопустимые символы (двоеточие) и/или использоваться различные кодировки на принимающей и отправляющей сторонах.
Если с данными и хешем все довольно понятно и очевидно, то что такое "тип операции"? Под этими словами скрываются коды различных взаимодействий:
- Начало сессии связи
- Информационные сообщения
- Удаленное выполнение сценариев
- Обновление сессионных ключей
- Конец сесси связи
Здесь может представлять интерес только операция "Обновление сессионых ключей" данный протокол предназначен для запуска алгоритма описанного ранее в пункте Шифрование, начиная с пункта 2.
Политики взаимодействия призваны решить проблему расширяемости и гибкости фреймворка. Сейчас используется 3 подвида политик:
- Политики компиляции.
- Политики виртуальной машины.
- Политики сетевого взаимодействия.
В свою же очередь политики компиляции подразделяются по этапам компиляции:
-
Политики связывания имён
1.1 Политика импорта
1.2 Политика инициализации
-
Политики трансляции
2.1 Политика трансляции имён
2.2 Политика трансляции смещений
2.3 Политика трансляции узлов
-
Политики линковки
3.1 Политика линковки
-
Общие политики компиляции
4.1 Политика обработки ошибок
4.2 Политика компиляции
Политика трансляции имён будет определять имена переменных после процесса трансляции, политика трансляции смещения задавать правила формирования отступов (ведь в выходной язык может зависеть от смещения от края страниц, как Python), политика трансляции узлов будет задавать общие правила для трансляции узлов абстрактного синтаксического дерева в выходной язык (порядок и синтаксис их трансляции).
Линкер, имеет всего одну политику, и не сложно догадаться, что это политика линковки, по умолчанию она будет линковать сгенерированные секции в REX (Red Executable).
Политика обработки ошибок, по-умолчанию, будет останавливать компиляцию и вызывать исключение.
Политика виртуальной машины определяет пути импорта для библиотек требуемых в определенном REX.
Работа с сетью обладает куда большим потенциалом для гибкости и расширяемости, чем виртуальная машина, это и отражено в количестве политик, предназначенных для сетевого модуля. Их можно разделить на две категории:
-
Политики уровня приложения.
-
Политики транспортного уровня.
Просвещенный читатель может заметить сходство между терминологиями категорий сетевые политик и уровнями модели OSI, спешу заверить, что сходство только внешнее. Во-первых, каждая из представленных выше категорий политик имеет в себе еще две подкатегории: политика отправки и политика получения данных. Во-вторых, по терминологии модели OSI транспортный уровень занимают протоколы транспортного уровня (TCP, UDP), а к уровню приложений (прикладному) относятся такие протоколы, как HTTP. Но в нашей терминологии HTTP может быть, как политикой уровня приложения, так и транспортной политикой. Рассмотрим категории политик более подробно: политика транспортного уровня определяет «транспорт» для передаваемых данных, то есть она может имплементацией как TCP, так и HTTP, как уже было сказано ранее. По умолчанию в нашем фреймворке в качестве политики транспортного уровня будет использоваться TCP.
Политика же уровня приложения будет определять формат подключений и обмена данными и опять же может быть имплементирована в виде HTTP, но уже не получится использовать чистый TCP, ведь он просто не располагает такими возможностями. По умолчанию политика транспортного уровня определяет формат подключения как защищенный канал (описанный в главе «Сетевые менеджеры»), а также определяет формат обмена размерами посылаемых сообщений протокола – размер посылается в незашифрованном виде в первых четырех байтах сообщения.
Подкатегории данных политики (политики отправки и получения данных) для обеих категорий являются имплементациями для серверного и клиентского менеджеров соответственно. Итак, финальный вид сетевых политик следующий:
-
Политики уровня приложения.
1.1 Политика отправки данных.
1.2 Политика получения данных.
-
Политики транспортного уровня.
2.1 Политика отправки данных.
2.2 Политика получения данных.
Формально процесс поиска объекта на изображении можно разбить на 3 этапа:
- Поиск «шаблонов» объекта на изображении.
- Определение класса «шаблона».
- Присвоение идентификатора распознанному объекту.
С первыми двумя этапами не возникает сложностей в понимании, стоит обратить внимание на 3 пункт, в нашем случае «Присвоение идентификатора» будет являться распознаванием текста с полученного объекта.
Поиск прообраза (шаблона) осуществляется с помощью OpenCV и метода findCountors настроенного на поиск полей ввода и кнопок. После к каждому найденному прообразу будет применяться нейронная модель (разработанная на Tensorflow, набор данных собран вручную). Для распознавания идентификатора будет использоваться метод оптического распознавания символов (OCR) и библиотека Tesseract-OCR.
Для хранения промежуточных значений используются дескрипторы объектов:
- Template descriptor - хранит в себе координаты шаблона.
- Object descriptor - хранит дескриптор шаблона, а также его класс (кнопка, поле ввода).
- Text object descritor - хранит дескриптор объекта и распознанный идентификатор (текст).
Данный модуль содержит в себе два подмодуля: Actions и Tools.
Подмодуль Actions будет абстрагировать работу с низкоуровневыми механизмами операционной системы и содержать два класса Object actions и Window actions – абстрагирующие действия с объектами окна и окнами соответственно.
В подмодуле Tools будут содержаться классы для оперируемых объектов окон (кнопки и поля ввода), а также абстракции для окна, менеджера окон и набора инструментов специфичных для операционной системы, облегчающие взаимодействия с ней.
Пространство имён Win Objects, будет реализовывать абстракции для объектов окна (кнопок и полей ввода), а также реализовывать функции для взаимодействия с ними, посредством подмодуля Actions и класса Object actions, содержащего функции для взаимодействия с объектами.
Класс Window предоставляет возможности для работы с окном, как с объектом операционной системы, а не окном для 
Данный модуль похож по структуре на модуль взаимодействия с ОС, описанный выше.
Из отличий, появился еще один тип объекта для взаимодействия - ссылка (Link), а также убраны ненужные в данном контексте опции (нажатие правой кнопки мыши, так как для веб-браузера это действие бессмысленно).
«Внутренняя кухня» модуля осталась прежней: класс Web Page является представлением веб-страницы в обычном понимании, а Web Page Manager являет собой абстракцию для нашего фреймворка, и хранит в себе пул уже использованных объектов и предоставляет интерфейс для взаимодействия с веб-страницей из вне.
Для обеспечения единообразия всего фреймворка рекомендуется использовать следующую систему имён. Все абстрактные классы, расположенные в модуле Core/Abstract должны начинаться со слова Abstract. А реализации, включенные в сборку данного фреймворка иметь префикс STD (STD – стандартная реализация, при разработке сторонних внешних модулей стоит добавлять префикс, определенный правилами именования модуля).
Ниже представлен пример работы клиентского и серверного приложения со следующим сценарием:
CV_scan("Конфигурация");
click_on_object("Конфигурация", "Первая");
wait(1);
click_on_object("Конфигурация", "Вторая");
wait(1);
click_on_object("Конфигурация", "Третья");
wait(1);
CV_scan("Конфигурация");
click_on_object("Конфигурация", "Справочник три");
wait(1);
CV_scan("Конфигурация");
click_on_object("Конфигурация", "Создать");
wait(1);
CV_scan("Справочник три (создание)");
input_text("Справочник три (создание)", "Наименование", "object for test");
wait(1);
click_on_points("Справочник три (создание)", 80, 60);
web_open("https://google.com", "g");
web_scan("g");
web_click("g","Почта");
web_close("g");
wait(1);
CV_scan("data:, - Google Chrome");
wait(1);
click_on_points("data:, - Google Chrome", 1000, 18);