Northbound XML Interface User Guide V100R002C01 05

(1)

System

V100R002C01

Northbound XML Interface User

Guide

Issue 05

Date 2010-11-19

(2)

(3)

No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd.

All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice

The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute the warranty of any kind, express or implied.

Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base

Bantian, Longgang Shenzhen 518129

People's Republic of China

Website: http://www.huawei.com

(4)

(5)

About This Document

Related Versions

The following table lists the product versions related to this document.

Product Name Version

iManager U2000 V100R002C01

Intended Audience

The iManager U2000 Northbound XML Interface User Guide describes the basic concept and principles of U2000 northbound XML interface. And it is also describes how to deploying and maintaining the XML NBI. This document also provides the relationship between the XML NBI and license, service port description, supported equipments, the object naming rule, layer rate description, the glossary, and the acronyms and abbreviations.

This document guides the user to understand basic operations of the U2000 XML NBI. This document is intended for:

l Installation and Commissioning Engineer

l Data Configuration Engineer

l Application Developer

Symbol Conventions

The symbols that may be found in this document are defined as follows.

Symbol Description

DANGER

Indicates a hazard with a high level of risk, which if not avoided, will result in death or serious injury.

WARNING

Indicates a hazard with a medium or low level of risk, which if not avoided, could result in minor or moderate injury.

(6)

Symbol Description

CAUTION

Indicates a potentially hazardous situation, which if not avoided, could result in equipment damage, data loss, performance degradation, or unexpected results.

TIP Indicates a tip that may help you solve a problem or save

time.

NOTE Provides additional information to emphasize or supplement

important points of the main text.

Command Conventions

The command conventions that may be found in this document are defined as follows.

Convention Description

Boldface The keywords of a command line are in boldface.

Italic Command arguments are in italics.

[ ] Items (keywords or arguments) in brackets [ ] are optional.

{ x | y | ... } Optional items are grouped in braces and separated by

vertical bars. One item is selected.

[ x | y | ... ] Optional items are grouped in brackets and separated by

vertical bars. One item is selected or no item is selected.

{ x | y | ... }* _{Optional items are grouped in braces and separated by}

vertical bars. A minimum of one item or a maximum of all items can be selected.

[ x | y | ... ]* _{Optional items are grouped in brackets and separated by}

vertical bars. Several items or no item can be selected.

GUI Conventions

The GUI conventions that may be found in this document are defined as follows.

Convention Description

Boldface Buttons, menus, parameters, tabs, window, and dialog titles are in boldface. For example, click OK.

> Multi-level menus are in boldface and separated by the ">"

(7)

Change History

Updates between document issues are cumulative. Therefore, the latest document issue contains all updates made in previous issues.

Changes in Issue 05 (2010-11-19) Based on Product Version V100R002C01

Errors are corrected.

Changes in Issue 04 (2010-09-24) Based on Product Version V100R002C01

Changes in Issue 03 (2010-08-16) Based on Product Version V100R002C01

Changes in Issue 02 (2010-07-16) Based on Product Version V100R002C01

Changes in Issue 01 (2010-05-18) Based on Product Version V100R002C01

Initial release.

(8)

(9)

About This Document...iii

1 System Overview...1-1

1.1 Introduction...1-2 1.2 Standards and Protocols Compliance...1-2 1.3 Position of the XML NBI in the Integrated NMS...1-2 1.4 Supported Domains and Functions...1-3 1.4.1 Alarm Function of the XML NBI...1-3 1.4.2 Functions of the XML NBI (Configuration)...1-4 1.4.3 Performance Function of the XML NBI...1-6 1.4.4 Functions of the XML NBI (Resource)...1-6 1.5 System Structure...1-10 1.6 Technical Specifications...1-11

2 Principles...2-1

2.1 Description of Involved Technology...2-2 2.2 Working Principles of an XML NBI...2-3 2.3 Sample Flow...2-8

3 Deploying and Configuring the XML NBI...3-1

3.1 Overview...3-2 3.2 Configuration Requirements...3-3 3.3 Logging in to the Client of the NMS Maintenance Suite...3-3 3.4 Checking the XML NBI Status...3-5 3.5 Deploying the XML NBI for the First Time...3-6 3.5.1 Adding XML NBI Component...3-6 3.5.2 Adding the XML NBI Instance...3-7 3.6 Configuring the XML NBI...3-13

4 Maintaining the XML NBI...4-1

4.1 Requirements for Maintenance Staff...4-3 4.2 Routine Maintenance...4-3 4.3 Logging In to the System Monitor Client...4-4 4.4 Stopping the XML NBI...4-5 4.5 Disabling the XML NBI...4-7 4.6 Restarting the XML NBI...4-8

(10)

4.7 Deleting the XML Interface Instance...4-10 4.8 Deleting the XML NBI Component...4-11 4.9 FAQ...4-12 4.9.1 Failure in Starting the U2000 XML Interface...4-12 4.9.2 Whether the U2000 Successfully Enables the XML Interface...4-12 4.9.3 Whether the U2000 XML Interface is Licensed...4-13

A Relations Between License and XML Interface...A-1

B Service Port Description...B-1

B.1 Service Ports Used by the XML Interface...B-2 B.2 Notes and Precautions...B-3

C Product List...C-1

D Object Naming Rules...D-1

D.1 MD...D-2 D.2 OS...D-2 D.3 ME...D-3 D.4 TL...D-4 D.5 EH...D-5 D.6 EQ...D-6 D.7 PTP...D-8 D.8 FTP...D-9 D.9 CTP...D-11 D.10 RESOURCESITE...D-12 D.11 TUNNELPOLICY...D-13 D.12 TMD...D-14 D.13 CC...D-15 D.14 PG...D-16 D.15 SNC...D-17 D.16 EPG...D-18 D.17 EXPLICITPATH...D-19 D.18 FDFR...D-20 D.19 VRRP...D-21 D.20 TCPROFILE...D-22

E Layer Rate Description...E-1

F Glossary...F-1

G Acronyms and Abbreviations...G-1

(11)

Figures

Figure 1-1 Position of the XML interface of the U2000 in the integrated NMS... 1-3 Figure 1-2 Software structure...1-11 Figure 2-1 SOAP message... 2-4 Figure 2-2 Principles of HTTP request response... 2-5 Figure 2-3 JMS...2-6 Figure 2-4 Interconnection process of the XML NBI...2-7 Figure A-1 Main dimensions...A-1

(12)

(13)

Tables

Table 1-1 Functions supported by the XML NBI (configuration)... 1-4 Table 1-2 Functions supported by the XML NBI (resource)... 1-6 Table 1-3 XML component...1-11 Table 1-4 Performance indicators of an XML NBI...1-12 Table 3-1 Parameters for the JMS server... 3-8 Table 3-2 Parameters for the JMS server... 3-9 Table 3-3 Parameters for the Advanced Items...3-10 Table 3-4 Parameters for the JMS server...3-14 Table 3-5 Parameters for the JMS server...3-15 Table 3-6 Parameters for the Advanced Items...3-16 Table 4-1 Meanings of license items...4-13 Table A-1 Dimension description...A-2 Table A-2 Description for License Item...A-2 Table E-1 List of layer rates supported by the U2000 XML NBI...E-1

(14)

(15)

1

System Overview

About This Chapter

This chapter describes the technology features of XML NBI.

1.1 Introduction

By bringing together modern software technologies and state-of-the-art technology models, the TM Forum has enabled the birth of a new interface standard, the Multi-Technology Operations Systems Interface (MTOSI). MTOSI will facilitate application-to-application inter-working, reduce time of deployment, and lower the cost of ownership of Operations Software and Systems (OSS). Service providers will gain leverage by being able to integrate systems from multiple vendors with a minimum of "integration tax."

1.2 Standards and Protocols Compliance

The upper-level integrated NMS and OSS can communicate with the iManager U2000 that is compliant with the MTOSI standards by using the MTOSI. In this way, the upper-level integrated NMS and OSS can manage Huawei transport equipment, routers equipment, security equipment and metro ethernet equipment) in a centralized manner.

1.3 Position of the XML NBI in the Integrated NMS

This section describes the position of XML NBI in the integrated NMS. 1.4 Supported Domains and Functions

The U2000 XML NBI provide alarm management, service provisioning, inventory management, and performance management and can be integrated with the upper-layer OSS easily.

1.5 System Structure

This topic describes the system structure of the U2000 XML NBI. 1.6 Technical Specifications

This topic describes the performance indicators of the U2000 XML NBIs to provide a reference for the interconnection with the OSS.

(16)

1.1 Introduction

By bringing together modern software technologies and state-of-the-art technology models, the TM Forum has enabled the birth of a new interface standard, the Multi-Technology Operations Systems Interface (MTOSI). MTOSI will facilitate application-to-application inter-working, reduce time of deployment, and lower the cost of ownership of Operations Software and Systems (OSS). Service providers will gain leverage by being able to integrate systems from multiple vendors with a minimum of "integration tax."

With reference to the MTOSI recommendations, the XML interface of the U2000 is developed for iManager U2000. Network management systems of different levels can communicate with one another by using the MTOSI. The application of the MTOSI can meet the trends of the integration of network management systems and the development of cross-domain network management systems.

1.2 Standards and Protocols Compliance

The upper-level integrated NMS and OSS can communicate with the iManager U2000 that is compliant with the MTOSI standards by using the MTOSI. In this way, the upper-level integrated NMS and OSS can manage Huawei transport equipment, routers equipment, security equipment and metro ethernet equipment) in a centralized manner.

The MTOSI is compliant with the TMF standards as follows:

l TMF518

l TMF612

l TMF864

The MTOSI can realize the standard interface functions as follows: l Query and notification of the physical inventory

l Alarm reporting

l Alarm query

l Acknowledgement and unacknowledgement of alarms

1.3 Position of the XML NBI in the Integrated NMS

This section describes the position of XML NBI in the integrated NMS.

(17)

Figure 1-1 Position of the XML interface of the U2000 in the integrated NMS Security Equipment Transport Network SDH/WDM /OTN/MW IP Network Router/Switch /PTN/BRAS OSS U2000 Northbound XML Interface U2000 Transport Network SDH/WDM /OTN/MW Other EMS other Equipments

1.4 Supported Domains and Functions

The U2000 XML NBI provide alarm management, service provisioning, inventory management, and performance management and can be integrated with the upper-layer OSS easily.

1.4.1 Alarm Function of the XML NBI

1.4.2 Functions of the XML NBI (Configuration) 1.4.3 Performance Function of the XML NBI 1.4.4 Functions of the XML NBI (Resource)

1.4.1 Alarm Function of the XML NBI

The northbound XML alarm interface provides the following functions: l Query of the alarm.

l Measurement of the alarm quantity.

l Acknowledgment and unacknowledgment of the alarm.

(18)

l Query of the performance threshold-crossing event.

1.4.2 Functions of the XML NBI (Configuration)

Table 1-1 Functions supported by the XML NBI (configuration)

Function Description Domain

Per-NE-based VPN service provisioning

Creating, deleting, modifying, activating, and deactivating a per-NE-based service, a PWE3 service (AES, CES, or EES service), or an L3VPN service, and reporting notifications accordingly

Adding, deleting, activating, and deactivating a per-NE-based VPLS service site, and reporting

notifications accordingly

Adding, deleting, activating, and deactivating a per-NE-based L3VPN service site, and reporting notifications accordingly

Creating, deleting, activating, and deactivating a per-NE-based PW switch, and reporting notifications accordingly

Configuring the QoS feature for the PWE3, VPLS, and L3VPN services in the routing domain, the multicast feature for VPLS and L3VPN services, and the BRAS feature for L3VPN services

Routing and PTN domains

Per-NE-based tunnel management

Creating, deleting, modifying, activating, and

deactivating a per-NE-based tunnel (RSVP-TE, static, or IP tunnel), and reporting notifications accordingly

Routing and PTN domains QoS template

management

Creating, deleting, modifying, applying, and

unapplying a QoS template, and reporting the creation and deletion notifications of a QoS template

accordingly

Applying and unapplying a QoS template to and from a port Routing and PTN domains Attribute configuration of physical ports

Configuring the attributes of physical ports (POS, ATM, Ethernet, or PDH ports) in the IP domain and reporting notifications accordingly

Configuring the attributes of physical ports in the transport domain and reporting notifications accordingly Routing, PTN, switch, and transport domains

(19)

Function Description Domain Management of

logical ports

Creating, deleting, and modifying a logical port (Ethernet trunk, IP trunk, MP group, IMA, logical serial port, MFR group, VLAN IF, or tunnel IF) and reporting notifications accordingly

Configuring a member port for a logical port of the aggregation type, including adding, modifying, and deleting a member port and reporting notifications accordingly

Configuring an Ethernet trunk port of the aggregation type in the switch domain, including creating and deleting an Ethernet trunk logical port, and configuring member ports for the Ethernet trunk logical port

Routing, PTN, and switch domains Subinterface management

Creating and deleting a subinterface, configuring the attributes of a subinterface, and reporting notifications accordingly

Routing domain

VLAN management of ports

Configuring the working mode of a port

Configuring the default VLAN, allowed VLANs, and VLAN removal attributes

Configuring the VLAN stacking, VLAN mapping, and VLAN multicast feature for a port

Routing and switch domains

Global VLAN management

Creating, deleting, and modifying a VLAN in the access domain, and configuring the multicast feature for the VLAN

Creating, deleting, and modifying a global VLAN in the switch domain, and configuring the multicast feature for the global VLAN

Creating, deleting, and modifying a global VLAN in the routing domain

Access, switch, and routing domains NE attribute configuration

Configuring the basic attributes of an NE, deleting an NE, and reporting notifications accordingly

All domains GPON service

provisioning

Provisioning GPON services, and creating, deleting, modifying, activating, and deactivating the GPON services

Access domain

ONT management Creating and deleting an ONT, and configuring the

attributes of the ONT and ONT ports

Access domain Transmission

descriptor management

Creating and deleting a transmission descriptor, and reporting notifications accordingly

Routing and PTN domains Tunnel policy

management

Creating, deleting, and modifying a tunnel policy, and reporting notifications accordingly

Routing domain

(20)

Function Description Domain VRRP management Creating, modifying, and deleting a VR interface and a

VR monitoring interface, configuring the global attributes of the VR interface, and reporting notifications accordingly

Routing domain

ANCP management Configuring the global ANCP attributes, creating and deleting a global ANCP template, applying an ANCP neighbor template to ports, and setting ANCP line parameters

Routing domain

1.4.3 Performance Function of the XML NBI

The XML NBI provides the following functions: l Querying the current performance data. l Querying the history performance data.

l Reporting performance threshold-crossing events.

1.4.4 Functions of the XML NBI (Resource)

Table 1-2 Functions supported by the XML NBI (resource)

Function Description Domain

Query for the management domains and OS

Querying the management domains of the U2000 and OS information

-Resource site query Querying information about all optical NEs in the transport domain

Querying the names of all optical NEs in the transport domain

Querying the details of a single optical NE by optical NE name

Querying information about resources (such as card and slot information) of an optical NE by optical NE name

Reporting the creation and deletion notifications of an optical NE

Reporting the status change notifications of resources of an optical NE

Transport domain

(21)

Function Description Domain NE information

query

Querying the names of all NEs in the management domain

Querying the details of all NEs in the management domain

Querying the details of a single NE by NE name Querying information about NEs in the routing and switch domains by IP address

Reporting the creation, deletion, and attribute change notifications of an NE

All domains

Fiber/Cable query Querying information about fibers in the transport domain

Querying information about IP links and Layer 2 links in the routing domain

Querying fibers, IP links, and Layer 2 links, and reporting the creation and deletion notifications accordingly Transport and routing domains Query for information about the resources of an NE

Querying information about shelves, slots, cards, and subslots of an NE by NE name

Querying information about cards, subslots, and others of an equipment holder by equipment holder name Reporting addition and deletion notifications of a shelf, slot, or card

All domains

Query for physical port information

Querying the names of all physical ports (including POS, ATM, Ethernet, and PDH ports) on an NE by NE name

Querying the details of all physical ports on an NE by NE name

Querying the details of a single physical port by physical port name

Reporting the change notifications of important attributes of a physical port

All domains

Query for logical port information

Querying the names of all logical ports (including Ethernet trunk, IP trunk, MP group, IMA, logical serial port, MFR group, and VLAN IF) on an NE by NE name Querying the details of all logical ports on an NE by NE name

Querying the details of a single logical port by logical port name

Reporting the creation, deletion, and attribute change notifications of a logical port

Reporting the notifications of adding and deleting a member port to and from a logical port of the aggregation type Transport, routing, PTN, and switch domains

(22)

Function Description Domain Subinterface query Querying the names of all subinterfaces of a physical

port or logical port by physical port name or logical port name

Querying the details of all subinterfaces of a physical port or logical port by physical port name or logical port name

Querying the details of a single subinterface by subinterface name

Reporting the creation, deletion, and attribute change notifications of a subinterface

Transport and routing domains

VPN service query Querying the names of all VPN services (including PWE3, VPLS, and L3VPN services) on an NE by NE name

Querying the details of all VPN services (including PWE3, VPLS, and L3VPN services) on an NE by NE name

Querying the details of a single VPN service (PWE3, VPLS, or L3VPN service) by VPN service name Reporting the creation, deletion, status change, and attribute change notifications of a VPN service

QoS template query Querying the names of all global QoS templates in the management domain

Querying the details of all global QoS templates in the management domain

Querying the details of a single QoS template by QoS template name

Querying resources where a QoS template is applied by QoS template name

Reporting the creation and deletion notifications of a QoS template

Tunnel query Querying the names of all dynamic tunnels, static

tunnels, and IP tunnels of an NE by NE name Querying the details of all dynamic tunnels, static tunnels, and IP tunnels of an NE by NE name

Querying the details of a single tunnel by tunnel name Reporting the creation, deletion, status change, and attribute change notifications of a tunnel

Tunnel policy query Querying the names of all tunnel policies of an NE Querying the details of all tunnel policies of an NE Reporting the creation and deletion notifications of a tunnel policy

Routing domain

(23)

Function Description Domain Transmission

descriptor query

Querying the names of all transmission descriptors of an NE

Querying the details of all transmission descriptors of an NE

Reporting the creation and deletion notifications of a transmission descriptor

Query for trails and cross-connections

Querying the names of network-wide SDH, WDM, OTN, and RTN trails

Querying the details of network-wide SDH, WDM, OTN, and RTN trails

Querying the details of a single SDH, WDM, OTN, or RTN trail by trail name

Querying all cross-connections of an NE Querying the routes of a trail by trail name

Querying the routes and optical fibers of a trail by trail name

Reporting the creation, deletion, status change, and attribute change notifications of a trail

Reporting the creation and deletion notifications of a cross-connection

Reporting the notification of route attribute changes of a trail

Transport domain

Protection group query

Querying all SDH, WDM, and equipment protection groups of an NE

Querying the details of a single SDH, WDM, or equipment protection group by protection group name Querying the protection switching data of a single SDH, WDM, or equipment protection group by protection group name

Transport domain

GPON service query Querying the names of all PON services on an NE by NE name

Querying the details of all PON services on an NE by NE name

Querying the details of a single PON service by PON service name

Querying the routes of a PON service by PON service name

Access domain

ONT query Querying information about ONTs associated with an

OLT or a PON port by OLT name or PON port name, and querying ONT information by ONT name

Access domain

(24)

Function Description Domain Query for service

virtual ports and profiles

Querying service virtual ports of an NE by NE name Querying ADSL line profiles, G.SHDSL line profiles, and MEF IP traffic profiles of an NE by NE name

Access domain

ANCP information query

Querying all ANCP neighbor templates on an NE by NE name

Querying all ANCP line information of an NE by NE name

Querying ports where an ANCP neighbor template is applied by ANCP neighbor template name

Routing domain

VRRP information query

Querying the names of all VR interfaces of an NE by NE name

Querying the details of all VR interfaces of an NE by NE name

Querying information about the VR monitoring interface of a VR interface by VR interface name Querying the global attributes of a VR interface by VR interface name

Routing domain

Query for physical inventories by using a coarse granularity interface

Querying the management domain, OS, cables, and NEs by using the getInventory interface

Querying the shelves, slots, cards, physical ports of the entire network or a single NE by using the getInventory interface

Querying the names, attributes, or details of inventory objects by specifying filter criteria

The getInventory interface supports multiple MEP modes such as SRR, SIT, and AFB.

All domains

1.5 System Structure

This topic describes the system structure of the U2000 XML NBI.

(25)

Figure 1-2 Software structure Inventory Provisioning Performance (get/set/create/delete/edit/ active/deactive operations) OSS Applications Alarm Inventory Update

(Notify events) Qx/SNMP ASN.1 JMS SOAP/HTTP/ HTTPS/FTP/ SFTP TCP/ ODBC/ JDBC Database Managed Networks U2000 GUI Client Table 1-3 XML component Component Function

U2000 Indicates the U2000 server. It is used for managing network and

providing NBIs.

GUI client Indicates the U2000 client. It provides a GUI for performing

operations on network. The client communicates with the U2000 server through the Asn.1 protocol.

OSS applications Indicates the upper layer OSS. It performs operations on network through the XML NBI provided by the U2000.

Database Indicates the U2000 database. It is used for saving and providing

U2000 data.

1.6 Technical Specifications

This topic describes the performance indicators of the U2000 XML NBIs to provide a reference for the interconnection with the OSS.

(26)

Table 1-4 shows the performance indicators of each XML NBI. Table 1-4 Performance indicators of an XML NBI

Item Indicator

Number of NMS connections received concurrently

10

Delay of response to XML request Shorter than 3s when the CPU usage is

lower than 50%

Alarm notification processing capability More than 60 records per second when 3

NMSs are connected

Alarm notification transmission delay Shorter than 10s when 3 NMSs are

connected

CAUTION

The alarm handling capability of the CORBA NBI depends on many factors, such as alarm quantity on the live network, and CPU performance and memory size of the server. If an alarm storm occurs, the CORBA NBI will possibly reach its handling limit. The CORBA NBI can report a maximum of 1,000,000 alarms within one hour. To ensure the stability of the system, the CORBA NBI will discard some alarms if the alarm quantity exceeds 1,000,000. You are recommended to handle network faults instantly if an alarm storm occurs. Also, the OSS is suggested to synchronize alarms actively at proper times, for example, when the system is idle.

(27)

2

Principles

About This Chapter

2.1 Description of Involved Technology

This section describes the related technology and concept involved in this document. 2.2 Working Principles of an XML NBI

The U2000 XML NBI adopts the Web Service technology. Web Service is a technology for accessing network services. It defines services through WSDL or XSD and implements the communication through the SOAP message. In addition, it supports various transmission protocols, such as HTTP, HTTPS, and JMS. The following describes the principles of the XML NBI based on the key scenarios supported by the U2000 XML NBI and the preceding features. 2.3 Sample Flow

(28)

2.1 Description of Involved Technology

This section describes the related technology and concept involved in this document.

MTOSI

Multi-Technology Operations System Interface (MTOSI) is a standard for implementing interfaces between OSSs. Service providers (carriers) use multiple Operational Support Systems (OSS) to manage complex networks. Since the various parts of the network must interact with the OSSs. It is standardized by the Tele-management Forum (TM Forum). The TMF NGOSS provides a set of reference models that aid in analyzing and designing next generation BSS and OSS solutions that may utilize the MTOSI interface specifications.

JMS

The Java Message Service (JMS) API is a Java Message Oriented Middleware (MOM) API for sending messages between two or more clients. JMS is a specification developed under the Java Community Process as JSR 914. The JMS API supports the following models:

l Point-to-point or queuing model. l Publish and subscribe model.

In the point-to-point or queuing model, a producer posts messages to a particular queue and a consumer reads messages from the queue. Here, the producer knows the destination of the message and posts the message directly to the consumer's queue. It is characterized by the following rule:

l Only one consumer gets the message.

l The producer does not have to be running at the time the receiver consumes the message, nor does the receiver need to be running at the time the message is sent.

l Every message successfully processed is acknowledged by the receiver.

The publish/subscribe model supports publishing messages to a particular message topic. Zero or more subscribers may register interest in receiving messages on a particular message topic. In this model, neither the publisher nor the subscribers know about each other. A good metaphor for it is anonymous bulletin board. The following is the characteristics of this model.

l Multiple consumers obtain the message.

l There is a timing dependency between publishers and subscribers. The publisher has to create a subscription in order for clients to be able to subscribe. The subscriber has to remain continuously active to receive messages, unless it has established a durable subscription. In that case, messages published while the subscriber is not connected are redistributed whenever it reconnect.

l Using Java, JMS provides a way of separating the application from the transport layer of providing data. The same Java classes are used to communicate with different JMS providers by using the JNDI information for the desired provider. The classes first use a connection factory to connect to the queue or topic, and then use populate and send or publish the messages. On the receiving side, the clients then receive or subscribe to the messages.

Web Service

The W3C defines a Web Service as a software system designed to support interoperable Machine to Machine interaction over a network. Web Service is frequently just Web APIs that are accessed

(29)

over a network, such as the Internet, and executed on a remote system hosting the requested services. The W3C Web Service definition encompasses many different systems, but in common usage the term refers to clients and servers that communicate using XML messages that follow the SOAP standard. Common in both the field and the terminology is the assumption that there is also a machine readable description of the operations supported by the server, a description in the Web Service Description Language (WSDL). The latter is not a requirement of a SOAP endpoint, but it is a prerequisite for automated client-side code generation in the mainstream Java and .NET SOAP Frameworks. Some industry organizations, such as the WS-I, mandate both SOAP and WSDL in their definition of a Web Service.

HTTP(S)

Hypertext Transfer Protocol (HTTP) is a communications protocol used to transfer or convey information on the World Wide Web. HTTP is a request/response protocol between clients and servers. The client making an HTTP request, such as a web browser, spider, or other end-user tool - is referred to as the user agent. The responding server, which stores or creates resources such as HTML files and images, is called the origin server.

WSDL

The Web Service Description Language (WSDL) is a XML-based language that provides a model for describing Web Service. The WSDL defines services as collections of network endpoints, or ports. WSDL specification provides an XML format for documents for this purpose. The abstract definition of ports and messages is separated from their concrete use or instance, allowing the reuse of these definitions. A port is defined by associating a network address with a reusable binding, and a collection of ports define a service. Messages are abstract descriptions of the data being exchanged, and port types are abstract collections of supported operations. The concrete protocol and data format specifications for a particular port type constitutes a reusable binding, where the messages and operations are then bound to a concrete network protocol and message format. In this way, WSDL describes the public interface to the Web Service.

SOAP

Simple Object Access Protocol (SOAP) is a protocol for exchanging XML-based messages over computer networks, normally using HTTP/HTTPS. SOAP forms the foundation layer of the Web Service stack, providing a basic messaging framework upon which abstract layers can be built.

XML

The eXtensible Markup Language (XML) is a general-purpose markup language. It is classified as an extensible language, because it allows its users to define their own tags. Its primary purpose is to facilitate the sharing of structured data across different information systems, particularly through internet. It is used both to encode documents and serialize data.

2.2 Working Principles of an XML NBI

The U2000 XML NBI adopts the Web Service technology. Web Service is a technology for accessing network services. It defines services through WSDL or XSD and implements the communication through the SOAP message. In addition, it supports various transmission protocols, such as HTTP, HTTPS, and JMS. The following describes the principles of the XML NBI based on the key scenarios supported by the U2000 XML NBI and the preceding features.

(30)

Defining Services Through WSDL or XSD

l The WSDL or XSD is a type of XML document.

l The XSD describes the data type and message format.

l The WSDL describes the external services and interface, and the bound transmission protocols, such as HTTP, HTTPS, and JMS.

Implementing the Communication Through the SOAP Message

l SOAP defines the data format that is irrelevant to the transmission protocol.

l The SOAP message can be enveloped as the message of any protocol for transmission.

Figure 2-1 SOAP message

Adopting the HTTP as the Key Protocol for Request Response of an Interface

l The cost of developing the client and server by using HTTP is lower than that by using

other protocols.

l The HTTP protocol is relatively mature and is supported by most of systems.

l Usually, a firewall does not block the HTTP-based communication. Therefore, HTTP can penetrate a firewall.

(31)

l Figure 2-2 Principles of HTTP request response

Adopting the JMS as the Notification Bus

l Subscription and unsubscription of various notification resources, such as inventory and alarms

– You can subscribe to one type of notifications or multiple types of notifications. l One to many notification sending

– Multiple users can subscribe to the same type of notifications. That is, the notifications can be sent to multiple users at the same time.

l Saving of notifications as a file

– The message middleware can save notification messages in a physical medium. After an OSS subscribes to a type of notifications, if the OSS goes offline due to a fault, the OSS can receive the notifications sent during the offline period when the OSS goes online.

l Flexible setting of filter criteria

– When subscribing to a type of notifications, you can specify the filter criteria. Currently, you can set filter criteria only for alarms. In this way, only the notifications that meet the filter criteria are sent to you.

(32)

(33)

Interconnection Process

Figure 2-4 Interconnection process of the XML NBI

Step Description

1 Start the JMS message middleware. 2 Start the Web Service middleware. 3 Establish a connection.

4 Connect to the JMS message middleware. 5 Sent a request message.

6 Return a response message.

7 Report an alarm.

l Scenario 1: System startup process 1. Start the JMS message middleware. 2. Start the Web Service middleware.

3. Connect the JMS message middleware to the U2000. l Scenario 2: User's subscription to a notification

1. Connect the OSS to the JMS message middleware. 2. The OSS subscribes the desired notification. l Scenario 3: Alarm reporting

(34)

1. The U2000 reports an alarm to the JMS message middleware.

2. The OSS receives the alarm that is forwarded by the JMS message middleware. l Scenario 4: Call of common interfaces

1. The OSS sends a request message. 2. The U2000 returns a response message. l Scenario 5: Call of coarse granularity interfaces

1. The OSS sends a request message.

2. The U2000 returns a message to the FTP server and upload the progress information. 3. After the file transfer is complete, the U2000 sends a completion notification to the

OSS.

2.3 Sample Flow

The following section describes how to query all the current alarms on the NMS.

Context

NOTE

When integrating with the XML NBI, you can compile the WSDL file to an API interface file, which simplifies the operation of code integration.

Procedure

1 Find the interface definition corresponding to the current alarms in the AlarmRetrievalHttp.wsdl file, as shown below.

<wsdl:operation name="getActiveAlarms">

<soap:operation soapAction="getActiveAlarms" style="document"/> <wsdl:input>

<soap:header message="tns:getActiveAlarmsRequest" part="mtopHeader" use="literal"/>

<soap:body parts="mtopBody" use="literal"/> </wsdl:input>

<wsdl:output>

<soap:header message="tns:getActiveAlarmsResponse" part="mtopHeader" use="literal"/>

<soap:body parts="mtopBody" use="literal"/> </wsdl:output>

<wsdl:fault name="getActiveAlarmsException">

<soap:fault name="getActiveAlarmsException" use="literal"/> </wsdl:fault>

</wsdl:operation>

2 Find the data type definition of the request message in the AlarmRetrievalMessages.xsd file, as shown below.

<xsd:element name="getActiveAlarmsRequest"> <xsd:annotation>

<xsd:documentation>

Request message structure of the getActiveAlarms operation

This operation returns (to the requesting OS) a specified subset of the active alarms known to the target OS. The target OS returns all alarms satisfying the filter constraints of the requesting OS. This operation can only be directed to a top-level OS and not to a subordinate OS.

</xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:sequence>

(35)

<xsd:element name="filter" type="tns:ActiveAlarmFilterType" minOccurs="0"> <xsd:annotation>

<xsd:documentation>

Defines the subset of the set of active alarms known to the target OS that are to be returned to the requesting OS.

</xsd:documentation> </xsd:annotation> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element>

3 Find the definition of the response message in the AlarmRetrievalMessages.xsd file, as shown below.

<xsd:element name="getActiveAlarmsResponse" type="alm:AlarmListType"> <xsd:annotation>

<xsd:documentation>

Response message structure of the getActiveAlarms operation </xsd:documentation>

</xsd:annotation> </xsd:element>

4 Construct the following XML message according to the data type definition of the request and send the XML message to the XML NBI through HTTP.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://www.tmforum.org/mtop/fmw/xsd/hdr/v1" xmlns:v11="http:// www.tmforum.org/mtop/rtm/xsd/ar/v1" xmlns:v12="http://www.tmforum.org/mtop/fmw/ xsd/nam/v1" xmlns:v13="http://www.tmforum.org/mtop/nra/xsd/com/v1" xmlns:v14="http://www.tmforum.org/mtop/nra/xsd/prc/v1"> <soapenv:Header> <v1:header> <v1:security>admin:u2000u2000</v1:security> <v1:communicationPattern>MultipleBatchResponse</v1:communicationPattern> <v1:communicationStyle>RPC</v1:communicationStyle> <v1:requestedBatchSize>20</v1:requestedBatchSize> <v1:batchSequenceNumber>1</v1:batchSequenceNumber> </v1:header> </soapenv:Header> <soapenv:Body> <v11:getActiveAlarmsRequest> </v11:getActiveAlarmsRequest> </soapenv:Body> </soapenv:Envelope>

5 Receive the following XML message from the XML NBI and parse the message according to the data type definition of the response message.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:v1="http://www.tmforum.org/mtop/fmw/xsd/hdr/v1" xmlns:v11="http:// www.tmforum.org/mtop/rtm/xsd/ar/v1" xmlns:v12="http://www.tmforum.org/mtop/fmw/ xsd/nam/v1" xmlns:v13="http://www.tmforum.org/mtop/nra/xsd/com/v1" xmlns:v14="http://www.tmforum.org/mtop/nra/xsd/prc/v1"> <soapenv:Header> <v1:header> <v1:security>admin:u2000u2000</v1:security> <v1:communicationPattern>MultipleBatchResponse</v1:communicationPattern> <v1:communicationStyle>RPC</v1:communicationStyle> <v1:requestedBatchSize>20</v1:requestedBatchSize> <v1:batchSequenceNumber>1</v1:batchSequenceNumber> </v1:header> </soapenv:Header> <soapenv:Body> <v11:getActiveAlarmsRequest> </v11:getActiveAlarmsRequest> </soapenv:Body> </soapenv:Envelope> ----End

(36)

(37)

3

Deploying and Configuring the XML NBI

About This Chapter

This chapter describes how to deploy and configure the U2000 XML NBI. It includes the following information:

3.1 Overview

This topic describes the background information and the terms involved in the process of deploying and configuring the northbound interface.

3.2 Configuration Requirements

U2000 XML NBI and the U2000 server run on the same PC or Sun workstation, any additional configuration is not required. But to enable the XML NBI, you must purchase the license for the corresponding functions.

3.3 Logging in to the Client of the NMS Maintenance Suite

After you log in to the client of the NMS Maintenance Suite, you can maintain the U2000 by using the NMS Maintenance Suite, including deploying the U2000 and configuring the instance of the northbound interface.

3.4 Checking the XML NBI Status

After check the license and ensure it is support XML functions, you need to check the current status of XML NBI, and deploy the XML NBI according the status.

3.5 Deploying the XML NBI for the First Time

By default, the XML NBI is not installed during the installation of U2000 server. To enable the XML NBI, you need to add the XML NBI the XML NBI component first, then add the XML NBI instance.

3.6 Configuring the XML NBI

In order to enable the XML NBI, even though you have installed XML NBI component, you need configure the XML parameters accord to NMS planning. Also, you can modify the parameters by configuring XML NBI again. Generally, general parameters are mandatory and advanced items are optional but the default values are recommended. Every advanced item is independent and you need not set the parameters.

(38)

3.1 Overview

This topic describes the background information and the terms involved in the process of deploying and configuring the northbound interface.

Attention Item

l Northbound interface is an optional component of the U2000. A license is required for using this function.

l If you do not install the northbound interface component during the installation of the U2000, you need to add it manually.

l The northbound interface is a System single-instance deployment package. Therefore, only one instance can be deployed.

CAUTION

l After the northbound interface component is installed or added, you need to add a

corresponding instance and configure parameters. Then, the U2000 can start the NBI-related process.

l After initializing the database of the U2000, you need to configure the northbound interface instance again.

l After the northbound interface instance is configured, you need to restart all the NMS services.

Terms

The following explains certain confusable terms:

l Component: It is the software function unit that can be selected for installation. A component can consist of multiple deployment packages.

l Deployment package: It is the software unit that is deployed on a PC. In a distributed system, the deployment packages of a component may be deployed on different PCs.

Deployment packages are classified into the following types:

– System single-instance: Such deployment packages can be installed on only one server and the server can be deployed with only one instance.

– Single-server single-instance: Such deployment packages can be installed on multiple servers and each server can be deployed with only one instance.

– Single-server multi-instance: Such deployment packages can be installed on multiple servers and each server can be deployed with multiple instances.

NOTE

The type of northbound interface deployment package is System single-instance.

NMS Maintenance Suite

Through the GUI of the NMS maintenance tool, you can conveniently deploy the northbound interface.

(39)

The NMS Maintenance Suite is a graphical system maintenance tool that is developed for the iManager U2000. The NMS Maintenance Suite is used to deploy the instances and distributed system of the U2000.

Refer to the NMS Maintenance Suite part of the iManager U2000 Administrator Guide for the details about the NMS Maintenance Suite.

3.2 Configuration Requirements

U2000 XML NBI and the U2000 server run on the same PC or Sun workstation, any additional configuration is not required. But to enable the XML NBI, you must purchase the license for the corresponding functions.

NOTE

For different operation system, the configuration requirements of U2000 is different, refer to the corresponding Software Installation Guide for more information.

Hardware Configuration

In practice, the U2000 XML interface and the U2000 server run on the same PC or SUN workstation. The hardware should be well configured enough to ensure the proper installation and running of the U2000 server. Any additional hardware configuration is not required the U2000 XML interface.

For details of hardware requirements of U2000 Server, refer to section "Configuration Requirements" in the iManager U2000 Software Installation Guide.

Software Configuration

Since the XML interface is integrated into the U2000 installation software, no additional software configuration is required for the installation of the U2000 XML interface. For details of software requirements U2000 Server, refer to section "Configuration Requirements" in the iManager U2000 Software Installation Guide.

License

The U2000 controls the functions and available resources of the XML NBI through a license. If you want to enable the XML interface, you need to purchase the U2000 license. Ensure the license support XML interface function before deploying the XML NBI.

For details, see A Relations Between License and XML Interface. If the license does not support the functions or resources needed, contact Huawei engineers to apply for the license. For the license introduction and information on how to apply for a license, see section Applying

for and Updating the License in the iManager U2000 Administrator Guide.

3.3 Logging in to the Client of the NMS Maintenance Suite

After you log in to the client of the NMS Maintenance Suite, you can maintain the U2000 by using the NMS Maintenance Suite, including deploying the U2000 and configuring the instance of the northbound interface.

(40)

Prerequisite

l The server of the NMS Maintenance Suite must be started.

l The client and the server of the NMS Maintenance Suite must communicate with each other normally.

Context

In normal cases, the NMS Maintenance Suite server starts along with the OS. You can do as follows to check whether the NMS Maintenance Suite server is started:

l In the Windows OS, check whether the msdaemon.exe and msserver.exe processes are started in the Task Manager window. If you can find the two processes in the process list, it indicates that the NMS Maintenance Suite server is started. Otherwise, open the DOS window and run the following command to start the NMS Maintenance Suite server: > net start nodemgr

l In the Solaris or SUSE Linux OS, run the following command as the root user to check whether the NMS Maintenance Suite server is started:

# ps -ef | grep java

If ./engineering/jre/jre_unix/bin/java is displayed, it indicates that the NMS Maintenance Suite server is started. Otherwise, run the following commands to start the NMS

Maintenance Suite server: # cd /opt/HWENGR/engineering # ./startserver.sh

Procedure

1 On a computer installed with the NMS Maintenance Suite client, double-click the U2000 MSuite shortcut icon on the desktop and then wait about one minute. The Login dialog box is displayed.

NOTE

l In the Solaris OS, you must log in to the Java desktop system as the root user. Otherwise, the U2000

MSuite shortcut icon is not displayed on the desktop.

l In the SUSE Linux OS, you cannot log in to the NMS Maintenance Suite client through the shortcut icon. You need to run the following commands as the root user to start the NMS Maintenance Suite client:

# cd /opt/HWENGR/engineering # ./startclient.sh

2 Set the related login parameters.

The login parameters are described as follows:

l IP Address: It refers to the system IP address of the computer where the NMS Maintenance Suite server resides. In a distributed system, you need to enter the system IP address of the master server.

l Port No.: The default port number is 12212. You do not need to change the default value during login.

l User Name: The default user name is admin. l Password: The initial password is admin. 3 Click OK.

(41)

NOTE

l When you log in to the client of the NMS Maintenance Suite, a progress bar showing the progress of querying components and instances is displayed. In this case, wait until the operation is complete.

l The NMS Maintenance Suite works in single-user mode. That is, only one NMS Maintenance Suite client can log in to the NMS Maintenance Suite server at one time. In a high availability system, only one site can be logged in at one time.

----End

Result

If a dialog box is displayed during the login, indicating that network configuration information is inconsistent and re-synchronization is required after login, read through the message to learn the server that needs to be synchronized. Then, do as follows:

1. On the NMS Maintenance Suite client, click the Server tab.

2. Right-click the server whose network configuration needs to be synchronized, and choose Synchronize the network configuration from the shortcut menu. A dialog box is displayed for you to confirm the operation.

NOTE

Before synchronizing network configuration, you need to stop NMS services. For details, see the U2000

Administrator Guide.

3. Click OK.

3.4 Checking the XML NBI Status

After check the license and ensure it is support XML functions, you need to check the current status of XML NBI, and deploy the XML NBI according the status.

Context

The XML NBI is one of the components of U2000. The installation of the XML NBI is integrated in the process of installing the U2000 server. There are two cases of the installation.

l If the XML NBI is not installed during the installation of the U2000 server, to enable the interface, you need to add the component first and then add the instance. For details, see 3.5 Deploying the XML NBI for the First Time.

l If the XML NBI is installed during the installation of the U2000 server, to enable the interface, you need to configure the instance. For details, see 3.6 Configuring the XML NBI.

The details for how to install the U2000 Server, refer to iManager U2000 Software Installation

Guide. If you want to install XML NBI, ensure you have select Northbound XML Interface

component during the installation of the U2000 server.

Procedure

1 Log in to the client of the NMS Maintenance Suite. For details, see 3.3 Logging in to the Client of the NMS Maintenance Suite.

(42)

l If the AgentXML instance exist, refer the steps in 3.6 Configuring the XML NBI enable the XML NBI.

l If the AgentXML instance not exist, you need to check whether the XML NBI deployment package exist according the Step 3.

3 Click Deployment Package tabs, check whether the XML NBI exist in the deployment package list.

l If the XML NBI deployment package exist, refer the steps in 3.5.2 Adding the XML NBI Instance enable the XML NBI.

l If the XML NBI deployment package not exist, refer the steps in 3.5 Deploying the XML NBI for the First Time enable the XML NBI.

----End

3.5 Deploying the XML NBI for the First Time

By default, the XML NBI is not installed during the installation of U2000 server. To enable the XML NBI, you need to add the XML NBI the XML NBI component first, then add the XML NBI instance.

3.5.1 Adding XML NBI Component

The XML NBI is one component of the U2000. If you have not installed the XML NBI by default, you need to add the XML NBI component.

3.5.2 Adding the XML NBI Instance

The type of XML NBI deployment package is system single-instance, you can deploy one instance only. After adding the XML NBI component, you need to adding XML NBI instance to enable the XML interface. You need set the general parameters, and it is recommended you set the advanced parameters to default value.

3.5.1 Adding XML NBI Component

The XML NBI is one component of the U2000. If you have not installed the XML NBI by default, you need to add the XML NBI component.

Prerequisite

l The NMS Maintenance Suite server installed on the master and slave servers must be started.

l The System Monitor server of the U2000 must be started. l The Database server process must be in the Running state.

l The NMS Maintenance Suite client communicates with the NMS Maintenance Suite server in the normal state.

Context

l In a distributed system, you only need to log in to the NMS maintenance tool server of the master server to perform this operation.

l In a high availability system, you only need to log in to the NMS maintenance tool server of the primary site to perform this operation.

(43)

Procedure

2 On the NMS Maintenance Suite client, choose Deploy > Add Component. The Add Component dialog box is displayed.

CAUTION

l In the distributed system, the XML NBI could be deployed in master server only. l You can add one XML NBI component only.

3 Choose the Northbound XML Interface component and click OK, the progress bar is displayed.

4 Wait until the dialog box is displayed to prompt the message The component is successfully added.

5 Click OK, completed the operation. ----End

Follow-up Procedure

After the component is added, you need to add the XML NBI instance, then you can enable the XML interface.

3.5.2 Adding the XML NBI Instance

The type of XML NBI deployment package is system single-instance, you can deploy one instance only. After adding the XML NBI component, you need to adding XML NBI instance to enable the XML interface. You need set the general parameters, and it is recommended you set the advanced parameters to default value.

Prerequisite

l The System Monitor server of the U2000 must be started. l Database Server Process must be in the Running state.

l The NMS Maintenance Suite client must communicate with the NMS Maintenance Suite server in the normal state.

l The component to which the instance is added must be installed. If the component is not installed, you must add XML NBI component first.

Context

(44)

Procedure

2 On the NMS Maintenance Suitel client, click the Deployment Package tab. Right-click the northbound XML interface deployment package and choose Add Instance. The dialog box is displayed.

3 In the General tab, set the parameters for basic items.

4 Configure the JMS server.

1. Enter the IP and JMS Server Port, the default IP is the IP address of NMS server and the default port is 61616.

2. Optional: Select Base on SSL, set SSL Port, the default port is 61617.

NOTE

l The JMS server is a message server located between the upper layer OSS and the interfaces for JMS communication.

l JMS Server and U2000 server could run in different PC or workstation, but you must ensure it is valid. It is recommended you use the default value, depoly the JMS server and U2000 server in the same PC or workstation.

Table 3-1 provides the parameters for JMS Server. Table 3-1 Parameters for the JMS server

Parameter Description Default Value

IP Indicates the IP address of the JMS

server.

(45)

Parameter Description Default Value JMS Server Port Indicate the port ID used for the

JMS server.

l Port 61616 is used for non-SSL JMS server.

l Port 61617 is used for SSL JMS server.

61616

JMS User Name The user name to access the JMS server.

admin

