JavaAPI for Tellabs® 8000 Network Manager Northbound Interface

(1)

JavaAPI for Tellabs

®

_{8000 Network Manager}

Northbound Interface

70182_01

30.09.09

(2)

This Tellabs manual is owned by Tellabs or its licensors and protected by U.S. and international copyright laws, conventions and treaties. Your right to use this manual is subject to limitations and restrictions imposed by applicable licenses and copyright laws. Unauthorized reproduction, modification, distribution, display or other use of this manual may result in criminal and civil penalties. The following trademarks and service marks are owned by Tellabs Operations, Inc. or its affiliates in the United States and/or

other countries: TELLABS®_{, TELLABS}®_{logo, TELLABS and T symbol}®_{, and T symbol}®_.

Any other company or product names may be trademarks of their respective companies.

The specifications and information regarding the products in this manual are subject to change without notice. All statements, information, and recommendations in this manual are believed to be accurate but are presented without warranty of any kind,

express or implied. Users must take full responsibility for their application of any products.

(3)

Terms and Conventions Term Explanation

API Application Programming Interface

DB Database

GPT General Problem Type

NBI Northbound Interface

NE Network Element

OSS Operations Support System. Includes e.g. EMS, NMS and SMS functionalities.

(4)

(5)

7.2.1 Method getValueAsString... 55 7.2.2 Method getValueByte ... 56 7.2.3 Method getValueShort ... 56 7.2.4 Method getValueInt ... 56 7.2.5 Method getValueDouble ... 56 7.2.6 Method getValueLong64 ... 57 7.2.7 Method getValueDate ... 57 7.2.8 Method getValueString ... 57 7.2.9 Method getValueBytes... 57

7.3 Datetime Pattern of TolResultSet ... 58

8 NbifAttributeInfo and NbifAttributeService Classes ... 59

8.1 Entity IDs and Names... 59

8.2 Attribute IDs and Names ... 59

8.3 Methods for Handling Entities ... 60

8.3.1 Methods that Return All Entities ... 60

8.3.2 Methods that Return Inventory and Performance Entities ... 60

8.3.3 Methods that Return Alarm Entities... 61

8.3.4 Method getEntityName... 62 8.3.5 Method getEntityIdForEntityName... 62 8.3.6 Method getEntityObject ... 62 8.3.7 Method isAlarmEntity ... 62 8.3.8 Method isEclEntity ... 63 8.3.9 Method getEntityNotificationSupport ... 63

8.4 Methods for Handling Attributes... 63

8.4.1 Methods that Return Attributes ... 63

8.4.2 Method getAttributeNamesInArrayList ... 64

8.4.3 Method getNumberOfKeyAttributes... 64

8.4.4 Methods that Return Key Attributes... 64

8.4.5 Method getAttributeObject... 65 8.4.6 Method getAttributeIdForAttributeName... 66 8.4.7 Method getAttributeEntityId ... 66 8.4.8 Method getAttributeName... 66 8.4.9 Method getAttributeDataTypeCode ... 66 8.4.10 Method getAttributeDataTypeDesc ... 67 8.4.11 Method getAttributeDataLength... 67 8.4.12 Method getAttributeIsKey... 67

8.5 Methods for Parsing Strings ... 67

8.5.1 Method parseEntities ... 68 8.5.2 Method parseOneEntity... 68 8.5.3 Method parseAttributes ... 68 8.5.4 Method parseOneAttribute ... 69 8.5.5 Method parseFilters ... 69 8.5.6 Method parseAttributeValueList... 70 8.5.7 Method parseOneValue... 70 8.5.8 Method parseIntegerParameterList... 71 8.5.9 Method parseOneInteger ... 71

(8)

8.6 Methods for Getting Capacity Vectors ... 72

8.6.1 Method convertBytesToCapacityVectorString ... 72

8.6.2 Method convertBytesToCapacityVectorArrayList ... 73

8.7 Attribute Data Type Definition ... 75

8.8 Methods for Getting Example Value Format for Attributes ... 75

8.8.1 Method getExampleValueString... 75

8.8.2 Method getExampleTolDateTimeString... 76

9 NbifAttributeValueService Class... 77

9.1 Methods for Handling the Attribute Value Descriptions ... 77

9.1.1 Method NbifAttributeValueService... 77 9.1.2 Method getService_data_is_ok... 78 9.1.3 Method getDescriptionOfAttributeValue ... 78 9.1.4 Method getValueOfAttributeDescription ... 78 9.1.5 Method getAttributeValueObjectsOfAttribute ... 79

10 NbifAttributeAlarmValueService Class ... 80

10.1 NE Alarm Types ... 80

10.2 Methods for Handling the Alarm Values... 80

10.2.1 Method NbifAttributeAlarmValueService... 80 10.2.2 Method getService_data_is_ok... 81 10.2.3 Method getGptText... 81 10.2.4 Method getSptText ... 81 10.2.5 Method getAlarmtypetext... 82

11 NbifAttributeSptValue Class... 83

11.1 Methods for Handling the Specific Problem Type Descriptions of an NE Alarm ... 83

11.1.1 Method getSpttext... 83 11.1.2 Method getProbablecause... 83 11.1.3 Method getSourcehw... 83 11.1.4 Method getSptCode ... 84 11.1.5 Method getAlarmtype... 84 11.1.6 Method getHwtype ... 84

12 TolType and TolTypeService Classes ... 85

12.1 Values in TolType Class... 85

12.1.1 Codes of Commands for Accessing Data from NBI Server... 85

12.1.2 Codes for Received Notifications ... 85

12.1.3 Status Stored in the Header of the Reply Message... 85

12.1.4 Error Codes Set in Case of Problems in Reading Reply Data... 85

12.1.5 Codes and Names of Supported Capacity Vector Types ... 86

(9)

12.1.7 Trace Level ... 87

12.1.8 Filter Types Available for GetFilteredAllData Command... 87

12.2 TolTypeService Methods for Handling Commands ... 87

12.2.1 Method getCommandName... 87

12.2.2 Method getCommandCode... 88

12.2.3 Methods that Return Commands for Managing Inventory and Performance Data... 88

12.2.4 Methods that Return Commands for Managing Alarms ... 88

12.3 TolTypeService Methods for Capacity Vector Types ... 89

12.3.1 Method getCapacityVectorAlloctypeForTrunkAllocType ... 89

12.3.2 Method getCapacityVectorTypeCode... 89

12.3.3 Method getCapacityVectorTypeName... 90

12.3.4 Method getCapacityVectorTypeCodes ... 90

12.3.5 Method getCapacityVectorTypeNames ... 90

12.4 TolTypeService Methods for Handling Trace Log Levels ... 91

12.4.1 Methods getTraceLevelCodes and getTraceLevelNames ... 91

12.4.2 Method getTraceLevelName ... 91

12.4.3 Method getTraceLevelCode ... 91

12.5 TolTypeService Methods for Handling Filter Types of Command GetFilteredAllData ... 92

