none
Обработка условий в Оркестраторе RRS feed

  • Вопрос

  • Моделирую следующую ситуацию: Хочу использовать для всех заявок один шаблон, построенный на стандартном классе Инцидента с добавленным в него Ранбуком, который будет формировать в полях данные. Первый ранбук, непосредственно добавленный в шаблон, должен запускать другие ранбуки, в зависимости от значения поля "Категория классификации", на скрине я привел настройки его активностей:

    В "Инициализации данных" собраны все данные, необходимые для обоих ранбуков. Для данных заданы значения по умолчанию. Далее вытаскивается инцидент с заданным GUID, а после этого, в зависимости от значения "Категории классификации" должен вызываться один из ранбуков - Установка\Удаление ПО или Тех. поддержка пользователей. Значение Категории классификации выбирает сам пользователь на портале, а затем в "Сопоставлениях" эта категория записывается в шаблон:

    Проблема в том, что при описанном условии выборки по категории классификации действие до выбора ранбука не доходит. Если добавить к условиям "Get Object вернул успех", то будут вызываться оба ранбука одновременно.

    Заявка, полученная в результате работы скрипта, содержит в Категории классификации правильное значение - Установка-Удаление ПО (по началу думал на проблему с символом "\" в названии, не мог ли оркестратор интерпретировать его как вложенность, но изменив на "-" результат остался прежним)

    Каким образом следует организовать условие в данном случае?






    12 октября 2013 г. 7:58

Все ответы

  • Аналогично, описанным способом, я попытался организовать изменение значения в поле "Группа поддержки" в ранбуке "Установка\Удаление ПО", с той лишь разницей что теперь условие накладывалось на результат работы скрипта:

    Скрипт PS Execution 05 возвращает значение свойства Property_5 - название отдела исполнителя. В зависимости от этого значения нужно поменять Группу поддержки:


    В этом случае в результатах добавленные активности отображались как невыполненные. Скрин ошибки будет чуть позже.
    12 октября 2013 г. 8:33
  • Проблема в том, что при описанном условии выборки по категории классификации действие до выбора ранбука не доходит.



    Причина проблемы описана вами же выше.

    а затем в "Сопоставлениях" эта категория записывается в шаблон.

    В шаблон чего? Инцидента? Конечно, Ранбук понятия не имеет, чего вы сопоставили с шаблоном Инцидента, и не получает эти данные ;-)

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

    Либо заставьте ранбук эти данные для начала вытащить из родительского инцидента.


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.



    • Изменено Dismantled 12 октября 2013 г. 11:31
    12 октября 2013 г. 11:26
  • Вот в чем нюансы:

    1. Ранбук принимает в качестве входных данных только текст или простой список, а "Категория классификации" это, так называемый, "Список перечисления шаблона" (не ручаюсь за правильность, пишу по памяти). Одним словом в Сопоставлениях мне не дают выбрать в Ранбуке в качестве добавляемых данных "Категорию классификации".

    2. Но добавление в шаблон инцидента логично, ведь, как я понял, сначала создается экземпляр заявки, а уже потом запускается входящий в шаблон ранбук. Вот заявка, созданная моим ранбуком из первого поста:

    Тут видно, что поля "Категория классификации" и "Альтернативный вид связи" заполнились.

    3. Я и хочу сделать запрос экземпляра инцидента, для этого использую активность Get Object, она возвращает успех. Проблема в том, что условия к моему экземпляру к полю "Категория классификации" на последующих стрелках не срабатывают, от чего на Get Object все заканчивается.




    12 октября 2013 г. 12:40
  • Быть может:


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.

    12 октября 2013 г. 18:34
  • Предыдущее свое сообщение удалил, т.к. в действительности всё-таки отображаемое имя для Enumeration.

    И собственно, у меня всё работает нормально. Но я использую несколько извращенную логику обычно. В связи с тем, что в настройки соединения (в котором нам и надо установить фильтр) в фильтре нельзя установить условие AND, а только OR, то я обычно делаю так: оставляю Include-фильтр по-умолчанию ("PrevActivity" return success), а вот в Exclude-фильтре убираю все значения, которые мне не нужны. К примеру, в вашем случае в Exclude будет стоять "Категория классификации" doesn't equals "Установка\Удаление ПО 1" для шага, где как раз требуется выполнить логику для этого пункта.

    Посмотрите в Runbook Tester, что реально на выходе из GetObject. Это поможет.


    SCSMSolutions
    email: freemanru (at) gmail (dot) com

    14 октября 2013 г. 13:01
    Модератор
  • В результате тестирования выяснил, что те пункты в меню "Категория классификации", которые созданы в системе по умолчанию, имеют свои внутренние имена, не совпадающие с отображаемыми и написанные на английском. Поэтому условие и не могло сработать. А вот новые пункты, созданные пользователем, будут иметь одинаковое внутреннее и отображаемое имя.

    Что касается условия на результат работы скрипта. Тут дело было в том, что нужно выбирать Группу поддержки из предложенных вариантов, а не пытаться вводить вручную.

    От идеи с использованием ранбука Диспетчера отказались по тем причинам, что :

    1. Грузить один ранбук распределением ~50 типов заявок не надежно. И общая схема ранбука будет перегружена (50 значков вызова ранбуков).

    2. В Инициализации данных в ранбуке Диспетчера будет перечень объектов с 50 заявок, будет трудно не запутаться.

    3. При использовании одного шаблона инцидента все предложения запросов должны будут храниться в одном пакете. При неисправности пакета , например, возникших при операции экспорт\импорт, можно потерять всю систему. Поэтому буду делать каждый шаблон в отдельном пакете.

    4. Для эффективной работы шаблона Диспетчера нужно передавать в ранбук категорию классификации с портала, т.е. вынуждать пользователя в каждой заявке выбрать, какой она принадлежит категории в списке перечисления "Категория классификации". Пробовал сделать в каждом предложении запроса простой список, состоящий из одной записи категории, чтобы нельзя было изменить значение, но наличие не задействованного элемента на портале не представляется целесообразным. Таким образом для шаблонов из п.2 моего сообщения будет еще одно назначение - они будут хранить категорию классификации заявки.

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


    18 октября 2013 г. 1:06
  • Каким образом можно разделить инцидент на несколько из условия, что:

    1. Если выбран один компьютер, и три ПО, то на выходе получить три инцидента - по установке одного из ПО на указанный компьютер.

    2. Если выбрано три компьютера и одно ПО - получить три инцидента, по одному на каждый компьютер.

    3. Если указано три компьютера и три ПО, то получить, соответственно девять инцидентов.

    Тут ведь будет проблема в том, что один инцидент создастся в консоли сразу, получается его нужно так же учитывать. Просто необходимо делить такие заявки между несколькими специалистами по установке ПО.


    18 октября 2013 г. 10:26
  • Делайте это не инцидентами, а запросом на обслуживание. В ЗнО - Ранбук, который нагенерит вам РУчных действий, в зависимости от ваших условий. В ранбуке основным ядром вижу PowerShell с условиями и циклами.

    ЗЫ: Инцидент - это не установка ПО. Инцидент (по ITIL), это некое еденичное проблемное событие, решением к устранению которого может быть и установка (удаление, обновление и пр.) ПО.

    Поразмышляйте над политикой Инцидентов и ЗНО.


    Если сообщение оказалось полезным, пожалуйста, проголосуйте за него или пометьте в качестве ответа.


    • Изменено Dismantled 18 октября 2013 г. 12:21
    18 октября 2013 г. 12:19