Данный материал рассказывает о возможностях специализированного проектного решения CleverENGINE на платформе OMNITRACKER по расширению модели данных.

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

 

В HP OpenView Service Desk 4.5 возможности по расширению модели данных (объекты, поля, связи между объектами) были ограничены.

Набор объектов был строго фиксирован. Создание новых объектов было невозможно, что существенно ограничивало круг решаемых системой задач, например, без отдельного объекта Трудозатраты учет трудозатрат по связанным объектам представляется невыполнимой задачей (подробнее см. «CleverENGINE. Единый универсальный механизм учёта трудозатрат»). При необходимости существующие объекты приспосабливались под различные нужды. Например, не было отдельного объекта для накопления стандартных решений в базе знаний. Для данных целей использовались объекты Service Call (Обращения), отмеченные специальным признаком (FAQ), для просмотра и работы с которыми использовалось отдельное представление (подробнее см. «CleverENGINE. База знаний по решению обращений пользователей и инцидентов»).

Для объектов, помимо набора системных полей, определенных производителем, была возможность создавать поля нескольких типов (текстовые, числовые, выпадающий список и т.д.). Однако:

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

Кроме того, существовал ряд ограничений по созданию связей объектов между собой. Для связи объектов были предусмотрены специализированные типы полей (Entity Reference), позволяющие связывать объекты с объектами типов: Organization, Person, Workgroup, Configuration Item (CI), Service. Например, связать объекты Service и Work order для контроля работ по ведению каталога услуг и созданию/редактированию услуг было невозможно. Аналогично, не было возможности связывать объекты Project и Work order для описания проектов в виде последовательности заданий. Но и там, где связи могли быть установлены, существовал ряд ограничений, например:

  • не было возможности создания связей объектов одного типа (например, Service call – Service call)
  • установленные связи не были симметричными, например, можно ввести новое поле [Куратор услуги] для объекта Service, однако нельзя добавить соответствующее поле, для объекта Person, в котором бы отражались все услуги, за которые отвечал куратор.

Таким образом, HP OpenView Service Desk 4.5 жёстко ограничивал возможности применения системы автоматизации процессов за рамками функциональных возможностей, заложенных производителем.

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

Основным элементом модели данных OMNITRACKER является папка (Folder), представляющая собой контейнер, хранящий все свойства и атрибуты объекта, правила бизнес-логики, права доступа, формы и так далее. Пример приведен на рисунке ниже.

omnitracker_screenshot78

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

Папки могут быть вложенными друг в друга, при этом свойства родительской папки могут быть унаследованы, что позволяет определять общие атрибуты для однотипных объектов. Например, поля, используемые во всех объектах рабочих процессов (Обращения, Задания), [Ответственная группа], [Ответственный специалист] определены на уровне корневой папки Рабочие процессы. Данный подход очень удобен, так как позволяет не только выстраивать папки в виде иерархической структуры, удобной для навигации, но и облегчает задачи по разработке и администрированию. Помимо этого позволяет осуществлять отображение, поиск и фильтрацию объектов по общим полям на уровне корневой папки. В качестве атрибутов объектов могут быть определены поля всех стандартных типов данных (числовые, логические и так далее), а также некоторые специальные поля, например:

  • Workflow – позволяет определять жизненный цикл объекта, настраивать правила перехода между статусами, вызывать определённые события при изменении статуса (например, отправлять уведомления) , определять обязательные для заполнения поля для каждого статуса
  • Schedule – используется для создания расписаний и работы с ними, например, используется для автоматизации регламентных операций – автоматической регистрации цепочек заданий по заданному расписанию (подробнее см. «Автоматизация регламентных (плановых, регулярных) операций»)
  • Memo–Time Stamped – накапливаемый журнал записей с указанием даты внесения записи, имени пользователя, а также текущего состояния обработки объекта (при наличии поля [Статус]). Пример приведен на рисунке ниже

omnitracker_screenshot79

Рисунок 2. Пример заполнения поля типа Memo–Time Stamped
(нажмите на изображении для увеличения) 

Перечень доступных типов полей приведен на рисунке ниже.

omnitracker_screenshot80

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

Свойства поля настраиваются (например, включение поля в журнал изменения объекта, полнотекстовый поиск и так далее), определяются первичные ключи (в том числе и составные). Для поля определяются условия доступности и обязательности. Данные условия могут быть определены с помощью правил бизнес-логики, а также с помощью скриптов. Например, в обращении поле [Внешний ID] доступно, если определена внешняя организация в соответствующем поле, которой данное обращение передано для обработки. В зависимости от типа поля его настройки могут дополняться, например, для текстовых полей могут определяться маски с помощью регулярных выражений и сообщения об ошибке, если введённые данные не соответствуют.

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

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

Для удобства работы OMNITRACKER позволяет накладывать ограничения на доступные для связывания объекты с помощью фильтров (например, нельзя установить связи с объектом, если в объекте установлен признак «Не используется»).

Пример свойств поля типа Reference list of objects приведён на рисунке ниже.

omnitracker_screenshot81

Рисунок 4. Свойства поля типа Reference list of objects
(нажмите на изображении для увеличения) 

Таким образом, за счёт средств разработки, предоставляемых платформой OMNITRACKER, а также за счёт того, что решение OMNITRACKER CleverENGINE является полностью открытым (за исключением демо-версии), предоставляются возможности:

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