Проект RedRpa

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 - окружением
• Правила именования
• Демонстрация работы

Состав проекта

В проекте реализованы:

1. 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).

2. Клиентское приложение.

3. Серверное приложение.

Описание

Структура библиотеки представляет из себя "связку" Ядра (Core) и внешних модулей (External Modules). Ядро в свою очередь будет состоять из внутренних модулей и включать в себя основные абстракции для обеспечения гибкости, расширяемости и взаимозаменяемости внешних и внутренних модулей, а также платформо-независимые и независящие от внешних библиотек механизмы, обеспечивающие функционирование фреймворка (шифрование, хеширование, сетевые функции, компилятор, виртуальная машина, логирование и система исключений).

Подсистема внешних модулей будет включать в себя платформо-зависимые и реализуемые с помощью сторонних библиотек механизмы:

• модуль для взаимодействия с Windows,
• модуль взаимодействия с Web-окружением,
• модуль компьютерного зрения.

Ядро. SDK. Язык сценариев

Ниже представленна грамматика языка 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);
}

Ядро. SDK. Компилятор

RSLC - Red Scenario Language Compiler.

Компиляция состоит из 6 этапов:

1. Лексический анализ.
2. Синтаксический анализ.
3. Семантический анализ.
4. Процесс связывание имён.
5. Трансляция.
6. Линковка.

Этап компиляции	Выходные данные
Лексический анализ	Массив лексемм (токенов) / список лексических ошибок
Синтаксический анализ	Абстрактное синтаксическое дерево (далее - AST) / список синтаксических ошибок
Семантический анализ	AST / список семантических ошибок
Процесс связывание имён	AST + секции импорта и инициализации / список ошибок процесса связывания имён
Трансляция	Секция пользовательского кода
Линковка	REX - Red Executable

Ядро. SDK. REX

REX - является исполняемым файлом Red Virtual Machine. Структура файла являет собой секции (по-умолчанию 4).

• Секция информации.
• Секция импорта.
• Секция инициализации.
• Секция пользовательского кода.

Секция информации содержит в себе метаданные о исполняемом файле (хэш остальных секций, номер версии, стандарт реализации) и генерируются после создания всех остальных секций.

Секции импорта и инициализации генерируются в процессе компиляции на этапе связывания имён - предназначение этих секций довольно очевидно (они содержат данные о подключаемых модулях, и их инициализации соотвественно).

В секции импорта определяются только модули требуемые для выполнения REX, пути их импорта вычисляются непосредственно перед выполнением внутри RVM.

Секция пользовательского кода содержит скомпилированный код языка RSL (что тоже довольно очевидно). Секции представлены в виде json - структуры.

Ядро. SDK. Red Virtual Machine

RVM принимает на вход файлы формата REX и анализирует их. Первоначально производится контроль целостности файла путем сравнения хэшей. Если хэши совпадают производится импорт требуемых модулей из секции импорта выполняемого REX.

Далее секции импорта, инициализации и пользовательского когда передаются на выполнение. В данном случае выполнением занимается Python, так как RSL по-умолчанию транслируется именно в него.

Ядро. SDK. Набор библиотек языка RSL

На данный момент в фреймворке реализованы три библиотеки языка RSL:

1. Универсальная (на основе машинного зрения) - позволяет работать с любыми приложениями.
2. Web - позволяет взаимодействовать с Web - приложениями.
3. General - набор общих функций, не связанных с автоматизацией напрямую.

Ядро. Криптография

Ядро. Криптография. Шифрование

В библиотеку по умолчанию включены реализации двух алгоритмов шифрования: AES и RSA. Оба этих алгоритма используются в сетевом модуле для защищенной передачи данных. Общая идея описана ниже:

1. Алиса генерирует RSA – ключи и отправляет публичный ключ Бобу по незащищенному каналу связи.
2. Боб получив публичный ключ RSA, генерирует сессионный AES – ключ, шифрует его с помощью полученного RSA – ключа и отправляет Алисе (уже по защищенному RSA каналу связи).
3. Алиса получает зашифрованный AES – ключ, расшифровывает его с помощью приватного RSA – ключа и сохраняет у себя.
4. Далее «общение» между ними происходит по защищенному, с помощью двух алгоритмов (RSA + AES) каналу связи.

Ядро. Криптография. Хэширование

