NexTool Solutions

Бизнес-правила — встроенный движок автоматизации GLPI: без единой строки кода они классифицируют, назначают и применяют SLA к каждой заявке. То, что документация объясняет редко — и что чаще всего порождает заявки в поддержку при сопровождении клиентских инсталляций GLPI, — это не то, как создать правило, а модель вычисления, которая решает, какое правило побеждает, когда два пересекаются. Это руководство начинается там, где большинство инструкций заканчивается: порядок, условие срабатывания и цепочка.

Модель вычисления, которую почти никто не читает до первого правила

Любое бизнес-правило для заявок относится к подтипу RuleTicket и хранится в таблице glpi_rules. Поведением управляют три столбца:

• ranking — порядок вычисления. Движок читает по возрастанию, от меньшего к большему. Экран показывает сверху вниз, но решает число.
• condition — когда правило срабатывает: 1 при создании, 2 при обновлении, 3 в обоих случаях. Правило, созданное только для 1, никогда не пересчитывается, когда заявку редактируют позже.
• match — логика между критериями: AND (должны совпасть все) или OR (любой).

Деталь, на которой спотыкается большинство: правила заявок не останавливаются на первом совпадении. В отличие от правил сборщика почты и импорта инвентаризации, движок RuleTicket проходит ВСЕ активные правила в порядке ранга и использует результат одного как входные данные следующего. То есть общее правило с большим рангом (вычисляемое позже) может перезаписать назначение, которое уже сделало частное правило до него.

Реальная анатомия: критерии, действия и операторы

У каждого правила три блока. Критерии хранятся в glpi_rulecriterias, действия — в glpi_ruleactions:

• Критерий = criteria (поле) + condition (оператор, числовой) + pattern (ожидаемое значение).
• Действие = action_type (assign, regex_result, append, fromuser, fromitem) + field (изменяемое поле) + value.

Оператор — это числовой код, а не текст, и выбор неправильного — самая частая «тихая» ошибка. Значения в GLPI 11:

0  = é (igualdade exata)
1  = não é
2  = contém
3  = não contém
4  = começa por
5  = termina por
6  = expressão regular (regex)
7  = regex negada
8  = existe
9  = não existe
11 = sob (árvore de entidade/categoria)
12 = não sob

Реальные поля, которые чаще всего используются в действиях: _groups_id_assign (группа специалистов), _users_id_assign (специалист), slas_id_ttr (SLA решения), itilcategories_id (категория) и urgency. В критериях _mailgate определяет заявку, пришедшую через конкретный сборщик почты, а _x-priority читает заголовок приоритета письма.

Чек-лист: правило, которое срабатывает с первого раза

1. Определите триггер. Нужно переклассифицировать при создании? Используйте ONADD (условие 1). Нужно реагировать на смену категории, сделанную позже? Отметьте также обновление (условие 3).
2. Выберите правильный оператор. «Равно» (0) требует идентичного заголовка; для совпадения по фрагменту используйте «содержит» (2) или регулярное выражение (6). Большинство правил по заголовку, которые «не срабатывают», использовали «равно» там, где нужно было «содержит».
3. Расставьте ранг. Сначала частное, потом общее, — но помните, что общее, идущее позже, перезаписывает. Если общее правило не должно трогать то, что уже решено, сузьте его критерий.
4. Проверьте организацию. Правило, созданное в дочерней организации без флага «рекурсивно», действует только для заявок этой организации — и пропадает для остальной инсталляции.
5. Протестируйте в тестовой среде, прежде чем включать в продуктиве.
6. Проверьте с помощью Rule Inspector внутри реальной заявки: он показывает, какие правила вычислялись, какие критерии прошли, а какие нет.

Диагностический SQL: что мы запускаем, когда «правило не работает»

Прежде чем трогать интерфейс, NexTool выгружает весь набор правил заявок в порядке вычисления. За секунды ranking рассказывает всю историю — почти всегда дело в порядке или условии, а не в неверном критерии. Запускайте на реплике для чтения или осторожно на продуктивной базе:

SELECT r.ranking,
       r.name,
       IF(r.is_active, 'ativa', 'INATIVA') AS estado,
       r.match AS logica,
       CASE r.condition WHEN 1 THEN 'criacao'
                        WHEN 2 THEN 'atualizacao'
                        WHEN 3 THEN 'criacao+atualizacao'
       END AS quando,
       (SELECT GROUP_CONCAT(
                 CONCAT(c.criteria, ' [op ', c.condition, '] ', c.pattern)
                 ORDER BY c.id SEPARATOR ' | ')
          FROM glpi_rulecriterias c WHERE c.rules_id = r.id) AS criterios,
       (SELECT GROUP_CONCAT(
                 CONCAT(a.action_type, ':', a.field, '=', a.value)
                 ORDER BY a.id SEPARATOR ' | ')
          FROM glpi_ruleactions a WHERE a.rules_id = r.id) AS acoes
FROM glpi_rules r
WHERE r.sub_type = 'RuleTicket'
ORDER BY r.ranking;

Читайте сверху вниз: две строки, которые записывают _groups_id_assign, означают, что побеждает строка с большим ranking. Строка с estado = INATIVA объясняет «исчезновение» правила. quando = criacao объясняет, почему редактирование заявки не меняет её маршрут.

Матрица решений: какую коллекцию правил использовать

В GLPI несколько коллекций правил, и каждая ведёт себя по-своему. Путаница между ними — корень многих вопросов «почему это правило выполняется дважды?»:

Обратите внимание: для заявки, пришедшей по e-mail, последовательно работают два движка: сначала движок сборщика (останавливается на первом совпадении), затем бизнес-движок для уже созданной заявки (выполняет все правила).

Типичная практическая ошибка

При сопровождении самая частая заявка о правилах всегда одна и та же: «я создал правило, а оно не срабатывает». В подавляющем большинстве случаев дело не в критерии, а в модели вычисления. Случай номер один: есть два правила, записывающих _groups_id_assign; частное с меньшим рангом срабатывает первым, а общее правило с большим рангом, созданное месяцы спустя «просто чтобы гарантировать группу по умолчанию», перезаписывает всё, потому что движок передаёт результат по цепочке. Второй случай: правило было создано только с condition = 1 (только при создании), поэтому, когда оператор позже меняет категорию, маршрут не меняется. Поэтому мы приняли как операционный стандарт всегда запускать приведённый выше SQL для аудита ДО того, как трогать интерфейс: столбец ranking выявляет конфликт за секунды, а перебор правил по одному на экране скрывает реальный порядок выполнения. Такие вещи становятся очевидными только тогда, когда вы сопровождаете десятки сред и видите, как один и тот же паттерн повторяется.

Нужен GLPI, автоматизация которого ведёт себя предсказуемо, без правил, наступающих друг другу на ноги? Сопровождение NexTool проводит аудит и наводит порядок в вашем наборе правил, а плагин Rule Inspector показывает внутри каждой заявки, какое именно правило что решило.

Проверено командой NexTool Solutions.