13 OpenResultSet Class ... 93

13.1 Extracting the Tellabs 8000 Manager NBI Session’s Handle ID ... 93

14 TolEventObserver Class ... 94

14.1 Processing the Tellabs 8000 Manager NBI Inventory Notifications ... 94

14.1.1 Create Notifications ... 94

14.1.2 Attribute Value Change Notifications... 95

14.1.3 Delete Notifications ... 95

14.2 Processing the Tellabs 8000 Manager NBI Alarm Notifications ... 96

14.2.1 TolAlarmEvent Methods ... 96

14.3 Processing the Tellabs 8000 Manager NBI System Notifications... 96

14.3.1 TolSystemEvent Methods... 97

15 OSS Client Development and JavaAPI Use ... 98

15.1 Using JavaAPI to Simultaneously Integrate Inventory Data and Alarm Data ... 98

15.2 Entity IDs and Attribute IDs ... 98

15.3 Required Setting at NIMA.INI ... 99

15.4 Providing Key Attribute Values in getOneData and getIntervalData Requests ... 99

15.5 Other JavaAPI Specific Data Types... 99

15.5.1 TolDateTime Class ... 99

15.6 JavaAPI Exceptions... 102

15.6.1 TolCommunicationException... 102

15.6.2 TolAttributeException ... 104

(10)

16.1 Installing Java Runtime Environment ... 105

16.2 Files of the NBI Test Client... 105

16.2.1 jar-files NBITestClient.jar and tol.jar ... 105

16.2.2 Clear Text Description File... 105

16.2.3 Ini File for the Test Client... 106

16.3 Launching the Test Client... 107

16.4 NBI Inventory and Performance Services (Target NIMA)... 108

16.4.1 Commands for Subscribing to Notifications ...110

16.4.2 Command GetAll...111

16.4.3 Command GetFilteredAll ...112

16.4.4 Command GetOne ...114

16.5 NBI Fault and Provisioning Services (Target NSA)...115

16.5.1 Commands for Subscribing to Notifications ...117

16.5.2 Command GetAll...117

16.5.3 Command Execute Macro ...118

(11)

About the Manual

Objectives

This manual gives information on JavaAPI, a Java based library that provides a high-level programming interface for developers of third party OSS Client applications.

Audience

This information is aimed at the developers of third party OSS Client applications. With the help of JavaAPI library, the developers do not need to know details about the underlying protocols used in the Tellabs 8000 Network Manager Northbound Interface (Tellabs 8000 network manager NBI). The developers of third party OSS Client applications must use the Java programming language to be able to benefit from the JavaAPI library and must implement an adapter module at the OSS System that uses JavaAPI classes to integrate with the Tellabs 8000 network manager NBI.

Document Conventions

This is a note symbol. It emphasizes or supplements information in the document.

This is a caution symbol. It indicates that damage to equipment is possible if the instructions are not followed.

This is a warning symbol. It indicates that bodily injury is possible if the instructions are not followed.

(12)

Documentation Feedback

Please contact us to suggest improvements or to report errors in our documentation: Email: [email protected]

(13)

1 Introduction to JavaAPI

The figure below shows an overview of how JavaAPI and the Tellabs 8000 manager NBI are used when integrated to a third party OSS system.

Fig. 1 JavaAPI and Tellabs 8000 Network Manager NBI Integrated to a Third Party OSS System

JavaAPI is composed of more than 20 Java classes and one interface, but only a selection of the classes and methods are public for OSS Client development. For processing notifications messages sent by the Tellabs 8000 manager NBI, the OSS Client needs to implement one JavaAPI Interface. The main public classes are:

(14)

• openCommunication • openSession • getAllData • getOneData • getFilteredData • getActiveAlarmData • acknowledgeAlarm • getIntervalData • subscribeNotification and others.

• OpenResultSet containing a method to obtain the HandleId that identifies a session to the Tellabs 8000 manager NBI.

• TolResultSet containing methods to read and parse data sent by Tellabs NBI in response to getAllData, getOneData and getIntervalData calls. Notification data is also han-dled by TolResultSet.

• NbifAttributeService containing methods to handle data entities and attributes.

• NbifAttributeValueService containing methods to get descriptions for the attribute values. To process the notifications sent by the Tellabs 8000 manager NBI, the OSS Client application must implement the TolEventObserver interface.

JavaAPI is provided as a set of Java class files that should be installed at the computer/server running the OSS Client application. JavaAPI requires J2SE release 1.5 or newer.

The figure below shows an example of the OSS Client application being implemented in the

TellabsClient.java file and installed under directory \OSSApp. JavaAPI files should then be

(15)

Fig. 2 An Example of JavaAPI Files Implemented

The JavaAPI can be used for two purposes: 1. NBI Inventory and Performance Services 2. NBI Fault and Provisioning Services

These services are provided in different ports of the NBI Server. The JavaAPI programmer must create the connection to the wanted port to have access to the services.

For GET operations, there is a list of supported entities. Each entity supports a list of attributes. An entity can be a physical object (for example a node or a unit), a logical object (for example a circuit, an mplsvpn), a performance object (for example G821 performance data), an alarm object (network element alarm or service alarm), etc.

(16)

2 Downward Compatibility of JavaAPI

JavaAPI is downward compatible with previous releases of Tellabs 8000 network manager. OSS application can implement the most recent methods and performance enhancements of the latest JavaAPI even when it is integrating with an older release of Tellabs 8000 manager. OSS application can start using the new commands and getting data for the new entities and attributes as soon as Tellabs 8000 network manager is upgraded to a release which supports them.

JavaAPI is not compatible upward. When upgrading to a new release of Tellabs 8000 manager, the newest JavaAPI must be taken into use.

(17)

3 Clear Text Descriptions and Capacity Vectors

of Attribute Values

JavaAPI provides Clear Text description texts for the attribute values (since R15A) and Capacity Vectors (since R16).

For example, you can easily view the node’s hardware type. After you have received the data from the NBI Server to your client, you can pass the values over to Clear Text Description methods of JavaAPI to get the Clear Text description, e.g. string “8630” in case of a Tellabs 8630 access switch node (whose code value is 10017). For more information on using the Clear Text descriptions, see the information below.

The trunk capacity usage can also be clearly seen. After receiving the data from the NBI Server to your client, you can pass the capacity data over to Capacity Vector methods of JavaAPI to get the Capacity usage in a clear format, e.g. the used capacity of a STM-1 trunk can been seen as a clear text “TU:100,211,212,310,370”, which shows which TU-12’s, TU-2’s and TU-3’s are used.

(18)

4 Problem Type Descriptions and Probable

Cause of Network Element Alarms

JavaAPI provides descriptions for alarms which is a useful feature for NBI alarm integration. It provides the following:

• description of the Generic Problem Type (GPT) code • description of the Specific Problem Type (SPT) code • probable cause for alarms