JMS Password The password to access the JMS

server.

test1234

5 Configure the Web service.

1. Choose IP from the drop-list, the default IP is the IP address of NMS server. 2. Optional: Select Register JMS Service, enable the JMS Service.

NOTE

If you have not select the check box, the JMS service is disabled.

3. Select the protocol, Base on HTTP or Base on HTTPS, set the Port, it is 9997 by default.

NOTE

You cannot select both of the Base on HTTP and Base on HTTPS. It is recommended that you select Base on

HTTP only by default.

Table 3-2 provides the parameters for Web Service. Table 3-2 Parameters for the JMS server

WebSerivice IP Displays the IP address of the

Web server.

The IP of U2000 server

HTTP Port Set the port. 9997

Register JMS Service Sets whether to use JMS. Enable

Base on HTTP/Base on HTTPS

Choose the protocol to be used.

HTTP

(46)

7 Choose the item in the left object tree, set the parameters in the right windows. Refer Table 3-3 for details.

Table 3-3 Parameters for the Advanced Items

Parameter Value Description

iView Log Switch Open, Close

Default Value: Open

Enables or disables iView internal logs for the XML Framework.

iView Log Level All, Trace, Warning, Error

Default Value: Warning

Sets the iView Debug Level. Namely, the system will record the selected level iView log in the log files.

Max Debug Folder Size 100-1024 MB

Default Value: 100MB

When the debug folder reaches the maximum size, the five oldest debug file will be deleted.

Framework Log Switch Open, Close

Default Value: Open

Enables or disables the logs of the XML Framework.

Product Log Switch Debug, Info, Warn, Error,

Fatal

Default Value: Info

Specifies the level of the product log. Namely, the system will record the selected level product log in the log files.

Framework Log Level Debug, Warn, Error

Default Value: Warn

Specifies the Level of Trace Information to be placed in Log File. Namely, the system will record the selected level log in the log files.

(47)

Parameter Value Description

Log Queue Size 10 to 2147483647

Default Value: 10000

Indicates the queue size for asynchronous logs.

Product Log Max Backup Index

1 to 100

Default Value: 40

Specifies the maximum number of the product log files. When the parameter value reaches a specified value, the system will generate new file to displace the older log file.

Product Log Max File Size 1 to 100 M

Default Value: 5 M

The size of the product log file. When the size of the file is greater than the maximum size, the system will generate the new log file.

Encoding Format UTF-8, GBK

Default Value: UTF-8

Specifies the encoding format of the files.

Configure Domain Name Default Value: Huawei/

U2000

Indicates the name of a managed domain.

8 Click OK to complete the configuration.

9 Optional: In the case of a distribute HA system with multiple NICs, if you enter the IP address of the master server to deploy XML NBI, and this IP address is not in the relevant address drop-list, the Address for Standby Server dialog box is displayed.

(48)

CAUTION

l You can enter any IP address of the standby server (except 127.0.0.1).

l You can set the same IP address or different IP addresses for the JMS Server IP and Web Server IP fields.

l Ensure that the input IP address is correct. That is, the standby server should be able to communicate with the upper-layer NMS successfully with the input IP address. l The XML NBI searches for the IP configuration list (hosts file) of the computer

automatically. Additionally, the first IP address in the configuration list is bound to the JMS Server IP. In the case of a single IP address, you need not set the JMS Server IP. In the case of multiple IP addresses, you need to set the JMS Server IP because the bound IP address is unknown. When setting the JMS Server IP field, you need to set it to an IP address that the upper-layer NMS can have access to. The same as the Web Server IP.

2. Click OK.

10 Wait until the dialog box is displayed to prompt the success message. 11 Click OK, complete add the instance.

12 The dialog box is displayed, prompt that restart all of the NMS service. 13 Click OK, close the dialog box.

14 Log in to the System Monitor. Restart all services of the U2000.

15 In the System Monitor client, check the Status of the XML service and JMS service. If all the processes are running, the XML NBI is enabled successfully.

(49)

3.6 Configuring the XML NBI

In order to enable the XML NBI, even though you have installed XML NBI component, you need configure the XML parameters accord to NMS planning. Also, you can modify the parameters by configuring XML NBI again. Generally, general parameters are mandatory and advanced items are optional but the default values are recommended. Every advanced item is independent and you need not set the parameters.

Prerequisite

l Log in to the Solaris or SUSE Linux OS as the root user. l Log in to the Windows OS as the Administrator user.

l In a HA system, configure the XML interface on the active server.

l The System Monitor server of the U2000 must be started. l The Database server process must be in the Running state.

l The NMS Maintenance Suite client communicates with the NMS Maintenance Suite server in the normal state.

l The XML NBI instance must be added. Otherwise, add the related XML NBI instance first.

Context

Procedure

2 On the NMS Maintenance Suite client, choose NBI > Configure the XML interface instance from the Main Menu. The dialog box is displayed.

(50)

4 Configure the JMS server.

1. Enter the IP and JMS Server Port, the default IP is the IP address of NMS server and the default port is 61616.

2. Optional: Select Base on SSL, set SSL Port, the default port is 61617.

NOTE

l The JMS server is a message server located between the upper layer OSS and the interfaces for JMS communication.

l JMS Server and U2000 server could run in different PC or workstation, but you must ensure it is valid. It is recommended you use the default value, depoly the JMS server and U2000 server in the same PC or workstation.

Table 3-4 provides the parameters for JMS Server. Table 3-4 Parameters for the JMS server

IP Indicates the IP address of the JMS

server.

The IP address of U2000 server.

JMS Server Port Indicate the port ID used for the JMS server.

l Port 61616 is used for non-SSL JMS server.

l Port 61617 is used for SSL JMS server.

61616

JMS User Name The user name to access the JMS server.

admin

JMS Password The password to access the JMS

server.

(51)

5 Configure the Web service.

1. Choose IP from the drop-list, the default IP is the IP address of NMS server. 2. Optional: Select Register JMS Service, enable the JMS Service.

NOTE

If you have not select the check box, the JMS service is disabled.

3. Select the protocol, Base on HTTP or Base on HTTPS, set the Port, it is 9997 by default.

NOTE

You cannot select both of the Base on HTTP and Base on HTTPS. It is recommended that you select Base on

HTTP only by default.

Table 3-5 provides the parameters for Web Service. Table 3-5 Parameters for the JMS server

WebSerivice IP Displays the IP address of the

Web server.

The IP of U2000 server

HTTP Port Set the port. 9997

Register JMS Service Sets whether to use JMS. Enable

Base on HTTP/Base on HTTPS

Choose the protocol to be used.

HTTP

6 Click the Advanced tab, set the parameters for advanced items.

7 Choose the item in the left object tree, set the parameters in the right windows. Refer Table 3-6 for details.

Northbound XML Interface User Guide V100R002C01 05

System

V100R002C01