Я, по какой-то неведомой мне причине, был уверен в том, что описал в блоге каталог услуг, существующий в SCSM 2012, уже давно. Но как выяснилось в ходе недавно состоявшейся беседы, это совсем не так. Видимо сказалось то, что я часто рассказываю об этом на презентациях. Сегодня я решил исправить эту оплошность и описать каталог услуг в подробностях.

Каталог услуг в SCSM представляет интерес сразу по нескольким причинам. В первую очередь каталог услуг это “лицо” вашего ИТ-отдела. Именно через него пользователи узнают об услугах, которые вы предоставляете. Вторая причина это тот факт, что каталог услуг очень часто пересекается с таковым в базе данных конфигурационных единиц (в SCSM эти услуги зовутся бизнес-услугами). И наконец третья причина чисто техническая – элементы каталога услуг по своему уникальны: его элементы одновременно существуют в пакете управления и в базе данных в виде экземпляров класса. Но об этом будет рассказано в самом конце статьи.

Структура каталога услуг

Каталог услуг в SCSM состоит из двух сущностей – Предложение услуги (Service Offering) и Предложение запроса (Request Offering). Перевод несколько корявый, но тем не менее верно передает смысл каждой из них. Предложение услуги – это сервис, который мы предлагаем нашим заказчикам. Примером такой услуги может быть электронная почта, рабочее место, 1С, доступ в сеть и так далее. Предложение запроса – это то, какие запросы мы можем предложить нашим пользователям в рамках каждой услуги. К примеру, создание псевдонима в услуге электронная почта. Если попытаться кратко сформулировать всё сказанное выше, то Предложение услуги это ответ на вопросе ГДЕ (.. у вас что-то произошло, …вам надо что-то изменить), а предложение запроса – это ответ на ЧТО (.. именно произошло, …. вам необходимо изменить). От качества каталога услуг будет зависеть то, как эффективно смогут пользоваться им ваши пользователи, как быстро находить нужные запросы. А это, в свою очередь, снимет нагрузку с ИТ-подразделения по категоризации и маршрутизации запросов (но, к сожалению, не сможет убрать её совсем).

Предложение услуги

Как было сказано выше – предложение услуги это описание сервиса, которое вы предоставляете пользователям. И  тут мы подходим к первому часто задаваемому вопросу по этому каталогу – в чем отличие Предложение услуги от Бизнес-Услуги (Business Service), доступной в разделе Конфигурационные Элементы.

Тут важно помнить, что бизнес-услуга это в первую очередь конфигурационный элемент, а значит участвует в процессе инвентаризации. В SCSM бизнес-услуга – это фактически паспорт услуги, в котором описаны всё его технические данные. И это именно техническое понятие, хотя именно оно, скорее всего, будет фигурировать в ваших договорах на обслуживание и договорах на уровень сервиса (SLA, далее я буду называть их одним словом Соглашение), которые у вас заключены с бизнесом. Бизнес-услуга содержит в себе как описательную часть (название, описание, ответственные и т.д.), так и компонентную часть – другие конфигурационные элементы, из которых состоит ваша услуга. К примеру, бизнес-услуга “Электронная почта” будет содержать в себе сервера Exchange (ну или postfix, кому как повезет), зависимости от услуг “СХД” и “Сеть”. Важным момент является тот факт, что распределенные приложения в SCOM передаются в SCSM именно в виде объектов бизнес-услуг.

Предложение услуги же является чисто описательным объектом, и содержит данные о том, как эта услуга предоставляется вашим конечным пользователям. И это его основное отличие от бизнес-услуги. Часть Бизнес-Услуг и Предложений услуг скорее всего будут у вас совпадать. К примеру, Электронная Почта скорее всего будет представлена как в виде Бизнес-Услуги, так и в виде Предложения Услуги. А вот предоставлять пользователям бизнес-услугу “Active Directory” вряд ли является хорошей идеей, хотя бы потому, что большинство пользователей просто не поймут, что это такое. Помните, что Предложение Услуг – это в первую очередь каталог. Он не обязательно должен отображать ту же структуру, в которая у вас есть в вашем Соглашении. Этот каталог должен быть понятен вашим пользователям.

