Данный материал рассказывает о том, как в специализированном проектном решении CleverENGINE реализованы связи между однотипными workflow-объектами (например, связь между двумя обращениями пользователей).

Материал является частью описания новых функциональных возможностей решения CleverENGINE по сравнению с продуктом HP OpenView Service Desk 4.5.

В HP OpenView Service Desk 4.5 было четыре базовых класса, которые использовались как фундамент для автоматизации ITSM-процессов:

1. Обращение пользователя (Service call)
2. Инцидент (Incident)
3. Проблема (Problem)
4. Изменение (Change)

Эти классы имели общий системный родительский класс, который назывался Service event. Использовались и другие классы, в частности задания (work orders) и проекты (projects), но с точки зрения автоматизации процессов ITSM они играли вспомогательную роль и в этой заметке мы о них говорить не будем.

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

• отсутствовала возможность связывания объектов одного класса (однотипных workflow-объектов). Например, связать между собой два обращения пользователя было невозможно;
• отсутствовала возможность поиска по связям объектов, причем как однотипных, так и различных workflow-объектов. В частности, штатными средствами продукта нельзя было найти обращения пользователей, которые не имеют связей с инцидентами или проблемами;
• отсутствовала возможность связывать с полями связей правила бизнес-логики (это ограничение также действовало для связей как однотипных, так и различных workflow-объектов).

Для максимального сохранения обратной совместимости по модели данных в решении CleverENGINE используются те же базовые workflow-объекты, имеющие общий родительский класс (только теперь к ним же добавлены и задания, но для данной заметки это несущественно):

Рисунок 1. Базовые объекты для автоматизации процессов ITSM в решении CleverENGINE
(нажмите на изображении для увеличения)

При этом схема связей объектов существенно доработана для того, чтобы преодолеть указанные ограничения. Так, CleverENGINE обеспечивает возможность связывать однотипные объекты между собой. Например, существует возможность связать два обращения пользователя:

Рисунок 2. Форма обращения со связями объектов
(нажмите на изображении для увеличения)

Это позволяет, например, реализовать обработку ситуаций, когда при подаче нового обращения пользователь ссылается на ранее закрытое обращение с жалобой на неудовлетворённость решением или повторяющийся инцидент. Или строить связи между массовым сбоем и отдельными обращениями пользователей, если ИТ-подразделение по каким-то причинам не ведет отдельный учёт инцидентов (а такое довольно часто встречается на практике).

Более того, с полями связей можно связывать правила бизнес-логики (как декларативные, так и процедурные). Это позволяет, например, автоматизировать следующие сценарии:

• обеспечить проверку корректности статусов и других атрибутов изменений, объединяемых в составе одного релиза (головного изменения);
• требовать устанавливать ссылку на новую либо ранее зарегистрированную проблему при закрытии обращения либо инцидента с уровнем влияния выше установленного порога и так далее.

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

Рисунок 3. Пример условия поиска обращений по связям с проблемами
(нажмите на изображении для увеличения)

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