Улучшение приложений, опирающихся на IBM Intelligent Operations Center

Как управлять операциями

IBM Intelligent Operations Center поддерживает стандартные рабочие процедуры. При возникновении инцидента для каждого определенного в процедуре шага создается операция. Настоящая статья рассказывает о том, как архитекторы и разработчики могут изменять существующие инструменты и создавать новые для представления данных пользователю и получения данных от пользователя в рамках операции, а также записывать представленные и полученные данные и передавать их в последующую операцию в рамках одного инцидента.

Айдан Кларк, ИТ-архитектор, IBM

Photo of Aidan ClarkeАйдан Кларк (Aidan Clarke) работает ИТ-архитектором в IBM Software Group. Он обладает более чем 30-летним опытом работы в области информационных технологий, главным образом в роли программиста. В настоящее время он работает в организации Industry Solutions, где занимается линейкой продуктов IBM i2 Intelligence Analysis.



Брайан Дэли, программист, IBM

Photo of Brian DalyБрайан Дэли (Brian Daly) — программист в группе IBM Industry Solutions Development в технологическом городке в Малуддарт, Ирландия. Он занят разработкой нового контента, расширяющего диапазон предложений Industry Solutions.



Артур Гженкович, старший разработчик Java, IBM

Photo of Artur GrzenkowiczАртур Гженкович (Artur Grzenkowicz) является старшим разработчиком Java и сотрудником группы IBM Industry Solutions Development в технологическом городке IBM в Малуддарт, Ирландия. В настоящее время занимается линейкой продуктов IBM i2.



Кевин Китинг, инженер-программист, IBM

Photo of Kevin KeatingКевин Китинг (Kevin Keating) является инженером-программистом и сотрудником группы Industry Products в составе IBM Software Group. Он разработал демонстрационные версии систем публичной безопасности на основе Intelligent Operations Center.



Винсент Келли, менеджер по разработке, IBM

Photo of Vincent KellyВинсент Келли (Vincent Kelly) — менеджер по разработке, работающий в Ирландской лаборатории, входящей в состав Industry Solutions Group. В настоящее время работает с недавно приобретенными продуктами i2 в отделе Общественной безопасности. До этого занимал различные руководящие должности в научно-исследовательских подразделениях компаний IM и Lotus.



Джейми О'Лири, инженер-программист, IBM

Photo of Jamie O'LearyДжейми О'Лири долго работал с семейством продуктов Lotus Connections, занимаясь разработкой интерфейсов и инструментов поиска в социальных сетях в Java 2 Platform, Enterprise Edition (J2EE), а затем перешел в подразделение Industry Solutions, где занимался интеграцией баз данных между собственными приложениями платформы и службами J2EE. В настоящее время Джейми разрабатывает прототипы расширений для Intelligent Operations Center.



05.06.2013

Введение

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

Тем не менее существует много базовых структурных требований, которые являются общими для всех этих отраслей:

  • Сигналы поступают из большого числа источников
  • Необходима организация группы реагирования
  • Необходима поддержка стандартных рабочих процедур
  • Необходимо следить за эффективностью по ключевым показателям
  • Необходимо вносить усовершенствования

IBM Intelligent Operation Center представляет собой программную среду, которая поддерживает реализацию таких решений, предлагая поддерживающую эти возможности архитектуру. Она предоставляет несколько точек интеграции, с помощью которых поставщики решений могут реализовать специальные ускорители. Подробная информация об IBM Intelligent Operations Center V1.5 приведена в выпуске United States Software Announcement 212 – 250 от 3 июля 2012 года (см. раздел Ресурсы).

Стандартные рабочие процедуры

Стандартные рабочие процедуры (или SOP) представляют собой набор предопределенных шагов, направленных на обеспечение эффективного реагирования на инцидент за счет координации деятельности людей, продуктов и процессов. Шаги могут быть дополнительно определены в виде серии операций; они могут начинаться без обратной связи или требовать некоторого уровня обратной связи перед переходом SOP к следующему шагу. Тип обратной связи зависит от конкретной операции.

При этом существует ряд общих требований: система должна знать время начала и окончания операции; необходимо обеспечить взаимодействие с людьми; нужно генерировать новые сигналы. Intelligent Operations Center поддерживает некоторые из этих возможностей за счет интеграции с IBM Tivoli Service Request Manager.