Как еще один из примеров организации каталога можно рассмотреть случай, когда в компании имеется отдел разработки веб-приложений (или разработка веб-приложений отдана внешним исполнителям). Очень часто Соглашение заключается на поддержку пула приложений в общем, а не какого-то конкретного приложения (в этом случае просто оплачивается количество часов разработки). В этом случае у вас в вашем списке Бизнес-Услуг будет значиться одна услуга под примерным названием “Веб-приложения Компании” (но при этом, в 99% случаях, также будут созданы Бизнес-Услуги для каждого приложения отдельно, но не указанные в Соглашении, но это будет сделано больше с целью каталогизации, мониторинга и более детального описания). А вот создавать Предложение Услуги под названием “Веб-приложения Компании” вряд ли является хорошей идеей, особенно если приложения несут разную функциональную нагрузку. Гораздо эффективнее создать Предложение Услуги для каждого приложения, и объединить их в одну категорию.

Свойства предложения услуги

Свойства предложения услуги перечислены в таблице ниже и дано их краткое описание.

Параметр	Английское название	Описание
Название	Title	Название. Отображается на портале в списке и в качестве заголовка при выборе услуги
Изображение	Image	Инока, связанная с этим предложением. Отображается на портале в списке и в качестве заголовка формы.
Категория	Category	Позволяет разбивать предложения по логическому признаку. Портал «из коробки» позволяет иметь только один уровень вложенности категорий.
Язык	Language	Язык, для которого создано это предложение. Об этом позже в разделе Локализация
Обзор	Overview	Краткое описание предложения. Отображается на портале в списке.
Описание	Description	Полное описание. Отображается на портале при выборе предложения.
Пакет управления	Management Pack	Пакет управления, в котором будет сохранено предложение.
Сведения о SLA	SLA Information	Текстовое поле, отображается на портале
Ссылка на дополнительные сведения	Link to additional information	URL, отображается на портала как «Дополнительные сведения» для SLA и сведения о стоимости
Сведения о стоимости	Cost infomation	Текстовое поле, отображается на портале
Связанные услуги	Related Services	Связанные бизнес-услуги. Никак не используется на портале
Статьи базы знаний	Knowledge Articles	Связанные статьи базы знаний, отображаются на портале при выборе предложения услуги.
Предложения запроса	Request Offering	Связанные предложения запроса
Состояние предложения	Offering Status	На портале отображаются только предложения в состоянии ‘Опубликовано’
Владелец предложения	Offering Owner	Справочное поле
Дата публикации	Published Date	Справочное поле
Издатель	Published By	Справочное поле
Внутренние примечания	Internal Notes	Справочное поле

Предложение запроса

Это самый важный компонент в каталоге услуг. Фактически это сам ваш запрос, который имеет массу настроек: вопросы, описание и т.д. Каждое предложение запроса может быть включено более чем в одно предложение услуги. Предложение запроса позволяет вам создавать инциденты или запросы на обслуживание. Создание других элементов из предложения запроса “из коробки” не возможно.

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

Свойства предложения запроса

Свойства предложения запроса перечислены в таблице ниже и дано их краткое описание

Параметр	Английское название	Описание
Название	Title	Название. Отображается на портале в списке и в качестве заголовка формы
Изображение	Image	Инока, связанная с этим предложением. Отображается на портале в списке и в качестве заголовка формы.
Описание	Description	Отображается на портале в списке и в момент выбора предложения запроса
Имя шаблона	Template name	Шаблон, который будет использоваться для создания элемента после окончания заполнения формы
Пакет управления	Management Pack	Пакет управления, в котором будет сохранено предложение.
Инструкция по заполнению формы	Form instruction	Текстовое поле, отображается на портале когда пользователь переходит на форму запроса
Текст приглашений или сведений	Prompt or information text	Список вопросов для формы (это этом ниже)
Настройка приглашений		Настройки каждого вопроса
Сопоставление приглашений со свойствами		Привязка ответов к свойствам создаваемого объекта
Статьи базы знаний	Knowledge Articles	Связанные статьи базы знаний, отображаются на портале при выборе предложения запроса.
Предложения запроса	Request Offering	Связанные предложения запроса
Состояние предложения	Offering Status	На портале отображаются только предложения в состоянии ‘Опубликовано’
Владелец предложения	Offering Owner	Справочное поле
Дата публикации	Published Date	Справочное поле
Издатель	Published By	Справочное поле
Внутренние примечания	Internal Notes	Справочное поле

Создание предложения запроса

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

