Архитектура проекта

Трехуровневая архитектура 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-программы

Рассмотрим сценарий загрузки данных на форму, например, десктопного приложения:

1. Запуск клиентского приложения WT-программы – транслятора Workflow Forms.

2. Одним из первых действий транслятора Workflow Forms будет чтение файла конфигурации WorkflowForms.dll.config.
3. Из файла конфигурации среди прочего будут извлечены: - IP-адрес и порт – где расположена серверная часть WT-программы - Путь до стартовой клиентской XML-формы

4. Чтение стартовой клиентской XML-формы.

5. После чтения стартовой клиентской XML-формы, в которой среди прочего наверняка будут XML-конструкции DataConnection, будет осуществлены запросы данных с сервера в соответствии с параметрами, указанными в коде DataConnection (к параметрам DataConnection в первую очередь относятся наименования SQL-запросов, результаты которых требуется получить, и параметры, которые следует в них передать перед выполнением). Запросы (чтобы не путать с SQL-запросами, назовем их WF-запросы) будут отправлены на адрес, ранее прочтенный из файла конфигурации, где расположена серверная часть WT-программы.
6. Серверная часть WT-программы – транслятор Workflow Engine – в первую очередь осуществит аутентификацию пользователя, который к нему обращается.
7. После успешной аутентификации пользователя Workflow Engine определит, на какие именно SQL-запросы аутентифицированный пользователь имеет права, прочитав эти сведения из файла Workflow.xml, из блока прав доступа.
8. Далее Workflow Engine, извлекая из WF-запроса наименования SQL-запросов, результаты которых требуется получить, сравнит извлеченные имена SQL-запросов с перечнем имен SQL-запросов, на выполнение которых пользователь имеет права – другими словами, авторизует пользователя.

9. После успешной авторизации WorkflowEngine разыменует SQL-запросы, результаты которых требуется получить, – другими словами, по именам SQL-запросов получит их текст, который хранится в серверном XML-файле – Workflow.xml.

10. После разыменования SQL-запросов в их тексты будут вставлены параметры, также переданные в WF-запросе.

11. После подстановки параметров SQL-запросы будут отправлены в БД на выполнение. К тому моменту это будет возможно потому, что транслятор WorkflowEngine сразу после запуска, считывая параметры подключения к БД из конфигурационного файла appsettings.json, осуществляет пробное подключение в БД и впоследствии всегда готов выполнять SQL-запросы к БД.
12. Workflow Engine, получив от БД результаты выполнения SQL-запросов, возвращает их на клиентскую часть в качестве ответа на WF-запрос.

13. Workflow Forms, получив данные, располагает и/или использует их на форме тем или иным образом – в соответствии с логикой, заданной в XML-файле клиентской формы интерфейса.