Главная/Портфолио/Интеграция 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 + Защита.

 

 

Примеры проектов

Запросите консультацию эксперта

Отправить заявку

Вы можете загружать файлы до 200 Мб в форматах doc, docx, pdf, odt, ott, txt, jpeg, xls, rar, zip, 7z

Фильтр

Закрыть

Технологии

Индустрии