Создание бизнес-процесса с помощью инструментов Rational и WebSphere

Основы. Имеющаяся архитектура

Разбить на страницы
Показывать лекцию целиком

Эта система была создана командой System House eMerge Solution Test в лабораториях разработки в Hursley1. Эти лаборатории занимаются созданием прототипов новых возможностей и тестированием интеграции новых версий платформы WebSphere. Команда проводит программу партнерства с клиентами, в рамках которой организуются краткосрочные визиты клиентов для совместной с сотрудниками Hursley работы по созданию прототипов новых возможностей решений. За подробной информацией обращайтесь в ваше местное представительство по связям с клиентами.

В данной лекции рассматриваются следующие темы:

  • до слияния компаний;
  • контекст объединенного решения;
  • интеграция решений;
  • ИТ-инфраструктура.
    •

    2.1 До слияния компаний

    В данном разделе мы рассмотрим инфраструктуры, имевшиеся в компаниях LGI и DirectCar до слияния. Они показаны на рис. 2.1.

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

    В компании LGI используется звездообразная инфраструктура, основанная на сообщениях, где все клиентские приложения посылают запросы центральному посреднику-брокеру, который производит преобразование данных и отправку их в серверные приложения или в системы потока операций (workflow). Все ответы приложений посылаются на центральный узел системы обмена сообщениями для преобразования и отправки в клиентское приложение. Клиент осуществляет регистрацию претензии путем обращения в центр приема запросов или к своему страховому агенту, после чего агент по претензиям при помощи стандартов EDI или специального клиентского приложения вводит данные для отправки LGI. Как и в случае DirectCar, вся обработка претензий ведется вручную или при помощи специальных приложений, которыми пользуется специалист по обработке претензий и эксперт по претензиям. Для бизнес-партнеров LGI предоставляет каналы доступа к брокеру сообщений.

    (рис 2.1) ИТ-инфраструктура компаний LGI и DirectCar до слияния

    Цель слияния с точки зрения бизнеса, как показано на рис. 2.2, состояла в создании представления "одна компания для всех каналов", чтобы скрыть от клиентов и персонала, занятого в обработке претензий, сложности, связанные с различием серверных приложений LGI и DirectCar.

    (рис 2.2) Бизнес-представление процесса объединенных компаний

    2.2 Объединенный контекст решения

    Контекст решения, показанный на рис. 2.3, относится к сценарию объединения, включающему процессы и системы работы со счетами, претензиями и полисами LGI и DirectCar.com. Те части, о которых мы будем говорить, обозначены красной рамкой в верхней правой части рисунка: обработка претензий в LGI и взаимодействие с внешними оценщиками. Чтобы вы получили представление о контексте, мы дадим краткое описание других компонентов данного решения.

    (рис 2.3) Контекст решения в сценарии слияния/поглощения

    Контакты с клиентами

    Эта подсистема отвечает за то, чтобы клиенты могли получить информацию по расценкам на полисы, получать полисы, проверять полисы и отправлять страховые претензии на обработку. Претензии в LGI могут поступать из нескольких источников. Клиент может напрямую отправить претензию через Интернет. Для этого необходимо Web-приложение. В качестве альтернативы можно отправить претензию непрямым путем, через агентов, через систему EDI (Electronic Data Interchange, обмен электронными данными) или через центр обработки запросов (EDI/ XML), где сотрудник центра использует специализированное приложение архитектуры клиент-сервер.

    Управление расценками и полисами

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

    Обработка претензий

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

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

    Оплата страховых претензий

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

    Финансы

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

    Поставщики услуг

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

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

    Обычно система обработки претензий поддерживает обмен информацией с этими сторонами различными способами.

    2.3 Интеграционные решения

    В этом разделе коротко описываются интеграционные решения, разработанные для объединенной компании LGI. Они основываются на объединении и создании общих процессов обработки претензий и полисов, лежащих в основе интеграции двух компаний. Эти решения делятся на две обширные области – администрирование расценок и полисов и обработку претензий. Мы коротко опишем решение, относящееся к расценкам и полисам, а затем обсудим существующую систему обработки претензий и предлагаемое новое интеграционное решение по работе с внешними оценщиками.

    2.3.1 Администрирование расценок и полисов

    Целью является интегрирование отдельных приложений в единую систему приема расценок и полисов, которая выбирает из разных страховых приложений наилучшую расценку, подает ее клиенту на утверждение и представляет как клиентам, так и остальной части системы единое видение всех полисов. Компонентное строение решения позволяет создать единое Web-приложение, работающее с имеющимися в LGI EDI-приложениями и специализированными приложениями для центров обработки клиентских запросов.

    После проверки информации, предоставленной клиентом, объединенная система приема расценок и полисов обращается к системам расценок LGI и DirectCar через брокер сообщений. На основе заданных правил брокер выбирает и возвращает наилучшую расценку.

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

    2.3.2 Интеграция систем обработки претензий

    Процесс обработки претензий состоит из четырех основных этапов, или процессов, которые выполняются последовательно (рис. 2.4):

    (рис 2.4) Базовый процесс обработки претензии
  • Регистрация претензии. Клиент сообщает информацию о своем полисе и претензии.
  • Проверка претензии. Страховая компания проверяет претензию. Оплачен ли полис, и соответствует ли претензия полису.
  • Изучение/оценка претензии. Страховая компания изучает претензию, собирает информацию от внешних организаций, например из полицейских и медицинских отчетов, и производит оценку претензии.
  • Решение по претензии.
    •

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

    Для интеграции систем обработки претензий компаний LGI и DirectCar в общий процесс обработки претензий используется система работы с процессами WebSphere MQ Workflow. Она визуализирует весь процесс обработки претензии, независимо от того, относится ли он к LGI или к DirectCar. Интеграция систем обработки претензий LGI и DirectCar при помощи общей системы работы с процессами также позволяет разрабатывать новые общие функции для процесса обработки претензий, например сбор отчетов об оценке от внешних оценщиков.

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

    Процесс обработки претензий в LGI

    LGI уже имеет инфраструктуру для системы обработки претензий, в которой все клиентские приложения посылают запросы в центральный узел обмена сообщениями, который выполняет трансформацию и маршрутизирует запросы в соответствующие серверные приложения и системы потока операций (workflow). Все ответы приложений посылаются на центральный узел системы обмена сообщениями для преобразования и отправки в клиентское приложение.

    К процессам для обработки претензий в LGI относятся:

  • Регистрация претензии. Клиент обращается в центр обработки запросов или к независимому агенту. Специалист по обработке претензий записывает детали инцидента, вручную заполняет необходимые формы и вводит необходимую информацию в базу данных о претензиях. Затем специалист выдает клиенту регистрационный номер претензии. Этот этап можно рассматривать как этап, выполняемый вручную.
  • Проверка претензии. Внесенная претензия проходит аутентификацию, в ходе которой проверяется, действителен ли полис клиента, не истек ли срок его действия, правильно ли указана вся информация и застрахован ли водитель полисом автострахования.
  • Изучение претензии. В ходе процесса изучения претензии специалист по обработке претензий запрашивает отчеты нескольких сторонних внешних организаций или компаний, как показано на рис 2.5(рис 2.5) Подпроцесс изучения претензииОдним из таких отчетов является отчет об оценке, получаемый от внешнего оценщика. Специалист по обработке претензий вручную выбирает оценщика из базы данных об оценщиках и посылает запрос на создание отчета об оценке, как показано на рис 2.6(рис 2.6) Ручной запрос отчетов у внешних оценщиков
  • Решение по претензии. На основе результатов отчетов и оценки обработчик претензии принимает решение о том, оправдана ли претензия, или ее нужно отвергнуть. В процессе может принимать участие эксперт по претензиям, если обнаруживаются какие-то необычные аспекты.
    •

    На рис. 2.7 и 2.8 приводятся прецеденты использования (use cases) в существующей системе обработки претензий LGI.

    (рис 2.8) Процесс регистрации претензий в LGI(рис 2.7) Задачи специалиста по обработке претензий и эксперта по претензиям

    Процесс обработки претензий в DirectCar

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

    В DirectCar используются следующие процессы обработки претензии:

  • Регистрация претензии. Клиент заходит на Web-сайт компании DirectCar и регистрирует претензию в режиме онлайн. Выполняется идентификация клиента как держателя полиса, после чего клиент получает регистрационный номер претензии. В данный момент никаких действий от специалиста по обработке претензий не требуется. Данный процесс является автоматическим.
  • Проверка претензии.
  • Изучение претензии.
  • Решение по претензии.
    •

    Эти этапы одинаковы и в DirectCar и в LGI.

    На рис. 2.9 и 2.10 показаны прецеденты использования (use cases) для существующей системы DirectCar.

    (рис 2.10) Процесс регистрации претензий в DirectCar(рис 2.9) Задачи специалиста по обработке претензий и эксперта по претензиям в DirectCar

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

    2.4 ИТ-инфраструктура

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

    При создании решения предполагалось повторно использовать имеющуюся инфраструктуру и приложения для обработки претензий, имеющиеся у LGI и DirectCar с преобразованием Web-приложения компании DirectCar под нужды LGI. Причины для такого выбора были следующие:

  • причины, связанные с бизнесом и стратегией:
  • стратегическая цель LGI при приобретении DirectCar заключалась в получении доли рынка и Web-канала, а не в уменьшении стоимости через рационализацию работы операционных отделов LGI и DirectCar;
  • ИТ-архитектура должна поддерживать возможность будущего разделения компаний;
  • слияние двух компаний должно отразиться на внешнем облике и работе Web-сайта компании, однако страховые полисы должны предоставляться те же самые, но теперь и для клиентов LGI, и для клиентов DirectCar;
    •
  • технические причины:
  • текущая аппаратная ИТ-инфраструктура DirectCar не рассчитана на предполагаемую нагрузку: у DirectCar менее 1 миллиона полисов, а у LGI – более 5 миллионов:
  • претензии от держателей полисов LGI должны обслуживаться имеющимися серверными системами LGI;
  • существующее Web-приложение DirectCar должно быть модифицировано для обработки новых полисов LGI, а также для работы с увеличенной нагрузкой.

    • Общая схема архитектуры

    На рис. 2.11 показана предлагаемая схема архитектуры для объединенной системы обработки претензий.

    (рис 2.11) Общая схема архитектуры объединенного процесса обработки претензий

    Как показано на этом рисунке, архитектура решения основывается на следующих решениях:

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

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

    Мы решили сохранить существующую инфраструктуру IBM WebSphere MQ компании LGI и дополнить ее новым клиентским Web-приложением и уже существующими серверными системами DirectCar. Инфраструктура WebSphere MQ состоит из нескольких кластеров WebSphere MQ, сконфигурированных для передачи данных между различными компонентами приложения, которые функционируют под управлением разных продуктов в разных операционных системах. Используются механизмы гарантированной доставки WebSphere MQ и широкий диапазон охватываемых платформ.

    Каждый из компонентов, показанных на рис. 2.12, описывается ниже более детально.

    (рис 2.12) Продукты, используемые при реализации архитектуры системы обработки претензий

    2.4.1 Пользовательские интерфейсы

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

  • Web-интерфейс интранета для клиентов DirectCar.
  • Приложение Java $$\text{\texttrademark}$$ Swing для офисов-филиалов LGI и центров обработки запросов. Это приложение использует клиентскую часть WebSphere MQ для передачи информации в систему трансформации и маршрутизации, а также из нее.
  • Интерфейс EDIFACT для бизнес-партнеров. Приложение посылает данные EDI 835 на шлюз Data Interchange.
    •

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

    Рабочая система

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

    Продукты для работы с пользовательскими интерфейсами
    Продукт Платформы Версии
    Java runtime engine (JRE) Microsoft Windows $$\text{\textregistered}$$ 2000 1.3, 1.4.x
    Web-браузер для просмотра Web-страниц [страниц Java Server Pages (JSP $$\text{\texttrademark}$$ ) и HTML] Windows 2000 N/A
    WebSphere Data Interchange (Oбмен данными) Windows 2000 3.2.1
    WebSphere MQ Client Linux $$\text{\textregistered}$$, Windows 2000 5.3.x

    Инструменты

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

    Продукты, используемые в качестве инструментов для создания пользовательских интерфейсов
    Продукт Платформы Версии
    WebSphere Studio Application Developer (Разработчик приложений). Linux 5.0.x, 5.1.x
    Использование: для разработки пользовательского интерфейса Java Swing

    2.4.2 Серверы приложений

    В наше промежуточное программное обеспечение входит сервер приложений Direct Application Server LGI и шлюз обмена данными Data Interchange Gateway. Это программное обеспечение выполняет следующие функции:

  • Предоставляет новый объединенный Web-сайт, основанный на имеющихся приложениях DirectCar и предназначенный для того, чтобы держатели полисов LGI и DirectCar могли зарегистрировать страховую претензию. Используется HTTP-сервер, на котором хранятся статические Web-страницы, и серверы приложений, содержащие JSP-страницы, сервлеты и компоненты EJB™. В EJB-компоненты были внесены изменения, позволяющие компонентам осуществлять вызовы JMS API для передачи запросов в систему трансформации и маршрутизации и из нее.
  • Предоставляет Web-сайт интранета для специалистов по обработке претензий, в котором используется HTTP-сервер и серверы приложений для взаимодействия с менеджером процессов.
  • Компоненты Network Deployment Edge Server предоставляют возможности распределения нагрузки по нескольким узлам серверов приложений для формирования масштабируемого решения с отказоустойчивостью.
  • Шлюз Data Interchange помещает получаемые им от бизнес-партнера данные EDI 835 в очередь WebSphere MQ, откуда их забирает система трансформации и маршрутизации.
    •

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

  • сервер приложений позволяет объединенной компании дополнить свою инфраструктуру J2EE-технологиями, применяя навыки и технологии, имеющиеся в компании DirectCar;
  • помимо поддержки WebSphere MQ в качестве JMS-провайдера, сервер приложений удовлетворяет требованиям, которые компания предъявляет к качеству обслуживания;
  • шлюз Data Interchange необходим для продолжения поддержки каналов связи с бизнес-партнерами.
    •

    Рабочая система

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

    Продукты для промежуточного программного обеспечения в рабочей системе
    Продукт Платформы Версии
    IBM HTTP Server (IHS) AIX $$\text{\textregistered}$$, Solaris $$\text{\texttrademark}$$, Windows 2000 1.3.x, 2.0
    WebSphere Application Server (Application Server) AIX, Solaris, Windows 2000 5.0.x, 5.1.x
    WebSphere Application Server Network Deployment (Network Deployment) AIX 5.0.x, 5.1.x
    WebSphere Data Interchange (Data Interchange) Gateway Windows 2000 3.2.1
    WebSphere MQ AIX, Windows 2000 5.3

    Инструменты

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

    Продукты, используемые в качестве инструментов для создания промежуточного программного обеспечения
    Продукт Платформы Версии
    WebSphere Studio Application Developer (Application Developer) Windows 2000 5.0.x, 5.1.x
    Использование: для разработки сервлетов и компонентов Enterprise JavaBeans $$\text{\texttrademark}$$ (EJB)
    WebSphere Studio Site Developer (Site Developer) Windows 2000 5.0.x, 5.1.x
    Использование: для разработки страниц HTML и JSP

    2.4.3 Брокеры сообщений

    Продукт WebSphere MQ Integrator Message Broker реализует систему трансформации и маршрутизации, которая преобразует данные, полученные от серверов приложений или менеджера процессов, из одного XML-формата либо в другой XML-формат, необходимый для существующего серверного приложения компании DirectCar, либо в формат коммуникационной области (COMMAREA), используемый в системах компании LGI. Область COMMAREA – это область CICS, которая передает данные между задачами, обращающимися к данному терминалу. Эту область также можно использовать для передачи данных между программами в рамках задачи.

    После трансформации данные передаются в соответствующую серверную систему на основе содержимого сообщения WebSphere MQ. В случае запросов от бизнес-партнеров данные EDIFACT преобразуются в XML при помощи DTD (Document Type Description, Описание типа документа), импортированного в виде набора сообщений.

    Системы WebSphere Business Integration Message Broker конфигурируются в домен для обработки больших объемов нагрузки и обеспечения отказоустойчивости.

    Мы используем Message Broker по следующим причинам:

  • продолжение поддержки инфраструктуры обмена сообщениями и использование существующей инфраструктуры WebSphere Business Integration Message Broker, уже применяемой для доступа к серверным системам LGI;
  • поддержка всех форматов данных, которые необходимы для работы приложений: XML, COMMAREA, EDIFACT, а также нескольких операционных систем, используемых объединенной компанией.
    •

    Рабочая система

    Продукты, применяемые в рабочей системе управления бизнес-процессами, перечислены в табл. 2.5.

    Продукты, используемые в рабочей системе трансформации и маршрутизации
    Продукт Платформы Версии
    WebSphere Business Integration Message Broker AIX, Solaris, Windows 2000, z/OS 2.1.x
    WebSphere Business Integration Message Broker Windows 2000 5.x

    Инструменты

    Продукты, применяемые в качестве инструментов для создания системы BPM, перечислены в табл. 2.6.

    Продукты, используемые в качестве инструментов для создания системы BPM
    Продукт Платформы Версии
    WebSphere Business Integration Message Broker Control Center Windows 2000 2.1.x
    Использование: для разработки потоков сообщений
    WebSphere Business Integration Message Broker Workbench Windows 2000 5.x
    Использование: для разработки потоков сообщений

    2.4.4 Менеджеры процессов

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

    Решения по выбору конкретных продуктов принимались на следующих основаниях:

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

    Рабочая система

    Продукты, применяемые в качестве менеджеров процессов в рабочей системе, перечислены в табл. 2.7.

    Продукты, используемые в качестве менеджеров процессов в рабочей системе
    Продукт Платформы Версии
    WebSphere MQ Workflow AIX, Windows 2000 3.4, 3.5

    Инструменты

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

    Продукты, используемые в качестве инструментов при создании менеджеров процессов
    Продукт Платформы Версии
    WebSphere Business Integration Modeler Windows 2000 4.2.x
    Использование: для разработки потоков в бизнес-процессах
    WebSphere MQ Workflow Buildtime Windows 2000 3.4, 3.5
    Использование: для разработки потоков в бизнес-процессах

    2.4.5 Оконечные серверы транзакций и центры данных

    В данном разделе рассматриваются оконечные серверы транзакций и центры данных для DirectCar и LGI.

    Сервер приложений и центр данных DirectCar

    Сервер приложений DirectCar конфигурируется так, чтобы использовать в качестве JMS-провайдера WebSphere MQ. Были разработаны компоненты, управляемые сообщениями (Message Driven Beans, MDB), которые предназначены для приема сообщений из очереди WebSphere MQ при помощи селектора сообщений с последующим вызовом соответствующих сеансовых EJB-компонентов. Эти сеансовые компоненты вызывают сущностные компоненты (entity beans) для доступа к базам данных Oracle.

    В ходе проверки претензии выполняется проверка данных полиса, которые хранятся в базе данных. В данном случае сеансовые компоненты применяют вызов RMIIIOP для обращения к интерфейсу EJB, который с помощью служб JCA направляет запросы в TXSeries через шлюз CICS Transaction Gateway (CTG). Приложения CICS COBOL, входящие в TXSeries, обращаются к базе DB2®, в которой хранятся полисы.

    Между LGI и DirectCar были установлены безопасные соединения с использованием протокола Secure Sockets Layer (SSL) над соединениями WebSphere MQ.

    Использование существующих систем оставляет без изменений работающие приложения. TxSeries и DB2 являлись частью готового приложения для управления страховыми полисами. Компания DirectCar решила применить для разработки своей системы обработки претензий технологии J2EE и сервер приложений в сочетании с базой данных Oracle. Единственным дополнением является WebSphere MQ, который объединяет эти системы вместе.

    Центр данных LGI

    Центр данных LGI представляет собой существующую систему, основанную на CICS. В качестве интерфейса между более широкой инфраструктурой WebSphere MQ и системой CICS используется мост WebSphere MQ-CICS. Сообщения WebSphere MQ передаются через мост WebSphere MQ-CICS, который вызывает приложения CICS COBOL. Эти приложения запускают инструкции SQL для доступа к базам данных DB2, где содержится информация о клиентских полисах и претензиях.

    Рабочая система

    Продукты, применяемые в рабочей системе как оконечные серверные системы, перечислены в табл. 2.9.

    Продукты, используемые в рабочей системе как оконечные серверные системы
    Продукт Платформы Версии
    Центр данных DirectCar:
    DB2 Windows 2000 7.2, 8.1.x
    Oracle Windows 2000 9.1
    TXSeries Windows 2000 5.0.x
    WebSphere Application Server Windows 2000 5.0.x, 5.1.x
    WebSphere MQ Windows 2000 5.3.x
    Центр данных LGI:
    CICS Transaction Server for z/OS (CICS) z/OS 2.2, 3.1
    DB2 z/OS 7.2, 8.1.x
    WebSphere MQ z/OS 5.3.x

    Инструменты

    Продукты, применяемые в качестве инструментов для создания серверных систем, перечислены в табл. 2.10.

    Продукты, используемые в качестве инструментов для создания серверных систем
    Продукт Платформы Версии
    Центр данных DirectCar:
    VisualAge® for COBOL Windows 2000 3.6
    WebSphere Studio Application Developer Windows 2000 5.0.x, 5.1.x
    Использование: для разработки сеансовых и сущностных компонентов
    WebSphere Studio Application Development Integration Edition Windows 2000 5.0.x, 5.1.x
    Использование: для разработки EJB-компонентов Java Connection Architecture (JCA)
    Центр данных LGI:
    WebSphere Studio Enterprise Developer Windows 2000, z/OS 5.0.x, 5.1.x
    Использование: для разработки программ CICS COBOL
    Примечание. Версии продуктов, используемые в решении System House, со временем развиваются. Указанные здесь версии действительны на момент написания курса.

    2.5 Расширение архитектуры

    В разделе 1.2, "Бизнес-цели", и в разделе 1.3, "Цели и ограничения, связанные с ин- формационными технологиями", мы описываем цели слияния компаний LGI и DirectCar. Реализация этих целей осуществляется как минимум в трех фазах.

    Фаза 1. Уже выполнена

    Прежде чем переходить к действиям, описанным далее, мы выполнили следующие шаги:

  • Мы автоматизировали этапы процесса, что увеличило скорость и предсказуемость обработки претензий.
  • Мы предоставили специалистам по обработке претензий общий набор интерфейсов, через которые можно обращаться к системам обработки претензий и полисов как LGI, так и DirectCar. Это повысило гибкость обработки претензий по полисам, принадлежащим любой из наших компаний.
  • Мы автоматизировали взаимодействия с некоторыми внешними агентами, такими, как органы по выдаче лицензий. Такая автоматизация была относительно простой и содержала только одно взаимодействие – проверку регистрации автомобилей.
    •

    За дополнительной информацией обращайтесь к серии статей в IBM developer-Works $$\text{\textregistered}$$, "Merging disparate IT systems: Build a single integrated view for users quickly and with minimal disruption", которую можно найти по адресу http://www-128.ibm.com/developerworks/ibm/library/i-merge.html

    Фаза 2. Автоматизация внешних транзакций

    В оставшейся части курса мы сконцентрируемся на второй фазе реализации:

  • Автоматизация более сложных взаимодействий с внешними организациями, в частности автоматизация задач, связанных с оценкой претензии:
  • создание контрактов с оценщиками ущерба;
  • выбор оценщика для данного конкретного случая;
  • запуск процесса оценки;
  • слежение за ходом оценки и производительностью оценщика;
  • получение отчета об оценке.
    •

    Автоматизация внешней оценки претензии

    В компании LGI в рамках корпоративной ИТ-стратегии было решено считать проект по автоматизации работы с внешними оценщиками пилотным проектом перевода технологической базы в сторону большего использования открытых стандартов в бизнес-приложениях. Компания уже использовала Java 2 Enterprise Edition (J2EE) на уровне представления и употребила Web-службы для простых взаимодействий с внешними организациями.

    Теперь проблема состоит в том, чтобы уделить внимание навыкам, необходимым для создания приложений для бизнес-процессов с использованием BPEL на платформе J2EE, выявить все технологические нестыковки при внедрении технологии BPEL и оценить преимущества использования новой технологии. Основными вопросами здесь являются инструменты для моделирования решений на BPEL и UML. Будут ли эти инструменты работать друг с другом и ускорят ли они разработку и внедрение решения?

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

  • С точки зрения бизнеса данное решение должно быть полезным вложением капитала. Оно не влияет сразу на весь бизнес, поскольку его можно устанавливать поэтапно, с постепенной заменой имеющегося ручного процесса.
  • С технической точки зрения переход на открытые стандарты, такие, как Web-службы и BPEL, весьма приоритетен для процессов, в которых участвуют бизнес-партнеры. Процесс оценки претензий также будет пилотным для интеграции WebSphere MQ Workflow и WebSphere Business Integration Server Foundation, а также интеграции BPEL-процесса, использующего Web-службы, с существующей в LGI инфраструктурой обмена сообщениями.
    •

    Новый процесс также должен использовать имеющийся у LGI каркас WebSphere MQ для взаимодействия со службами, входящими в системы LGI и DirectCar. Этот каркас также предоставляет шлюз для соединения со службами бизнес-партнеров и со службами LGI, которые компания предоставляет своим бизнес-партнерам. Этот каркас развился из шины обмена сообщениями, соединяющей компоненты приложений, и стал сервисной шиной, использующей в качестве основных транспортных протоколов SOAP/JMS и SOAP/http.

    Фаза 3. Будущий мониторинг данных о претензии

    В будущем нужно будет выполнить такие действия:

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

    Слежение за ходом обработки претензии

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

  • Созданием "пульта управления" бизнесом, обеспечивающего для бизнеса представление о ходе процесса обработки.
  • Совершенствованием процесса обработки претензии путем сбора данных о производительности. Эти данные могут использовать:
  • бизнес-партнеры, для изучения своей производительности;
  • бизнес-аналитики для изучения возможностей для совершенствования процесса на основе ввода реальных данных в модель, имитирующую работу оценщика претензий.
    •

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

    Дальнейшее содержание данного курса имеет следующую структуру:

  • в следующей лекции обсуждается методика и инструменты, используемые нами при создании нового решения, которое позволит компании LGI достичь поставленных ИТ-целей – увеличения производительности, обеспечения большего соответствия ИТ-решений бизнес-целям и более быстрого ввода решения в эксплуатацию;
  • в лекции 4, "Бизнес-процесс", мы используем WebSphere Business Integration Modeler для разработки нового бизнес-процесса;
  • в лекции 5, "Архитектура системы", и в лекции 6, "Архитектура решения" мы используем для разработки нового решения и расширения имеющейся архитектуры шаблоны для электронного бизнеса (Patterns for e-Business) и Rational Software Architect.
    •

    2.6 Заключение

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

    Страницы:

    Эта система была создана командой System House eMerge Solution Test в лабораториях разработки в Hursley1. Эти лаборатории занимаются созданием прототипов новых возможностей и тестированием интеграции новых версий платформы WebSphere. Команда проводит программу партнерства с клиентами, в рамках которой организуются краткосрочные визиты клиентов для совместной с сотрудниками Hursley работы по созданию прототипов новых возможностей решений. За подробной информацией обращайтесь в ваше местное представительство по связям с клиентами.

    В данной лекции рассматриваются следующие темы:

  • до слияния компаний;
  • контекст объединенного решения;
  • интеграция решений;
  • ИТ-инфраструктура.
    •

    2.1 До слияния компаний

    В данном разделе мы рассмотрим инфраструктуры, имевшиеся в компаниях LGI и DirectCar до слияния. Они показаны на рис. 2.1.

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

    В компании LGI используется звездообразная инфраструктура, основанная на сообщениях, где все клиентские приложения посылают запросы центральному посреднику-брокеру, который производит преобразование данных и отправку их в серверные приложения или в системы потока операций (workflow). Все ответы приложений посылаются на центральный узел системы обмена сообщениями для преобразования и отправки в клиентское приложение. Клиент осуществляет регистрацию претензии путем обращения в центр приема запросов или к своему страховому агенту, после чего агент по претензиям при помощи стандартов EDI или специального клиентского приложения вводит данные для отправки LGI. Как и в случае DirectCar, вся обработка претензий ведется вручную или при помощи специальных приложений, которыми пользуется специалист по обработке претензий и эксперт по претензиям. Для бизнес-партнеров LGI предоставляет каналы доступа к брокеру сообщений.

    (рис 2.1) ИТ-инфраструктура компаний LGI и DirectCar до слияния

    Цель слияния с точки зрения бизнеса, как показано на рис. 2.2, состояла в создании представления "одна компания для всех каналов", чтобы скрыть от клиентов и персонала, занятого в обработке претензий, сложности, связанные с различием серверных приложений LGI и DirectCar.

    (рис 2.2) Бизнес-представление процесса объединенных компаний

    2.2 Объединенный контекст решения

    Контекст решения, показанный на рис. 2.3, относится к сценарию объединения, включающему процессы и системы работы со счетами, претензиями и полисами LGI и DirectCar.com. Те части, о которых мы будем говорить, обозначены красной рамкой в верхней правой части рисунка: обработка претензий в LGI и взаимодействие с внешними оценщиками. Чтобы вы получили представление о контексте, мы дадим краткое описание других компонентов данного решения.

    (рис 2.3) Контекст решения в сценарии слияния/поглощения

    Контакты с клиентами

    Эта подсистема отвечает за то, чтобы клиенты могли получить информацию по расценкам на полисы, получать полисы, проверять полисы и отправлять страховые претензии на обработку. Претензии в LGI могут поступать из нескольких источников. Клиент может напрямую отправить претензию через Интернет. Для этого необходимо Web-приложение. В качестве альтернативы можно отправить претензию непрямым путем, через агентов, через систему EDI (Electronic Data Interchange, обмен электронными данными) или через центр обработки запросов (EDI/ XML), где сотрудник центра использует специализированное приложение архитектуры клиент-сервер.

    Управление расценками и полисами

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

    Обработка претензий

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

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

    Оплата страховых претензий

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

    Финансы

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

    Поставщики услуг

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

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

    Обычно система обработки претензий поддерживает обмен информацией с этими сторонами различными способами.

    2.3 Интеграционные решения

    В этом разделе коротко описываются интеграционные решения, разработанные для объединенной компании LGI. Они основываются на объединении и создании общих процессов обработки претензий и полисов, лежащих в основе интеграции двух компаний. Эти решения делятся на две обширные области – администрирование расценок и полисов и обработку претензий. Мы коротко опишем решение, относящееся к расценкам и полисам, а затем обсудим существующую систему обработки претензий и предлагаемое новое интеграционное решение по работе с внешними оценщиками.

    2.3.1 Администрирование расценок и полисов

    Целью является интегрирование отдельных приложений в единую систему приема расценок и полисов, которая выбирает из разных страховых приложений наилучшую расценку, подает ее клиенту на утверждение и представляет как клиентам, так и остальной части системы единое видение всех полисов. Компонентное строение решения позволяет создать единое Web-приложение, работающее с имеющимися в LGI EDI-приложениями и специализированными приложениями для центров обработки клиентских запросов.

    После проверки информации, предоставленной клиентом, объединенная система приема расценок и полисов обращается к системам расценок LGI и DirectCar через брокер сообщений. На основе заданных правил брокер выбирает и возвращает наилучшую расценку.

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

    2.3.2 Интеграция систем обработки претензий

    Процесс обработки претензий состоит из четырех основных этапов, или процессов, которые выполняются последовательно (рис. 2.4):

    (рис 2.4) Базовый процесс обработки претензии
  • Регистрация претензии. Клиент сообщает информацию о своем полисе и претензии.
  • Проверка претензии. Страховая компания проверяет претензию. Оплачен ли полис, и соответствует ли претензия полису.
  • Изучение/оценка претензии. Страховая компания изучает претензию, собирает информацию от внешних организаций, например из полицейских и медицинских отчетов, и производит оценку претензии.
  • Решение по претензии.
    •

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

    Для интеграции систем обработки претензий компаний LGI и DirectCar в общий процесс обработки претензий используется система работы с процессами WebSphere MQ Workflow. Она визуализирует весь процесс обработки претензии, независимо от того, относится ли он к LGI или к DirectCar. Интеграция систем обработки претензий LGI и DirectCar при помощи общей системы работы с процессами также позволяет разрабатывать новые общие функции для процесса обработки претензий, например сбор отчетов об оценке от внешних оценщиков.

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

    Процесс обработки претензий в LGI

    LGI уже имеет инфраструктуру для системы обработки претензий, в которой все клиентские приложения посылают запросы в центральный узел обмена сообщениями, который выполняет трансформацию и маршрутизирует запросы в соответствующие серверные приложения и системы потока операций (workflow). Все ответы приложений посылаются на центральный узел системы обмена сообщениями для преобразования и отправки в клиентское приложение.

    К процессам для обработки претензий в LGI относятся:

  • Регистрация претензии. Клиент обращается в центр обработки запросов или к независимому агенту. Специалист по обработке претензий записывает детали инцидента, вручную заполняет необходимые формы и вводит необходимую информацию в базу данных о претензиях. Затем специалист выдает клиенту регистрационный номер претензии. Этот этап можно рассматривать как этап, выполняемый вручную.
  • Проверка претензии. Внесенная претензия проходит аутентификацию, в ходе которой проверяется, действителен ли полис клиента, не истек ли срок его действия, правильно ли указана вся информация и застрахован ли водитель полисом автострахования.
  • Изучение претензии. В ходе процесса изучения претензии специалист по обработке претензий запрашивает отчеты нескольких сторонних внешних организаций или компаний, как показано на рис 2.5(рис 2.5) Подпроцесс изучения претензииОдним из таких отчетов является отчет об оценке, получаемый от внешнего оценщика. Специалист по обработке претензий вручную выбирает оценщика из базы данных об оценщиках и посылает запрос на создание отчета об оценке, как показано на рис 2.6(рис 2.6) Ручной запрос отчетов у внешних оценщиков
  • Решение по претензии. На основе результатов отчетов и оценки обработчик претензии принимает решение о том, оправдана ли претензия, или ее нужно отвергнуть. В процессе может принимать участие эксперт по претензиям, если обнаруживаются какие-то необычные аспекты.
    •

    На рис. 2.7 и 2.8 приводятся прецеденты использования (use cases) в существующей системе обработки претензий LGI.

    (рис 2.8) Процесс регистрации претензий в LGI(рис 2.7) Задачи специалиста по обработке претензий и эксперта по претензиям

    Процесс обработки претензий в DirectCar

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

    В DirectCar используются следующие процессы обработки претензии:

  • Регистрация претензии. Клиент заходит на Web-сайт компании DirectCar и регистрирует претензию в режиме онлайн. Выполняется идентификация клиента как держателя полиса, после чего клиент получает регистрационный номер претензии. В данный момент никаких действий от специалиста по обработке претензий не требуется. Данный процесс является автоматическим.
  • Проверка претензии.
  • Изучение претензии.
  • Решение по претензии.
    •

    Эти этапы одинаковы и в DirectCar и в LGI.

    На рис. 2.9 и 2.10 показаны прецеденты использования (use cases) для существующей системы DirectCar.

    (рис 2.10) Процесс регистрации претензий в DirectCar(рис 2.9) Задачи специалиста по обработке претензий и эксперта по претензиям в DirectCar

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

    2.4 ИТ-инфраструктура

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

    При создании решения предполагалось повторно использовать имеющуюся инфраструктуру и приложения для обработки претензий, имеющиеся у LGI и DirectCar с преобразованием Web-приложения компании DirectCar под нужды LGI. Причины для такого выбора были следующие:

  • причины, связанные с бизнесом и стратегией:
  • стратегическая цель LGI при приобретении DirectCar заключалась в получении доли рынка и Web-канала, а не в уменьшении стоимости через рационализацию работы операционных отделов LGI и DirectCar;
  • ИТ-архитектура должна поддерживать возможность будущего разделения компаний;
  • слияние двух компаний должно отразиться на внешнем облике и работе Web-сайта компании, однако страховые полисы должны предоставляться те же самые, но теперь и для клиентов LGI, и для клиентов DirectCar;
    •
  • технические причины:
  • текущая аппаратная ИТ-инфраструктура DirectCar не рассчитана на предполагаемую нагрузку: у DirectCar менее 1 миллиона полисов, а у LGI – более 5 миллионов:
  • претензии от держателей полисов LGI должны обслуживаться имеющимися серверными системами LGI;
  • существующее Web-приложение DirectCar должно быть модифицировано для обработки новых полисов LGI, а также для работы с увеличенной нагрузкой.

    • Общая схема архитектуры

    На рис. 2.11 показана предлагаемая схема архитектуры для объединенной системы обработки претензий.

    (рис 2.11) Общая схема архитектуры объединенного процесса обработки претензий

    Как показано на этом рисунке, архитектура решения основывается на следующих решениях:

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

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

    Мы решили сохранить существующую инфраструктуру IBM WebSphere MQ компании LGI и дополнить ее новым клиентским Web-приложением и уже существующими серверными системами DirectCar. Инфраструктура WebSphere MQ состоит из нескольких кластеров WebSphere MQ, сконфигурированных для передачи данных между различными компонентами приложения, которые функционируют под управлением разных продуктов в разных операционных системах. Используются механизмы гарантированной доставки WebSphere MQ и широкий диапазон охватываемых платформ.

    Каждый из компонентов, показанных на рис. 2.12, описывается ниже более детально.

    (рис 2.12) Продукты, используемые при реализации архитектуры системы обработки претензий

    2.4.1 Пользовательские интерфейсы

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

  • Web-интерфейс интранета для клиентов DirectCar.
  • Приложение Java $$\text{\texttrademark}$$ Swing для офисов-филиалов LGI и центров обработки запросов. Это приложение использует клиентскую часть WebSphere MQ для передачи информации в систему трансформации и маршрутизации, а также из нее.
  • Интерфейс EDIFACT для бизнес-партнеров. Приложение посылает данные EDI 835 на шлюз Data Interchange.
    •

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

    Рабочая система

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

    Продукты для работы с пользовательскими интерфейсами
    Продукт Платформы Версии
    Java runtime engine (JRE) Microsoft Windows $$\text{\textregistered}$$ 2000 1.3, 1.4.x
    Web-браузер для просмотра Web-страниц [страниц Java Server Pages (JSP $$\text{\texttrademark}$$ ) и HTML] Windows 2000 N/A
    WebSphere Data Interchange (Oбмен данными) Windows 2000 3.2.1
    WebSphere MQ Client Linux $$\text{\textregistered}$$, Windows 2000 5.3.x

    Инструменты

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

    Продукты, используемые в качестве инструментов для создания пользовательских интерфейсов
    Продукт Платформы Версии
    WebSphere Studio Application Developer (Разработчик приложений). Linux 5.0.x, 5.1.x
    Использование: для разработки пользовательского интерфейса Java Swing

    2.4.2 Серверы приложений

    В наше промежуточное программное обеспечение входит сервер приложений Direct Application Server LGI и шлюз обмена данными Data Interchange Gateway. Это программное обеспечение выполняет следующие функции:

  • Предоставляет новый объединенный Web-сайт, основанный на имеющихся приложениях DirectCar и предназначенный для того, чтобы держатели полисов LGI и DirectCar могли зарегистрировать страховую претензию. Используется HTTP-сервер, на котором хранятся статические Web-страницы, и серверы приложений, содержащие JSP-страницы, сервлеты и компоненты EJB™. В EJB-компоненты были внесены изменения, позволяющие компонентам осуществлять вызовы JMS API для передачи запросов в систему трансформации и маршрутизации и из нее.
  • Предоставляет Web-сайт интранета для специалистов по обработке претензий, в котором используется HTTP-сервер и серверы приложений для взаимодействия с менеджером процессов.
  • Компоненты Network Deployment Edge Server предоставляют возможности распределения нагрузки по нескольким узлам серверов приложений для формирования масштабируемого решения с отказоустойчивостью.
  • Шлюз Data Interchange помещает получаемые им от бизнес-партнера данные EDI 835 в очередь WebSphere MQ, откуда их забирает система трансформации и маршрутизации.
    •

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

  • сервер приложений позволяет объединенной компании дополнить свою инфраструктуру J2EE-технологиями, применяя навыки и технологии, имеющиеся в компании DirectCar;
  • помимо поддержки WebSphere MQ в качестве JMS-провайдера, сервер приложений удовлетворяет требованиям, которые компания предъявляет к качеству обслуживания;
  • шлюз Data Interchange необходим для продолжения поддержки каналов связи с бизнес-партнерами.
    •

    Рабочая система

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

    Продукты для промежуточного программного обеспечения в рабочей системе
    Продукт Платформы Версии
    IBM HTTP Server (IHS) AIX $$\text{\textregistered}$$, Solaris $$\text{\texttrademark}$$, Windows 2000 1.3.x, 2.0
    WebSphere Application Server (Application Server) AIX, Solaris, Windows 2000 5.0.x, 5.1.x
    WebSphere Application Server Network Deployment (Network Deployment) AIX 5.0.x, 5.1.x
    WebSphere Data Interchange (Data Interchange) Gateway Windows 2000 3.2.1
    WebSphere MQ AIX, Windows 2000 5.3

    Инструменты

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

    Продукты, используемые в качестве инструментов для создания промежуточного программного обеспечения
    Продукт Платформы Версии
    WebSphere Studio Application Developer (Application Developer) Windows 2000 5.0.x, 5.1.x
    Использование: для разработки сервлетов и компонентов Enterprise JavaBeans $$\text{\texttrademark}$$ (EJB)
    WebSphere Studio Site Developer (Site Developer) Windows 2000 5.0.x, 5.1.x
    Использование: для разработки страниц HTML и JSP

    2.4.3 Брокеры сообщений

    Продукт WebSphere MQ Integrator Message Broker реализует систему трансформации и маршрутизации, которая преобразует данные, полученные от серверов приложений или менеджера процессов, из одного XML-формата либо в другой XML-формат, необходимый для существующего серверного приложения компании DirectCar, либо в формат коммуникационной области (COMMAREA), используемый в системах компании LGI. Область COMMAREA – это область CICS, которая передает данные между задачами, обращающимися к данному терминалу. Эту область также можно использовать для передачи данных между программами в рамках задачи.

    После трансформации данные передаются в соответствующую серверную систему на основе содержимого сообщения WebSphere MQ. В случае запросов от бизнес-партнеров данные EDIFACT преобразуются в XML при помощи DTD (Document Type Description, Описание типа документа), импортированного в виде набора сообщений.

    Системы WebSphere Business Integration Message Broker конфигурируются в домен для обработки больших объемов нагрузки и обеспечения отказоустойчивости.

    Мы используем Message Broker по следующим причинам:

  • продолжение поддержки инфраструктуры обмена сообщениями и использование существующей инфраструктуры WebSphere Business Integration Message Broker, уже применяемой для доступа к серверным системам LGI;
  • поддержка всех форматов данных, которые необходимы для работы приложений: XML, COMMAREA, EDIFACT, а также нескольких операционных систем, используемых объединенной компанией.
    •

    Рабочая система

    Продукты, применяемые в рабочей системе управления бизнес-процессами, перечислены в табл. 2.5.

    Продукты, используемые в рабочей системе трансформации и маршрутизации
    Продукт Платформы Версии
    WebSphere Business Integration Message Broker AIX, Solaris, Windows 2000, z/OS 2.1.x
    WebSphere Business Integration Message Broker Windows 2000 5.x

    Инструменты

    Продукты, применяемые в качестве инструментов для создания системы BPM, перечислены в табл. 2.6.

    Продукты, используемые в качестве инструментов для создания системы BPM
    Продукт Платформы Версии
    WebSphere Business Integration Message Broker Control Center Windows 2000 2.1.x
    Использование: для разработки потоков сообщений
    WebSphere Business Integration Message Broker Workbench Windows 2000 5.x
    Использование: для разработки потоков сообщений

    2.4.4 Менеджеры процессов

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

    Решения по выбору конкретных продуктов принимались на следующих основаниях:

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

    Рабочая система

    Продукты, применяемые в качестве менеджеров процессов в рабочей системе, перечислены в табл. 2.7.

    Продукты, используемые в качестве менеджеров процессов в рабочей системе
    Продукт Платформы Версии
    WebSphere MQ Workflow AIX, Windows 2000 3.4, 3.5

    Инструменты

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

    Продукты, используемые в качестве инструментов при создании менеджеров процессов
    Продукт Платформы Версии
    WebSphere Business Integration Modeler Windows 2000 4.2.x
    Использование: для разработки потоков в бизнес-процессах
    WebSphere MQ Workflow Buildtime Windows 2000 3.4, 3.5
    Использование: для разработки потоков в бизнес-процессах

    2.4.5 Оконечные серверы транзакций и центры данных

    В данном разделе рассматриваются оконечные серверы транзакций и центры данных для DirectCar и LGI.

    Сервер приложений и центр данных DirectCar

    Сервер приложений DirectCar конфигурируется так, чтобы использовать в качестве JMS-провайдера WebSphere MQ. Были разработаны компоненты, управляемые сообщениями (Message Driven Beans, MDB), которые предназначены для приема сообщений из очереди WebSphere MQ при помощи селектора сообщений с последующим вызовом соответствующих сеансовых EJB-компонентов. Эти сеансовые компоненты вызывают сущностные компоненты (entity beans) для доступа к базам данных Oracle.

    В ходе проверки претензии выполняется проверка данных полиса, которые хранятся в базе данных. В данном случае сеансовые компоненты применяют вызов RMIIIOP для обращения к интерфейсу EJB, который с помощью служб JCA направляет запросы в TXSeries через шлюз CICS Transaction Gateway (CTG). Приложения CICS COBOL, входящие в TXSeries, обращаются к базе DB2®, в которой хранятся полисы.

    Между LGI и DirectCar были установлены безопасные соединения с использованием протокола Secure Sockets Layer (SSL) над соединениями WebSphere MQ.

    Использование существующих систем оставляет без изменений работающие приложения. TxSeries и DB2 являлись частью готового приложения для управления страховыми полисами. Компания DirectCar решила применить для разработки своей системы обработки претензий технологии J2EE и сервер приложений в сочетании с базой данных Oracle. Единственным дополнением является WebSphere MQ, который объединяет эти системы вместе.

    Центр данных LGI

    Центр данных LGI представляет собой существующую систему, основанную на CICS. В качестве интерфейса между более широкой инфраструктурой WebSphere MQ и системой CICS используется мост WebSphere MQ-CICS. Сообщения WebSphere MQ передаются через мост WebSphere MQ-CICS, который вызывает приложения CICS COBOL. Эти приложения запускают инструкции SQL для доступа к базам данных DB2, где содержится информация о клиентских полисах и претензиях.

    Рабочая система

    Продукты, применяемые в рабочей системе как оконечные серверные системы, перечислены в табл. 2.9.

    Продукты, используемые в рабочей системе как оконечные серверные системы
    Продукт Платформы Версии
    Центр данных DirectCar:
    DB2 Windows 2000 7.2, 8.1.x
    Oracle Windows 2000 9.1
    TXSeries Windows 2000 5.0.x
    WebSphere Application Server Windows 2000 5.0.x, 5.1.x
    WebSphere MQ Windows 2000 5.3.x
    Центр данных LGI:
    CICS Transaction Server for z/OS (CICS) z/OS 2.2, 3.1
    DB2 z/OS 7.2, 8.1.x
    WebSphere MQ z/OS 5.3.x

    Инструменты

    Продукты, применяемые в качестве инструментов для создания серверных систем, перечислены в табл. 2.10.

    Продукты, используемые в качестве инструментов для создания серверных систем
    Продукт Платформы Версии
    Центр данных DirectCar:
    VisualAge® for COBOL Windows 2000 3.6
    WebSphere Studio Application Developer Windows 2000 5.0.x, 5.1.x
    Использование: для разработки сеансовых и сущностных компонентов
    WebSphere Studio Application Development Integration Edition Windows 2000 5.0.x, 5.1.x
    Использование: для разработки EJB-компонентов Java Connection Architecture (JCA)
    Центр данных LGI:
    WebSphere Studio Enterprise Developer Windows 2000, z/OS 5.0.x, 5.1.x
    Использование: для разработки программ CICS COBOL
    Примечание. Версии продуктов, используемые в решении System House, со временем развиваются. Указанные здесь версии действительны на момент написания курса.

    2.5 Расширение архитектуры

    В разделе 1.2, "Бизнес-цели", и в разделе 1.3, "Цели и ограничения, связанные с ин- формационными технологиями", мы описываем цели слияния компаний LGI и DirectCar. Реализация этих целей осуществляется как минимум в трех фазах.

    Фаза 1. Уже выполнена

    Прежде чем переходить к действиям, описанным далее, мы выполнили следующие шаги:

  • Мы автоматизировали этапы процесса, что увеличило скорость и предсказуемость обработки претензий.
  • Мы предоставили специалистам по обработке претензий общий набор интерфейсов, через которые можно обращаться к системам обработки претензий и полисов как LGI, так и DirectCar. Это повысило гибкость обработки претензий по полисам, принадлежащим любой из наших компаний.
  • Мы автоматизировали взаимодействия с некоторыми внешними агентами, такими, как органы по выдаче лицензий. Такая автоматизация была относительно простой и содержала только одно взаимодействие – проверку регистрации автомобилей.
    •

    За дополнительной информацией обращайтесь к серии статей в IBM developer-Works $$\text{\textregistered}$$, "Merging disparate IT systems: Build a single integrated view for users quickly and with minimal disruption", которую можно найти по адресу http://www-128.ibm.com/developerworks/ibm/library/i-merge.html

    Фаза 2. Автоматизация внешних транзакций

    В оставшейся части курса мы сконцентрируемся на второй фазе реализации:

  • Автоматизация более сложных взаимодействий с внешними организациями, в частности автоматизация задач, связанных с оценкой претензии:
  • создание контрактов с оценщиками ущерба;
  • выбор оценщика для данного конкретного случая;
  • запуск процесса оценки;
  • слежение за ходом оценки и производительностью оценщика;
  • получение отчета об оценке.
    •

    Автоматизация внешней оценки претензии

    В компании LGI в рамках корпоративной ИТ-стратегии было решено считать проект по автоматизации работы с внешними оценщиками пилотным проектом перевода технологической базы в сторону большего использования открытых стандартов в бизнес-приложениях. Компания уже использовала Java 2 Enterprise Edition (J2EE) на уровне представления и употребила Web-службы для простых взаимодействий с внешними организациями.

    Теперь проблема состоит в том, чтобы уделить внимание навыкам, необходимым для создания приложений для бизнес-процессов с использованием BPEL на платформе J2EE, выявить все технологические нестыковки при внедрении технологии BPEL и оценить преимущества использования новой технологии. Основными вопросами здесь являются инструменты для моделирования решений на BPEL и UML. Будут ли эти инструменты работать друг с другом и ускорят ли они разработку и внедрение решения?

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

  • С точки зрения бизнеса данное решение должно быть полезным вложением капитала. Оно не влияет сразу на весь бизнес, поскольку его можно устанавливать поэтапно, с постепенной заменой имеющегося ручного процесса.
  • С технической точки зрения переход на открытые стандарты, такие, как Web-службы и BPEL, весьма приоритетен для процессов, в которых участвуют бизнес-партнеры. Процесс оценки претензий также будет пилотным для интеграции WebSphere MQ Workflow и WebSphere Business Integration Server Foundation, а также интеграции BPEL-процесса, использующего Web-службы, с существующей в LGI инфраструктурой обмена сообщениями.
    •

    Новый процесс также должен использовать имеющийся у LGI каркас WebSphere MQ для взаимодействия со службами, входящими в системы LGI и DirectCar. Этот каркас также предоставляет шлюз для соединения со службами бизнес-партнеров и со службами LGI, которые компания предоставляет своим бизнес-партнерам. Этот каркас развился из шины обмена сообщениями, соединяющей компоненты приложений, и стал сервисной шиной, использующей в качестве основных транспортных протоколов SOAP/JMS и SOAP/http.

    Фаза 3. Будущий мониторинг данных о претензии

    В будущем нужно будет выполнить такие действия:

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

    Слежение за ходом обработки претензии

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

  • Созданием "пульта управления" бизнесом, обеспечивающего для бизнеса представление о ходе процесса обработки.
  • Совершенствованием процесса обработки претензии путем сбора данных о производительности. Эти данные могут использовать:
  • бизнес-партнеры, для изучения своей производительности;
  • бизнес-аналитики для изучения возможностей для совершенствования процесса на основе ввода реальных данных в модель, имитирующую работу оценщика претензий.
    •

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

    Дальнейшее содержание данного курса имеет следующую структуру:

  • в следующей лекции обсуждается методика и инструменты, используемые нами при создании нового решения, которое позволит компании LGI достичь поставленных ИТ-целей – увеличения производительности, обеспечения большего соответствия ИТ-решений бизнес-целям и более быстрого ввода решения в эксплуатацию;
  • в лекции 4, "Бизнес-процесс", мы используем WebSphere Business Integration Modeler для разработки нового бизнес-процесса;
  • в лекции 5, "Архитектура системы", и в лекции 6, "Архитектура решения" мы используем для разработки нового решения и расширения имеющейся архитектуры шаблоны для электронного бизнеса (Patterns for e-Business) и Rational Software Architect.
    •

    2.6 Заключение

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

    Предыдущее занятие Следующее занятие
    Вернуться к учебному плану
    ^