Наиболее распространенный сценарий применения SOP, в настоящее время не поддерживаемый в Intelligent Operations Center, заключается в том, что операция требует от оператора некоторого ответного действия или передачи определенного набора данных. Как правило, для поддержки такого сценария используются формы. На сайте Федерального агентства по чрезвычайным ситуациям США (FEMA) приведено множество форм, охватывающих всевозможные операции (см. раздел Ресурсы).

Стандартные рабочие процедуры в Tivoli Service Request Manager

Для создания SOP в Tivoli Service Request Manager необходимо использовать три инструмента Intelligent Operations Center: стандартную рабочую процедуру, матрицу выбора и план реагирования. SOP состоит из полного набора составляющих процедуру шагов и операций. Пример SOP в контексте обеспечения общественной безопасности приведен на рисунке 1.

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

Рисунок 1. Пример SOP в консоли Tivoli Service Request Manager
SOP example in Tivoli Service Request Manager console

(увеличенная версия рисунка 1)

Для построения матрицы выбора SOP используется приложение SOP Selection Matrix. Эта матрица определяет значения селектора SOP на основе категории, опасности, достоверности и срочности события. Значение матрицы выбора SOP для угрозы взрыва равно 7, что можно видеть на рисунке 1.

Затем на основе плана реагирования производится выбор применяемой SOP по значению селектора SOP — см. рисунок 2.

При создании в Tivoli Service Request Manager инцидента Intelligent Operations Center, запускаемого событием Operations Center, значение селектора SOP для инцидента выбирается на основе матрицы выбора SOP, которая, в свою очередь, опирается на параметры события. События Intelligent Operations Center запускают Tivoli Service Request Manager, который создает инцидент. Применение параметров события к матрице выбора для создания значения селектора и сопоставление этого значения с планом реагирования Intelligent Operations Center определяет SOP, который присваивается этому событию.

Рисунок 2. Пример плана реагирования в консоли Tivoli Service Request Manager
Response Plan example in Tivoli Service Request Manager console

(увеличенная версия рисунка 2)

Текущий подход Intelligent Operations Center к SOP

Инцидент Intelligent Operations Center создается в Tivoli Service Request Manager при каждом получении сигнала Протокола всеобщего оповещения — Common Alerting Protocol (CAP). К каждому инциденту применяется соответствующая SOP; при этом портлет операций в консоли Intelligent Operations Center отображает все связанные операции.

Несмотря на то, что портлеты, предлагаемые Intelligent Operations Center, допускают некоторый уровень взаимодействия с нижележащими операциями Tivoli Service Request Manager, это взаимодействие ограничено, и изменения не всегда отражаются в нижележащем инструменте. Чтобы отредактировать инциденты и операции Intelligent Operations Center таким образом, чтобы изменения полностью отражались в Tivoli Service Request Manager, Intelligent Operations Center передает соответствующую ссылку в Web-интерфейс Tivoli Service Request Manager. Стиль этого интерфейса отличается от стиля интерфейса пользователя Intelligent Operations Center, поэтому пользователи Intelligent Operations Center могут испытывать при работе с ним некоторые неудобства.

Формы

Давайте обсудим подход к расширению Intelligent Operations Center, обеспечивающему поддержку получения обратной связи в виде формы. Разработку формы и бизнес-сценария мы рассматривать не будем.

Для поддержки форм для конкретных операций Intelligent Operations Center необходимы следующие основные компоненты:

  • Реестр, описывающий взаимосвязи между операциями и формами
  • Портлет контейнера формы, который реагирует на выбор операции
  • Механизм сохранения структур данных экземпляра операции
  • Механизм редактирования операции

Ниже описан наш подход к реализации этих компонентов.


Наше дополнение к текущему подходу

Исходный сценарий применения заключался в представлении пользователям относящихся к операции данных, получении данных от пользователей, сохранении этих данных и использовании их в контексте последующих операций. Для поддержки этого сценария мы применили и расширили функциональность некоторых существующих портлетов Intelligent Operations Center.

Кроме того, мы получали дополнительные сведения об инцидентах, используя географические координаты для определения того, какие из зарегистрированных ресурсов расположены поблизости от места возникновения инцидента. Эта дополнительная информация сохранялась и привязывалась к инциденту, так что ее могли просматривать и изменять различные операции в рамках инцидента. Также мы предусмотрели дополнительные функции для непосредственного обновления состояния операции, что раньше делалось через интерфейс пользователя Tivoli Service Request Manager с помощью ссылки, предоставляемой Intelligent Operations Center.

