Развитие инструментов No-Code

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

Еще No-Code не настолько требователен к объему знаний и накопленному бэкграунду, в отличие от тех же прикладных разработчиков, что сильно снижает порог вхождения и затраты на подготовку специалистов.

В новой версии Directum RX инструменты No-Code расширился еще больше и теперь некоторые кейсы, которые раньше решались только через разработку можно настроить за пару минут, кликая мышкой в клиенте. Красота, да и только!

Но, нужно признаться, что текущие инструменты No-Code не всесильны и, внедряя очередной проект, я столкнулся с потребностями заказчика, которые видел уже много раз.

Эти требования стары как мир. Они были на Directum 5 и с завидной регулярностью встречаются при внедрении Directum RX.

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

Давайте решать проблемы по классике, перекладывая их на других, т.е. переносить из плоскости разработки в плоскость настройки :)

Дополнение: из-за сжатых сроков и объема проекта, в данной статье обойдемся без сторонних компонент, оставим их на развитие решения.

Настройка формата наименования

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

Быстро и удобно.

Рис 1. Пример настройки формата наименования для исходящего письма.

Критерии фильтрации позволяют задать формат сразу на весь тип документа или только на определенные виды документов. Для разных типов свойств доступны собственные варианты форматирования значений.

Рис 2. Пример вариантов форматирования значений свойств.

Так же есть возможность проверить конечный результат на реальном документе, не покидая карточку настройки, что так же сокращает время на настройку.

Рис 3. Пример проверки шаблона наименования.

Справочник поддерживает все типы документов (наследников "Официального документа") и их свойства, кроме коллекций (на данный момент).

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

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

Валидация старта задачи или выполнения задания

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

Ни слова больше, я Вас услышал!

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

- А если я добавил свой вариант выполнения в настройках, валидация будет работать?

- Да, достаточно создать запись с локализированным наименованием варианты в  "Результатах выполнения" и использовать эту запись в настройках.

- А если я переименовал какой-то вариант выполнения в настройках, тоже будет работать ?

- Да, достаточно переименовать ранее созданный вариант выполнения или создать новый и использовать эту запись в настройках.

Рис 4. Пример справочника с результатами выполнения для заданий.

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

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

Рис 5. Пример выбора типа сущности.

В справочнике реализована возможность группировки проверок по условиям на случай, если проверки нужно проводить только если выполняются какие-то определенные условия, а так же реализованы объединения "И" и "ИЛИ".

На скриншоте ниже представлен пример, когда исходящее письмо с установленными флажками "Требуется согласование" или "Требуется электронное подписание" должны отправляться с версией документа, а остальные виды официальных исходящих писем версий документа не требуют, т.к. для них эти этапы в схеме пропускаются.

Рис 6. Пример настройки валидации старта задачи.

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

Рис 7. Пример ошибок валидации.

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

Рис 8. Пример настройки валидации выполнения задания определенного этапа процесса.

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

Рис 8. Пример настройки валидации выполнения задания определенного этапа процесса.

Результаты использования и планы на развитие

Объем прикладной разработки уменьшился на 100%

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

Разработанные инструменты, как и любые другие инструменты No-Code, позволили значительно снизить трудоемкость разработки "типовых" кейсов, которые периодически возникают почти у всех заказчиков.

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

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

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

Ну и о расширении возможностей и функционала тоже не забываем, в числе которых числится экспорт/импорт настроек для переноса на другой контур.

Команда решения

Автор идеи и разработчик - Беляков Сергей Александрович