Архитектура проекта
Трехуровневая архитектура WT-программы
Любое приложение, построенное на платформе Workflow Technology, – проще говоря, WT-программа – представляет собой трехуровневое клиент-серверное приложение.
Клиентская часть представляет собой:
Для десктопной разработки: приложение Windows.
Для мобильной разработки: Xamarin-приложение под iOS и Android.
Для веб-разработки: Blazor-веб-приложение.
Все три версии клиентских приложений построены на платформе .NET.
Настройки конфигурации приложения Windows вынесены в файл WorkflowForms.dll.config. Основными настройками являются путь до стартовой формы и IP-адрес и порт расположения серверной части.
Серверная часть представляет собой веб-приложение, построенное на платформе .NET, а именно на веб-сервере Kestrel, включенном в ASP.NET Core.
Сервер поддерживает протокол RestWebAPI, что позволят выстроить общение клиентских приложений и сервера через классические API-запросы.
Настройки сервера разбиты на два файла. В файл appsettings.json вынесены настройки доступа к базе данных, временной зоной сервера и другие, а в файл hosting.json – IP-адрес и порт сервера.
В качестве СУБД по умолчанию используется PostgreSQL – одна из наиболее производительных и популярных СУБД.
Состав элементов архитектуры WT-программы
Каждая WT-программа, созданная на базе платформы WT, состоит из элементов:
База данных. В качестве СУБД выступает PostgreSQL;
Серверная часть Workflow Engine (WE) включает:
бинарные файлы;
xml-файл серверной части с описанием SQL-запросов и прав доступа;
Клиентские части Workflow Forms (WF), Workflow MobileForms (WMF), Workflow WebForms (WWF) включают:
бинарные файлы;
xml-файлы форм, файлы ресурсов (картинки, звуки) и файлы шаблонов печатных форм (docx/xlsx).
Бинарные файл WE, WF, WMF и WWF помимо штатных, платформенных, могут быть кастомными – созданными разработчиками для расширения функциональности платформы в конкретном проекте. Для WF это могут быть кастомные команды или графические элементы форм. А для серверной части это могут быть библиотеки, которые отвечают за взаимодействие со сторонними сервисами. Например, отправка данных в Google Analytics или интеграция со сторонней CRM.
Технический сценарий работы WT-программы
Рассмотрим сценарий загрузки данных на форму, например, десктопного приложения:
Запуск клиентского приложения WT-программы – транслятора Workflow Forms.
Одним из первых действий транслятора Workflow Forms будет чтение файла конфигурации WorkflowForms.dll.config.
Из файла конфигурации среди прочего будут извлечены: - IP-адрес и порт – где расположена серверная часть WT-программы - Путь до стартовой клиентской XML-формы
Чтение стартовой клиентской XML-формы.
После чтения стартовой клиентской XML-формы, в которой среди прочего наверняка будут XML-конструкции DataConnection, будет осуществлены запросы данных с сервера в соответствии с параметрами, указанными в коде DataConnection (к параметрам DataConnection в первую очередь относятся наименования SQL-запросов, результаты которых требуется получить, и параметры, которые следует в них передать перед выполнением). Запросы (чтобы не путать с SQL-запросами, назовем их WF-запросы) будут отправлены на адрес, ранее прочтенный из файла конфигурации, где расположена серверная часть WT-программы.
Серверная часть WT-программы – транслятор Workflow Engine – в первую очередь осуществит аутентификацию пользователя, который к нему обращается.
После успешной аутентификации пользователя Workflow Engine определит, на какие именно SQL-запросы аутентифицированный пользователь имеет права, прочитав эти сведения из файла Workflow.xml, из блока прав доступа.
Далее Workflow Engine, извлекая из WF-запроса наименования SQL-запросов, результаты которых требуется получить, сравнит извлеченные имена SQL-запросов с перечнем имен SQL-запросов, на выполнение которых пользователь имеет права – другими словами, авторизует пользователя.
После успешной авторизации WorkflowEngine разыменует SQL-запросы, результаты которых требуется получить, – другими словами, по именам SQL-запросов получит их текст, который хранится в серверном XML-файле – Workflow.xml.
После разыменования SQL-запросов в их тексты будут вставлены параметры, также переданные в WF-запросе.
После подстановки параметров SQL-запросы будут отправлены в БД на выполнение. К тому моменту это будет возможно потому, что транслятор WorkflowEngine сразу после запуска, считывая параметры подключения к БД из конфигурационного файла appsettings.json, осуществляет пробное подключение в БД и впоследствии всегда готов выполнять SQL-запросы к БД.
Workflow Engine, получив от БД результаты выполнения SQL-запросов, возвращает их на клиентскую часть в качестве ответа на WF-запрос.
Workflow Forms, получив данные, располагает и/или использует их на форме тем или иным образом – в соответствии с логикой, заданной в XML-файле клиентской формы интерфейса.
Last updated