1. Согласно вашем Процессу определить, будет ли новый запрос инцидентом или запросом на обслуживание
2. Согласно выбору, создать новый шаблон, заполнив поля, которые будут одинаковыми для всех запросов данного типа (к примеру, инцидент или запрос на обслуживание может быть сразу назначен на какую-то группу)
3. Желательно до создания предложения запроса понимать, к каким полям выбранного класса вы будете привязывать ответы. Помните, что все ответы должны быть привязаны хотя бы к одному полю объекта.
4. Создать сам объект предложения запроса, указать название, описание и картинку, если необходимо
5. Добавить вопросы (здесь и далее я буду использовать термин “Вопрос” вместо “Приглашения”, используемого в консоли), указать их обязательность и тип
6. Произвести настройки, для некоторых типов вопросов они обязательны
7. Привязать каждый вопрос к полю объекта (или его дочернего действия, если применимо)
8. Привязать созданный объект к предложению услуги

Вопросы в предложении запроса

Вопросы формируют форму вашего запроса, именно её пользователь будет заполнять, чтобы создать новый объект в SCSM. От качества и “понятности” формы будет зависеть то, на сколько пользователю будет просто создать новый объект на портале, вместо того, чтобы звонить в службу поддержки.

Вопрос в запросе на обслуживание может быть обязательным (в этом случае нельзя будет отправить форму, пока поле не заполнено\значение на выбрано), необязательным (тут думаю понятно) и только для отображения. На портале “из коробки” в этом случае будет отображен только текст вопроса, без поля ввода значения.

В каждом вопросе вы можете использовать один из следующих типов вопросов (перечислены в алфавитном порядке):

• Вложенный файл. Позволяет добавить файл. На портале “из коробки” – только один файл. Настройки (опционально): Можно задать максимальный размер файла.
• Дата. Позволяет выбрать дату. На портале “из коробки” – только дату, без времени. Настройки (опционально): максимальную и минимальную дату (явно указав даты или относительно текущего времени)
• Десятичное число. Настройки (опционально): максимальное и минимальное значение.
• Истина\ложь. Выбор Да\Нет на портале. Не имеет настроек.
• Простой список. Выпадающий одноуровневый список. Настройки (обязательно): сам список, значение по умолчанию.
• Результат запроса. Отображает результат выборки из CMDB с возможностью выбрать одно или несколько значений. Настройки (обязательно): класс (или комбинированный класс), критерий запроса, отображаемые поля, привязка к отношению (доступно всего два), возможность выбрать несколько элементов.
• Список перечисления пакета управления. Отображает существующий список SCSM в виде древовидной структуры. Настройки (обязательно): какой список отображать.
• Текст. Настройки (опционально): проверка формата ввода, максимальная и минимальная длина
• Целое число. Настройки (опционально): максимальное и минимальное значение

Более подробно посмотреть на все типы вопросов и их настроек можно тут (на английском).

Тип вопроса “Результат запроса”

Результат запроса (Query Result) хотелось бы выделить отдельно, потому что это один из самых интересных и мощных инструментов в форме запроса. Как уже писалось выше, данный тип запроса предназначен для одной задачи: отображать выборку объектов из CMDB. Причем это могут быть объекты любых классов, а также комбинированных классов. Вы можете предоставить выбор пользователей, компьютеров, связанных запросов и так далее – любых объектов, которые хранятся в CMDB.

Кроме задания статического критерия (который задается на этапе создания вопроса и неизменен в любом предложении услуг) можно создавать критерии, в качестве значений которого использовать предыдущие ответы, а также специальный марке “Пользователь портала” (фактически это строка, возвращающая имя пользователя в формате DOMAIN\UserName, но см. примечание ниже). Это крайне полезно для создания динамических форм – вы можете отобразить список подчиненных для данного пользователя или список его оборудования, отобразить данные в зависимости от опций выше (в примеру, принтера по выбранному помещению). В качестве источника для значение может быть любой тип вопроса, кроме вложения. В том числе поддерживается фильтрация одного результата запроса на основе выбранного объекта в предыдущем результате опроса.

Примечание: маркер “Пользователь портала” возвращает строку в формате DOMAIN\UserName, но при этом вы можете использовать этот маркер для текущего пользователя в CMDB. Работает это следующих образом: вы создаете критерий, одним из условий которого должно быть “Имя Пользователь содержит Маркер Текущего Пользователя портала”. Понятно, что в явном виде такое условие работать не будет (условие “UserName” содержит “DOMAIN\UserName” будет возвращать false в любом случае). По этой причине портал “из коробки” видя такое условие “переворачивает” операнды, в итоге мы получаем условие “Маркер Текущего Пользователя портала содержит  Имя Пользователь”. Такое будет работать в 90% случаев, за исключением:

• если имя текущего пользователя содержится в части другого имени. К примеру, пользователь ivanov увидит в фильтре как свою учетную запись, так и ivanovad, fgivanov и так далее. Больше всех повезет пользователям с учетными записями li и подобным :)
• если в CMDB будут данные пользователей из разных доменов и будут встречаться повторяющиеся имена

Первая проблема проиллюстрирована на скриншоте (имя пользователя на портале – gritsenko):

Обе проблемы легко решаются с помощью токена [me], но портал “из коробки” его не поддерживает.

Хранение предложений запросов и предложений услуг в SCSM

Как уже было сказано выше, предложения запросов и предложений услуг имеют одну уникальную особенность – они представлены как в виде элементов объектной модели, так и в виде элементов пакета управления, при этом “мастером” является именно данные из пакета управления (именно поэтому его необходимо выбрать при создании предложений). Сделано это с помощью так называемых расширений схемы пакета управления. Механизм работы расширений следующий: в пакете управления описывается XML-схема расширения и в коде задается сопоставление между элементами и атрибутами схемы и свойствами класса в объектной модели (точнее будет сказать комбинированного класса). Проще пояснить это на примере. В объектной модели определен класс System.RequestOffering (также как и System.ServiceOffering) со следующими свойствами:

• EstimatedTimeToCompletion
• HideGotoRequestButton
• TargetTemplate
• PresentationMappingTemplate
• Title
• Notes
• BriefDescription
• Overview
• PublishDate
• Image
• Status
• Comment
• ID
• Domain
• Path
• Internal_ManagementPackId
• Internal_ElementId
• Internal_ParentId

Последние 6ть свойств являются системными (и наследуются от другого класса), а вот все остальные описывают само Предложение Запроса.

В базе данных SCSM также хранится схема, которая описывает XML-структуру предложения, и соответствие между структурой, классом и свойствами.

Работать с предложениями через SDK можно двумя способами: с помощью обычной объектной модели, либо с помощью специального API для работы с расширениями. Первый способ предпочтительнее во всех аспектах. Единственная проблема – вы должны знать схему расширения. К примеру, свойства Title, Overview и им подобные привязаны к атрибутам, а значит это простой текст. А вот свойство PresentationMappingTemplate (именно оно содержит все настройки вопросов) привязано к элементу схемы, а значит в него необходимо записывать правильно сформированный XML-документ.

Механизм расширений также используется в кубах.

Нюансы работы

Когда вы создаете, изменяете или удаляете объект предложения, одновременно с записью в базу данных самого объекта (в рамках одной транзакции) записывается соответствующий XML-элемент в пакет управления. Если же вы импортируете пакет управления с содержащимися в нем предложениями, в базу данных создаются объекты (также в рамках одной транзакции). Всё это в теории позволяет поддерживать объекты и пакет управления полностью синхронизированными.

К сожалению, теория не всегда соответствует практики. Я уже два раза видел случаи, когда происходила разсинхронизация объектов и пакетов управления. Если у вас возникла такая ситуация крайне рекомендую сразу обращаться в службу поддержки, не пытаясь “вылечить” симптомы.

Еще несколько неприятных моментов в работе с расширениями:

• Authoring Tools, официальный инструмент разработки для SCSM, оказался “не в курсе” наличия расширений, и если вы отредактируете пакет с предложениями в Authoring Tools, то все предложения будут удалены при сохранении пакета.
• Если категория (элемент списка) предложения запроса или предложения определены в том же пакете управления, что и сами предложения, вы получите ошибки при попытке их импортировать в систему, где эта категория не существовала ранее.
• Также помните, что отношения между предложением запроса и предложением услуги не хранится в пакете управления, а значит вам необходимо вручную воссоздать эти отношения после того, как вы первый раз импортировали пакет управления с предложениями (в случае, если вы импортируете пакет просто с изменениями, связи не нарушаются)

Вместо заключения

Каталог услуг является одним из ключевых компонентов SCSM. В этой статье лишь поверхностно описаны основные его компоненты. Полное описание всех нюансов работы каталога услуг может занять целую книгу. Но зная основные компоненты каталога услуг вы можете строить удобный и понятный интерфейс доступа к вашей ИТ-системе.