Интеграция SCOM 2012 R2 и SCDPM 2012 R2 со сторонней системой ServiceDesk с помощью SCOrch 2012 R2

Так уж получилось что в нашей компании используется система ServiceDesk не из состава System Center (я говорю о Service Manager). Возник вопрос об интеграции этого продукта с используемыми продуктами System Center, а конкретно с System Center 2012 R2 Data Protection Manager и System Center 2012 R2 Operations Manager. Первая задача по интеграции была следующая – необходимо отслеживать инциденты, возникающие в процессе резервного копирования, и регистрировать их в системе ServiceDesk.

Первым делом были рассмотрены возможности нашей системы ServiceDesk – у нее обнаружился удобный REST API для взаимодействия. Общей шиной для взаимодействия был выбран System Center Orchestrator и именно этот выбор побудил меня написать эту статью (а может и цикл статей, посвященный Orchestrator, так как по нему не очень много статей на русском, да и вообще).

Алгоритм работы процесса такой:

1. Operations Manager собирает информацию обо всех алертах Data Protection Manager

2. Orchestrator запускает каждые два часа RunBook в котором считывает все новые алерты из Operations Manager и создает на их основе инциденты в ServiceDesk, после чего обновляет алерты вписывая им номера инцидентов (TicketID) и меняя статус (ResolutionState).

Итак, имея все исходные данные и алгоритм работы, остается только реализовать его в виде RunBook в System Center Orchestrator.

Глоссарий

• RunBook – законченная автоматизированная последовательность процессов или задач, визуализированная в виде блок-схемы
• Процесс (Activity) – некий процесс, визуализированный в System Center Orchestrator как отдельная единица (блок)
• Соединение (Link) – элемент логики визуализированный в виде соединительной линии между процессами и задающий условия соединения
• Подписка (Scheldule) – способ передачи параметров и переменных из процесса в процесс

RunBook 1

Первый RunBook будет выглядеть так:

Далее будет описание элементов и логики работы данного RunBook.

Monitor Date/Time

Monitor Date/Time – это своеобразный таймер, который запускает цепочку остальных процессов (Activity).

Настраивается данный процесс следующим образом – выбираем один из трех вариантов интервала срабатывания, в нашем случае это Every 2 hours. И устанавливаем галку напротив Trigger immediately – это позволит запустить процесс при старте RunBook, в противном случае процесс выполнится по прошествии интервала, в нашем случае двух часов (к слову, это ОЧЕНЬ замедляет процесс отладки RunBook).

Check Scheldule

Check Scheldule – устанавливается по желанию (если есть необходимость в каком-либо условии на базе расписания, например, выполнять RunBook только по пятницам или только в рабочие дни и часы). Заранее создается необходимое расписание в разделе Global Settings / Scheldules, и в последствии выбирается в свойствах данного процесса. Скриншот свойств приводить не буду, так как там всего одно поле – Scheldule Template. Связав первый процесс со вторым связью (Link) мы тем самым выстраиваем последовательность действий, которая будет выполняться.

Get Alert

Третий процесс является главным в этом RunBook и его настройку мы рассмотрим наиболее тщательно. Называется он Get Alert (из Integration Pack SC 2012 Operations Manager).

Данный процесс получает ВСЕ алерты из сервера Operations Manager указанного в свойствах Connection. Connection настраиваются через меню Options в Runbook Designer. Для того что бы отфильтровать по заранее определенным критериям алерты в окне Filters добавляем следующие фильтры:

• Resolutions State Equals New – это сократит коллекцию до группы алертов со статусом New
• Severity Equals Critical – фильтруем только критически важные алерты
• Context Contains <Channel>DPM Alerts</Channel> – данный параметр наиболее важен, так как он оставляет в коллекции только алерты, созданные на DPM серверах.

На данном этапе RunBook мы получаем от сервера Operations Manager коллекцию алертов, и следующий за процессом Get Alert процесс выполнится столько раз, сколько алертов мы имеем в коллекции. Так как нам нужно выполнить не одно, а несколько действий, я вынес эту последовательность в отдельный RunBook (как функцию в языке программирования), о ней чуть позже. Выполнять последовательность действий после этого процесса имеет смысл только в случае если в коллекции один и более элемент, по этому мы соединяем процесс Get Alerts со следующим процессом Invoke RunBook связью и настраиваем эту связь следующим образом.

Удаляем имеющееся там условие Get Alert returns success и добавляем новое условие – AlertCount from Get Alert is greater than 0. Данное условие позволит выполнить связанный этим элементом процесс только в случае его (условия) выполнения, а значит если Get Alert вернет 0 алертов, то RunBook закончит цепочку процессов и начнет ее с начала.

