Главная/Портфолио/Интеграция Amdocs Cramer OSS с другими OSS/BSS-системами оператора связи
Telecom OperatorИнтеграция Amdocs Cramer OSS с другими OSS/BSS-системами оператора связи
Проект был выполнен для крупного европейского оператора связи, который предоставляет услуги сотовой и фиксированной телефонной связи, кабельного телевидения, Интернета и т. д. для миллионов пользователей в Европе.
Поставщик телекоммуникационных услуг использует множество корпоративных приложений, которые отвечают за поддержку различных аспектов бизнес-процессов компании. Таких как управление заказами, резервирование сетевого оборудования, управление документацией по оказываемым клиентам услугам, управление пулами IP-адресов и так далее.
Все эти системы так или иначе интегрированы и взаимодействуют с OSS Amdocs Cramer посредством малофункционального API-интерфейса (старый API), основанного на наборе атомных функций и процедур Oracle PL/SQL и таблицах Oracle, которые использовались в качестве буфера данных между клиентом и бизнес-логикой на стороне сервера.
Старый API позволял автоматически управлять лишь небольшой частью услуг и продуктов из спектра компании. Большинство предлагаемых услуг были задокументированы в Amdocs Cramer OSS вручную с помощью мастера. В некоторых случаях отдельные части документации находились в разных системах. Другими словами, не было единого хранилища данных.
Изучив все сильные и слабые стороны старого API-интерфейса, было решено разработать и внедрить совершенно новый API-интерфейс, который содержит операции высокого уровня и соответствует современным корпоративным стандартам. Основной целью нового API является создание единой точки интеграции с OSS Amdocs Cramer для всех систем, используемых компанией.
Наиболее сложная часть проекта связана с глубоким анализом бизнес-процессов компании, которые охватывают заказы клиентов и деятельность по управлению сетевыми ресурсами. Необходимо было тщательно исследовать и классифицировать бизнес-процессы и отразить их в операциях API.
Новый API должен охватывать следующие основные функции:
- Управление (резервирование, освобождение и изменение) физическими (порты, узлы и т. д.) и логическими (IP-адреса, идентификаторы виртуальных сетей, схемы, пропускная способность) сетевыми ресурсами.
- Документирование услуг, оказанных клиентам, на основе широкого спектра сетевых технологий и иерархий. Таких, например, как: ISDN, ATM, EFM, PDH, SDH, Ethernet, XDSL и т. д., и с другой стороны, поддержка различных видов услуг: телефония, IP/MPLS Core, Ethernet/VPLS, IP-телефония и т. д.
- Поддержка увеличения/уменьшения пропускной способности для проданных физических линий с использованием текущей конфигурации сети или с помощью подключения клиента к новому типу оборудования.
- Предоставление (по запросу) сторонних сведений о документируемых услугах, таких как перечень сетевых компонентов для физических и логических сетей.
- Клиент-серверный обмен данными на основе протокола SOAP.
- Предоставление общедоступных операций для получения экземпляров объектов из объектной модели OSS Cramer.
- Новый API и серверное решение должны соответствовать высоким требованиям к производительности.
Проект был связан с началом перехода на новый API на всех зависимых сторонних системах. Это привело к увеличению объема мероприятий по планированию проекта.
На этапе анализа проекта мы разработали объекты, представляющие модель предметной области (которая определяется содержанием проекта), и было принято решение представить бизнес-процесс для услуг документирования в виде совокупности атомарных операций (подпроцессов).
Каждая операция отвечает за небольшую часть потока бизнес-процесса. После завершения она перемещает все связанные с ней объекты в определенное состояние. Следующий подпроцесс использует эти объекты в качестве входных объектов.
Таким образом, последовательное (а иногда параллельное) выполнение подпроцессов приводит к запланированному результату. Например, для того чтобы задокументировать новую услугу, которая была продана клиенту, была выделена и разработана следующая последовательность подпроцессов: резервирование физических сетевых ресурсов компании, документирование локального оборудования клиента, резервирование IP-адресов (из пула) и идентификация виртуальной локальной сети (по требованию), разработка логического перечня для предоставления доступа к готовой сети.
Для каждой атомарной операции мы оценили необходимый объем действий для выполнения подпроцесса. В результате была разработана следующая классификация: автоматические подпроцессы — автономные операции, которые можно выполнить без каких-либо действий со стороны инженера, полуавтоматические подпроцессы — операции, которые требуют действий вручную на каком-то этапе (например, выбор физического порта вручную), ручные подпроцессы — выполняются полностью вручную инженером с помощью модуля задач Cramer OSS.
Изменения, выполненные подпроцессами, можно скорректировать или откатить с помощью операций «выпуска» и «изменения», предоставляемых новым API. Например, когда услуга больше не требуется для клиента, ее (а также все связанные с ней объекты) можно удалить из Cramer OSS.
Реализация API обеспечивается Cramer OSS на основе диалекта Oracle PL/SQL. Для достижения высокой производительности бизнес-логика нового API была реализована с помощью PL/SQL.
В качестве технологии со стороны интерфейса для нового API была выбрана спецификация веб-сервиса Java (JAX-WS), который использует стандарт на основе XML для связи клиента и сервера. Эта технология была выбрана потому, что она является стандартом де-факто для корпоративных приложений и по умолчанию поддерживается широким спектром систем. По сути дела, разработанный веб-сервис выступает в качестве буферного уровня (уровня прокси).
На данный момент новый API находится на пути к «рабочей фазе» — продолжается фаза пользовательского тестирования проекта. После того как этот этап будет завершен, все сторонние системы будут переведены на новую реализацию, доступ к старому API будет постепенно закрываться.
Новый API должен охватывать следующие основные функции:
- Значительное увеличение количества и скорости обрабатываемых данных благодаря широкому спектру автоматических операций и высокой производительности
- Более точная документация инвентаризации сети в Cramer OSS, в результате чего повысится эффективность службы поддержки клиентов
- Запуск одной точки интеграции Cramer OSS для систем компании
- Поддержка большой части продуктов из стека компании, которыми можно управлять с помощью нового API
- Предоставление гибкого решения для запуска совершенно новых продуктов: набор операций, предусмотренных новым API, может быть расширен, а бизнес-логика может быть изменена без значительных усилий.
Подпроекты:
- Анализ на месте. Начальная фаза проекта включала встречу с клиентом и его проектной командой лицом к лицу, чтобы обсудить проблемы, определить требования, спроектировать решение и, наконец, разработать документацию высокого уровня для создаваемого решения.
- Настройка Cramer. Поскольку проект касается бизнес-процесса, было необходимо также настроить Cramer OSS для соответствия новым требованиям. Были настроены следующие компоненты Cramer OSS: веб-отчеты, модуль задач, модуль синхронизации, мастера, модель данных, выноски.
- Миграция данных Cramer. Старый API управляет пользовательскими объектами (а также некоторыми объектами ядра) из модели данных Cramer. Все эти объекты должны быть перенесены в новую модель данных, предназначенную для нового API. Для удовлетворения требований высокой производительности были использованы следующие основные компоненты: Oracle PL/SQL, Cramer PL/SQL API и таблицы данных Cramer.
- Загрузка данных Cramer. Этот подпроект был направлен на то, чтобы импортировать или загрузить в Cramer OSS информацию о проданных услугах, которая не была задокументирована в Cramer OSS. Документация для услуг распределяется между несколькими корпоративными приложениями, и должна была быть извлечена перед загрузкой.
- Адаптер SDH для модуля синхронизации Cramer. Чтобы оборудование SDH было синхронизировано с «картинкой» в реальной сети SDH, был разработан и реализован пользовательский адаптер модуля синхронизации. Адаптер отвечает за следующие компоненты иерархии SDH: MS Bearer, HO Trail (в том числе положение KLM), LO Trail, LO Path + Защита.