Хэш-функцией по-умолчанию в данной реализации является ГОСТ 34.11 "Стрибог" в реализации Олега Казимирова на языке C. Для имлементирования в программу на языке Python была написана небольшая DLL-обертка.

За основу взята оптимизированная реализация, на предвычисленных таблицах значений.

Ядро. Работа с сетью

Ядро. Работа с сетью. Сетевые менеджеры

Для работы с сетью были реализованы "менеджеры":

• Менеджер клиентских подключений.
• Менеджер серверных подключений.
• Сетевой менеджер.

Как нетрудно догадаться клиентский и серверный менеджеры предназначены для клиента и сервера соответсенно. Сетевой менеджер является абстракцией более высокого уровня абстрагируя данные термины при работе с ним.

В «зону ответственности» этих самых менеджеров входят:

1. Контроль целостности передаваемых данных.
2. Установка соединения между пользователями сети.
3. Инициализация защищенного канала.
4. Шифрование/дешифрование потока данных.

Для инициализация защищенного канала будет использоваться связка криптоалгоритмов RSA + AES. Шифрование/дешифрование потока данных как следствие также будет использовать данную связку. Для контроля целостности будет использоваться хэш-функция "Стрибог", описанная ранее в пункте Хэширование.

Для обеспечения гибкости и настраевомости данных менеджеров используются классы политик, а именно у менеджеров есть два вида политик:

• Политика передача данных уровня приложения.
• Политика передачи данных транспортного уровня.

См. более подробно в пункте "Политики взаимодействия".

Все вышеописанное подводит нас к некой унификации формата передаваемых данных.

Ядро. Работа с сетью. Сетевые протоколы

Для стандартизации передаваемых данных был разработан протокол RDTP - Red Data Transfer Protocol, описывающий структуру передаваемых данных:

1. Тип операции.
2. Данные.
3. Хэш.

В «разрезе» протокол представляется в виде строковых символов, разделенных двоеточием по частям, описанным ниже (Тип операции:Данные в строковом формате:Хеш).

Перед вычислением хэша, и как следствие перед непостредственной транспортировкой, секция данных подвергается кодированию в base64. Это требуется для устранения ситуаций когда в передаваемых данных могут присутствовать недопустимые символы (двоеточие) и/или использоваться различные кодировки на принимающей и отправляющей сторонах.

Если с данными и хешем все довольно понятно и очевидно, то что такое "тип операции"? Под этими словами скрываются коды различных взаимодействий:

• Начало сессии связи
• Информационные сообщения
• Удаленное выполнение сценариев
• Обновление сессионных ключей
• Конец сесси связи

Здесь может представлять интерес только операция "Обновление сессионых ключей" данный протокол предназначен для запуска алгоритма описанного ранее в пункте Шифрование, начиная с пункта 2.

Ядро. Политики взаимодействия

Политики взаимодействия призваны решить проблему расширяемости и гибкости фреймворка. Сейчас используется 3 подвида политик:

• Политики компиляции.
• Политики виртуальной машины.
• Политики сетевого взаимодействия.

В свою же очередь политики компиляции подразделяются по этапам компиляции:

1. Политики связывания имён

   1.1 Политика импорта

   1.2 Политика инициализации

2. Политики трансляции

   2.1 Политика трансляции имён

   2.2 Политика трансляции смещений

   2.3 Политика трансляции узлов

3. Политики линковки

   3.1 Политика линковки

4. Общие политики компиляции

   4.1 Политика обработки ошибок

   4.2 Политика компиляции

Политика трансляции имён будет определять имена переменных после процесса трансляции, политика трансляции смещения задавать правила формирования отступов (ведь в выходной язык может зависеть от смещения от края страниц, как Python), политика трансляции узлов будет задавать общие правила для трансляции узлов абстрактного синтаксического дерева в выходной язык (порядок и синтаксис их трансляции).

Линкер, имеет всего одну политику, и не сложно догадаться, что это политика линковки, по умолчанию она будет линковать сгенерированные секции в REX (Red Executable).

Политика обработки ошибок, по-умолчанию, будет останавливать компиляцию и вызывать исключение.

Политика виртуальной машины определяет пути импорта для библиотек требуемых в определенном REX.

Работа с сетью обладает куда большим потенциалом для гибкости и расширяемости, чем виртуальная машина, это и отражено в количестве политик, предназначенных для сетевого модуля. Их можно разделить на две категории:

1. Политики уровня приложения.

2. Политики транспортного уровня.

Просвещенный читатель может заметить сходство между терминологиями категорий сетевые политик и уровнями модели OSI, спешу заверить, что сходство только внешнее. Во-первых, каждая из представленных выше категорий политик имеет в себе еще две подкатегории: политика отправки и политика получения данных. Во-вторых, по терминологии модели OSI транспортный уровень занимают протоколы транспортного уровня (TCP, UDP), а к уровню приложений (прикладному) относятся такие протоколы, как HTTP. Но в нашей терминологии HTTP может быть, как политикой уровня приложения, так и транспортной политикой. Рассмотрим категории политик более подробно: политика транспортного уровня определяет «транспорт» для передаваемых данных, то есть она может имплементацией как TCP, так и HTTP, как уже было сказано ранее. По умолчанию в нашем фреймворке в качестве политики транспортного уровня будет использоваться TCP.

Политика же уровня приложения будет определять формат подключений и обмена данными и опять же может быть имплементирована в виде HTTP, но уже не получится использовать чистый TCP, ведь он просто не располагает такими возможностями. По умолчанию политика транспортного уровня определяет формат подключения как защищенный канал (описанный в главе «Сетевые менеджеры»), а также определяет формат обмена размерами посылаемых сообщений протокола – размер посылается в незашифрованном виде в первых четырех байтах сообщения.

Подкатегории данных политики (политики отправки и получения данных) для обеих категорий являются имплементациями для серверного и клиентского менеджеров соответственно. Итак, финальный вид сетевых политик следующий:

1. Политики уровня приложения.

   1.1 Политика отправки данных.

   1.2 Политика получения данных.

2. Политики транспортного уровня.

   2.1 Политика отправки данных.

   2.2 Политика получения данных.

Внешние модули. Машинное зрение

Формально процесс поиска объекта на изображении можно разбить на 3 этапа:

1. Поиск «шаблонов» объекта на изображении.
2. Определение класса «шаблона».
3. Присвоение идентификатора распознанному объекту.

С первыми двумя этапами не возникает сложностей в понимании, стоит обратить внимание на 3 пункт, в нашем случае «Присвоение идентификатора» будет являться распознаванием текста с полученного объекта.

Поиск прообраза (шаблона) осуществляется с помощью OpenCV и метода findCountors настроенного на поиск полей ввода и кнопок. После к каждому найденному прообразу будет применяться нейронная модель (разработанная на Tensorflow, набор данных собран вручную). Для распознавания идентификатора будет использоваться метод оптического распознавания символов (OCR) и библиотека Tesseract-OCR.

Для хранения промежуточных значений используются дескрипторы объектов:

• Template descriptor - хранит в себе координаты шаблона.
• Object descriptor - хранит дескриптор шаблона, а также его класс (кнопка, поле ввода).
• Text object descritor - хранит дескриптор объекта и распознанный идентификатор (текст).

Внешние модули. Модуль взаимодействия с Windows

Данный модуль содержит в себе два подмодуля: Actions и Tools.

Подмодуль Actions будет абстрагировать работу с низкоуровневыми механизмами операционной системы и содержать два класса Object actions и Window actions – абстрагирующие действия с объектами окна и окнами соответственно.

В подмодуле Tools будут содержаться классы для оперируемых объектов окон (кнопки и поля ввода), а также абстракции для окна, менеджера окон и набора инструментов специфичных для операционной системы, облегчающие взаимодействия с ней.

Пространство имён Win Objects, будет реализовывать абстракции для объектов окна (кнопок и полей ввода), а также реализовывать функции для взаимодействия с ними, посредством подмодуля Actions и класса Object actions, содержащего функции для взаимодействия с объектами.

Класс Window предоставляет возможности для работы с окном, как с объектом операционной системы, а не окном для фреймворка, в свою же очередь Window Manager, наоборот предоставляет интерфейс для взаимодействия с окном «в стиле» фреймворка. Он хранит в себе пул найденных в окне объектов (Win Objects), а также предоставляет функции для использования их внутри API – библиотек языка RSL.

Внешние модули. Модуль взаимодействия с Web - окружением

Данный модуль похож по структуре на модуль взаимодействия с ОС, описанный выше.

Из отличий, появился еще один тип объекта для взаимодействия - ссылка (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);

2023-06-26-07-37-47.webm