Как перестать ждать прогона всей схемы и начать жить: набор приемов и чек-лист для отладки процессов в Directum RX

Всем привет! Работа над сложными процессами часто напоминает айсберг: заказчик видит красивую верхушку с быстрым согласованием, а мы под водой перебираем десятки вариантов условий и циклов в бизнес-процессах, матриц прав и вариаций вычисляемых ролей. Самое затратное время при разработке — это не написание кода, а тестирование с постоянным ожиданием и выполнением рутинных действий.

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

Оптимизация тестирования: ускоряемся без потери качества

Эти приемы помогают проверять логику локальных участков схем, не дожидаясь завершения «монструозного» процесса.

Отладчик — ваш главный инструмент

Пользуйтесь пошаговой проверкой вычисления выражений. Это база для понимания, почему в переменную упал null вместо ФИО сотрудника. Особенно полезно на вложенных вычисляемых ролях и сложных логических условиях.

Мульти-инкогнито для разных учёток

Сократите время на выход/вход в систему под разными ролями. Держите открытыми:

• Основной браузер (под собой).
• Chrome в режиме инкогнито (под «Согласующий 1»).
• Firefox в режиме инкогнито (под «Согласующий 2»).

Так переключение между пользователями происходит в один клик по иконке на панели задач.

Виртуальные рабочие столы Windows

Если список пользователей большой (5+), используйте Win + Tab и создайте несколько рабочих столов (например, «Инициатор», «Бухгалтерия», «Руководитель»). Навигация становится мгновенной. Дополните данный лайфхак пунктом выше – и вы получите инструмент, способный прогонять схемы за десятки секунд, вместо часов.

Клонирование сущностей заранее

Создайте копированием пул тестовых объектов с говорящими названиями: «Договор ТЕСТ 1 (пустой)», «Договор ТЕСТ 2 (с суммой)». Скопировать неиспользованный объект всегда проще, чем создавать с нуля.

Использование уже созданных сущностей

Если тестируются только права, гнать новый объект необязательно. Быстрее взять готовый тестовый документ и вручную «грохнуть» его разрешения через карточку. Аналогично с копированием: скопировали — сразу почистили права.

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

Подход «Песочница в схеме»

Если нужно проверить конкретный блок скрипта или условие, которое находится в середине длинного процесса:

• Способ А: Создайте копию схемы, оставьте в ней только старт, нужный блок и финиш. Прогоняйте только этот кусок.

• Способ Б (ещё быстрее): Протяните стрелку напрямую от Старта к тестируемому блоку. Но помните о риске: переменные, которые обычно вычисляются в предыдущих шагах, будут пустыми. Придется принудительно задать им значения через параметры старта.

Контрольные точки-задания

Если в схеме идут подряд 10 блоков скриптов и выдачи прав, вставьте между ними отправку простого задания (например, на пользователя, под кем тестируется, с темой «Проверь переменные»). Это затормозит процесс, позволит вам открыть карточку задачи, зайти в схему и посмотреть вычисленные параметры блоков прямо из запущенной задачи, не дожидаясь конца цепочки.

Метод Замещения (осторожно, мощно!)

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

Но помните о подводных камнях:

1. Автовычисляемые свойства документов могут сработать от вашего имени (замещающего), а не от имени пользователя.
2. Выдача прав может отработать некорректно, если у замещаемого нет лицензии на модуль или не настроены права на типы объектов. Всегда проверяйте сценарий и под реальной учёткой, если процесс касается прав доступа.

Отчёты и «Этапы процесса»

Перед тем как кликать мышкой по 30 блокам в поисках ошибки настройки срока, откройте в задаче закладку «Этапы процесса» или сформируйте отчёт по варианту процесса. Вы сразу увидите сводку: где висят бесконечные сроки, а где забыли указать тему. Это валидация «по верхам», которая экономит часы.

Изолированное тестирование сложной логики

Сложные развилки с блоками «И»/«ИЛИ» и параллельными ожиданиями — это отдельная боль. Не пытайтесь отлаживать их в боевой схеме с сотней блоков. Вынесите этот узел в отдельный тестовый вариант процесса, отладьте до идеала и только потом переносите в основную схему.

Сокращение таймаутов

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

Критерии тестирования: что нельзя пропустить

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

Тестирование под реальными пользователями

Избегайте тестирования под администратором системы. У администратора есть права на многие сущности. Поэтому можно упустить необходимость выдачи прав на сущности по процессу или на типы прав на объекты сущностей.

Минимальные и максимальные сценарии тестирования

Минимум: 1 исполнитель и 1 простой путь прохождения схемы. Максимум: много исполнителей, заполнены все вложения, есть эскалация.

Циклы

Обязательно выполните 2 прохода через цикл. Первый раз параметры могут перезаписаться, а во второй — «залипнуть» и поехать дальше с некорректным значением из предыдущей итерации.

Очистка параметров

Если в переменную пишется строка вроде «Кто вернул: Иванов», убедитесь, что при повторном входе в блок переменная очищается, а не дополняется до «Кто вернул: Иванов; Петров».

Кейс «Никого не нашли»

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

Права инициатора и галка «Не выше прав инициатора»

Галочка «не выше прав инициатора»: тестируйте сценарии, когда инициатор задачи с правами на просмотр — права участников процесса могут вычисляться не так, как ожидалось.

Изменение оргструктуры

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

Импорт/экспорт

Перенесли вариант процесса на другой стенд? Проверьте импорт/экспорт: после переноса варианта процесса на другой стенд убедитесь, что все ссылки на справочники (подразделения, виды документов) подхватились корректно — если запись не найдена или найдено несколько, импорт потребует ручной донастройки

Время — UTC, а не МСК

Помните: в отладчике и вычислениях скриптов дата отображается по серверному времени (UTC). Не подгоняйте формулы под свой часовой пояс. Пишите универсально, с учетом смещения.