«

»

Окт 24 2012

Распечатать Запись

Пара несложных скриптов под Naumen Service Desk 3.8

Написать в Naumen Service Desk скрипт, который бы реализовывал бы нужную функциональность – задача не из легких. Компания ЗАО “Россвязьсистема”, в которой я сейчас работаю, в прошлом году сертифицировалась по стандарту ISO20000:2005 и в этом году скорее всего пройдет повторный аудит уже по стандарту ISO20000:2011 (и все это, конечно же, не без моего участия). При выборе ПО Service Desk главным критерием была цена и в результате поисков было выбрано ПО Naumen Service Desk 3.8 (хотя нет… купили-то мы 3.6, а позднее уже я обновлял до 3.8). Поддержку по тем же материальным причинам купили минимальную, а она не подразумевает написание скриптов под наши требования, максимум что – дадут скрипт из своей библиотеки максимально близкий к нужному.  Это было бы вполне понятным бизнес-решением, если бы была хоть какая-то документация по скриптам, но адекватной документации нет (если не считать “Руководство по созданию сценариев”, но это скорее сборник примеров, нежели документация).

В свете всего выше сказанного и в условиях периодической потребности реализовать некоторый функционал скриптами приходится работать примерно так:

  1. Смотрим в руководстве что-то похожее на необходимый скрипт.
  2. Если не находим, то создаем запрос техподдержку Naumen и ожидаем ответа.
  3. После получение похожего скрипта из руководства или от техподдержки допиливаем его до удовлетворительного состояния методом проб и ошибок.

Ошибки, кстати, смотреть удобнее всего в разделе “Настройки”-“Консоль” (в самом низу страницы) – там будет лог последних событий. Примерно таким способом были написаны два ниже следующих скрипта.

Скрипт 1: При смене типа запроса оставить старое состояние

Название: При смене типа запроса, оставить старое состояние.

Что делает: При смене типа запроса пытается перевести запрос в состояние с кодом от предыдущего. Если перевести не удается, то об этом делается запись в историю запроса. При удачном переводе никаких дополнительных оповещений (например, оповещение ответственному о переводе запроса в новое состояние, если таковое настроено в системе) не отсылается.

Тип скрипта: Действия входа/выхода в/из состояния

Ограничение скрипта: Скрипт устанавливается на вход в начальное состояние для необходимых типов запросов (если надо для всех оставлять старое состояние, то придется повесить для всех типов запросов). Работоспособность скрипта для запросов на изменения не проверялась, но теоретически должен работать.

Проверенные версии Naumen Service Desk: 3.8.86.0

Тело скрипта:

Примечание 1: Закомментированные строки оставил из исходного скрипта, предоставленного техподдержкой, но в реальности я не совсем понял зачем они нужны, так как даже если вы выбираете сменить тип запроса, а конечный тип запроса оставляете тот же, что и был (т.е. реально ничего не меняете) система все равно проводит смену типа запроса:-) Как следствие, при наличии данного if-условия в этом случае старое состояние запроса не сохранится!

Примечание 2: Скрипт можно модернизировать: добавить параметр и в случае не возможности перевода в старое состояние, пробовать переводить еще и в состояние с кодом из параметра.

Скрипт 2: Условие на копирование атрибута при смене типа запроса

Название: Условие на установку времени назначения.

Что делает:Скрипт проверяет наличие какого-либо значения во флекс-атрибуте запроса. Если значение уже есть, то скрипт возвращает False, иначе – True.

Примечание: На выход из начального состояния в нашей системе настроено копирование из одного флекс-атрибута (в котором всегда просто значение по умолчанию – текущее время) в другой флекс-атрибут запроса “время назначения”. Тем самым фиксируется в атрибутах время, когда запрос был переведен из начального состояния. Но при смене типа запроса запрос переводится в начальное состояние и из него потом в нужное, а значит срабатывает копирование, которого не должно быть. Данный скрипт ставит условие на копирование -только один раз за всю жизнь запроса.

Тип скрипта: Условия на копирование значений атрибутов при входе/выходе в/из состояния

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

Проверенные версии Naumen Service Desk: 3.8.86.0

Тело скрипта:

Заключение

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

В дальнейшем думаю, продолжу выкладывать написанные мной скрипты – вдруг кому пригодятся:-)

14 комментариев

