English version

XAF позволяет быстро создавать системы корпоративного уровня – за что разработчики и любят этот инструмент. При всем богатстве функционала «из коробки» вопросы «трехуровневой» архитектуры в текущей версии XAF еще слабо проработаны, хотя возможности ее реализации и предусмотрены.
Ниже мы покажем, как реализовать одну из таких возможностей: повысить надежность и эффективность выполнения в системе длительных операций с возможностью масштабирования ресурсов.

Постановка задачи

Для систем корпоративного уровня надежное выполнение длительных операций – одна из важнейших задач. Особенно это актуально для операций и отчетов со временем формирования более 20 минут. Мало того, что подобные операции блокируют клиентскую систему, обрекая пользователей на «простой». Под большим вопросом оказывается и надежность данного сценария: в ходе многочасового формирования отчета клиентский компьютер может зависнуть либо потерять сетевое соединение – и формируемый отчет будет утерян, а время потрачено зря.
Подобные ресурсоемкие операции принято выполнять на высокопроизводительных выделенных серверах: на рабочем компьютере может банально не хватить оперативной памяти для полного построения отчета или выполнения расчета.
Другой сценарий работы – отложенное формирование ресурсоемких отчетов по расписанию с рассылкой результатов пользователям. Например, ночью необходимо автоматически запускать формирование отчетности, чтобы утром менеджеры смогли анализировать уже заранее подготовленные для них отчеты.
Как же решить эту проблему?

Идея сервера расчетов

В ходе создания бизнес-систем автоматизации мы постоянно сталкивались с необходимостью асинхронного выполнения расчетов и отложенного формирования отчетов.
Нам требовалось выполнять расчеты и формировать XAF Report асинхронно и, желательно, на выделенном сервере. Было принято решение о разработке полноценной службы для XAF приложений способной формировать в указанном сценарии.
Вначале мы пытались реализовать данные сервисы с использованием штатного модуля XAF Workflow – но это оказалась не совсем удобным из-за нестабильности работы службы WWF и ее администрирования.
Использование Devexpress Report Server тоже оказалось невозможно: это универсальный продукт, ориентированный на решение общих задач отчетности, и для работы в составе XAF-приложения не предназначен.

Первый шаг, который мы запланировали реализовать – создать сервер отчетов для приложений Xafari (XAF).
Необходимо заметить, что в рамках Xafari есть специальный модуль «Отчетность», существенно расширяющий функционал штатного модуля XAF Reports Module. Так, разработчик в рамках Xafari.Reports может определять:

  • параметры любой структуры и сложности
  • произвольный источник данных
  • алгоритм наполнения источника данных (реализация алгоритма может быть подменена путем настройки системы у заказчика)
  • множество различных шаблонов для одного отчета (XtraReport, Excel, PivotGrid, Files, View, Spreadsheet, RichEdit и т.д. – список шаблонов может быть изменен и расширен при внедрении системы у заказчика)

Поэтому нам требовался сервер отчетов именно для наших «Xafari отчетов».
По итогу анализа и обсуждений для решения задач по асинхронному/отложенному формированию отчетности мы решили реализовать более универсальное решение «Сервер расчетов».

Реализация

Итак, требовалось разработать сервер расчетов – отдельный сервис, обрабатывающий задачи в очереди сообщений и сохраняющий результат в базу данных XAF приложения.
Платформа XAF имеет очень продуманную и гибкую архитектуру и позволяет находить нешаблонные решения благодаря наличию достаточного количества точек расширения. Однако и тут пришлось потратить немало времени и усилий, прежде чем удалось добиться выполнения операций на сервере расчетов из-под учетной записи пользователя, а также обеспечить реальную многопоточную работу сервера. Подробности – ниже.
Удобство XAF заключается в легком и едином подходе к разработке приложений. Те же принципы мы старались сохранить и при использовании сервера расчетов. Прикладной программист при написании алгоритма расчета или дизайне отчета не должен сильно задумываться, где будет исполняться код: на сервере расчетов – либо в приложении на рабочей станции. Если у заказчика есть сервер расчетов, то часть операций может быть перенесена на него.
Нужно было научить общаться клиентское приложение с сервером расчетов. Для этого нам пришлось реализовать очередь сообщений, в которую клиенты генерируют новые задания (сообщения), обрабатывающиеся уже на сервере. Сервер расчетов – отдельный сервис, обрабатывающий задачи в очереди сообщений и сохраняющий результат в базу данных XAF приложения.

diagram_rus