Диаграмма на рисунке 3 показывает дополнения к текущим функциям поддержки операций Intelligent Operations Center. Слева приведен текущий процесс обработки Intelligent Operations Center, а справа – наши дополнения. Номера в позициях справа обозначают последовательность шагов, которую реализуют наши программные компоненты. Детально они будут описаны в следующем разделе настоящей статьи.

Рисунок 3. Наш подход в текущей версии Intelligent Operations Center
Diagram with our approach on the current Intelligent Operations Center

Пример сценария, использующего наш подход

К созданию представленного решения нас подтолкнула необходимость поддержки некоторых стандартных рабочих процедур по управлению чрезвычайными ситуациями, связанными со сложными погодными условиями. После того как Intelligent Operations Center зарегистрирует событие, ведущее к возникновению инцидента, запускается последовательность операций согласно соответствующему SOP.

В действительности некоторые операции могут потребовать ручного вмешательства ряда пользователей Intelligent Operations Center, таких как оператор штаба управления ЧС, руководитель штаба управления ЧС и другие официальные лица, ответственные за обеспечение общественной безопасности.

Ниже описан ход событий:

  • Поступает сигнал CAP
  • Вниманию оператора штаба управления ЧС представляется операция
  • Оператор выбирает соответствующую операцию
  • Отображается форма, показывающая ресурсы вблизи места возникновения инцидента, которые необходимо выбрать
  • Оператор выбирает ресурсы
  • Операция помечается как завершенная
  • Оператору представляется следующая операция
  • Руководитель штаба управления ЧС видит список ресурсов, выбранных оператором
  • Руководитель утверждает выбранные ресурсы
  • Операция помечается как завершенная

Модификации портлета операций

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

Когда пользователь выбирает операцию, портлет вызывает сервлет с помощью метода dojo.xhrGet. URL сервлета принимает два параметра: операцию с именем getActivityInformation и activityID. Кроме того, метод dojo.xhrGet загружает функцию обратного вызова, которая вызывается при возвращении данных сервером. Возвращаемые данные имеют формат JSON. После синтаксического разбора в той же функции обратного вызова ответ сервлета dojo.xhrGet публикуется с помощью метода dojo.publish. Впоследствии данные операции могут использоваться другими портлетами и виджетами, размещенными на той же странице, где находится портлет операций. В нашем примере их использует портлет форм, который мы опишем позже.


Сервлет, извлекающий дополнительные данные операции

Когда пользователь выбирает операцию в модифицированном сервлете операций, сервлет операций публикует информацию о выбранной операции в теме Dojo. Опубликованная в теме информация должна уникально идентифицировать шаг в SOP, который соответствует этой операции, — то есть определять тип шага.

В качестве типа операции мы используем объединение номера шага и идентификатора SOP (ID), например, для операции, соответствующей шагу 20 в SOP с именем "WCONFIRMED", тип равен WCONFIRMED_20.

В портлете операции эта информация недоступна, поэтому мы использует сервлет для извлечения этой информации из Web-сервисов Tivoli Service Request Manager MXWO и MXINCIDENT. Мы использовали Web-сервисы Tivoli Service Request Manager, потому что база данных Intelligent Operations Center не хранит SOP ID в своих таблицах.

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

Таблица 1. Элементы JSON, возвращаемые сервлетом для каждой операции.
Имя элемента Описание
sequenceNo Номер шага в SOP (WOSEQUENCE из Web-сервиса MXWO).
ticketId Идентификатор инцидента, связанный с операцией (ORIGRECORDID из Web-сервиса MXWO).
activityId Идентификатор операции (WONUM в Web-сервисе MXWO).
SoPId Идентификатор SOP (TEMPLATEID из Web-сервиса MXINCIDENT).
uniqueStepIdentifier 'Тип' операции, представляющий собой объединение SoPId и sequenceNo.

Портлет форм

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

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

Реализация

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

Создание экземпляра формы

Когда операция выбрана, сообщение передается на Web-страницу с помощью публикации Dojo. Контейнер формы подписывается на эту публикацию и использует информацию, отправленную для определения корректной формы для загрузки. Таблица реестра в базе данных распределяет идентификаторы операций, формируя имена классов и позволяя выполнять вызовы API, которые возвращают имя класса виджета формы, привязанного к выбранной операции. С помощью отражения контейнер формы создает экземпляр нужной формы и передает информацию об операции.