Перейти полю для комментария

  1. Анна

    добрый день.
    даже не думала найти друзей по несчастью)
    у нас тоже naumen 3.8 и в ходе работы с ним, больше года, что мы только не дорабатывали и не изменяли.
    очень хотелось бы делиться знаниями и умениями)
    скажите, пожалуйста, нет ли у вас скрипта кастомизации, который бы выводил в оповещение о согласовании информацию о предыдущем согласовании?) это очень нужно, но своими умениями этого я не достигла, а ТП только выпрашивает море денег для доработки.

    1. Stonekeeper

      Добрый день, Анна.

      В первую очередь, очень рад вашему комментарию, потому как не расчитывал, что кто-то кроеме самого Наумена заметит пост :-)

      Скрипта такого, к сожалению, нет. Да и с 3.8 мы уходим на 4.0 (недавно получил сертификат после курса Технолога Naumen SD 4.0), поэтому по 3.8 делиться знаниями не получится.

      По обозначенному вопросу лично мне понято, только как до нужно объекта в теории докопаться (получаем родителя текущего оповещения – это запрос, преобразуем его к реальному типу и копаемся в списке его согласований). Причем всю логику я бы запихнул в скрипт кастомизации, в котором сохранял нужную информацию в какую-нить переменную. А уж в самом оповещении выводил сию переменную. Но это все теория и на практике я бы навряд ли сумел реализовать такое…

      Как ни странно я в похожую тему начал копать на обучении. Интересовался на счет возможности реализации повторного согласования (в этом случае информация о предыдущем результате соглсования плучается в том же объекте и вытащить её проще). Минуя наши прения на обучении итог таков: в целом реализовать можно, но Якову (он проводил курс) не совсем понравилась такая идея – мол если уж что-то изменили, например, в плане ЗНИ, то это уже не повторное согласование, а новое. В целом 4.0 погибче в плане настройки по первым впечатления, поэтому есть надежда, что скриптов там поменьше надо будет. Плюс в рамках договора внедрения можно разумно израсходовать время на доработку и написание нужных скриптов, а не на установку самого приложения.

      Если интересно, то следите за обновлениями – я планирую написать пост по результатам нашего договора внедрения. Ориентировочно планируем основной функционал запустить к началу октября :-) А в остальном большие планы по автоматизации многих процессов и не только ITIL.

      1. Анна

        да уж) мы очень долго притирались к переходу на 4ку, но что-то так и не вышло у нас убедить начальство на этот шаг. у вас внедрено управление конфигурациями?)
         

        1. Stonekeeper

          В 3.8 по факту нет… только формально. В 4.0 буду внедрять, так как недавно повысли и стал начальником отдела, который как раз занимается инфраструктурой. Соответственно, мне самому оно стало надо, так как в экселевских файлах нормально учет вести сложно =) Да и знание и понимание ITIL и ISO20000 дает о себе знать – хочется по человечески организовать работу.
          На счет начальства – мы полгода на мозги капали про необходимость!

          1. Анна

            какие у вас интересные вообще доработки были?) вот хочу ваш первый скриптик проверить, дело полезное, имы тоже все страдали по этому поводу

      2. Анна

        что ж не пускает он на изменение типа запроса) говорит, что не выполнено условие перехода

        1. Stonekeeper

          Прошу прощения – в посте неправильно написал. Должно быть не условие, а действие при входе в состояние.

          Хотя можно помозговать и доработать до условия типа: если удается изменить состояние, то истина, иначе – ложь.

          1. Анна

            все равно так и не срабатывает скриптик у меня) падают запросы на регистрацию. эх
            ломаю голову над таким заданием, как автоматическое изменение регламентного времени закрытия при установленном сроке в атрибуте) никак
            вот в 4 также много проблем со скриптами или нет?
            помимо красивого интерфейса – чем он манит?)

          2. Stonekeeper

            На тему изменения регламентного времени закрытия – у ТП есть готовый скрипт… если вы заключали договор ТП хот бы минимальный – попросите у них, дадут 😉
            Количество проблем со скриптами в 4-ке покажет время, но по моим ощущениям будет примерно так же. Хотя один плюс точно уже есть – везде скрипты на groovy и не надо заморачиваться с тем, что импортировать в скрипте.
            Ну и кроме красивого интерфейса, я бы даже сказал на первом месте – пользовательские классы. Именно это в теории позволет автоматизировать на 4-ке любой процесс (разработка, документооборот, управление проектами и т.д.).

        2. Stonekeeper

          На счет доработок из насущного и крупного – это задачи в планировщике на автоматическую регистрацию запросов на регламентные работы. Но тут целая методика вкупе со скриптом. Причем методика дополнялась в ходе работы, так как всплывали нюансы. Если интересно, могу на досуге описать…

          По мелочи еще много было:

          • настраивал в скриптах один email, чтоб ему не слались письма;
          • разные сложные  логические выражения на условия отправки оповещения, чтобы не отсылать кому не надо;
          • запись в атрибут время перехода в определенное состояние;
          • повозился в свое время с настройкой срочности/критичности/приоритета (но это уже стандартный функционал);
          • полностью автоматические запросы на дежурства (чисто как напоминался и для фиксации потом в отчетности);
          • остальное уже не припомню…
  2. Анна

    не получится так) как нам списаться по почте?)

    1. Stonekeeper

      Вам по почте написал, а вообще мне всегда можно написать через форму на странице контактов.

  3. Алексей

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

    1. Stonekeeper

      Я сделал действие по на вход в состояние зарегистрирован для заявки.
      Вначале бы проверял, что по этой заявке надо регистрировать ЗНИ, а затем уж сама регистрация ЗНИ. Ответ на тему как зарегистрировать ЗНИ поискал бы сначала в мануале по скриптам, потом отправил бы запрос в тех.поддержку, ну и в крайнем случае начал бы копать доступные интерфейсы классов (просмотрел бы scriptutils и все с названием RFC).

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *