Ситуация

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

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

Причины изменения скорости сохранения

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

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

Пример 1

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

n+1, где n – число условий по горизонтали.

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

Пример 2

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

2n, где n – число условий по вертикали.

Таким образом, в примере 4 ветки. В схеме из 20 условий, расположенных вертикально, число веток будет больше миллиона.

Конкретная задача на согласование по регламенту всегда идет только по одной из веток правила. Если в правиле несколько раз используется одно и то же условие, то появляются ветки, по которым задача не пойдет никогда. Причина в том, что переходы из условий будут противоречить друг другу. В схеме из примера 2 конкретная задача на согласование по регламенту пойдет только по ветке 1 или 2. В ветке 3 при первом переходе вычислялось, что документ типовой, значит при втором переходе он не может стать не типовым. Ветка не имеет смысла. В ветке 4 аналогичная ситуация.

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

1.Система сверху вниз проверяет элементы схемы.

2.Когда в схеме попадется условие, система анализирует, были ли условия такого же типа раньше.

3.Если были, то сравнивает переход из предыдущего условия с вариантами перехода из проверяемого условия.

4.Переходы, которые противоречат друг другу исключаются.

Код для проверки веток с типовыми условиями уже написан в серверных функциях CheckRoutePossibility() в:

•базовом типе справочника «Правила согласования» (ApprovalRuleBase);

•справочниках «Правило согласования» (ApprovalRule) и «Правило согласования договоров» (ContractsApprovalRule) из базового решения Directum RX.

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

Решение

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

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

© Компания Directum, 2024