Amdocs Cramer OSS integration with other OSS/BSS systems

The Client

This project was completed for a major European telecom operator that provides cellular and landline telephone services, cable TV, Internet services, etc. to millions of users in Europe.

The Scope

The telecom provider has a lot of existing enterprise applications which are responsible for supporting different sides/aspects of company’s business processes, such as order management, network equipment reservation, document services sold to the customers, manage pools of IP addresses and so on. All those systems, one way or another, are integrated and communicating to Amdocs Cramer OSS via rudimentary custom application programming interface (old API) based on a set of atomic Oracle PL/SQL functions and procedures, and Oracle tables were used as a data storage buffer between the client and server-side business logic. The old API offered an ability to automatically manage only a small portion of services and products from the company’s stack. Most of the offered services were documented in Amdocs Cramer OSS manually using the Wizards or pieces of documentation were shared between the systems. In other words, there was no unified data storage.

Having studied all the weak and strong points of the old API, it was decided to design and implement a brand new application programming interface (new API) that exposes high-level operations and conforms to modern enterprise standards and trends. The main purpose of the new API is to provide a single point of integration with Amdocs Cramer OSS for all concerned systems (used by the company).

The Challenge

The most challenging part of the project is related to deep analysis of company’s business processes, which cover customer orders and network inventory management activities. The business processes had to be investigated carefully, classified and then reflected to API operations, domain model and states of its objects.

The new API has to cover the following key features

• Allow management (reserve, release and change) physical (ports, nodes, etc.) and logical (IP addresses, VLAN IDs, circuits, bandwidth, etc.) network resources.
• Make it possible to document services sold to the customers, based on a wide range of network technologies and hierarchies such as: Unbundling, ISDN, ATM, EFM, PDH, SDH, Ethernet, xDSL, etc., on the other hand different types of services: Telephony, IP/MPLS Core, Ethernet/VPLS, Voice over IP and End to End.
• Support upgrade\downgrade bandwidth for the sold physical lines via utilizing current network configuration or reconnecting a customer to a new type of equipment.
• Provide (by request) 3rd party systems details about documented services, as well as physical and logical network inventory associated to them.
• Client-server exchanging based on the SOAP protocol.
• Expose utility public operations which allow to retrieve object instances from the Cramer OSS object model.

The new API and back-end solution has to meet high performance requirements.

The project was coupled to the beginning of transition to new API on all dependent 3rd party systems. Which led to more activities for project timeline and phase planning activities.

The Solution

During the analysis phase of the project, we designed entities representing the domain model (affected by the project scope), and it was decided to represent the business process for documenting services as set of atomic operations (subprocesses). Each operation is responsible for a small part of business process flow. Once the operation is completed, it moves all associated objects to certain state, while the next subprocess uses them as input objects. Thus, sequential (and sometime parallel) execution of the subprocesses leads the planned result. For instance, in order to document a new service, which has been sold to a customer, the following sequence of sub-processes was extracted and designed: reservation of physical network resources on the company’s side, documentation of the customer premises equipment, reserve IP addresses (from the pool) and VLAN ID (on demand), document logical inventory to provide access to service ready network.

For each atomic operation we estimated the amount of activities to fulfill the subprocess. As a result, the following classification was designed: automatic subprocesses — closed loop operation which can be accomplished without any activities on engineer’s side, semiautomatic — has to be served manually at some step (for instance, a physical port has to be chosen manually), manual — complied fully by an engineer via Cramer OSS Task Engine.

Changes made by subprocesses can be adjusted or rolled back via “release” and “change” operations provided by the new API. For instance, when service is no longer required for a customer, it can be deleted from Cramer OSS (as well as all associated objects).

Implementation of API, provided by Cramer OSS, based on Oracle dialect of PL/SQL. To reach high performance, business-logic of the new API was implemented using PL/SQL.

As technology for the interface side of the new API was chosen specification Java Web Service (JAX-WS) which uses XML-based standard of communication between client and server. This technology was chosen because it is a de facto standard for enterprise application and wide range of systems support it out of the box. Essentially, the web service acts as a buffer (proxy) tier.

The Outcome

At the moment the new API is on its way to “production” — the UAT phase of the project is ongoing. Once this phase is complete, all concerned 3rd party systems are going to be switched to the new implementation, access to the old API will be smoothly switched off.

The new API has to reach the following key points

• Significant increase in the amount and speed of processed data, thanks to wide range of automatic operations and high performance.
• More accurate and precise documentation of the company’s network inventory in Amdocs Cramer OSS, as a result more efficient customer support service.
• Launch single Amdocs Cramer OSS integration point for the company’s systems.
• Support large portion of products from the company’s stack which can be managed via the new API.
• Provide flexible solution for the cases of launching a brand new product: set of operations provided by the new API can be extended, and business-logic changed without significant efforts.

Sub-Projects

On-site Analysis — the initial phase of the project involved a face-to-face meeting with the client and its project team to discuss the challenges, gather requirements, design the solution, and finally develop the high-level solution (HLS) document.

Cramer Customization — since the project touches business process, Amdocs Cramer OSS also had to be customized so as to meet new requirements. The following Cramer OSS components were customized: WebReports, TaskEngine, SyncEngine, Wizards, Data Model, Callouts.

Cramer Data Migration — the old API manages custom objects (as well as some core objects) from Cramer Data Model. All of them have to be migrated to a new Data Model designed for the new API. In order to meet high performance requirements the following key features were used: Oracle PL/SQL, Cramer PL/SQL API and Cramer data tables.

Cramer Data Load — the subproject is aimed to import\load to Cramer OSS information about the sold services, but not documented in Cramer OSS. The documentation for the services is shared between several enterprise applications, and had to be extracted before the load.

SDH Adapter for Cramer SyncEngine — in order to keep SDH equipment synchronized with “picture” in real SDH network, custom SyncEngine adapter was designed and implemented. The adapter is responsible for the following components of the SDH hierarchy: MS Bearer, HO Trail (including KLM position), LO Trail, LO Path + Protection.