Комплексный интерфейс Service Desk на базе технологии Web-сервисов

В августе 2006 г. на одном из сайтов разработчиков ПО компании HP была опубликована информация о новом программном средстве для интеграции известной системы HP OpenView Service Desk с внешними системами. Консультанты компании «Ай-Теко» (http://www.i-teco.ru) проявили интерес к новому механизму интеграции, был установлен контакт с его разработчиками, а затем проведено тестирование функциональности. В данной статье рассматриваются общие характеристики нового программного средства для интеграции, включая внутреннюю логику его работы, и его тестирование.

На текущий момент многие компании, использующие в своей деятельности программные продукты HP, приобрели и успешно внедрили у себя систему на базе продукта HP OpenView Service Desk 4.5, что позволило им автоматизировать основные процессы управления ИТ-услугами, представленные в методологии ITIL. Практически во всех случаях внедрение этой системы и автоматизация таких процессов, как управление инцидентами, проблемами, конфигурациями, влечет за собой необходимость интеграции внешних систем с HP OpenView Service Desk (HP OV SD) для обмена объектами (например, заявками и инцидентами), а также различными справочными данными.

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

Кроме того, в HP OV SD имеется широкий набор возможностей настройки, что позволяет разрабатывать системы автоматизации на базе данного продукта, исходя из потребностей конкретного предприятия и его ИТ-инфраструктуры. Естественно, что подобная легкость настройки усложняет для разработчика продукта, компании HP, создание интерфейсов для взаимодействия, поскольку она вынуждена принимать во внимание все разнообразие решений, которые можно построить на базе продукта HP OpenView Service Desk 4.5.

Не так давно, задавшись целью решить данную проблему для партнеров HP и для других компаний, которые занимаются автоматизацией бизнес-процессов на предприятиях, группа разработчиков приступила к созданию легко конфигурируемого программного интерфейса для системы HP OV SD, выбрав для этого широко распространенную на сегодня технологию Web-сервисов. Разработанный ими программный продукт получил название OVSD Service Bridge.

Возможности Service Bridge

Как известно, ПО HP OpenView Service Desk 4.5 имеет несколько интерфейсов для доступа извне к объектам системы. Один из них, Web-API системы HP OV SD — это низкоуровневый, но при этом самый мощный по возможностям механизм, с помощью которого можно выполнять любые манипуляции с объектами системы, доступными через GUI. Но для интеграции с помощью этого интерфейса необходимо написать программный модуль на языке Java (и при этом, естественно, потребуется знание самой системы HP OV SD).

Почему мы упомянули Web-API системы HP OV SD? Дело в том, что OVSD Service Bridge представляет собой оболочку для низкоуровневого Web-API, которая обеспечивает набор простых в использовании Web-сервисов, реализующих следующие возможности:

• поддержку синхронных и асинхронных интерфейсов на основе Web-сервисов для обмена XML-документами (при этом сами Web-сервисы построены на основе общепринятых стандартов ИТ-индустрии);
• добавление новых объектов в HP OV SD, обновление данных существующих объектов и получение информации о них;
• добавление, обновление и удаление связей между существующими объектами в HP OV SD;
• генерацию передачи данных в другие приложения в результате создания или обновления объектов в HP OV SD;
• поддержку обновления одного объекта или пакетного обновления объектов вместе со связями объектов;
• извлечение информации из системы HP OV SD;
• прикрепление вложений к объектам в HP OV SD.

Принцип работы

Service Bridge предоставляет пользователям два универсальных Web-сервиса. Один из них сконфигурирован для работы в синхронном режиме, он принимает входящие вызовы, обрабатывает содержимое сообщений и возвращает результат вызывающей стороне через то же самое соединение, подтверждая, что транзакция обработана. Второй Web-сервис работает в асинхронном режиме, принимая входящие вызовы, сохраняя сообщение во внутренней очереди сообщений и затем посылая подтверждение того, что сообщение принято. После того как транзакция будет завершена, посылается также подтверждение, что сообщение обработано.

Когда любой из двух Web-сервисов получает сообщение, Service Bridge проверяет содержимое сообщения, используя XML-схему. Схема определяет допустимую структуру и содержание сообщения. После проверки сообщение подвергается процессу XML-трансформации. Этот процесс определяется для каждого типа сообщений при помощи XSL-стилей (eXtensible Stylesheet Language). Благодаря этому процессу входящее XML-сообщение не обязано соответствовать какому-либо формату системы HP OV SD. В сущности, если в сообщении содержится достаточно информации для выполнения транзакции, интерфейс может принять XML-файл с весьма произвольным содержанием и успешно обработать сообщение. Эта функциональность особенно необходима в случае интеграции в среде различных систем, так как вызывающая система не обязана содержать какую-либо информацию об объектах системы HP OV SD, их атрибутах или взаимосвязях.

В листинге 1 приведен пример XML-сообщения, посылаемого в Service Bridge системой мониторинга. Допустим, эта система отслеживает статус и доступность устройств, таких, как серверы и маршрутизаторы. Если возникает событие, когда устройство перестает отвечать на запросы, система мониторинга должна отправить сообщение New_Event в систему HP OV SD. Так как система мониторинга не имеет возможности напрямую создать инцидент или заявку в системе HP OV SD, она просто отправляет сообщение New_Event, а Service Bridge выполняет конвертирование.

  <?xml version=»1.0″ encoding=»UTF-8″ ?>

— <Ovsd_ServiceBridge_Inbound schemaVersion=»1.0″>

  — <New_Event>

      <Event_Id>23411</Event_Id>

      <Event_Description>Hard drive failure</Event_Description>

      <Device_code>SRVHP001</Device_code>

    </New_Event>

  </Ovsd_ServiceBridge_Inbound>

В листинге 2 для пример приведена часть XSL-стиля. После применения стиля к сообщению о событии из листинга 1 генерируется набор команд для модуля OVSD, который показан в листинге 3.

<?xml version=»1.0″ encoding=»iso-8859-1″?>

<xsl:stylesheet version=»1.0″ xmlns:xsl=»http://www.w3.org/1999/XSL/Transform»>

<xsl:output method=»xml» encoding=»iso-8859-1″ indent=»yes»/>

<xsl:strip-space elements=»*»/>

<xsl:template match=»Ovsd_ServiceBridge_Inbound/New_Event»>

<Ovsd_Actions>

<!— Check for an existing servicecall already created for this Event_Id … —>

<Ovsd_Find execOrder=»1″ entityName=»servicecall_1″ entityType=»Servicecall»

multipleAllowed=»no» >

<!— … using value of Event_Id node as a search parameter —>

<Ovsd_Find_Param attrName=»SourceID» attrType=»String»>

<xsl:value-of select=»Event_Id»/>

</Ovsd_Find_Param>

<!— if no existing servicecall found, open a new one —>

<Ovsd_NotFound_Actions> 4

<Ovsd_OpenNew>

<Ovsd_OpenNew_Template>SMARTS</Ovsd_OpenNew_Template>

</Ovsd_OpenNew>

</Ovsd_NotFound_Actions>

</Ovsd_Find>

<!— Find a configuration item … —>

<Ovsd_Find execOrder=»2″ entityName=»configurationItem_1″

entityType=»ConfigurationItem» notFound=»ignore» multipleAllowed=»yes»>

<!— … using value of Device_code node as a search parameter —>

<Ovsd_Find_Param attrName=»Searchcode» attrType=»String»>

<xsl:value-of select=»Device_code»/>

</Ovsd_Find_Param>

</Ovsd_Find>

<!— Link servicecall with configuration item —>

<Ovsd_Set execOrder=»3″ entityName=»servicecall_1″ attrName=»ConfigurationItem»

attrValue=»configurationItem_1″/>

<!— Set servicecall Description attribute using value of Event_Description node—>

<Ovsd_Set execOrder=»4″ entityName=»servicecall_1″ attrName=»Description»

attrType=»String» maxLength=»80″ newLines=»Windows»>

<xsl:value-of select=»Event_Description»/>

</Ovsd_Set> 

Для выполнения требуемой транзакции модуль OVSD использует конвертированный XML-документ (листинг 3). Этот модуль обработки сообщений действует как интерпретатор команд, и логика его работы целиком определяется командами из конвертированного XML-файла. Модуль OVSD читает XML-файл и выполняет команды, вызывая соответствующие API-команды интерфейса Web-API системы HP OV SD.

  <?xml version=»1.0″ encoding=»iso-8859-1″ ?>

— <Ovsd_Actions>

  — <Ovsd_Find execOrder=»1″ entityName=»servicecall_1″ entityType=»Servicecall» multipleAllowed=»no»>

        <Ovsd_Find_Param attrName=»SourceID»>23411</Ovsd_Find_Param>

    — <Ovsd_NotFound_Actions>

      — <Ovsd_OpenNew>

          <Ovsd_OpenNew_Template>SMARTS</Ovsd_OpenNew_Template>

        </Ovsd_OpenNew>

      </Ovsd_NotFound_Actions>

    </Ovsd_Find>

  — <Ovsd_Find execOrder=»2″ entityName=»configurationItem_1″ entityType=»ConfigurationItem» notFound=»ignore» multipleAllowed=»yes»>

      <Ovsd_Find_Param attrName=»Searchcode» attrType=»String» />

    </Ovsd_Find>

    <Ovsd_Set execOrder=»3″ entityName=»servicecall_1″ attrName=»ConfigurationItem» attrValue=»configurationItem_1″ />

    <Ovsd_Set execOrder=»4″ entityName=»servicecall_1″ attrName=»Description» attrType=»String» maxLength=»80″

                   newLines=»Windows»>Event description</Ovsd_Set>

    <Ovsd_Set execOrder=»5″ entityName=»servicecall_1″ attrName=»SourceID» attrType=»String»>11</Ovsd_Set>

    <Ovsd_Save entityName=»servicecall_1″ />

  — <Ovsd_Out>

    — <Ovsd_ServiceBridge_Outbound schemaVersion=»1.0″>

      — <New_Event_Ack>

          <Event_Id>23411</Event_Id>

        — <Servicecall_Id>

            Ovsd_Get_Place_Holder

            <Ovsd_Get entityName=»servicecall_1″ attrName=»Id» />

          </Servicecall_Id>

        </New_Event_Ack>

      </Ovsd_ServiceBridge_Outbound>

    </Ovsd_Out>

  — <Ovsd_Error>

    — <Ovsd_ServiceBridge_Outbound schemaVersion=»1.0″>

      — <New_Event_Error>

          <Event_Id>23411</Event_Id>

          <Error_Message>Ovsd_Error_Place_Holder</Error_Message>

        </New_Event_Error>

      </Ovsd_ServiceBridge_Outbound>

    </Ovsd_Error>

  </Ovsd_Actions>

После того как модуль OVSD завершил создание, обновление объектов или извлечение информации, он выполняет одно из двух следующих действий. Если транзакция была успешной, модуль обработает команды, определяющие, какие данные должны быть отправлены обратно. Ответное сообщение, в свою очередь, может состоять из любых данных, которые есть в системе HP OV SD: например, в случае с событием New_Event системе мониторинга требуется отправить в ответ идентификатор заявки, который был сгенерирован системой HP OV SD.

Если при попытке проведения транзакции возникла ошибка, модуль обработки сообщений выполнит команды обработки ошибок, содержащиеся в XML-файле. Этот набор команд определяет формат и содержание сообщения об ошибке, которое следует отправить в ответ.

В листинге 4 приведен пример ответного сообщения, которое будет отправлено в случае успешного завершения транзакции. Результатом этого обмена сообщениями будет новая заявка в системе HP OV SD (рис. 1).

  <?xml version=»1.0″ ?>

— <Ovsd_ServiceBridge_Outbound schemaVersion=»1.0″>

  — <New_Event_Ack>

      <Event_Id>23411</Event_Id>

      <Servicecall_Id>390</Servicecall_Id>

    </New_Event_Ack>

  </Ovsd_ServiceBridge_Outbound>

Рис. 1. Новая заявка в системе HP OV SD.

Как определить новый интерфейс

Логика работы механизма Service Bridge устроена таким образом, что позволяет без особых сложностей определить и добавить новый тип интерфейса или входящего сообщения. Для этого Service Bridge требует создать два конфигурационных файла: XML-схему, которая будет служить для проверки входящего документа, и XSL-стиль для преобразования сообщения в формат, необходимый для модуля обработки сообщений системы HP OV SD.

После того как эти два файла будут помещены в нужный каталог, новый интерфейс будет автоматически доступен для синхронного и асинхронного интерфейсов.

Масштабируемость и управление

Service Bridge — это приложение на основе стандартов J2EE, которое функционирует под управлением сервера J2EE-приложений (рис. 2).

Рис. 2. Схема работы механизма Service Bridge.

Архитектура взаимодействия программных компонентов Service Bridge построена следующим образом: сервер приложений управляет всеми компонентами механизма (в течение их жизненного цикла) и динамически распределяет нагрузку между ними. Эта особенность и тот факт, что все компоненты обрабатывают каждую транзакцию независимо от предыдущей, позволяет масштабировать решение несколькими способами. Самый простой из них — изменить конфигурацию сервера приложений, а именно увеличить объем ресурсов, выделяемых для каждого компонента. Это увеличит число объектов в пуле, ожидающих обработки входящих сообщений.

Такая стратегия ограничена только числом сообщений, которое может обработать сервер приложений, и возможностью Web-API системы HP OV SD поддерживать несколько параллельных подключений (и соответственно транзакций). Если сервер приложений или Web-API оказываются узким местом, то, учитывая возможность независимой обработки транзакций, для увеличения пропускной способности и поддержки доступности альтернативным методом будет запуск дополнительного сервера приложений с конфигурацией с балансировкой нагрузки.

Практический опыт

Описание нового механизма интеграции, опубликованное разработчиками, содержит достаточно подробную информацию о Service Bridge, раскрывает внутреннюю логику его работы, способ взаимодействия с системой HP OV SD и даже возможности масштабирования данного механизма. С теорией, как говорится, не поспоришь, но без проверки на практике оценить преимущества и недостатки данного механизма достаточно сложно.

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

Здесь мы немного отступим от рассказа о тестировании и приведем примеры тех задач, которые в основном приходится решать при интеграции системы HP OV SD с внешними системами:

• создание заявок, инцидентов по какому-то событию во внешней системе;
• обновление данных в существующих заявках и инцидентах;
• прикрепление файлов к заявкам, инцидентам и другим объектам системы HP OV SD (при их создании или при обновлении данных по объектам);
• пакетное создание объектов и/или обновление данных в объектах системы HP OV SD.

Ниже мы покажем, в какой степени с помощью нового средства интеграции можно решать данные задачи.

Подготовка к тестированию

Начнем описание нашего опыта тестирования Service Bridge с описания того, что требуется для его успешной установки и использования. Исходя из полученной документации по установке, необходимы следующие программные продукты:

• HP OV SD 4.5 Service Pack 18 (с этим пакетом обновления Service Bridge тестировался разработчиками);
• Java Development Kit (JDK) 1.4.2;
• JBoss Application Server (JBoss AS) — в документации было указано, что необходима версия 4.0.3 (SP1).

На момент написания данной статьи мы активно использовали в проектах систему HP OV SD (SP13), которая работает с предыдущей версией Java — 1.3.1_03. Таким образом, прежде чем использовать Service Bridge, нам пришлось провести обновление всей системы до SP18, что имело некоторые нюансы: например, требование наличия Java версии 1.4.2 повлекло за собой обновление JDBC-драйвера для Oracle. Информация об этом была найдена в документации по установке одного из пакетов обновления для системы HP OV SD — в документе HP OpenView Service Desk 4.5 JRE 1.4.2 Migration Guide.

Установка и настройка J2EE-сервера JBoss AS 4.0.3 (SP1) — достаточно простая операция, которая состоит из извлечения файлов из архива, копирования полученных файлов в произвольный каталог (например, C:jboss-4.0.3SP1), затем определения необходимых переменных ОС. Единственная проблема, которая может встретиться при установке JBoss AS, состоит в том, что порт 8080, используемый этим приложением по умолчанию, может быть занят приложением Tomcat, или Oracle XML DB, или каким-то другим приложением. Эта проблема легко разрешается внесением соответствующих изменений в конфигурационный файл.

Установка самого Service Bridge состояла практически из тех же операций, что и установка J2EE-сервера, и также не вызвала трудностей. И вот после несложных манипуляций с архивами и переменными окружения подготовку к старту можно было считать законченной. Проверить правильность установки предлагалось следующим образом: ввести в строке браузера http://localhost:8080/ws4ee/services; при получении картинки, показанной на рис. 3, можно было непосредственно приступать к проверке возможностей Service Bridge.

Рис. 3. Проверка правильности установки Service Bridge.

Проверка возможностей Service Bridge

Разработчики Service Bridge подготовили достаточно функциональный демопакет, содержащий необходимые конфигурационные файлы, XML-файлы и XSL-стили, и после установки и настройки всех необходимых компонентов мы легко смогли проверить возможности Service Bridge, заявленные в анонсе.

Наиболее часто встречающаяся задача при интеграции HP OV SD с внешними системами — создание объектов на основе некоторого события, например, заявки или инцидента. Чтобы проверить, как Service Bridge справится с этой задачей, мы запускали из демопакета консольную утилиту run_ws_client.bat с необходимыми параметрами (рис. 4).

Рис. 4. Создание заявки с помощью Service Bridge.

Как видно из рис. 4, была создана заявка с номером 166, результат работы утилиты выдан в формате XML и выведен на консоль. Соответственно тот же результат легко вывести в XML-файл, который затем может анализироваться вызывающей системой, инициировавшей создание заявки.

Таким же образом, т. е. путем вызова консольной утилиты с необходимыми параметрами, удалось изменить значения атрибутов в уже существующей заявке и прикрепить к ней вложения. Но с созданием объектов и изменением данных в существующих объектах легко справляются интерфейсы и утилиты, входящие в состав системы HP OV SD, например, SD Event, Data Exchange; это можно также сделать с помощью электронной почты и Web-API.

Итак, мы вплотную подошли к обсуждению проблемы, очень часто возникающей при интеграции, — передачи вложенных файлов, прикрепленных к объектам, между системами. Что касается упомянутых выше интерфейсов, можно отметить, что с помощью SD Event нельзя передавать вложения, а построить с помощью электронной почты процесс интеграции, заключающийся, к примеру, в создании заявок, конечно, можно, но по нашему опыту этот процесс крайне нестабилен, так как зависит от многих составляющих, например от почтового сервера. Обмен информацией может быть достаточно медленным; кроме того, очень часто возникают проблемы с кодировкой писем, с вложениями, где имена файлов были на русском языке.

Остается Web-API, с помощью которого можно творить чудеса, но и у него, как оказалось, есть свои подводные камни, и некоторые из них как раз обнаружились при решении такой задачи, как передача вложенных файлов. При прикреплении файла к объектам системы HP OV SD через Web-API имеются следующие ограничения:

• прикрепляемый файл должен находиться на сервере приложений системы HP OV SD — естественно, это неудобно, так как файл обычно располагается на стороне передающей системы;
• если файл находится на другом сервере, то сервер приложений должен иметь к нему доступ, т. е. фактически папка, где лежит файл, должна быть расширена, что на практике не допускается службами информационной безопасности;
• Web-API системы HP OV SD пока не умеет распознавать URL-пути к файлам, начинающиеся с http:// или ftp://. Если бы такая возможность была, вышеупомянутые ограничения было бы легко обойти.

Эти ограничения упомянуты не случайно — наоборот, вполне преднамеренно, поскольку даже небольшой опыт использования Service Bridge показал, что вложения с его помощью передаются без проблем из любого места (этот механизм сериализует содержимое файла и передает его непосредственно в запросе).

Итоги и вопросы

Итак, какие можно сделать выводы и остались ли еще вопросы для дальнейшего исследования механизма Service Bridge?

Исходя из описания и небольшого опыта практического использования, мы понимаем, что механизм Service Bridge обеспечивает гибкое решение для интеграции различных систем с HP OV SD и потенциально с другими системами с использованием интерфейсов, основанных на общепринятых стандартах Web-сервисов. Service Bridge легко сконфигурировать с помощью XML-схем и XML-стилей для поддержки самых разнообразных стилей и структур интерфейсов.

Из вопросов, невыясненных на момент написания статьи, остались следующие.

Асинхронный интерфейс Service Bridge. Этот интерфейс, естественно, более сложен, но и предоставляет больше возможностей для нестандартных случаев интеграции. К сожалению, в демопакете не было всего необходимого, чтобы протестировать данную функциональность, но ее изучение будет продолжено при поддержке разработчиков Service Bridge.

Пакетная передача данных из внешних систем в HP OV SD — например, данных о сотрудниках и оргструктуре предприятия из Active Directory или другой справочной системы. Данная задача востребована в любом проекте внедрения процесса управления инцидентами и в принципе она легко и достаточно успешно решается с помощью стандартного механизма системы HP OV SD — Data Exchange. В данном случае для нас остался открытым вопрос о сравнении работы Service Bridge и Data Exchange при выполнении пакетной загрузки данных в систему HP OV SD.

Тестирование скорости работы Service Bridge и работы при большой нагрузке. Это важно для того, чтобы иметь полноценное представление об этом средстве для интеграции и сравнить его производительность с другими интерфейсами системы HP OV SD. Возьмем, к примеру, такой случай: возможна ситуация, когда из системы мониторинга будет идти очень большой поток сообщений с очень маленьким интервалом. Вполне вероятно, что SD Event справится с таким потоком эффективнее, чем Service Bridge — а возможно, наоборот…

Использование Service Bridge и поддержка продукта компанией-разработчиком. Этот вопрос также необходимо решить по объективным причинам. На текущий момент ведется переписка с разработчиками Service Bridge, и мы не сомневаемся, что положительный ответ будет получен в ближайшее время, что позволит применять данное решение для интеграции уже не в целях тестирования.

Благодарности

Автор выражает благодарность разработчикам системы Service Bridge: Kononov Dmitri (Senior Technical Consultant, HP) и Czarnecki Thomas (Senior Technical Consultant, HP).