Очень многие администраторы, перед которыми встала задача внедрения SCSM, задаются вопросом: как создать собственные кастомные формы Запроса на обслуживание или Инцидента, содержащие нужные поля, форматирование и т. п.? Основной способ, трактуемый в Интернете и на Технете в частности – использование Authoring Tool. Не будем описывать всех достоинств и недостатков данного метода. Оставим его на суд читателя. Единственное, что отмечу, проникнуться данным методом всё же стоит, т. к. он предоставляет довольно широкое понимание о структуре Пакетов управления и о внутренней работе механизмов SCSM в целом.

В этой статье речь пойдёт о своеобразном workaround-решении: как можно обойтись штатными формами, не использовать громоздкий механизм Authoring Tool, но при этом, обрабатывая совершенно произвольный набор данных, вводимых пользователем через Портал самообслуживания (Self Service Portal). Подчеркну, что методика, рассмотренная в данной статье, не претендует на звание идеальной и предоставляется «как есть». Здесь не будем детально вникать в описание скриптов, настройки и подобные вещи – вы и сами разберётесь при желании. Данный пример, в первую очередь, направлен на раскрытие методики работы связки SCSM<->Orchestrator.

Нам понадобится:

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

Шаг 1.

В голове или на бумаге (или ещё каким удобным способом) мы должны построить алгоритм прохождения будущего запроса. То есть последовательность ключевых действий. У нас он будет очень простым:

  1. Первый этап. Ранбук – Формирование запроса. Тут мы будем обрабатывать данные, введённые пользователем, формировать описание запроса, подцеплять элементы конфигурации и т. п. Собственно это ключевая задача, ради которой эта статья и затевалась.
  2. Второй этап. Ручное действие. Задача для сотрудника технической поддержки, который будет исполнителем запроса.

Запомните эти этапы, далее они будут упоминаться.

Шаг 2.

Открываем Оркестратор и начинаем рисовать ранбук. Добавляем первый шаг «Инициализация данных».



Добавляем три параметра, как показано на рисунке. «GUID» – это уникальный системный 32-хзначный номер, по которому обработчиком будет осуществляться идентификация объекта, в нашем случае – конкретного запроса. Последовательность параметров тут значения не имеет. У многих может возникнуть вопрос: а где же «Принтер»? Принтер у нас будет затрагиваемым элементом конфигурации, и он будет обрабатываться несколько иначе. Ниже будет ясность.

Шаг 3.

Добавляем следующий шаг и связываем с предыдущим. Этот шаг будет выбирать нужный запрос из множества при помощи GUID. Добавляем активность «Get Object» из «SCSM 2012 Integration Pack». Настраиваем параметр фильтра, как на рисунке. Подписываемся на GUID из «Инициализации данных» (правой кнопкой на поле «Value»).


Шаг 3.

Добавляем следующий шаг и связываем с предыдущим. Этот шаг будет выбирать нужный запрос из множества при помощи GUID. Добавляем активность «Get Object» из «SCSM 2012 Integration Pack».>


Теперь более сложный шаг. Нам нужно выцепить конфигурационные элементы: Принтер и Автора запроса. Я делаю это при помощи PowerShell (хотя можно сделать это и при помощи активности «Get Relationship»). Добавим активность «Execute PS Script – Global». Так как нам надо получить два связанных элемента разного типа, то создадим в этой активности два вложенных скрипта.



«PS Script 01» – тут мы получим затрагиваемого пользователя, т. е. автора запроса.

$Session = New-PSSession -ComputerName SC-SM
Invoke-Command -Session $Session -ScriptBlock {
Import-Module SMLets
$ServiceRequest = Get-SCSMObject -Class (Get-SCSMClass -Name System.WorkItem.ServiceRequest$) -Filter "ID -eq ???"
$GetInput = [xml] $ServiceRequest.UserInput
$GetAffectedUserName = (Get-SCSMRelationshipObject -BySource $ServiceRequest | ?{$_.RelationshipID -eq "dff9be66-38b0-b6d6-6144-a412a3ebd4ce"}).TargetObject.DisplayName
$GetAffectedUserName
}

Блок Invoke-Command -Session $Session тут является условным (выделено жёлтым). Дело в том, что у меня скрипты исполняются удалённо, на стороне сервера SCSM, а не сервера Orchestrator. Если у вас исполнение скриптов корректно настроено на стороне Orchestrator, то удалите эти строки. "ID -eq ???" – тут сделайте подписку (правой кнопкой мыши) на «ИД» из шага «Получаем запрос».



«PS Script 02» – тут мы получим принтер.

$Session = New-PSSession -ComputerName SC-SM
Invoke-Command -Session $Session -ScriptBlock {
Import-Module SMLets
$ServiceRequest = Get-SCSMObject -Class (Get-SCSMClт сделайте подписку (правой кнопкой мыши) на «ИД» из шага «Получае ass -Name System.WorkItem.ServiceRequest$) -Filter "ID -eq ???"
$GetInput = [xml] $ServiceRequest.UserInput
[xml] $GetValuesPrinter = $GetInput.UserInputs.UserInput | Where-Object {$_.Question -eq $GetInput.UserInputs.UserInput[0].Question} | %{$_.Answer}
$GetPrinterName = $GetValuesPrinter.Values.Value | %{$_.DisplayName}
$GetPrinterName = $GetPrinterName -join "; "
$GetPrinterName
}