Если у вас его нет Get Alert или Update Alert в RunBook Designer, то вам необходимо установить соответствующий пакет интеграции - Integrations Pack for System Center 2012 R2, а о том как это делается, можно прочитать в статье TechNet Library - Установка Integrations Pack

Invoke RunBook

Последний процесс данного RunBook называется Invoke RunBook и он позволяет запустить другой RunBook передав ему некие определенные вызываемым RunBook’ом параметры от других связанных процессов.

В свойствах процесса Invoke RunBook выбирается необходимый RunBook (его создание описано ниже) и передаются параметры от связанных процессов (в нашем случае это процесс Get Alert). Так же установлена галочка напротив Wait for completion, которая управляет синхронностью – будет ли Invoke RunBook дожидаться выполнения вызываемого RunBook или нет.

Параметры на скриншоте определяются входящими параметрами вызываемого RunBook и определены в нем. В свойствах процесса нам остается лишь указать какие значения мы будем передавать в эти параметры. Передача значений из связанных процессов в текущий процесс называется подпиской (Subscription) – то есть процесс подписывается на результаты связанного с ним процесса(-ов). В данном случае нам нужно получить из процесса Get Alert выходные параметры (данные алертов). Подписка производится следующим образом – в нужном поле параметра (или скрипта) щелкаете правой клавишей мыши и из контекстного меню выбираете Subscription –> Published Data

Появляется окно со списком параметров процесса – выбираем необходимый и нажимаем ОК.

В поля вставляются своеобразные переменные в виде текстовой ссылки, нажав на которую можно вызвать окно с параметрами и поменять его на другой.

В процесс Invoke RunBook я передаю следующие параметры (у вас они могут быть другими, на ваше усмотрение):

• SiteServer – передается имя сервера DPM (параметр NetbiosComputerName из процесса Get Alert), что бы по нему определить в тиките инцидента площадку
• AlertID – передается Id (параметр Id из процесса Get Alert) алерта Operations Manager для последующего изменения алерта
• TicketName и TicketDesc – Имя и описание алерта (параметры Name и Description из процесса Get Alert), для заполнения темы инцидента в Service Desk

На этом цепочка процессов этого RunBook заканчивается.

RunBook 2

Второй RunBook выглядит так

Этот RunBook состоит из трех последовательных процессов. Разберем их по порядку.

Initialize Data

Initialize Data – это даже не процесс, а некий контейнер для входящих параметров (аналог объявления переменных для функции или процедуры в языках программирования). В нем мы определяем входные параметры и их тип.

Собственно вот все те параметры, для которых мы оформляли подписку в процессе Invoke RunBook предыдущего RunBook.

Вполне логично предположить, что создание данного RunBook должно предшествовать настройке процесса Invoke RunBook из предыдущего RunBook. Здесь я описываю процессы последовательно, дабы читатель не запутался.

Run .Net Script

Run .Net Script позволяет, как это видно из названия выполнить некий скрипт на одном из четырех языков программирования – PowerShell, JScript, C# и VB.Net

Данный скрипт мне понадобился для связи с системой ServiceDesk. Он готовит шаблон инцидента и потом создает инцидент в системе ServiceDesk через REST API использую cmdlet Invoke-RestMetod. Скрипт возвращает в переменную $TID номер тикета в системе ServiceDesk, который будет опубликован процессом для использования в следующем процессе. Делается это через вкладку Published Data свойств процесса.

В данной вкладке нажимаем Add… и выбираем Имя публикуемого параметра, его тип и имя переменной скрипта из которой будет взято значение для параметра.

Внимательный читатель обратил внимание на то, что в моем примере powershell скрипт “обернут” в процедурные кавычки powershell{}. Это сделано для того что бы скрипт выполнился в отдельном процессе powershell системы – тогда версия powershell будет системная (в моем случае powershell 3.0), иначе будет использоваться powershell System Center Orchestrator, а он использует powershell 2.0 – в нем нет новых cmdlet’s из версии 3.0 и выполнить Invoke-RestMetod не получится.

Update Alert

Последний процесс данного RunBook является Update Alert. С помощью него я изменяю алерт Operations Manager присваивая ему полученный из ServiceDesk в предыдущем процессе Ticket ID и меняю ResolutionState на Shelduled, для того, что бы данный алерт не попал в коллекцию алертов повторно при следующей итерации RunBook.

Настраиваем Connection – такой же как и в Get Alert. Свойство Alert ID подписываем на параметр Alert ID из процесса Initialize Data. Нажимаем Select fields… и добавляем свойства TiketId и ResolutionState. TiketId подписываем на параметр TID из процесса Run .Net Script, а для ResolutionState указываем Sсhelduled (или любой другой отличный от New).

Собственно вот и все. Описания всевозможных процессов System Center Orchestrator можно найти в документе TechNet Library - Runbook Activity Reference for System Center 2012 - Orchestrator - Standard Activities