Жизненный цикл формы

Каждый виджет формы представляет собой виджет в стиле Dojo со своим собственным шаблоном и набором API. Используя информацию, переданную в форму в момент создания, виджет формы может обращаться к разным API для определения типа текущей инцидента, ее местоположения и т.п. Каждая форма может иметь уникальную функциональность, позволяющую обрабатывать разные операции. Например, можно создать форму, отображающую ресурсы в зоне инцидента и позволяющую оператору выбрать нужные ресурсы для обработки ситуации. Затем форма может сохранить введенную пользователем информацию в базе данных с помощью вызовов API. В дальнейшем эти сохраненные данные могут использоваться в иных формах инцидента при просмотре других операций. После того как форма достигнет необходимой конечной точки, она известит контейнер о завершении работы.

Завершение операции

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


Сервлет, обновляющий состояние операции

Этот сервлет позволяет обновлять состояние операции в Tivoli Service Request Manager. В качестве параметров передается идентификатор операции activityId и новое состояние. Для обновления состояния выбранной операции сервлет использует Web-сервис MXWO.


Дополнительные таблицы базы данных

В базу данных Intelligent Operations Center были добавлены следующие таблицы.

Таблица IOC.JSON

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

Эта таблица содержит одну строку для каждой заполненной пользователем формы. Таблица имеет следующие поля:

Таблица 2. Поля таблицы IOC.JSON и их описания
Имя поля Описание
ID Первичный ключ таблицы.
INCIDENT_ID Идентификатор инцидента.
FORM_ID Идентификатор формы в инцидента.
JSON Данные, полученные от пользователя с помощью этой формы.

Каждый экземпляр формы связан с инцидентом и уникальным образом идентифицируется в ее контексте.

Таблица IOC.FORMID

Эта таблица привязывает тип формы к шагу в SOP, то есть к типу операции. Портлет форм использует эту таблицу для определения того, какую форму отображать для данного типа операции. Как мы уже видели, тип операции представляет собой объединение идентификатора SOP с порядковым номером. Таблица имеет следующие поля:

Таблица 3. Описание полей таблицы IOC.FORMID
Поле Описание
ID Первичный ключ таблицы.
SoP_STEP Тип операции, представляющий собой объединение идентификатора SOP с порядковым номером
FORM_ID Идентификатор типа формы.

Заключение

Программная платформа IBM Intelligent Operation Center предоставляет несколько точек интеграции, с помощью которых поставщики решений могут реализовать специальные ускорители. Мы продемонстрировали один из возможных способов, который может использоваться архитекторами и разработчиками ПО для решения проблем и создания операций, поддерживающих стандартные рабочие процедуры. Intelligent Operations Center опирается на продукты IBM и обладает достаточной надежностью и гибкостью для того, чтобы добавлять необходимые клиентам возможности.

Ресурсы

  • Оригинал статьи: Enhance IBM Intelligent Operations Center-based applications.
  • IBM United States Software Announcement 212-250 от 3 июля 2012 года: информация о том, каким образом IBM Intelligent Operations Center V1.5 представляет новые приложения и расширяет функциональность интерфейса пользователя, а также улучшает интеллектуальное реагирование и оптимизационную логику.
  • Сайт Федерального агентства по чрезвычайным ситуациям США (FEMA)
  • Центр IBM Intelligent Operations Center: узнайте о том, как координировать работу служб вашего города для предоставления гражданам услуг высочайшего качества. Узнайте о функциях, преимуществах, системных требованиях, сервисах, технической поддержке и многих других аспектах.
  • Разумные города IBM Smarter Cities: получите информацию об IBM Intelligent Operations Center для Smarter Cities и узнайте о том, как использовать его для синхронизации и анализа действий секторов и агентств, предоставляя принимающим решения лицам сводную информацию, помогающую им предвидеть проблемы, а не просто реагировать на их возникновение.
  • Реализация IBM Tivoli Service Request Manager V7.1 Service Catalog: эта публикация серии IBM Redbook содержит информацию, которая может использоваться клиентами, партнерами и эксплуатационными сотрудниками IBM, которые хотят реализовать процессы ITIL на основе Service Catalog в корпоративной среде.

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=932765
ArticleTitle=Улучшение приложений, опирающихся на IBM Intelligent Operations Center
publish-date=06052013