Здесь аналогично. Удалите блок Invoke-Command -Session $Session по необходимости. Подпишитесь на ИД из шага «Получаем запрос». Теперь внимание! UserInput[0] – тут вам необходимо в квадратных скобках указывать цифру, в соответствии с последовательным номером поля, в которое будут добавляться конфигурационные элементы на Портале самообслуживания. В нашем примере это поле «Принтер». По счёту оно будет запрашиваться первым. Но с учётом правил формирования массивов, нумерация начинается с нулевого элемента, поэтому ставим ноль. Если бы наше поле для выбора принтера стояло последним (третьим по счёту), то мы бы поставили UserInput[2]. Если элементов будет несколько, то на выходе скрипта вы получите читабельный перечень связанных элементов конфигурации, разделённых точкой с запятой.



Шаг 4.

Теперь сформируем из полученных данных описание запроса по своему вкусу. Добавляем активность «Update Object», соединяем. Настраиваем, как на рисунке.



Заполняем поле «Описание». Подписываемся на полученные данные.



Шаг 5.

Теперь несколько упростим жизнь нашей техподдержке. Вы же помните, что наш будущий запрос состоит из двух этапов: «Ранбук» и «Ручное действие». Так вот, добавим наше описание также в «Ручное действие» (во второй логический этап), непосредственно с которым и будет работать инженер технической поддержки. Для этого добавим последовательно ещё две активности. Первая «Get Activity». Этим шагом мы получим все активности родительского запроса (а у нас она одна).



Второй активностью «Update Activity» сформируем описание «Ручного действия», полученного на предыдущем шаге. Значение поля «Описание» просто скопируем из сформированного ранее, на шаге 4.



Шаг 6.

Наш ранбук полностью готов. Сохраняем его, нажав «Вернуть», закрываем Оркестратор. Открываем Консоль SCSM. Синхронизируем коннектор Оркестратора. Убеждаемся, что наш ранбук появился в Библиотке.

Шаг 7.

Итак, мы создали ранбук. Что же теперь с ним делать? Перейдем к работе с Консолью SCSM и создадим новый Пакет управления «Замена картриджа». Далее создаем новый Шаблон для ранбука со следующими параметрами. Все шаблоны и настройки здесь и далее сохраняем в нашем Пакете управления «Замена картриджа».



ОБЯЗАТЕЛЬНО ставим галочку «Готово к автоматизации».



ОБЯЗАТЕЛЬНО ставим галочку «Готово к автоматизации».



Переходим во вкладку «Runbook», выбираем наш ранбук и больше ничего не меняем, нажимаем «ОК».






Шаг 8.

Создаем шаблон Запроса на обслуживание.



Заполняем основные поля шаблона в соответствии с установленными у вас требованиями.



Во вкладке действия, первым шагом добавляем наш, созданный ранее, шаблон ранбука «Замена картриджа». Откроется его шаблон. Теперь будьте внимательны. Тут нам надо привязать GUID, заданный в ранбуке, к родительскому ЗНО. Для этого во вкладке «Runbook» нажмите «Изменить сопоставление» напротив поля «GUID». Выберите сопоставление «Запрос на обслуживание», «Объект», «Id». Все как на рисунке. Сохраните шаблон, нажав «ОК».



Мы вернулись к шаблону нашего ЗНО, вкладка «Действия».



Теперь добавим сюда «Ручное действие по умолчанию» для нашей техподдержки. Заполним название – «Замена картриджа», остальные поля на ваше усмотрение. Сохраните, нажав «ОК». В итоге у нас получилась последовательность, как на рисунке ниже. Сохраняем наш шаблон ЗНО «Замена картриджа», нажав «ОК».



Шаг 9.

Шаблон у нас готов, остается последний шаг. Создание предложения запроса.



Заполняем поля приглашений. В поле «Принтер» выбираем тип «Результаты запроса». Остальное, как на картинке.



На следующем шаге настройки приглашений наfile.ashx/__key/communityserver-wikis-components-files/00-00-00-00-05/1665.18.png" style="font-family:Verdana;">

Заполняем поля приглашений. В поле «Принтер» выбираем тип «Результаты запроса». Остальное, как на картинке.



Вкладка «Параметры» у нас будет выглядеть следующим образом.



Для «Цветности», аналогичным способом, настроим выпадающий список, как на картинке.



На следующем шаге сопоставим заданные поля с соответствующим свойством нашего ранбука.



Думаю, оставшиеся шаги по оформлению предложения запроса не вызовут у вас затруднений. Главное не забудьте перевести запрос в статус «Опубликовано».


Шаг 10.

В общем и целом – работа завершена :). Осталось протестировать наш запрос и проанализировать работу ранбука. Заходим на портал, заполняем поля и ждем несколько минут, пока отработает ранбук.



Результат вполне соответствующий и оправдывающий ожидания!



Аналогично во вложенном «Ручном действии».



Резюмируем результат. Мы получили вполне полноценное, читабельное описание в штатной форме запроса. В примере мы работали с формой Запроса на обслуживание. С Инцидентами можно работать аналогичным способом.