В ходе реализации проекта были решены следующие задачи:

  • Распределенная очередь сообщений
    Конечно, можно было использовать MSMQ, RabbitMQ и другие распространенные сервисы. Однако это существенно усложнило бы развертывание и настройку. Поэтому мы реализовали простой «встроенный» вариант MQ и дополнительно предусмотрели API для возможности подключения и использования внешней службы сообщений.
  • Обработка сообщений очереди и сохранение результатов в БД
    Мы выбрали одну из самых простых возможных схем передачи сообщений, а именно: через общую БД XAF приложения. Это существенно упрощает общую архитектуру и делает ее более прозрачной для XAF разработчиков и администраторов.
  • Сохранение функционала XAF и Xafari
    Было поставлено условие, чтобы все существующие отчеты и бизнес-операции без каких-либо модификаций и дополнительных требований к их кодированию смогли исполняться на сервере Xafari.
  • Многопоточность Xafari Server, пул соединений с БД
    Потребовалось достаточно много усилий, чтобы обеспечить это требование. В этом плане платформа XAF имеет достаточно сложную реализацию – но и задача была не из простых. Огромное спасибо, тем кто создает и поддерживает разделы тикетов и подробную документацию на сайте Devexpress, в которых даны действительно полезные рекомендации и советы.
  • Интеграция с системой безопасности XAF и Xafari
    Еще одна достаточно сложная задача в рамках XAF приложения – начать выполнять операции из-под пользователя, который сформировал задание в очередь сообщений. Это очень важно, т.к. пользователь, запустивший отчет на выполнение, должен получить данные в отчет в соответствии со своими правами и привилегиями, определенными в системе безопасности.
  • Функционал для работы с сообщениями в приложении
    Пришлось разработать целое API для работы с очередью сообщений в клиентском приложении для размещения сообщений в очередь и получения результатов. При этом мы постарались обеспечить возможную подмену функционала в случае необходимости (например – переключение на использование RabbitMQ).
  • Обработка сообщения от имени пользователя
    Вторая часть API для работы с очередью сообщений, но уже для чтения сообщений на сервере расчетов, позволяет обрабатывать сообщение на сервере расчетов от имени пользователя, инициировавшего данное задание.

Удобство использования сервера расчетов заключается в использовании всех преимуществ XAF, хранении сообщений из очереди в БД, а также хранении в ней результатов обработки сообщений. Это позволяет сделать работу прикладного программиста абсолютно «прозрачной».

В целом удалось полностью выполнить поставленные задачи.
Были сомнения, сможем ли мы обеспечить приемлемое быстродействие для собственной реализации очереди. Тестирование показало, что показателей промышленных сервисов MQ, конечно, достичь не удалось. Однако полученные результаты полностью удовлетворяют запросы текущих задач. Так, на средней рабочей станции производительность очереди сообщений составила более 1000 сообщений в 1 секунду, что более чем достаточно для наших целевых сценариев. Отдельно были решены задачи блокировок при наличии множества параллельных обработчиков сообщений.

Очередь сообщений

Отдельно хотелось бы выделить основные достоинства очереди сообщений. Приведем ссылку на обзорную статью Романа Кононова "Очередь сообщений". В данной статье очень замечательно описаны причины по которым очереди сообщений являются жизненно важны для любой архитектуры корпоративных приложений. Позволим привести тут сокращенное описание:

  • Слабое связывание — очереди определяют интерфейсы обмена данными, которые позволяют приложениям быть независимыми друг от друга, определяется только формат сообщений
  • Избыточность — очереди дают возможность минимизировать неэкономное использование аппаратных ресурсов (памяти) для хранения «лишних» (необработанных) данных
  • Масштабируемость — очереди позволяют распределять процессы обработки информации по разным серверам и выделенным службам, тем самым позволяют легко наращивать мощность системы подключая дополнительные узлы/обработчики сообщений
  • Эластичность — очереди сообщений могут выполнять роль своего рода буфера для накопления данных в случае пиковой нагрузки, смягчая тем самым нагрузку на систему обработки информации и не допуская отказов обработки
  • Отказоустойчивость — очереди сообщений позволяют изолировать процессы друг от друга; при «падении» обработчика сообщений очереди, необработанные сообщения могут быть обработаны позднее, после восстановления работоспособности системы
  • Гарантированная доставка — использование очереди сообщений гарантирует, что сообщение будет доставлено и обработано в любом случае (пока есть хотя бы один обработчик)
  • Гарантированный порядок доставки — сервисы очередей, при необходимости, позволяют гарантировать, что данные будут обрабатываться c заданным порядком
  • Буферизация — процесс записи в очередь происходит настолько быстро, насколько быстро эту операцию в состоянии выполнить очередь сообщений, а не обработчик сообщения
  • Понимание потоков данных — очереди сообщений позволяют выявлять наиболее нагруженные каналы и потоки данных в системе, что позволяет управлять перераспределением и оптимизацией нагрузки
  • Асинхронная связь — очереди сообщений предоставляют возможность проводить обработку данных и расчеты не блокируя систему, пославшую сообщение в очередь, что делает систему более интерактивной

C выходом Xafari.MQ и Xafari сервера приложений все разработчики, администраторы и заказчики систем на платформе Xafari смогут использовать данные преимущества очередей сообщений.

Первый релиз в Xafari x06

В версии Xafari x06 мы выпускаем первый релиз, включающий сервер отчетов.
Пользователь создает новый отчет, который обрабатывается на сервере и сохраняется в базе данных приложения. Пользователь может просмотреть сохраненный отчет в любое время.
В этом сценарии нам пришлось дополнительно реализовать возможность сохранять результаты отчетов в БД для длительного хранения, а также сервисы очистки данного хранилища.

Планы расширения и развития

Далее мы планируем реализовать следующие проекты:

  1. Полноценный сервер расчетов для асинхронного выполнения бизнес-операций
  2. Конфигуратор серверов для мониторинга их работы
  3. Административный модуль для управления очередью сервера расчетов
  4. Служба обработки сообщений по расписанию
  5. API и сервисы извещений и напоминаний

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