• the type of the alarm (NODE Alarm, NTU Alarm or NMS Alarm) • the hardware type of the faulty unit or the faulty NTU

After you have received the alarms from the NBI Server to your client, you can pass the alarm data to Alarm Description methods of JavaAPI to get the SPT and GPT problem type descriptions, the probable cause of the alarm, the type of the alarm and the hardware type of the faulty unit or NTU. E.g. for an alarm from Interface unit for Tellabs 8660 edge switch, the alarm might have GPT code 10004 and SPT code 1769474. The Alarm Description methods of JavaAPI provide the following descriptions:

• GPT: "Alarm received from the Tellabs 8600 equipment" • SPT: "Tx circuit down"

• probable cause: "Circuit is down in transmit direction. The reason may be that the LDP signalling is not successfully executed."

• type of the alarm: "NODE Alarm"

• hardware type of the unit: "8605 Interface Unit"

For more information on using the Alarm Description methods of JavaAPI, see the information below.

(19)

5 How to Use JavaAPI

5.1 Java Runtime Environment

Use JavaAPI with Java Runtime Environment 5.0 or newer.

5.2 Create an Object of TolService Class

The class TolService provides methods for handling the commands of JavaAPI. The default constructor is

TolService Srv = new TolService();

An alternative constructor of TolService takes the trace level as a parameter.

TolService prints only those messages to JavaAPI trace which have a higher importance than the selected (or default) trace level. For more information on the constructors and the trace level settings, see6 TolService Class.

5.3 Decide if You Want to See the Clear Text Descriptions of DB

Values

If you want to use the Clear Text descriptions, create an object of class NbifAttributeValueService. With the methods of NbifAttributeValueService you can either get all Clear Text descriptions or convert an attribute value to its description.

You can use NbifAttributeValueService to give the Clear Text descriptions for the result data of Get commands or when you receive notifications.

There should be only one instance of NbifAttributeValueService since creating such an object is a reasonably heavy task.

5.3.1 Create an Object of NbifAttributeValueService Class

Class NbifAttributeValueService provides methods for getting Clear Text descriptions for the attribute values.

When an instance of class NbifAttributeValueService is created, it loads the Clear Text descriptions from files and maps them to those attributes which support the descriptions.

(20)

method getService_data_is_ok(). This status contains the boolean value True if the Clear Text descriptions exist.

For more information on NbifAttributeValueService, see9 NbifAttributeValueService Class.

5.4 Decide if You Want to See the Problem Type Descriptions and

Probable Cause of NE Alarms

If you are integrating to NBI Alarms and want to get the Problem type descriptions and probable cause of NE alarms, create an object of class NbifAttributeAlarmValueService. With the methods of NbifAttributeAlarmValueService you can get the GPT and SPT descriptions, the probable cause of the alarm, the type of the alarm and the hardware type of the faulty unit or NTU.

You can use NbifAttributeAlarmValueService to get the descriptions for the result data when getting all existing active alarms or when you receive alarm notifications. There should be only one instance of NbifAttributeAlarmValueService since creating such an object is a reasonably heavy task.

Starting up the JavaAPI takes longer, when you use the feature to get the Problem type descriptions and probable cause of alarms since the JavaAPI loads the problem type description and probable cause texts at startup.

5.4.1 Create an Object of NbifAttributeAlarmValueService Class

Class NbifAttributeAlarmValueService provides methods for getting the GPT and SPT descriptions, the probable cause of the alarm, the type of the alarm and the hardware type of the faulty unit or NTU.

When an instance of class NbifAttributeAlarmValueService is created, it loads the problem type descriptions and probable cause texts from files.

You can check that the NbifAttributeAlarmValueService was loaded properly by getting the status with method getService_data_is_ok(). This status contains the boolean value True if the descriptions exist.

For more information on NbifAttributeAlarmValueService, see10 NbifAttributeAlarmValueService Class.

5.5 Decide the Datetime Format of JavaAPI

JavaAPI prints out datetimes and requires the datetimes to be inserted in a certain pattern. The pattern is common (static) in JavaAPI.

The default datetime pattern is " dd.MM.yyyy HH:mm:ss:SSS". For example: “10.03.2005 19:30:25:55”.

(21)

1. with set-methods of TolService (see6.7.2 Datetime Pattern of JavaAPI) or

2. with set-methods of a TolDateTime object (see15.5.1 TolDateTime Class). Changing the pattern affects all the places where datetimes are used.

1. The datetime pattern is used when printing out results containing datetime attributes with meth-ods of TolResultSet class.

2. The datetime pattern is needed in class TolService when giving datetime values as input to commands GetFilteredAllData (or GetIntervalData).

NBI Server applications return the TolDateTime values by default in the local normal time. There is an option to return the TolDateTime values in UTC time by adding the parameter USE_UTC_TIME=YES to the nsa.ini and nima.ini files in the NBI Server.

5.6 Open Communication (Socket)

Define the hostname or the IP address of the Northbound Interface. Define the port where the Northbound Interface provides the requested services:

Requested Services Service Name Service Port (Server Default)

NBI Inventory and Performance services

NIMA 2462

NBI Fault and Provisioning services

NSA 2461

Open the socket using the method openCommunication of TolService class public void openCommunication(String hostAddress, int portNumber) throws IOException

When using JavaAPI to communicate with NBI Fault and Provisioning services, the following configuration changes have to be made:

in %DXXDIR%\dat\nsa.ini, set the parameter BYTE_CONVERSION=OFF.

5.7 Open Session

Define an object of the class OpenResultSet:

OpenResultSet resultSet = new OpenResultSet(); Define the username and the password.

(22)

OpenResultSet openResultSet)

throws IOException, TolCommunicationException Get the handleId using the method getHandleId of OpenResultSet class:

public long getHandleId()

Store the handleId. You need it every time you send commands to the Northbound Interface: long handleId = openResultSet.getHandleId();

5.8 Running a Get Command

The available commands depend on the port you have opened. However, there are common features in the different Get commands:

• All Get commands return the data in TolResultSet. You can use the same methods of the class TolResultSet to evaluate the results.

• All Get commands require the entityId as an input parameter.

• Most Get commands require an ArrayList of selected attributes as an input parameter. • Some Get commands require specific input parameters.

5.8.1 Creating Object TolResultSet

First, define an instance of class TolResultSet to let the Get command fill it with data. TolResultSet resultSet = new TolResultSet();

5.8.2 Getting Inventory and Performance data

The following methods are available for getting Inventory and Performance data (NIMA in port 2462):

Method or TolService Description Parameters

getAllData Method to retrieve the selected attributes for all existing rows of the selected entity.

long handleId int entityId

ArrayList selectedAttributes TolResultSet resultSet (Output) getFilteredAllData Method to retrieve the selected

attributes for those rows of the selected entity which match the given filters. long handleId int entityId ArrayList selectedAttributes ArrayList filterAttributes ArrayList filterAttrValues ArrayList filterTypes

(23)

getOneData Method to retrieve the selected attributes for a single row of the selected entity, which matches the given key attribute values.

ArrayList selectedAttributes ArrayList keyAttributes ArrayList keyAttrValues TolResultSet resultSet (Output) getIntervalData Note: A deprecated method

which works only for some performance entities.

Method to retrieve the selected attributes for those rows of the selected entity which are in the given time interval and, for some of the entities, match the given Circuit ID/ NTU ID. It is recommended to use the method getFilteredAllData instead!

Deprecated method

Parameters are as in case of getOneData. However, the order of the keyIds does matter. Since this command is deprecated, the details are not described here.

5.8.3 Getting Alarm Data

The following method are available for getting alarm data (NSA in port 2461):

Command Description Parameters

getActiveAlarmData Returns all attributes for all existing rows of the selected (alarm) entity.

The method getActiveAlarm-Data does not require giving any attributes as an input parameter but it always returns all the attributes.

TolResultSet resultSet (Output)

getAllData Returns all attributes for all existing rows of the selected (alarm) entity.

The method getAllData requires giving all existing attributes of the select (alarm) entity in the prespecified order.

ArrayList selectedAttributes TolResultSet resultSet (Output)

5.8.4 Managing the Input Parameters of the Get Commands

Commands require giving the supported entities, attributes, filter types etc. as input parameters. Commands allow giving ArrayLists containing either IDs/codes or names/symbols.

OSS client applications dealing with predefined supported entities and attributes can directly use them from the NbifAttributeInfo class and in the TolType class.

(24)

etc. There are several methods available which format the parameters to the format expected by the

Getcommand.

1. You can get a list of all possible supported entities. 2. You can get a list of all possible attributes of an entity. 3. You can get a list of possible values for an attribute. 4. You can convert the names into IDs and vice versa. See alsoAppendix: JavaAPI Examples

The handleId Is Needed for Any Get Command

Input parameter handleId is the handle ID which you received from the OpenSession command.

The entityId is Needed for Any Get Command

The entityIds can be taken directly from the NbifAttributeInfo class (see8.1 Entity IDs and Names). There are also methods in NbifAttributeService, which return (see8.3 Methods for Handling Entities):

1. All supported entities (either Inventory and Performance or Alarm entities). 2. Entity name for an entity ID and vice versa.

3. Information if the entity is the Tellabs 8000 manager Provisioning related entity (ECL entity). And methods which can be used for parsing the entity from a string (see8.5 Methods for Parsing Strings).

4. Methods for parsing entity IDs or NAMEs from a string.

Selected Attributes for Get Commands

The input parameter selectedAttributes is an ArrayList of attributes, which you want to get. ArrayList is allowed to contain either attribute IDs (as Integers) or attribute names (as Strings). The attribute IDs and names can be taken directly from the NbifAttributeInfo class (see8.1 Entity IDs and Names).

For Inventory and Performance entities you can select, that is, add to the ArrayList, as many attributes as you like in any order. However, to make the getting of the data faster, it a recommended to select only those attributes which are of importance to your OSS Client application.

For Alarm entities ALL attributes must be selected in the predefined order. So, instead of selecting the attributes, it is recommended either to

• use the command getActiveAlarmData(), where you do not have to give the selected at-tributes

or

• use the method ArrayList getAttrIdArrayList(int entityId) of NbifAttribute-Service to create the ArrayList. Give that ArrayList directly as an input parameter selectedAt-tributes to GetAllData()command.

(25)

For Get commands of Alarm entities, all attributes must be included in the selected attributes and they must be included in the order of the attribute IDs.

There are also methods in NbifAttributeService which return (see8.4 Methods for Handling Attributes):

1. All attributes of the given entity.

2. A number of key attributes and all key attributes of the given entity. 3. Properties of the given attribute (entity, data type, data length, if it is key). 4. Attribute name for an attribute ID and vice versa.

And methods which can be used for parsing the attributes from a string (see8.5 Methods for Parsing Strings):

5. Methods for parsing attribute IDs or NAMEs from a string.

Key Attributes and Key Values for GetOneData Command

For the GetOneData command you must give the key attributes of the entity in one ArrayList and the key values in another ArrayList. ArrayList of key attributes is allowed to contain either attribute IDs (as Integers) or attribute names (as Strings). ArrayList of key values must contain a value for each key attribute in its own data type.

To be able to use the command GetOneData(), you must know which of the attributes are key attributes and you must know their data types to give the key value in its own data type format. Note that there are methods available in NbifAttributeService to find out which attributes are key attributes and the methods to get the key attributes.

The key attributes can be added to the ArrayList in any order. However, you must insert the key attribute values to their ArrayList in the same order as you inserted the key attributes.

The key attributes can be managed as the selected attributes (described above).

Additionally, there are methods in NbifAttributeService for parsing the values from a string (see

8.5 Methods for Parsing Strings):

• Methods for parsing attribute value(s) from a string to the data type(s) of the attribute.

Filter Attributes, Filter Types and Filter Values for GetFilteredAllData Command

For the GetFilteredAllData command you can give a filter which consists of one or more logical conditions.

The logical condition is a condition on the values of one attribute. For example, you can have a filter for the NODE entity where the logical condition is that the node hardware type attribute has value 10017:

NODE_HWTYPE = 10017

(26)

operatorN valueN)

AttributeX means attribute (ID or name)

operatorX means filter type ( =, < , > , <= , >= , LIKE) where

valueX means value used in filtering

The maximum of ten logical conditions (AttributeX operatorX valueX) can be applied in a filter. For example, you can have a filter for the NODE entity where the logical condition is that the node hardware type attribute has value 10017 and the node ID is in the range of 100 and 199:

( NODE_NHWTYPE = 10017 ) AND ( NODE_NID >= 100 ) AND ( NODE_NID <= 199 )

The filter is given to the GetFilteredAll command in three ArrayLists: • ArrayList containing the filter attributes (IDs or names)

• ArrayList containing the filter attribute values (by their types) • (OPTIONAL) ArrayList containing the filter types (codes or symbols)

If you do not give the filter types of the logical conditions, filter type equal (“=”) is assumed for all the logical conditions in the filter. Filter type “LIKE” can be applied only for the attributes with data type NIMA_DT_CHARARRAY. Filter type “LIKE” finds those records, where the filter attribute contains the given value (value_x) as a substring.

For more information on the filter types refer to TolType class in12.1.8 Filter Types Available for GetFilteredAllData Commandand to TolTypeService class in12.5 TolTypeService Methods for Handling Filter Types of Command GetFilteredAllData.

Refer to6.2.2 Method getFilteredAllDatafor more information on the parameters of the method GetFilteredAllData.

If NbifAttributeValueService is used, you can use the methods of NbifAttributeValueService to parse the filter values from their descriptions. For example, it is more convenient to refer to Tellabs 8630 access switch by its descriptive value string “8630” than by its node hardware type code 10017 (see9 NbifAttributeValueService Class)

Additionally, NbifAttributeService class provides a parseFilters method for parsing the filter from a semicolon-separated string (see8.5 Methods for Parsing Strings). You will input one semicolon-separated string to the method parseFilters and you get the three ArrayLists necessary for the GetFilteredAllData command.

5.8.5 Retrieve the Result Data

All Get commands return the result in an object of TolResultSet class. TolResultSet class contains the methods to read and parse the Tellabs 8000 manager NBI response data. Response data is sent by the NBI as TolResultSet objects. TolResultSet is a buffer containing NBI objects (records). Each record is composed of attributes. See the figure below.

(27)

Fig. 3 TolResultSet

By using the TolResultSet methods the OSS Client can scan all records contained in the TolResultSet object. By using attribute IDs the OSS Client can extract the value of a specific attribute. To parse the records and attributes in the TolResultSet, the OSS Client should use the getNext() and getValueXX (attrId)methods. These methods are described in more detail in the sections below.

Fig. 4 getNext

The values can be replaced or extended by the Clear Text explanations if wanted. Class NbifAttributeValueService provides methods for retrieving the Clear Texts.

In case of NBI Alarm integration, the class NbifAttributeAlarmValueService can be used for getting the GPT and SPT descriptions, the probable cause and the type of an NE alarm and also the hardware type of the faulty unit or NTU.

(28)

Scan the Tellabs 8000 Manager NBI Response Records

TolResultSet class provides methods for Scanning the Tellabs 8000 manager NBI response records. See also7.1 Scanning the Tellabs 8000 Manager NBI Response Records. Use the method getNext()to scan the records one by one (returns True as long as there are records). After using the method getNext() you must use the methods for extracting the attributes from the record as described below.

Get Attributes in the TolResultSet Object

Use the method ArrayList getAttrIdList() to get an ArrayList containing the IDs of the attributes which are contained in each record of the TolResultSet. Every record of the same TolResultSet — object contains the same attributes. You need to know the attributes to be able to retrieve the values using the proper data type.

Extract Attributes from a Record

TolResultSet class provides methods for extracting attributes from a record. See7.2 Extracting Attributes from a Record.

To extract attribute values, the OSS Client can use two approaches:

1. Extract all attributes as string values with the method string getValueAsString (int attrId).

2. Extract each attribute in its native data type (byte, short, int, double, long64, String, byte[], Tol-DateTime) with the method getValueXX(int attrId). For example, extract an attribute of data type short with method short getValueShort(int attrId).

Developers of the OSS Client can choose which one is more appropriate.

In both cases, the OSS Client must know the entity in a TolResultSet, and the IDs of the attributes to be extracted.

In case of extracting attributes in their native data type, OSS Client must also know the data type of the attribute in order to call the correct method, otherwise the getValueXX() method will throw a TolAttributeException. To find out the data type of an attribute, use the method int getAttributeDataTypeCode (int attrId) of the class NbifAttributeService, which returns the data type code of the given attribute, e.g. NbifAttributeService.NIMA_DT_SHORT.

For more methods giving information on the attribute, see8.4 Methods for Handling Attributes. For more information on possible data types, see8.7 Attribute Data Type Definition.

Get General Information on the TolResultSet Object

There are also methods for

1. Getting the number of records in the TolResultSet object. 2. Getting the size of the whole TolResultSet object. 3. Getting the size of one record.

(29)

5.8.6 Retrieve the Clear Text Descriptions for the Attribute Values

To retrieve the Clear Text descriptions, create on object of class

NbifAttributeValueSer-vice. With methods of the NbifAttributeValueService class you can:

• Check that the service has been loaded properly.

• Get the description for a given value of a given attribute.

• Get the attribute value for a given description of a given attribute. • Get all possible values for a given attribute.

See also9 NbifAttributeValueService Class

5.8.7 Retrieve the Problem Type Descriptions and Probable Cause of NE Alarms

To retrieve the GPT and SPT descriptions, the probable cause of the alarm, the type of the alarm and the hardware type of the faulty unit or NTU, create on object of class NbifAttributeAlarmValueService. With methods of the

NbifAttributeAlarmValueServiceclass you can do the following:

• Check that the service has been loaded properly. • Get the description of a given GPT code. • Get the description of a given SPT code. • Get the probable cause for the alarm.

• Get the type of the alarm (NODE Alarm, NTU Alarm or NMS Alarm). • Get the hardware type of the faulty unit or the faulty NTU.

See also10 NbifAttributeAlarmValueService Class.

5.8.8 Retrieve the Capacity Vector

For a capacity vector attribute, you can see the capacity structure with methods provided in class NbifAttributeService.

There are methods for converting a byte array into a string or an ArrayList containing the TS, TU, AU-4 or bit capacity vector:

• Method convertBytesToCapacityVectorString returns the capacity structure in a string

• Method convertBytesToCapacityVectorArrayList returns the capacity structure as integer values in an ArrayList.

Capacity Vector Type

Contents Example of Capacity

Structure in a String Example ofCapacity Structure as Integers

(30)

Vector

Type Structure in a String CapacityStructure as

Integers

TU: non-zero KLM values:

• TU-12s in format K*100+L*10+M • TU-2s in format K*100+L*10 • TU-3s in format K*100

“TU:100,211,212,310,370” 100,211,212,310,370

AU-4 non-zero AU4s “AU4:1,2” 1,2

Bit capacity Non-zero bits. First all eight bits of TS0 (TS0\b0, TS0\b1, TS0\b2, ..., TS0\b7), then all bits of TS1 (TS1\b0, TS2\b1, ...TS2\b7), then bits of all following time slots. Zero-bits in the end of list are NOT included in the ArrayList.

“TS0:B6\B7\,TS1:B1\B2” 0,0,0,0,0,0,1,1,1,1

See also8.6 Methods for Getting Capacity Vectors.

5.9 Provisioning with Macros

The following method is available for executing macros (NSA in port 2461):

executeMacro The macro file, whose name is given as a parameter, is executed on the Northbound Interface. In case of success the method returns. In case of failure, the method throws exception, which contains explanation on the failure.

long handleId String macroFileName String macroArguments (optional) int timeout

Configuration changes, such as provisioning operations, are possible through the executeMacro feature of the Tellabs 8000 manager NBI.

The executeMacro method allows the OSS to request the NBI Server to execute a Macro program with given arguments. When calling the executeMacro method, the OSS must specify the name of the Tellabs 8000 manager Macro program and the input parameters for the Macro program. The Macro programs must be installed in the NBI Server, and will be executed by the Tellabs 8000 manager NBI every time the OSS calls the executeMacro method with appropriate parameters. The method executeMacro accepts the name of the macro program with or without the .mac suffix. For example, the macro program OSSMacro.mac can be given to method executeMacro as “OSSMacro” or “OSSMacro.mac”

(31)

Most of the Tellabs 8000 manager Macro programs expect input parameters. Input parameters are defined in the Macro program and are specific to each Macro. Input parameters can vary in type or quantity. Every input parameter in a Macro has a name. The OSS Client should use the input parameter names when building the macroArguments String. The generic format for this string is:

<Arg1_name>=<value><space><Arg2_name>=<value>...<ArgN_name>=<value>

For Macro parameters of STRING type, the <value> must be enclosed in quotation marks (”). For example, let us assume a Macro file named OSSMacro.mac that expects one INT parameter named NodeID and one STRING parameter named NodeName. When the OSS Client calls the executeMacro method for a node with ID=10 named “New Node” under a session with handleId = 100, the method should be called as follows:

executeMacro(100, “OSSMacro”, “NodeID=10 NodeName=\”New Node\”“)

5.10 Subscribing to the Tellabs 8000 Manager NBI Inventory and NBI

Alarm Notifications

Subscribe to notifications before using the getAll command to avoid loosing any notifications.

The mechanism implemented in JavaAPI to send event notifications to the OSS Client is based on the “Observer” Java Design Pattern (compare for example with the MouseListener interface in Java). The OSS Client takes the role of “Observer”, and JavaAPI takes the role of “Subject”. In this scenario, the OSS Client first has to register as an ”Observer” to JavaAPI. This is done by calling the addChangeListener method. After that, the OSS Client can inform JavaAPI from which object entities it is interested in receiving the notifications. This is done by calling the subscribeNotificationmethod. As a summary, JavaAPI will start giving notifications to the client, when the client:

1. Implements the interface TolEventObserver and overrides all of its event processing methods. 2. Registers as an observer with method addChangeListener.

3. Subscribes to the notifications.

After receiving the OSS Client registration and subscription, JavaAPI calls the appropriate event processing methods implemented at the OSS Client application.

(32)

Fig. 5 Subscribing to NBI Inventory and NBI Alarm Notifications

5.10.1 Implement TolEventObserver Interface

Implement interface TolEventObserver in your client application and override all its event processing methods:

public class MyClientService implements TolEventObserver { ...

//Method addNotification is called when a new change message of type "add" occurs. public void addNotification(TolAddEvent addEvent) {

... }

//Method updateNotification is called when a new change message of type "update" occurs.

public void updateNotification (TolUpdateEvent updateEvent) { ...

}

// Method delNotification is called when a new change message of type “delete“ occurs. public void delNotification(TolDelEvent delEvent) {

... }

//Method systemNotification is called when a new system notification message occurs. public void systemNotification(TolSystemEvent systemEvent) {

(33)

... {

// Method alarmNotification is called when a new alarm notification message occurs. public void alarmNotification(TolAlarmEvent alarmEvent) {

... } }

5.10.2 Register as an Observer with addChangeListener Method

Register the OSS Client application as a listener to notifications by calling the method addChangeListener:

addChangeListener Register the given Java class as an observer to notifications.

Note: the given java class

must implement the interface TolEventObserver.

eventObserver

5.10.3 Check if Notifications Are Supported for the Entity

NbifAttributeService provides methods for checking if notifications are supported for an entity. Also, NbifAttributeService provides you with methods for getting all entities.

5.10.4 Subscribe Commands for Subscribing to Inventory Entities

The following methods are available for getting notifications on Inventory entities (NIMA in port 2462). Note that the NBI server does not support notifications on Performance entities:

subscribeNotification Subscribe to those entities for

which notifications are wanted. int handleIdArrayList entityIds

unsubscribeNotifica-tion

Unsubscribe all notifications. int handleId

If you call the method subscribeNotification again, the old subscriptions are dropped and the new list of entities will be subscribed to.

(34)

5.10.5 Subscribe Commands for Subscribing to Alarm Entities and System

Notifications

The following methods are available for getting Alarm and System notifications through the NBI Fault and Provisioning adapter in port 2461:

subscribeNotification Subscribe to those entities for which notifications are wanted.

int handleId ArrayList entityIds

unsubscribeNotifica-tion

Unsubscribe all notifications int handleId

subscribeSystemNoti-fication

Subscribe to system notifications int handleId

unsubscribeSystemNo-tification

Unsubscribe system notifications

int handleId

5.10.6 Handle the Received Inventory Notifications

You have already implemented interface TolEventObserver in your client application and overridden all of its event processing methods addNotification, updateNotification, delNotification, alarmNotification, and systemNotification (see

5.10.1 Implement TolEventObserver Interface).

JavaAPI calls the event processing methods every time there is a new event coming from the NBI service. For each of the notification types (Create, Attribute Value Change, Delete, Alarm, System) there is a corresponding class (TolAddEvent, TolUpdateEvent, TolDelEvent, TolAlarmEvent, TolSystemEvent) containing the methods that can be used to extract the notification-specific data. The actual record data should be extracted using the TolResultSet methods.

Create Notifications

JavaAPI calls method addNotification (TolAddEvent addEvent) implemented in the OSS client application when a new inventory object has been created in the Tellabs 8000 manager system.

There are methods available for retrieving data from the TolAddEvent object which the method addNotificationgets as a parameter:

1. Method for getting the entity ID of the created object (int getEntityId()).

2. Method for getting the number of attributes of the created object (int getNumberOfAt-tributes()).

3. Method for getting attribute IDs of the created object in an ArrayList (ArrayList getAt-trIdList()).

4. Method for the getting the TolResultSet object containing values for each of the attributes (Tol-ResultSet getAttrValueSet()).

(35)

To retrieve the data from the TolResultSet object, use the methods of TolResultSet. TolResultSet is described in5.8.5 Retrieve the Result Data.

Attribute Value Change Notifications

JavaAPI calls method updateNotification (TolUpdateEvent updateEvent) implemented in the OSS client application, when there is a change in the Tellabs 8000 manager system inventory data.

There are methods available for retrieving data from the TolUpdateEvent object which the method updateNotificationgets as a parameter. The TolUpdateEvent object contains data on the key attributes and data on the changed attributes.

1. Method for getting the entity ID of the object, whose values have been changed (int getEn-tityId()).

2. Method for getting the number of key attributes (int getNumberOfKeyAttributes()). 3. Method for getting the number of changed attributes (int

getNumberOfChangeAt-tributes()).

4. Method for getting key attribute IDs in an ArrayList (ArrayList getKeyAt-trIdList()).

5. Method for getting attribute IDs of the changed attributes in an ArrayList (ArrayList getChangeAttrIdList()).

6. Method for the getting the TolResultSet object containing key attribute values (TolResult-Set getKeyAttrValue(TolResult-Set ()).

7. Method for the getting the TolResultSet object containing attribute values for the changed at-tributes (TolResultSet getChangeAttrValueSet()).

To retrieve the data from the TolResultSet objects, use methods of TolResultSet. The use of TolResultSet is described in5.8.5 Retrieve the Result Data.

Delete Notifications

JavaAPI calls method delNotification (TolDelEvent delEvent) implemented in the OSS client application when an inventory object has been deleted from the Tellabs 8000 manager system. There are methods available for retrieving data from the TolDelEvent object which the method delNotification gets as a parameter.

1. Method for getting the entity ID of the deleted object (int getEntityId()).

2. Method for getting the number of key attributes (int getNumberOfKeyAttributes()). 3. Method for getting the key attribute IDs in an ArrayList (ArrayList

getKeyAt-trIdList()).

4. Method for the getting the TolResultSet object containing values for each of the key attributes (TolResultSet getKeyAttrValueSet()).

To retrieve the data from the TolResultSet object, use methods of TolResultSet. The use of TolResultSet is described in5.8.5 Retrieve the Result Data.

(36)

5.10.7 Handle the Received Alarm Notifications

You have already implemented the interface TolEventObserver in your client application and overridden all of its event processing methods addNotification, updateNotification, delNotification, alarmNotification, and systemNotification (see

5.10.1 Implement TolEventObserver Interface). JavaAPI calls method alarmNotification (TolAlarmEvent alarmEvent)implemented in the OSS client application when there is changed alarm data in the Tellabs 8000 manager system.

Notification handling of alarm notifications is different from handling inventory notifications. For the NBI Inventory data, Tellabs 8000 manager NBI provides separate event notification for Create, Attribute Value Change, and Delete events. For NBI alarm data, there is no concept of Create, Delete, and AVC events. Whenever there is a change in a alarm object instance (NE alarm, service alarm), the NBI will send a complete updated object to the OSS Client. This “update” message does not contain information on what has happened to the object. Also, the “update” data can contain information on more than one alarm record.

For example, in case of an existing NE Alarm whose status has turned from Active to Cleared, the NBI sends a complete NE Alarm record with the Alarm Status attribute set to Clear, and with the Clear Date set with the time stamp when the NE Alarm was cleared. There are methods available for retrieving data from the TolAlarmEvent object which the method alarmNotification gets as a parameter:

1. Method for getting the entity ID of the alarm object (int getEntityId()).

2. Method for the getting the TolResultSet object containing values for each of the attributes of the alarm object (TolResultSet getAttrValueSet()).

To retrieve the data from the TolResultSet object, use methods of TolResultSet. The use of TolResultSet is described in5.8.5 Retrieve the Result Data.

Note that more than one alarm object can be included in the TolResultSet.

To get the attribute IDs of the alarm object, use the method ArrayList getAttrIdList() of the TolResultSet object.

5.10.8 Handle the Received System Notifications

You have already implement interface TolEventObserver in your client application and

overridden all of its event processing methods addNotification, updateNotification, delNotification, alarmNotification, and systemNotification (see

(37)

JavaAPI calls method systemNotification (TolSystemEvent systemEvent) implemented in the OSS client application when there is an error in the NBI service. There is a method available for retrieving data from the TolSystemEvent object which the method systemNotification gets as a parameter:

1. Method for getting the error code of the system notification (int getMessageType()) 1. error code 1:

The NBI Kernel shutting down. Sent when the NBI Server Supervisor stops NBI Kernel processes.

2. error code 2:

Notifications lost. Internal processes of the NBI server are unexpectedly terminated, or the server has lost connection to the database.

5.11 Acknowledging Alarms

The following method is available for acknowledging Network Element (NE) alarms through the NBI Fault and Provisioning adapter in port 2461:

acknowledgeAlarm acknowledges an NE alarm in Tellabs 8000 manager

long handleId int faultID

Method acknowledgeAlarm acknowledges the NE alarm, which has the given alarm ID (given as a parameter faultId). Give as input the ID of one Network Element alarm which you want to acknowledge.

5.12 Pinging the NBI Server to Verify that It Is Alive

Use ping commands to verify the status of the services on the NBI Server. Verify that the NBI Server Inventory and Performance service (NIMA) is alive using the method pingNima of TolService class:

public void pingNima (long pingPacketSize) throws IOException, TolCommunicationException

Verify that the NBI Server Fault and Provisioning Service (NSA) is alive using the method pingNsaof TolService class:

public void pingNsa () throws IOException, TolCommunicationExcep-tion

For more information on the ping commands, refer to6.2.5 Method pingNimaand6.2.6 Method pingNsa.

5.13 Command Names and Codes

You do not have to worry about the command names or codes if you call the TolService methods which carry out the commands.

(38)

use JavaAPI classes TolType and TolTypeService.

The command codes and names are available in TolType class. You can use those variables directly from TolType class (see12.1 Values in TolType Class).

You can also use methods of TolTypeService class to get all command codes or names and to find a name for a command code and vice versa. For example, the methods listed below are available. There are also methods in TolTypeService, which return (see12.2 TolTypeService Methods for Handling Commands):

1. All command names or codes (either Inventory and Performance or Alarm commands). 2. Command name for a command code and vice versa.

5.14 Close Session

After using the JavaAPI, release the threads and other resources by closing the socket using method closeCommunicationof TolService class.

Method closeSession expects the handleId of your session as a parameter. • public voidcloseSession(long handleId)

throws IOException, TolCommunicationException

5.15 Close Communication (Socket)

At the very end, close the socket using method openCommunication of TolService class • public void closeCommunication() throws IOException

JavaAPI commands allow managing the commands with names/symbols. However, the corresponding IDs/codes are used in the communication between the Northbound Interface and the JavaAPI. So in the byte streams between your OSS clients and the Northbound Interface you would see only the IDs/codes.

(39)

6 TolService Class

This class contains all methods needed to establish sessions to the Tellabs 8000 manager NBI and to send request commands. Other classes (e.g. TolResultSet) should be used to process the Tellabs 8000 manager NBI response data.

To initiate a session to the Tellabs 8000 manager NBI, the OSS Client application should first call the openCommunication method to establish a communication path to the appropriate NBI Server and TCP port. Once the communication is established, the OSS Client should login to the NBI service by calling the openSession method.

Once the session is established, the OSS Client can subscribe to event notifications by calling the

subscribeNotificationmethod, send get requests using the getXXXData methods, and

send provisioning requests by using the executeMacro method.

The default constructor of TolService takes no parameter and prints trace messages on default trace level:

• TolService ()

Construct a new TolService object. Use default trace log level of JavaAPI.

Parameters –

Exceptions –

The alternative constructors of TolService take the trace level as a parameter. • TolService (int loglevel)

• TolService(String loglevelname)

Construct a new TolService object and define the trace log level of JavaAPI. Valid values for the trace level are defined in class TolType (see12.1.7 Trace Level.) If the given trace log level is invalid, the default trace log level is used.

Parameters logLevel/loglevelName trace level for JavaAPI

Exceptions –

For more information on the trace levels, see6.7.1 Trace Level of JavaAPI. The following sections describe all the methods available in the TolService class.

(40)

6.1 Establishing Connections to the Tellabs 8000 Manager NBI

6.1.1 Method openCommunication for Opening Socket

Open a communication path to the Tellabs 8000 manager NBI. This is the first method the OSS Client should call to establish a connection to the Tellabs 8000 manager NBI. This method establishes the TCP socket connection to the NBI server port.

• void openCommunication (String hostAddress, int portNum-ber)throws IOException

Parameters hostAddress (Input)

Specifies the IP address of the NBI server computer

portNumber (Input)

Specifies the TCP port number of the NBI service

Exceptions IOExceptionis thrown if an I/O error occurs

6.1.2 Method closeCommunication for Closing Socket

Close communication path to the Tellabs 8000 manager NBI.

• void closeCommunication () throws IOException

6.1.3 Method openSession

Opens an OSS Client session to the NBI service. This method should be called after a successful execution of the openCommunication method. While openCommunication establishes a connection to the NBI Server socket port, the openSession establishes a client session to the NBI service. The OSS Client should include a OpenResultSet object as a parameter which will be filled by JavaAPI with a Client HandleId that uniquely identifies the session to the NBI service.

• void openSession(String userName, String passWord, OpenResultSet openResult) throws IOException, TolCommunicationException

(41)

Parameters userName (Input)

specifies the login name for the OSS Client session passWord (Input)

specifies the password for the OSS Client session openResult (Output)

OpenResultSet returned by Tellabs 8000 manager NBI containing the handleId.

TolCommunicationExceptionis thrown if a communication exception occurs

6.1.4 Method closeSession

Close an OSS Client session to the NBI service.

• void closeSession (int handleId) throws IOException,TolCommuni-cationException

Parameters handleId (Input)

Client specific handle that is used to identify a session

6.2 Requesting Inventory or Performance Data from the Tellabs 8000

Manager NBI

6.2.1 Method getAllData

Populate resultSet with all objects within the requested inventory or performance entity.

To parse the resultSet data, the OSS Client should use the methods available in the TolResultSet class. See description of the TolResultSet object in7 TolResultSet Class.

• void getAllData (long handleId, int entityId, ArrayList se-lectedAttributes, TolResultSet resultSet) throws IOException, TolCommunicationException, TolAttributeException

entityId (Input)

(42)

tributes Arraylist containing the IDs or names of the attributes that should be included in the returned records. ArrayList must contain attribute IDs as Integers and attribute names as Strings. resultSet (Output)

Data set returned by the NBI containing all objects with the requested attributes of the given inventory/performance entity.

TolAttributeExceptionis thrown if the given entityId or the selectedAttributes are incorrect

6.2.2 Method getFilteredAllData

Populate resultSet with those objects which match the given filters within the requested inventory or performance entity (entityId).

For the GetFilteredAllData command you can give a filter which consist of one or more logical conditions.

The logical condition is a condition on the values of one attribute. For example, you can have a filter for the NODE entity where the logical condition is that the node hardware type attribute has value 10017:

NODE_NHWTYPE = 10017

If you give more logical conditions in a filter, the logical conditions are joint with “AND”. (Attribute1 operator1 value1) AND (Attribute2 operator2 value2) AND ... AND (AttributeN operatorN valueN)

AttributeX means attribute (ID or name)

operatorX means filter type ( =, < , > , <= , >= , LIKE) where

valueX means value used in filtering

The maximum of ten logical conditions (AttributeX operatorX valueX) can be applied in a filter. For example, you can have a filter for the NODE entity where the logical condition is that the node hardware type attribute has value 10017 and the node ID is in the range of 100 and 199:

( NODE_NHWTYPE = 10017 ) AND ( NODE_NID >= 100 ) AND ( NODE_NID <= 199 )

The filter is given to the GetFilteredAll command in three ArrayLists: • ArrayList containing the filter attributes (IDs or names)

• ArrayList containing the filter attribute values (by their types) • (OPTIONAL) ArrayList containing the filter types (codes or symbols)

(43)

If the filter type codes are not given, the default filter type (=) is used for all the logical conditions in the filter.

For more information on the filter types refer to TolType class in12.1.8 Filter Types Available for GetFilteredAllData Commandand to TolTypeService class in12.5 TolTypeService Methods for Handling Filter Types of Command GetFilteredAllData.

To parse the resultSet data, the OSS Client should then use the methods available in the TolResultSet class. See the description of the TolResultSet object in7 TolResultSet Class.

• void getFilteredAllData(long handleId, int entityId, ArrayList selectedAttributes, ArrayList filterAttributes, ArrayList fil-terAttrValues, ArrayList filterTypes, TolResultSet resultSet) throws IOException, TolAttributeException,TolCommunicationEx-ception

or without specifying the filter types

• void getFilteredAllData(long handleId, int entityId, ArrayList selectedAttributes, ArrayList filterAttributes, ArrayList fil-terAttrValues, TolResultSet resultSet) throws IOException, TolAttributeException, TolCommunicationException

Client specific handle that is used to identify a session.

entityId (Input)

ID of requested

inventory/performance entity. selectedAttributes (Input)

Arraylist containing the IDs or names of the attributes that should be included in the returned records. ArrayList must contain attribute IDs as Integers or attribute names as Strings.

filterAttributes (Input)

Arraylist containing the filter attribute IDs or names. ArrayList must contain attribute IDs as Integers or attribute names as Strings.

filterAttrValues (Input)

Array list of filter attribute values

filterTypes (Optional input)

Array list of filter types. The filter types can be given as symbols (string values) or as codes (integer values).

resultSet (Output)

Result set that contains received attribute values from the NBI

(44)

Code Symbol FILTER_TYPE_EQUAL "=" FILTER_TYPE_LESS "<" FILTER_TYPE_GREATER ">" FILTER_TYPE_LESS_OR_EQUAL "<=" FILTER_TYPE_GREATER_OR_EQUAL ">=" FILTER_TYPE_LIKE "LIKE"

If this input is not given, FILTER_TYPE_EQUAL “=” is used for all the given filters. See the description of TolType to see the methods available for handling the filter codes.

Exceptions IOExceptionis thrown if an I/O error occurs TolCommunicationExceptionis thrown if a communication exception occurs

TolAttributeExceptionis thrown if an attribute exception occurs

Chapter5.8.4 Managing the Input Parameters of the Get Commandsprovides more information on how to use the parameters of the GetFilteredAllData command.

6.2.3 Method getOneData

Populate resultSet with one object from the given inventory entity. Method getOnedata is not supported to Performance entities. To call this method the OSS Client application must include the IDs and values of the key attributes as parameters to select a unique record from the entity. To parse the resultSet data, the OSS Client should use the methods available in the TolResultSet class. See description of the TolResultSet object in7 TolResultSet Class.

• void getOneData (long handleId, int entityId, ArrayList selecte-dAttributes, ArrayList keyAttributes, ArrayList keyAttrValues, TolResultSet resultSet) throws IOException, TolCommunicationEx-ception, TolAttributeException

entityId (Input)

ID of requested inventory/performance entity

JavaAPI for Tellabs® 8000 Network Manager Northbound Interface