Расширение функциональных возможностей триггеров на уровне веб-приложения в СЭД «Атач»

Концепция системы триггеров, представленная в прошлой публикации, считается полной и подойдет для большинства веб-приложений. Несмотря на все достоинства, данное решение не могло эффективно покрыть новые кейсы заказчиков СЭД «Атач».

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

Решение в рамках старой реализации системы триггеров неэффективно, поскольку:

На дополненной схеме БД заголовками с темным фоном отмечены новые таблицы. На схеме видно, что для каждого триггера может быть задан набор свойств с определенным типом (в соответствии с рисунком 1).

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

Задание последовательности выполнения групп осуществляется сортировкой.

Данная реализация позволяет формировать необходимые наборы из заранее заданных свойств на конкретной установке, в зависимости от требуемой ситуации (в соответствии с рисунком 3).

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

Тип свойства является универсальным параметром, и, благодаря настройкам, может быть переопределен в зависимости от назначения в конкретном триггере. Например, в одном триггере тип свойства «ID» может иметь целочисленный тип данных, а в качестве значения принимать идентификатор внешнего справочника, в другом – GUIDS пользователей.

В качестве примера использования свойств триггеров на реальной задаче рассмотрим триггер «Создать поручение». Обработчик создания поручений принимает следующие параметры: срок поручения, резолюция, получатель поручения, на контроль (да/нет). Триггер на создание поручений должен поддерживать рассылку на вариативное количество пользователей, которые заранее неизвестны.

Таким образом, мы получаем следующие возможные наборы свойств для одной установки данного триггера (в соответствии с рисунком 5-6).

Одна группа со свойствами поддерживает следующие входные параметры (в соответствии с рисунком 7):

Было проведено сравнение исходной и новой реализации системы триггеров (в соответствии с таблицей 1).

Решение в рамках представленного подхода расширило функциональные возможности триггеров и позволило решить проблемы старой реализации. Дополнительное преимущество от ввода свойств триггеров – удалось уйти от многих системных зависимостей на уровне веб-приложения.

На основании статистики из системы управления проектами Easy Project было проведено сравнение временных затрат на разработку триггеров по четырем временным составляющим, где были получены следующие средние значения (в соответствии с таблицей 2).

Из этого следует, что разработка триггеров со свойствами требует больших затрат времени на проектирование, поэтому свойства не используются для решения задач, где не требуется настройка вариативного поведения (в соответствии с рисунком 8).

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

Данный расчет на создание одного базового и 50 типовых триггеров.

Если на 10 базовых триггеров разрабатываются 50 типовых на каждый из них для 5 разных заказчиков, то речь идет о потери 279 часов рабочего времени (в соответствии с таблицей 4; в соответствии с рисунком 10).

На основании прогнозируемых временных затрат был произведен расчет прироста экономической эффективности разработки триггеров по формуле разности процентов между суммами (в соответствии с рисунком 11):

Таким образом, прирост экономической эффективности при разработке триггеров в новой реализации составляет 71,722 %, что доказывает правильность выбора направления решения данной проблемы.

В качестве обобщающего вывода необходимо отметить, что расширение функциональных возможностей триггеров на уровне веб-приложения в СЭД «Атач» посредством ввода свойств триггеров покрыло новые и существующие кейсы заказчиков и повысило экономическую эффективность разработки триггеров за счет уменьшения временных затрат.

#сэд , #ecm , #эдо , #разработка , #документооборот , #бизнеспроцессы