Tl1 Tutorial

TL1 Tutorial
Table Of Contents

1.0 TL1 TUTORIAL.................................................................................................... 4
1.1 Foreword........................................................................................................................ 5
1.2 Introduction.................................................................................................................... 8
1.3 TL1 Tutorial Tour......................................................................................................... 10
1.4 Application Overview................................................................................................... 12
2.0 TRY IT YOURSELF ........................................................................................... 16
3.0 APPLICATION DESIGN.................................................................................... 24
4.0 MODELING MANAGED RESOURCES............................................................. 27
4.1 Modeling the TL1 Managed Object.............................................................................. 29
5.0 IMPLEMENTATION........................................................................................... 32
5.1 Creating TL1 Project.................................................................................................... 34
5.2 Modeling the Switch and its Components.................................................................... 36
5.2.1 Managed Resource Modeling...............................................................................................37
5.2.2 Custom Code for Managed Object Classes .........................................................................40
5.3 Discovering the AcmeMSU devices and GNEs........................................................... 42
5.3.1 Discovering Switch Devices..................................................................................................44
5.3.2 Custom Code for Discovery Filter.........................................................................................46
5.4 Creating Maps to Display AcmeMSU Devices............................................................. 52
5.4.1 Creating Maps.......................................................................................................................53
5.4.2 Customizing the Map Filter Code.........................................................................................56
5.4.3 Creating and Configuring other Map related files.................................................................58
5.5 Managing the Alerts of AcmeMSU Device................................................................... 61
5.5.1 Correlating Events ................................................................................................................62
5.5.2 Status Propagation...............................................................................................................63
5.6 Fetching Device Status Periodically............................................................................ 64
5.6.1 Status Polling for Card..........................................................................................................65
5.6.2 Status Polling for Port...........................................................................................................67
5.7 Performance Monitoring of the AcmeMSU Device...................................................... 69
5.7.1 Performance Management...................................................................................................70
AdventNet Inc. 1

TL1 Tutorial

5.8 Provisioning the AcmeMSU Device............................................................................. 72
5.8.1 Modifying the Managed Object Property..............................................................................73
5.8.2 Creating a Cross Connection................................................................................................76
5.8.3 Configuring Provisioning Files ..............................................................................................78
5.9 Client-Server Communication...................................................................................... 81
5.9.1 Creating Client Server Communication Class ......................................................................81
5.10 Re-branding............................................................................................................... 82
5.11 Creating Menus ......................................................................................................... 84
5.12 Packaging the Project................................................................................................ 85
6.0 FAST TRACK IMPLEMENTATION................................................................... 87
7.0 INSTALLATION AND TESTING........................................................................ 88
7.1 Installation Notes ......................................................................................................... 88
7.2 Testing the Application................................................................................................ 90
8.0 KNOWN ISSUES............................................................................................... 97
9.0 TROUBLE SHOOTING TIPS............................................................................. 98
10.0 DESCRIPTION OF CUSTOM CODE AND CLASS FILES............................ 100
10.1 Description of Discovery Filter Custom Code.......................................................... 100
10.1.1 Customizing the Discovery Filter Code ............................................................................100
10.1.2 Adding Device Components - Part1.................................................................................102
10.1.3 Adding Device Components - Part2.................................................................................106
10.2 Description of Map related files ............................................................................... 108
10.2.1 Description of AcmeMSU Device Map Layout Class........................................................108
10.2.2 Description of AcmeMSU Device Map Symbol Renderer Class ......................................111
10.2.3 Description of AcmeMSU Map Applet Extension Class with Complete Code..................112
10.3 Description of Fault Management related files ........................................................ 113
10.3.1 Description of MSU Event Correlation Filter Class...........................................................113
10.3.2 Description of AcmeMSU Alarm Propagation Filter Class ...............................................118
10.4 Description of Status Polling Custom Code............................................................. 120
10.4.1 Description of Custom Code for Status Polling of Card....................................................120
10.4.2 Description of Custom Code for Status Polling of Port.....................................................122
10.5 Description of Performance Management Configuration......................................... 125
10.6 Description of Provisioning Files.............................................................................. 127
10.6.1 Description of ChangeCardType Provisioning Template..................................................127
10.6.2 Description of AcmeCrossConnect Provisioning Template..............................................129
10.6.3 Description of Post Provisioning Filter Class....................................................................131
10.7 Description of Client Server Communication Code ................................................. 133
AdventNet Inc. 2

TL1 Tutorial

11.0 APPENDIX..................................................................................................... 134
11.1 TL1 Command Set used in the Application............................................................. 134
11.2 TL1 Basics............................................................................................................... 138
11.2.1 Message Structure............................................................................................................139
11.2.2 Input Message..................................................................................................................140
11.2.3 Output Response Message..............................................................................................142
11.2.4 Acknowledgement Message.............................................................................................144
11.2.5 Autonomous Message......................................................................................................145
12.0 OTHER TUTORIALS ..................................................................................... 147

AdventNet Inc. 3

TL1 Tutorial

TL1 Tutorial

Managing a TL1 Device
AdventNet Web NMS Tutorial

Version 1.0

A guide to developers on how to build an application to manage a TL1 device.

Copyright 1996-2002

AdventNet, Inc.
5645 Gibraltar Drive
Pleasanton, CA 95014
http://www.adventnet.com
info@adventnet.com

AdventNet Inc. 4

TL1 Tutorial

1.1 Foreword

AdventNet Web NMS aims at providing real world network management solutions to telecom and
enterprise markets.

It meets the demand of the market for advanced network management features.

It fulfills the need of the market for shortest possible deployment time.

TL1 Tutorial will demonstrate how the above market expectations are met by AdventNet Web NMS.

Real World TL1 Element Management Solutions
Why AdventNet Web NMS
Application Life Cycle

Real World TL1 Element Management Solutions
Real world TL1 Element management applications that can be made available on AdventNet Web
NMS, categorized by specific domains are

Core Network : Optical and IP/ATM core.
Metro Network : SONET/DWDM/Ethernet metro equipment.
Edge and Access
Network
: Cable, DSL, Optical, and Wireless-based Broadband
access technologies, with IP, ATM, and SONET protocols.

The list of Web NMS applications goes on.

For complete information on TL1 Protocol solutions, visit the web site TL1 GURU.com.

Why AdventNet Web NMS
AdventNet Web NMS fulfills your specific network management needs. It comes with the most sought
after features in the market.

They are

Massive scalability
High availability
Customization
o Modeling managed systems
o Extending management services
o Supporting variety of management protocols
o Various deployment options

It can be customized and extended to suit your needs. The extensibility makes the design of the
application more organized.

The customization addresses the specific needs of the application to mange your custom equipment.
AdventNet Web NMS comes bundled with a developer suite with rich tools, called AdventNet Web
NMS Studio. This tool reduces the development life cycle time drastically.
This in turn brings host of benefits:

The time taken to deploy the application is lesser compared to the conventional development
and deployment techniques.
AdventNet Inc. 5

TL1 Tutorial

The human resources required are cut to a fraction of what is required for conventional
techniques.
The tool supports user from the level of novice to professional. The tool contains UI-based
Wizards to accomplish all the simple tasks if you are a novice user and makes room for
custom code if you are a professional to handle advanced tasks.
The required skill level of the user is also brought down. For example, you do not require J ava
knowledge to use the tool and only network management and your element domain
knowledge will suffice.

All these benefits put together will make AdventNet Web NMS a wise choice for your network
management solution.

Application Life Cycle
AdventNet Web NMS offers a comprehensive development environment for building your
management solution. This section explains how the complete product life cycle needs of your
management solution are realizable using AdventNet Web NMS.

They are captured in five easy steps that you can follow to build your management solution, as below:

Step 1: Modeling the managed elements
Step 2: Customizing managed object services
Step 3: Re-branding the management solution
Step 4: Packaging
Step 5: Deployment and Testing

The following diagram gives an overview of the experience of building management solutions with the
AdventNet Web NMS.

AdventNet Inc. 6

TL1 Tutorial

Step 1: Modeling the Managed Elements

Each managed system comprises many inter-related elements that need to be individually
managed. You start with modeling your elements, so that you can capture the data, operations
and state of the elements, and the relationships between the elements. The Web NMS
provides a comprehensive, simple and easy to learn information model, using which the
various elements of the managed system can be modelled. The basic element of the Web
NMS information model is the ManagedObject. The Web NMS also has models for various
common IP network components such as Network, Node, SNMP Node, TL1 Node, etc. These
form the core objects of the Web NMS information model. You have to extend any of the core
objects of Web NMS to model your managed element. The core objects can be extended, by
adding attributes, operations, and state to those objects (modeling the data, operations, and
state of your element in addition to capturing the relationship).

This task can easily be accomplished by using the Managed Resources of AdventNet Web
NMS Studio. It helps you walk through the steps in terms of the object that needs to be
extended, the new attributes of your element, etc. It then generates MO classes, relational
classes, and database schema files for your managed element.

Step 2: Customizing Managed Object Services

AdventNet Web NMS offers a number of management services to the managed objects. The
southbound services that populate the database with information from the elements such as
data collection, status polling, etc. are classified as the mediation services. The services that
enable the user to perform network planning, error management, and service deployment tasks
are classified as the management services. Management services include event correlation,
element configuration, service provisioning, access control, etc.
Using the module management services available as part of the Web NMS framework, you
could also build other management application modules.

Step 3: Re-branding the Management Solution

You can re-brand the application to display the name of your company, the name of your
product, and your logos. The I18N tool, bundled in AdventNet Web NMS Studio, helps you re-
brand your application by replacing references to AdventNet and Web NMS. The logos,
images, and icons can be changed by modifying configuration files.

Step 4: Packaging

You can package your application resources alone as a NAR (NMS Archive file) that can be
installed over the AdventNet Web NMS.

Step 5: Deployment and Testing

Before testing your management solution, make sure all the third-party packages are installed
correctly and you have the required privileges to use them for your testing. Once you start your
application, look at the Web NMS server log files to make sure all the services are started
successfully and are running.

Having deployed your application at a customer's site, you will be required to support the
product and provide upgrades as part of support. AdventNet Web NMS Studio available in
AdventNet Web NMS makes it easy to handle upgrades.
AdventNet Inc. 7

TL1 Tutorial

1.2 Introduction

The purpose of this tutorial is to guide you through designing an EMS for TL1-managed devices and
provide illustrative examples to help you understand the choices to be made during development. This
tutorial will elaborate the various features in AdventNet Web NMS to manage TL1 Devices and
describes how AdventNet Web NMS Studio can be used to simplify the development of an EMS.

The Tutorial
Consider a real life scenario. Suppose you want to manage Switches, which are TL1-protocol devices.
Then this tutorial will help you to build an EMS (Element Management System) to manage the
Switches by using AdventNet Web NMS.

The tutorial will walk through a series of steps, which will help you understand how a unique EMS
solution can be built using AdventNet Web NMS Studio to suit your needs. Use of AdventNet Web
NMS Studio will make the development of the application virtually very little or zero coding. This
makes the development faster.

This tutorial helps you to build only a sample application. In which, it adopts a generic TL1-managed
device (i.e., Acme MSU Switch) as an example. This limited scope example will serve only to illustrate
what can be built on AdventNet Web NMS and it is only a subset of the custom capabilities of
AdventNet Web NMS. However, for many EMS applications of specific needs, this basic example can
be extended.

This topic covers the following details of the tutorial:

The Intended User
Prerequisites
Related Information
Printed Version
Tutorial Conventions
At the end of the Tutorial

The Intended User
This tutorial is intended for those, who are interested in developing an Element Management System
for TL1 based Devices using the AdventNet Web NMS.

Prerequisites
To develop this tutorial application, you will need a good knowledge of Element Management System
and TL1 based Devices.

Knowledge of J ava programming, SQL, and relational database concepts will be an added advantage,
but it is not essential.

Related Information
This tutorial provides concise information about AdventNet Web NMS Studio and AdventNet Web
NMS. For detailed information about these, refer to the Web sites listed below:

1. AdventNet Web NMS Studio documentation - from the following URL:
<Web NMS Home>\StudioTools\Studio\help\index.html
2. AdventNet Web NMS documentation - from the following
URL:http://www.adventnet.com/products/webnms/help.html
AdventNet Inc. 8

TL1 Tutorial

Printed Version
To print this tutorial, follow these steps:

1. Ensure that Adobe Acrobat Reader is installed in your system.
2. Download the PDF version of this document from the following URL:
http://download.adventnet.com/products/webnms/tl1_tutorial.pdf

3. Click the printer icon in Adobe Acrobat Reader.

Tutorial Conventions
The following table lists the typographic conventions followed in this tutorial:

Font Style Uses
Arial Bold File name
Arial Italic Directory
Arial Bold Italic Methods / Interfaces / Classes
Cour i er New Code snippet
Courier New Bold Italic Highlighting important code snippets

At the end of the Tutorial
From this tutorial you will learn how to

Build an EMS for managing TL1 devices by customizing AdventNet Web NMS with the help of
AdventNet Web NMS Studio.
Model Objects.
Achieve Fault, Configuration, Performance, and Security management and Discovery of
network elements.
AdventNet Inc. 9

TL1 Tutorial

1.3 TL1 Tutorial Tour

Welcome to the TL1 Tutorial Tour

This tutorial is in three stages.

Stage 1

At this stage, you are provided the ready-built tutorial application which can be deployed right away
and experienced.

Try it Yourself - This topic lists the steps to be followed to experience the application.
Application Design - This topic gives you an overview of the Application Design. It elucidates
the various stages involved in building the application.

Stage 2

This stage guides you step by step on how to build the application yourself, including the relevant help
on AdventNet Web NMS Studio. Refer to the Implementation section for this stage.

AdventNet Inc. 10

TL1 Tutorial

Stage 3

At this stage, you are given the Studio Project of this application. You can compile this project,
package and deploy it directly if you are unable to build the project successfully. Further, you can
open this project in AdventNet Web NMS Studio and modify it as per your requirement. You can
compile, package and deploy it to see the effect of your modifications. Refer to the Fast Track
Implementation topic for Stage Three of this tutorial.

Hope you will enjoy this tour and experience easy and quick Application development.

Fig: Tutorial Tour
AdventNet Inc. 11

TL1 Tutorial

1.4 Application Overview

In this section, an overview of the Tutorial Application is provided.

This application has a simple TL1 command set which is designed to be in sync with many of the
commercial TL1 Devices available in the market. Over and above the normal TL1 device
management, this application highlights the Terminal Server feature of the TL1 devices.

The tutorial application provides information on how to develop an EMS to manage TL1 devices.

The tutorial application is built exploring the various modules of AdventNet Web NMS.

Application Specification
Description of System Used in the Application
Implementation in a Nutshell

Application Specification
Name of the Application : TL1_Tutorial
Version of Web NMS : AdventNet Web NMS Release 4
Compatibility with other
Versions
: Not compatible with previous
versions of Web NMS
Tools used and their
Versions
: AdventNet Web NMS Studio
Platform-specific
requirements
: No special requirements

Description of System Used in the Application
This application uses an imaginary TL1 device called AcmeMSU and Terminal Server of TL1 devices.

The AcmeMSU device is a simple switching device interconnecting various external elements. The
switching device has a shelf with 11 slots numbered (1-11). Each slot from (1-11) has a card
associated with it. Each card will be having only one port.

The AcmeMSU holds three types of cards.

They are

1. CPU
2. ST1 DSX
3. ST1 CSU

The AcmeMSU holds one CPU card, seven ST1 DSX cards, and three ST1 CSU cards. Each ST1
card has one port and the port is used to connect the devices, which require the service of the
AcmeMSU.

Terminal Server of TL1 devices, i.e., Gateway Network Element (GNE) provides gateway to IP
Addressless TL1 devices through Target IDentifier (TID).

This application has been provided with a TL1 Agent Simulator created for demonstration. This
simulates a generic network device (AcmeMSU) with a simple TL1 message set. This also supports
the Terminal Server of TL1 devices.

AdventNet Inc. 12

TL1 Tutorial

AcmeMSU agent is configured to show each card with only one port (led). The status of the card is
shown separately (because in most of the TL1 Devices each and every card used will be intelligent
cards and these cards do have various LEDs to show various alarm/status changes).

Implementation in a Nutshell
The tutorial application covers various aspects of network management. Various modules of
AdventNet Web NMS are used to achieve the network management objectives as listed below:

Modeling the AcmeMSU Device and Component Objects
Discovering AcmeMSU Devices
Customizing Maps to display the AcmeMSU Devices
Managing Alerts of AcmeMSU Device and Its Components
Provisioning of the AcmeMSU Device
Monitoring the performance of the AcmeMSU Device
Re-branding AdventNet Web NMS as Your AcmeMSU Manager

Modeling the Switch and Component Objects
In AdventNet Web NMS, the managed device data are stored in the database for persistency.
For storing the managed devices' data into a database, you need to model the managed
device and its components.

The tutorial explains how the Acme MSU discovered as an AcmeMSUNode is modeled and it
further drills down and sends a few commands to the device to find the list of active cards
present in the device. In order to simulate a real time switch, the related components objects
such as shelves, slots, cards, and ports are modeled.

The Object Modeling topic illustrates how the existing AdventNet Web NMS Managed Object
model is extended to emulate a real TL1 Switch device and its sub-components.

This tutorial supports MySQL and Oracle databases only.
However, the support can be extended to other databases such as MSSQL, Sybase, Solid, and
Timesten using AdventNet Web NMS Studio.

Discovering Switch Devices
The Discovery process of AdventNet Web NMS discovers all the elements available in the
managed network. The tutorial explains how the Discovery process is customized to discover
generic TL1 and advanced GNE Nodes. The discovered nodes are modeled as explained
above and stored in the topology database for effective management.

The Discovery topic illustrates how to customize discovery and store the discovered
information in the Topology database.

Creating Maps to Display the Switches
AdventNet Web NMS provides default maps with default layouts and symbols to display of
various networks and element groups.

The tutorial explains how the custom maps are created from the elements of the topology
database and how to customize the display and configuration of network maps.

Also, if a Gateway Network Element (GNE) is detected, then a TL1 Topo Map will be created.
This map displays the GNE. This map can be drilled down further to the Logical objects (Ports)
AdventNet Inc. 13

TL1 Tutorial

to which the GNE will be listening to various TL1 devices and further to the TL1 devices (which
are accessed through the GNE).

A separate map will be created for each discovered switch and the various components of the
switch are shown in the chassis view. The following diagram shows the various components of
an individual switch.

Managing Alerts of Switch and Its Components
AdventNet Web NMS implements Fault Management to identify failures in the managed
network elements.

The tutorial explains how to handle alarms effectively and to generate meaningful outputs. In
this application, you will be dealing with alarms which come in the form of Autonomous
message from the device. This message from the device is parsed to get the component and
its health.

The Correlating Events and failures topics explains how to minimize the clutter due to
multiple related failures and alarms.
The Alarm propagation topic elaborates how to notify failure events to affected
components.
The Status polling topic explains how to carryout surveillance of Switch and
components periodically.

Provisioning the Switch
AdventNet Web NMS enables you to provision the network devices, where you can schedule a
task to get executed at any convenient time. If the configuration of the device through
Provisioning does not succeed, then the previous settings of the device can be restored. All the
Provisioning information (tasks) are cached in an XML file which can be reused.
The tutorial illustrates how Provisioning can be implemented to provision the modeled Switch
components.

AdventNet Inc. 14

TL1 Tutorial

Monitoring the Performance of the Switch
AdventNet Web NMS monitors the performance of the Switch with TL1 protocol.
The tutorial implements Performance management using the Performance Service of Web
NMS.

Re-branding AdventNet Web NMS as your EMS
The tutorial re-brands AdventNet Web NMS into AcmeMSU Manager. The logo, images, etc.
can be replaced with your own using Rebranding tool. You have the i18N tool for
internationalization of various UI reference of AdventNet and Web NMS. With these, the EMS
developed can easily be re-branded.
AdventNet Inc. 15

TL1 Tutorial

2.0 Try It Yourself

In this section, the steps to deploy the ready built application is provided. This would help you run the
application by yourself and view the results.

The steps involved are

Before You Begin
Get the Ready Built Application
Deploy the Ready Built Application in AdventNet Web NMS
Run the Application
View the Result

Before You Begin
Download a copy of AdventNet Web NMS 4.
For trying this tutorial, you have to take a Trial User License from AdventNet, Inc.
Get it installed in your machine.

For pertinent information, refer to the following document resources in the Installation Guide of
AdventNet Web NMS 4

System Requirements
Startup Options

Get the Ready Built Application
The working example comes bundled with AdventNet Web NMS as a NAR file. Alternatively, you can
download the latest version of the tutorial from the AdventNet Web site and use the NAR in it.

a. Use the bundled application

OR

b. Download the latest version from the Web site at the following URL:

http://download.adventnet.com/products/webnms/tutorials/tl1_tutorial.zip

If you are using the downloaded tutorial from the Web site, then extract the tutorial under
<Web NMS HOME> directory.
Select the NAR file mentioned below from the <Web NMS HOME>/tutorials/tl1_tutorial/ems
directory.

TL1_Tutorial1.0.nar

Caution: If a NAR is already installed, uninstall that NAR, before you install a new NAR.

Deploy the Ready Built Application in AdventNet Web NMS
Using the following instructions, deploy the TL1_Tutorial1.0.nar file.

AdventNet Inc. 16

TL1 Tutorial

To install the tutorial application,

Stop the Web NMS Server if it is running.
Run the DeploymentWizard.bat/.sh file under <Web NMS HOME>/bin directory.
Select the NarInstall/Uninstall tab.
Select Install button in the screen.
Click Browse button in the NAR INSTALLER pop-up screen.
Select the TL1_Tutorial1.0.nar available in the <Web NMS HOME>/tutorials/tl1_tutorial/ems
directory from the File Chooser pop-up screen and click the Select button.
Click OK button in the NAR INSTALLER pop-up screen.
On clicking OK button, NmsPwsNarInstaller screen will pop up.
In that, Select the Application Database (in which you want to run the tutorial) listed from the
combo box.
Click Next button.
In this screen, click Install button.
Now the installation will start and the status will be shown in the progress bar. When the
installation is complete, the Close button will be enabled.
Click Close button. You will see TL1_Tutorial1.0.nar entry listed in the NarInstall/Uninstall
tab.
Now the installation is complete.
Click Exit button to quit the Deployment Wizard. The Confirm.. dialog box will pop-up.
Click Yes button in the dialog box. This will quit the Deployment Wizard.

Start the TL1 Agent
To simulate a single TL1 Device and/or simulate multiple TL1 Devices in one and/or multiple
ports refer to Setting Up Environment for Testing section of Testing the Application topic.

Note: You must configure your machine IP address in tl1seed.file located in <Web NMS
Home>/conf directory for discovery of TL1 Elements.

Reinitialize Web NMS using reinitialize_nms.bat/.sh. Reinitialize Web NMS Database option
dialog pops up. Select Yes option in the option dialog for reinitializing Web NMS.

Caution: This tutorial will function only if Web NMS is reinitialized. Therefore, after
installing the tutorial, reinitialize Web NMS.
Ensure you use separate Web NMS installation for tutorial application development and
installation.
Do not experiment on Web NMS deployed in real world.

Run the Application
Start the Web NMS Launcher, by invoking WebNMSLauncher.bat/.sh file in the <Web NMS
HOME> directory.
Click Start NMS Server icon in the Web NMS Launcher.

View the Result
Connect a Browser or Application Client to the TL1 Element Manager Server in port 9090. Log in as
user root and password public.

In the left side frame, you will see the map tree. In that you can see the ACME > EMS-Panels >
Network Maps > Switches node. Under this node you can see the five switches discovered.

AdventNet Inc. 17

TL1 Tutorial

Displaying Switches in a Map

The Switches map will be the default map when you open the client. The following image is a
snapshot taken from the application, which shows the switches map, where all the switches are
laid out in the map.

AdventNet Inc. 18

TL1 Tutorial

Device Menus

On double-clicking the individual Switch nodes, you can see the Chassis view of the individual
switches. Right-click the device to see the device specific menu items. It has TL1-Node and
Acme-MSU(N) menu items with more submenus.

AdventNet Inc. 19

TL1 Tutorial

Chassis View of the Switch Device

The Chassis view of Switch device shows the various components of an individual switch. The
screen shot is given below. The map shows a shelf with slots. Each slot has a card associated
with it. Select and right-click a port to see menu specific to it. Right-click a card to see its
menu..

AdventNet Inc. 20

TL1 Tutorial

Alerts from the Switch Device and Sub-components and Its Propagation

The following diagram depicts how events are propagated from a child node (Port) to the
parent container (Card) and how they are correlated to generate more meaningful alarms.

AdventNet Inc. 21

TL1 Tutorial

Events View

AdventNet Inc. 22

TL1 Tutorial

Performance View

AdventNet Inc. 23

TL1 Tutorial

3.0 Application Design

Aim
To come up with the design on customizing the AdventNet Web NMS platform features in order to
provide various functions to the EMS, as specified in the requirements.

The primary design consideration in this tutorial application is to stick on to a simple command set.

For this purpose, the TL1 simulator was developed which contains a simple command set. This
models a generic Tl1 device (AcmeMSU). The Acme TL1 commands and responses used in this
tutorial application are appended to this tutorial.

EMS Management Requirements

Modeling the Switch device as Managed Resource
Discovering the Switch devices in the network
Representing the Switch components in the Map
Managing the Events and Alerts of Switch and its components
Provisioning the Switch Device
Re-branding AdventNet Web NMS as your EMS

Managed Resource Modeling

Objective

Modeling a device enables you to represent the various attributes and the behaviour of the
corresponding physical device and its components in a convenient way so as to reflect their
current state at any point of time. The EMS stores these persistent data in the database.
Modeling the Managed Object topic elaborately deals with various aspects to be considered for
designing the Managed object.

Tasks

Define the resources to be managed by the EMS. The properties of the Device and its
Components that will be used for modeling the resources are given below:

AcmeMSUNode location, contact
AcmeMSUShelf Serialno
AcmeMSUSlot state. slotno, slotName
AcmeMSUCard CRDREV, prodNo, ST1Type, CRDSN, MFDAT, deviceName, priority,
cardName
AcmeMSUPort deviceName, portName, portNo
Channel Connection, channelNumber
CrossConnection Destination, bandWidth, source, deviceName

The Role of Studio

Using the Resource Factory of the Studio, all the above resources can be modeled easily.

AdventNet Inc. 24

TL1 Tutorial

Discovering AcmeMSU Devices

Objective

To automatically discover and add the AcmeMSU devices and their components into the
topology database of Web NMS. This will necessitate identifying the component hierarchy of
the AcmeMSU devices.

Tasks

Create a Discovery Filter defining the containment hierarchy of the device and its
components.

The Role of Studio

The Discovery Filter Wizard will help you define the discovery filter. During discovery, Web
NMS will discover the device and its components and store them in the database according to
the containment hierarchy that has been defined in the discovery filter.

Representing the AcmeMSU Device and its components in the Map

Objective

To graphically represent the AcmeMSU Devices and its components, illustrating the
Containment hierarchy, in the map view of Web NMS Client.

Tasks

Create a custom map for the AcmeMSU Device and its components
Create a custom map layout class to customize the format in which the Map
Containers are arranged in the map view of Web NMS Client.
Create a custom map renderer class to customize the shape, style and color of the
Map Containers, which gives the flexibility of depicting the various components in the
map view of Web NMS Client.

The Role of Studio

Using the Map Filter Wizard of the Studio, all the above tasks can be completed.

Managing the Events and Alerts of AcmeMSU and its components

Objective

To monitor and manage the failures in the system effectively including, polling the AcmeMSU
Device and its components periodically for their status and thereby take preventive action
where necessary.

Tasks

Convert the failure notifications (Traps) into meaningful Events.
Write Custom code for Status Polling in the Managed Object classes. This will poll the
necessary devices for their current state on demand.

The Role of Studio

Using the Trap Filter Wizard of the Studio, it is easy to create a Trap Filter that filters the traps
and converts them into meaningful Events which can be managed.
AdventNet Inc. 25

TL1 Tutorial

Provisioning the AcmeMSU Device

Objective

The TL1 Application should be capable of controlling and configuring the device. It should be
able to switch the status of the card from active state to inactive state.

Tasks

Identify the Configuration commands to activate and deactivate the AcmeMSU Card.

The Role of Studio

In the Studio, two templates are created using the XML Editor can be used to configure tasks
and set Device lists where the tasks have to be executed. Source is generated for executing
the task. When the project is installed in Web NMS, there will be an option to execute the
defined tasks.

Re-branding AdventNet Web NMS as your AcmeMSU Manager

Objective

The EMS has to be renamed according to your requirements. All the relevant images and icons
will have be changed to reflect its new name (For example AcmeMSU Manager).

Tasks

Replace the existing AdventNet & Web NMS images and logo to Acme.
Internationalize the text and buttons that appear in the Client of the EMS.

The Role of Studio

Using the I18N Editor, the EnglishToNative properties file will be changed to internationalize
the text that appears in the Client. The images and logo of AdventNet will also be replaced with
that of Acme using this Editor
AdventNet Inc. 26

TL1 Tutorial

4.0 Modeling Managed Resources

What Are the Different Methods Available for Designing Managed Resources?
ManagedObject Parent-Child Containment Relationship
Naming Conventions Used in Modeling the Managed Resources

What Are the Different Methods Available for Designing Managed Resources?
We have two choices for our design of managed elements.

1. Use the dynamic properties feature of Web NMS ManagedObjects
2. Design ManagedObject subclasses

The former is a quick solution requiring less up-front design effort. However, we will choose to do a
cleaner design by modeling our objects as ManagedObject subclasses. This will enable us to better
serve our application needs, as well as provide a better design. This approach also results in a better
table structure for storing our objects in an RDBMS.

ManagedObject Parent-Child Containment Relationship
In our EMS example model, we will be applying Parent-Child Containment Relationship. In this
Relationship, the Device is called Parent. The Device will hold sub-components called Children. The
sub-components will be Parents and the sub-components will hold sub-sub-components called
Children.

We have to apply the containment relationship modeled to all the device components. That is, ports
are contained within a card, cards within a slot, slots within a shelf and the shelf within the node. For
mapping this relationship, we use the parent-children modeling feature available in the
ManagedObject class. This can be made available to our component classes just by implementing the
ContainerInterface in the parent component's class and setting/storing the parent object name/key in
the child component object using setParentKey() method of the ManagedObject class. This enables
us to fetch all the children of a parent component by using the getChildrenKeys() method of the
ManagedObject class, once the parent component and its children are added to the database. Also
we need to ensure that the parent component is added to the database before its children.

Another benefit of this ManagedObject property, namely ParentKey is it allows for quickly looping up
the component object hierarchy as required when propagating alarms.

Naming Conventions Used in Modeling the Managed Resources
Although a naming convention is not essential, it provides some benefits. It supports the requirement
of providing unique keys for all managed objects. It also allows us to easily identify some useful object
properties, without having to explicitly store these properties in the object. We will use a naming
convention for these objects that will make it easy to tell which object we are dealing with. This will
also help with filtering, etc. if we wish to use them.

The naming convention will be of the form:

Shelf : <nodename>_Shelf1
Slots : <nodename>_Shelf1_<slotname>
Cards : <nodename>_Shelf1_<slotname>_<cardname>
Ports : <nodename>_Shelf1_<slotname>_<cardname>-<portNo>

AdventNet Inc. 27

TL1 Tutorial

where, <nodename> will be the name of the TL1Device, <slotname> is the name of the slot as
obtained from RTRV-INVENTORY command, <cardname> is the name of the card as obtained from
RTRV-EQPT command and <portNo> is the number of the port in the card.

Note: In this example, although we have used a detailed object naming convention, we
have not made use of object names for accessing such properties for better design
considerations.
AdventNet Inc. 28

TL1 Tutorial

4.1 Modeling the TL1 Managed Object

In the TL1 application, you will be modeling a switch with associated shelves, slots, cards, and ports.
The following relationships are assumed between the ManagedObjects:

AcmeMSUNode : This represents a manageable switch that can be managed via
TL1. That is, Web NMS finds it as an TL1Node in the network
or is manually added by an operator.
AcmeMSUShelf : This represents the shelf that acts as the container for slot,
cards, and ports.
AcmeMSUSlot : Each switch consists of 11 slots, which are numbered 1-11.
AcmeMSUCard : Each slot may contain a card, which can be of different types. In
this simple example we will work with only one card object, with
a type field to specify the card type.
AcmeMSUPort : Each card can have multiple ports. For the example, only one
port is assumed per card.
Channel : Each port supports 24 Channels, for data transaction.
CrossConnection : This represents the connection details of a Channel to an
external element.

You will model these components in the Web NMS topology database and use these definitions to
build AcmeMSU Manager functionality into our application.

Class Diagram of Managed Resources of AcmeMSU Application
Design of Managed Elements

Class Diagram of Managed Resources of AcmeMSU Application

AdventNet Inc. 29

TL1 Tutorial

Design of Managed Elements
For each of the components of the TL1 device, you will create a ManagedObject subclass. The
following list captures the properties you will be providing in each component you model, i.e., the
ManagedObject subclasses.

The AcmeMSUNode object will extend a TL1Node object instead of ManagedObject directly.
This is because our example assumes that our node should be discovered as a TL1Node by
Web NMS.

Location
(location)
: Denotes the location of the TL1 Network Element.
Contact
(contact)
: The Contact person to be approached in case of failure of this
Equipment. (Normally E-Mail ID)

You will create a ManagedObject subclass AcmeMSUShelf to model the shelf. You will
provide the following additional properties in the slot object, in addition to what is available in
a ManagedObject class:

Serial number (serialNo) : Denotes the serial number of the shelf.

You will create a ManagedObject subclass AcmeMSUSlot to model the slot. You will provide
the following additional properties in the slot object, in addition to what is available in a
ManagedObject class:

Slot number
(slotNo)
: The slot number is the identification of position on the shelf.
State (state) : An indication of the state of the slot, whether the slot is empty or
the card type it contains.
Slot Name
(slotName)
: The name of the slot as obtained from the agent.

The Card object AcmeMSUCard is modeled using a ManagedObject subclass. You will
provide the following additional properties in the card object, in addition to what is available in
a ManagedObject class:

Device Name
(deviceName)
: The name of the device in which this card is present.
CRDSN : Denotes the serial number of the cards as obtained from
RTRV-INVENTORY.
MFDAT : Denotes the manufacturing date of this card as obtained
from RTRV-INVENTORY .
PRODNO (prodNo) : Denotes the production number of the card as obtained
from RTRV-INVENTORY.
CRDREV : Denotes the card revision index as obtained from RTRV-
INVENTORY.
Card Name
(cardName)
: Name of the card as obtained from the agent.
ST1 Type (ST1Type) : Denotes the ST1 Type of the Card.
Priority (priority) : Denotes the Priority of the Card.

AdventNet Inc. 30

TL1 Tutorial

The Port object AcmeMSUPort is also directly subclassed from ManagedObject. You will
provide the following additional properties in the port object, in addition to what is available in
a ManagedObject class.

Port number
(portNumber)
: The port number is the identification of position on the card.
Device Name
(deviceName)
: The name of the device in which this port is present. This is
just for using during the status polling.
Port Name
(portName)
: The port name as given by the agent.

The Channel object is also directly subclassed from ManagedObject. You will provide the
following additional properties in the port object, in addition to what is available in a
ManagedObject class.

Connection (connection) : Denotes whether a connection exists in this channel
or not.
Channel number
(channelNo)
: Denotes the serial number of the Channel in the Port.

The Cross Connection object is also directly subclassed from ManagedObject. You will
provide the following additional properties in the port object, in addition to what is available in
a ManagedObject class.

Source (source) : Denotes the Network Element or its subcomponent from
where the Cross connection is originating.
Destination
(destination)
: Denotes the Network Element or its subcomponent to where
the Cross connection is terminating.
Device Name
(deviceName)
: The name of the device in which this port is present.
Bandwidth
(bandWidth)
: Denotes the bandwidth used by this Cross connection.

AdventNet Inc. 31

TL1 Tutorial

5.0 Implementation

This tutorial application has been created using AdventNet Web NMS Studio. This comes bundled
with AdventNet Web NMS.

Using AdventNet Web NMS Studio
In the AdventNet Web NMS Studio, you have to create a separate project for this application. When
the project is complete, compile it and package it into a NAR file. For deploying the application in the
AdventNet Web NMS, you will have to deploy the NAR into the AdventNet Web NMS using the
Deployment Wizard tool. Various features available in the Studio allow you in creating the Application.
However, you need to write certain amount of custom code in order to suit the need of the tutorial
application. You need to add certain files as other files in the Studio project, which are specific to the
exclusive implementation of this tutorial application.

AdventNet Inc. 32

TL1 Tutorial

Implementation Overview
To start with, you will have to create a new Studio project.

In the Project, build the application using the following Service Wizards:

Model the Managed Resource

Model your AcmeMSU TL1 devices and their components into Managed Resources of
AdventNet Web NMS Topology database. You will be filling up the Managed Resource's
Name, Parent Resource, and its attributes in the Managed Resource wizard. In the end, you
will get the Managed Resource's class, and its Relational class.

Build Discovery-related Files Using Discovery Service

Create a Discovery filter to discover the AcmeMSU objects you have modeled in the previous
task. Create the filter using the Wizard.

Select the Shallow Discovery. Declare the variables. Prepare the Criteria Table using
Add/Modify Criteria Editor. View the summary. In the end, you will get the discovery filter. Add
the Custom code specific to this application.

Build Maps, Layouts, and Other Related Files Using Maps Service and
Chassis Wizard

Create a Map filter to display the discovered AcmeMSU devices. Modify mapIcon.data file to
invoke a Map specific to a particular Icon. Modify maps.conf file to add Custom Map. Create a
Map Symbol Renderer class to paint the Map as per your requirement. Create a Map-based
Chassis and other related Maps for the AcmeMSU device by extending the MAP API.

Build Fault Management Related Files Using Fault Service

Create an Event filter to process the events. Create a propagation filter to propagate the status
of the Child nodes to the Parent node. Configure the propagation filter. Create an Event filter to
group the alerts to one aggregated Alert. Add custom code in the Managed Object classes
(Port and Card) to get the status of the discovered devices.

Configure Performance Parameters to be Monitored

Configure the Performance parameters of the AcmeMSU Device to be monitored in the
Polling.conf file. Rest of the functions are handled effectively by Web NMS Performance
Management module.

Build Provisioning Related Templates, Menus and Filters

Create Provisioning related Templates, Associate the templates with the Menus to get it
invoked from the Client, and create Post-Provisioning Filter to handle the other related
activities.

Re-brand the Application Using the Re-branding and i18N Editor Tools

Change the splash image, logo, and frame icons etc. in the Re-branding tool and Company
Name, Product, and Version in the i18N Editor tool.
AdventNet Inc. 33

TL1 Tutorial

5.1 Creating TL1 Project

The first step in building our application using the AdventNet Web NMS Studio is to create a Project.
A Project created in Web NMS Studio copies the necessary files from the reference Web NMS to the
workspace where the project will be stored.

Starting Web NMS Studio
To start the Web NMS Studio

Invoke the Web NMS Launcher by running the script WebNMSLauncher.sh/bat present in <Web
NMS Home> directory.

Double-click on the sub-Web NMS Launcher icon Web NMS IDE and then double click on the Studio
icon.

Alternatively, you can start Web NMS Studio by running the script startWebNMSStudio.sh/bat
present in <Web NMS Home>/StudioTools/Studio/bin directory.

For details of Creating Project of AdventNet Web NMS Studio, refer to the AdventNet Web NMS
Studio documentation.

Instructions
Follow the steps given below to create the project.

Step 1: Invoke the Project Wizard

Select File > New Project menu item to invoke the Project Wizard.

Step 2: Add Project Details

Provide the following details about the TL1 EMS Project.

Project Name - TL1_User
Package Name - com.adventnet.nms.tutorials.tl1
Application Name - TL1_User
Version - 1.0

Click Next to proceed.

Step 3: Select Device Details

Select the Protocol as TL1.

Provide the following details about the Device.

Device Type - AcmeMSUNode


Step 4: Select Web NMS Services Details

Select the Services to be customized in your application.

All Services are selected by default.
AdventNet Inc. 34

TL1 Tutorial

For the EMS application, select only the following Services:

MANAGEDRESOURCE
DISCOVERY
MAP
FAULT
PROVISIONING
PERFORMANCE
SECURITY
SERVER_CONFIGURATION
REBRANDING

Out of these services, MANAGEDRESOURCE, SECURITY, and REBRANDING services are
selected by default.

You cannot uncheck the boxes.


Step 5: Select Database Details

Select the required Databases that are listed. The Databases that are listed are

MySQL
MSSQL
Oracle
Solid
Sybase
Timesten

Select MySQL and Oracle.


Step 6: Enter User Details

Select Single User option by selecting the radio button. The User options are

Single User
Multiple Users

Selecting Single User option will fill all the selected services rows with User Name Admin.

Step 7: Preview the Project Summary

You can view the TL1 Project details in the Project Summary screen.
Click Finish to create the Project Workspace.

Result
The Workspace for the Project is now created. After the Project is created the Resource Factory
starts. Using the Resource factory, you will see how to model the Switch Device and its components.
AdventNet Inc. 35

TL1 Tutorial

5.2 Modeling the Switch and its Components

To manage a physical device and its components, you need to model them as database objects. The
status and behaviour of the physical device and sub components are modeled as attributes of the
objects. By controlling/monitoring the attributes of the objects, the physical device can be managed by
the TL1 Element Management Application. By storing the details of the Modeled Resource in the
database, the data is made persistent and this helps the Element Management.

You are converting the device, its components, status, and behaviour into a network management
application manageable form. This is achieved by modeling them as Managed Resources.

The following table lists the device/components, which are required to be modeled as Managed
Resources, the core Web NMS Resources which are extended in order to these Resources, and the
Properties which are mapped for the status/behaviour of the physical device/sub-component.

Managed
Resource
Properties to be
managed
Core Web NMS Resource
AcmeMSUNode location, contact com.adventnet.nms.topodb.tl1.TL1Node
AcmeMSUShelf serialno
AcmeMSUSlot state, slotno, slotName
AcmeMSUCard CRDREV, prodNo,
ST1Type, CRDSN,
MFDAT, deviceName,
priority, cardName
AcmeMSUPort deviceName, portName,
portNo
Channel connection,
channelNumber
CrossConnection destination, bandWidth,
source, deviceName
com.adventnet.nms.topodb.ManagedObject

This chapter explains the procedure to model the Managed Resources, using AdventNet Web NMS
Studio.

The topics in this chapter cover the following procedures:

Managed Resource Modeling for AcmeMSU Management System.
Writing convenience methods by adding Custom code to Managed Resource's source.
AdventNet Inc. 36

TL1 Tutorial

5.2.1 Managed Resource Modeling

Aim

The AcmeMSU Device and its components have to be represented as Managed Resources. During
the discovery process, Web NMS discovers these managed resources and stores them in the
database to manage them.

For details of Creating Managed Resource of AdventNet Web NMS Studio, refer to the AdventNet
Web NMS Studio documentation.

Instructions
The AcmeMSU system consists of seven major components. The components with a short
description are given below.

AcmeMSUNode : This represents a manageable switch that can be managed via TL1, i.e.
Web NMS finds it as an TL1Node in the network or is manually added by
an operator.
AcmeMSUShelf : This represents the shelf that acts as the container for slot, cards, and
ports.
AcmeMSUSlot : Each switch consists of 11 slots, which are numbered 1-11.
AcmeMSUCard : Each slot may contain a card, which can be of different types. In this
simple example we will work with only one card object, with a type field
to specify the card type.
AcmeMSUPort : Each card can have multiple ports. For example only one port is
assumed per card.
Channel : Each port supports 24 Channels for data transaction.
CrossConnection : This represents the connection details of a Channel to an external
element.

Steps to Model AcmeMSU Device
Step 1: Managed Resource Details

Specify the managed resource details.

Name of the Managed Resource : AcmeMSUNode

Click Select button, Parent Resource Detail screen pops up.
Select the Parent Resource from the list.

Name the Parent Resource : com.adventnet.nms.topodb.tl1.TL1Node


Step 2 : MIB Details

Skip Step 2 of Resource Factory.

Note: Because this Application is based on TL1 Protocol Device. This does not
require MIB which is exclusive for SNMP protocol.

AdventNet Inc. 37

TL1 Tutorial

Step 3: Attributes of the Managed Resource

Add the following attributes.

Attribute Name Attribute Type
location
contact
String

All the properties of the Managed Resource with type and description are listed in the Attribute
table.


Step 4: View the Source

View the source of the Managed Resource, Relational Managed Resource, schema to store
the persistent data in the database and aliases for the tables.

Click Finish.

Adding Custom Codes for AcmeMSUNode Managed Resource
Now the AcmeMSUNode Managed Resource is modeled. Before compiling, add the custom code to
the J ava source file generated by the Wizard. You can add the custom code to the source using the
J MACS editor directly as per your requirement.

The details of the custom code meant for various objects added to the respective Managed Resource
classes are discussed in the next topic.

Compile the AcmeMSUNode node created under MANAGEDRESOURCE.

Steps to Model Other Managed Resources
Follow the above steps to model the AcmeMSUShelf, AcmeMSUSlot, AcmeMSUCard,
AcmeMSUPort, Channel, and CrossConnection as per the table given below:

Managed
Resource
Attribute
Name
Attribute
Type
Parent Resource
AcmeMSUShelf serialno String
state
slotName
String
AcmeMSUSlot
slotno Int
CRDREV
prodNo
ST1Type
CRDSN
MFDAT
deviceName
priority
AcmeMSUCard
cardName
String
com.adventnet.nms.topodb.ManagedObject
AdventNet Inc. 38

TL1 Tutorial

Managed
Resource
Attribute
Name
Attribute
Type
Parent Resource
deviceName
portName
String
AcmeMSUPort
portNo Int
connection String
Channel
channelNumber Int
destination
bandWidth
source
CrossConnection
deviceName
String

Adding Custom Codes for Other Managed Resources
Now the AcmeMSUShelf, AcmeMSUSlot, AcmeMSUCard, and AcmeMSUPort Managed Resource
are modeled. Before compiling, add the custom code to the J ava source files generated by the
Wizard. You can add the custom code to the source using the J MACS editor directly as per your
requirement.

The details of the custom code meant for various objects added to the respective Managed Resource
classes are discussed in the next topic.

Compile the AcmeMSUShelf, AcmeMSUSlot, AcmeMSUCard, AcmeMSUPort, Channel, and
CrossConnection nodes created under MANAGEDRESOURCE.

Result
All the Managed Resources are created now. We can proceed toward customization of Web NMS
Services. The first task is to define a Discovery Filter to discover the Switch components.
AdventNet Inc. 39

TL1 Tutorial

5.2.2 Custom Code for Managed Object Classes

You will be adding custom code to the Managed object J ava source files after their generation.

Add the following import statement in AcmeMSUShelf and AcmeMSUSlot MO Classes.

i mpor t com. advent net . nms. t opodb. Cont ai ner I nt er f ace;

Also append the following at the end of the Class Declaration lines in the AcmeMSUNode,
AcmeMSUShelf, AcmeMSUSlot, AcmeMSUCard, and AcmeMSUPort MO Classes.

i mpl ement s Cont ai ner I nt er f ace

Add the custom code in the following source files:

AcmeMSUNode - Custom code is added to accomplish Alarm propagation from the
AcmeMSUCard managed object.
Add custom code in the managed objects source files given below to achieve status polling
of these managed objects.
AcmeMSUCard - Custom code is added to accomplish status polling of the AcmeMSUCard
managed object.
AcmeMSUPort - Custom code is added to accomplish status polling of the AcmeMSUPort
managed object.

Add the following imports in AcmeMSUNode.

i mpor t j ava. ut i l . Vect or ;
i mpor t j ava. ut i l . Pr oper t i es;
i mpor t com. advent net . nms. t opodb. TopoAPI ;
i mpor t com. advent net . nms. t opodb. ManagedObj ect ;
i mpor t com. advent net . nms. ut i l . NmsUt i l ;

Add the following custom code in the AcmeMSUNode managed resource after the
//<End_Variable_Declarations> tag.

publ i c AcmeMSUNode( )
{
set Type( " acme_msu_node" ) ;
set Cl assname( " AcmeMSUNode" ) ;
}

Add the following custom code in the AcmeMSUNode managed resource after the Object clone()
method.

publ i c Vect or get Par ent Net s( )
{
r et ur n super . get Par ent Net s( ) ;
}

publ i c Vect or get Car dNames( )
{
t r y
{
TopoAPI t opoapi = ( TopoAPI ) NmsUt i l . get API ( " TopoAPI " ) ;
Pr oper t i es pr op = new Pr oper t i es( ) ;
pr op. put ( " t ype" , " acme_msu_car d_*" ) ;
AdventNet Inc. 40

TL1 Tutorial

Vect or car dsAndPor t s = t opoapi . get Obj ect NamesWi t hPr ops( pr op) ;
r et ur n car dsAndPor t s;
}cat ch( Except i on exp)
{
exp. pr i nt St ackTr ace( ) ;
}
r et ur n nul l ;
}
publ i c i nt checkSt at us( ) t hr ows j ava. r mi . Remot eExcept i on
{
i f ( t r ue)
{
Vect or car dNames = get Car dNames( ) ;
i nt i f _st at us_mi n = 5;
t r y
{
f or ( i nt i = 0; i < car dNames. si ze( ) ; i ++)
{
St r i ng next Car dName = ( St r i ng) car dNames. el ement At ( i ) ;
ManagedObj ect car dObj = t opoapi . get ByName( next Car dName) ;
i nt i nt St at = 5;
i f ( car dObj ! = nul l )
{

i nt St at = car dObj . get St at us( ) ;
}
el se
{
Syst em. er r . pr i nt l n( " Sl ot Obj ect i s nul l f or : " +
next Car dName) ;
}
i f ( i nt St at > 0)
{
i f ( i nt St at < i f _st at us_mi n)
{
i f _st at us_mi n = i nt St at ;
}
}
}
{
}
i f ( get St at us( ) ! = i f _st at us_mi n)
{
Syst em. out . pr i nt l n( " STATUS OF " + get Name( ) + " MODI FI ED FROM "
+ get St at us( ) + " TO - - > " + i f _st at us_mi n) ;
set St at us( i f _st at us_mi n) ;
}
r et ur n get St at us( ) ;
}

AdventNet Inc. 41

TL1 Tutorial

5.3 Discovering the AcmeMSU devices and GNEs

Discovering the AcmeMSU Devices and Gateway Network Elements

After modeling the Managed Resource, you need to make the AcmeMSU Manager to discover the
Acme MSU devices and add them to the Topology database. To achieve this, you need to customize
the existing AdventNet Web NMS Discovery process. This is done by writing a Discovery filter. This
filter will ensure that the AcmeMSU Devices and GNEs and the TL1 Devices through the Terminal
Servers (GNEs) are discovered. This filter retrieves the details of the AcmeMSU and other TL1
devices and stores in the Topology database.

Discovery Filter Code Description in a Nutshell
The Discovery filter gets called when any new object is discovered by Web NMS and decides whether
the discovered object can be passed through. As stated earlier, the filter will discover the AcmeMSU
Devices and GNEs and the TL1 Devices through the Terminal Servers (GNEs) and add components
such as shelves, slots, cards, etc.

Refer to the Discovery Filter Flowchart for a pictorial representation Discovery filter class code
implementation.

This chapter explains the procedure to customize the discovery for the modeled Managed Resources
and to populate the database with the network elements' details, using the AdventNet Web NMS
Studio.

AdventNet Inc. 42

TL1 Tutorial

Discovery Filter Flowchart

AdventNet Inc. 43

TL1 Tutorial

5.3.1 Discovering Switch Devices

Aim

To create a discovery filter to discover the AcmeMSU Device and its components and to set the
properties for the discovered Managed Resources. The components of the AcmeMSU device are
discovered by querying the Agent.

For details of Creating Shallow Discovery Filter of AdventNet Web NMS Studio, refer to the
AdventNet Web NMS Studio documentation.

Instructions to Create a Discovery Filter
Follow the steps given below to discover the Switch Device and its components.

Step 1: Invoke the Shallow Discovery Filter Wizard

Select the node SERVICES > DISCOVERY > DISCOVERY FILTER. Right-click on the node
and select New menu item.

Shallow Discovery Filter Wizard pops up.

Step 2: Enter the Shallow Discovery Filter Details

Provide the following details about the deep discovery filter

Class Name - AcmeMSUDiscFilter


Step 3: Declare the Variables

Skip this Variable Declaration screen.

Click Next.

Step 4: Specify the Filter Criteria

In the Filter Criteria screen, choose the Code_Builder node. Right click and select Create
Sub Node menu.
Create all the three nodes Criteria1, Criteria1, and Criteria1 as SubNodes under
Code_Builder node in the tree by right-clicking the node and selecting Add. This brings up the
Add/Modify Criteria Editor.
Add the following criteria against the nodes, using the Add/Modify Criteria Editor.

Criteria
flow
Criteria
Criteria1 (managedObject ==null)
Criteria2 (managedObject instanceof TL1GatewayNode) || (managedObject
instanceof TL1GatewayAccessSession)
Criteria3 ( !(managedObject instanceof TL1Node) )

Click Next to see the Property Information screen. Click Next in this screen.

AdventNet Inc. 44

TL1 Tutorial

Step 5: View the summary of Criteria and Modified properties

In the Criteria and Modified Properties screen, you can check the Properties specified.

Click Next.


In the Source screen, check the generated source code for the Criteria and the Properties
defined.

Click Finish.

Adding custom codes
After this, the J ava source file is generated by the Wizard. You can add the custom code or modify the
existing code of the source using the J MACS editor directly as per your requirement.

The details of the custom code added to the Discovery filter class in discussed in the following topics.

Result
Now you are ready with the device and its components needed to manage the AcmeMSU system.

You can now proceed to the next phase, that is Creating custom map and map containers for the
AcmeMSU Device and its components.
AdventNet Inc. 45

TL1 Tutorial

5.3.2 Custom Code for Discovery Filter

You will be adding custom code to the Discovery Filter J ava source files after their generation.

The details of the custom code added to the Discovery Filter are available in the Description of
Discovery Filter Custom Code topic of this document.

Add the following import statements in AcmeMSUDiscFilter class.

i mpor t j ava. r mi . Remot eExcept i on;
i mpor t com. advent net . nms. ut i l . Lockabl eObj ect ;
i mpor t com. advent net . nms. t opodb. t l 1. TL1Node;
i mpor t com. advent net . nms. t opodb. t l 1. TL1Gat ewayNode;
i mpor t com. advent net . nms. t opodb. t l 1. TL1Gat ewayAccessSessi on;
i mpor t com. advent net . t l 1. message. TL1ResponseMessage;
i mpor t com. advent net . t l 1. message. TL1Li ne;

Add the following variable in the AcmeMSUDiscFilter after the //<End_Variable_Declarations> tag.

st at i c St r i ng t l 1t ype = nul l ;

Add the following code in the AcmeMSUDiscFilter after the
//<UserCode_Begin_METHOD_FINISH> tag.

Obj ect i nvObj =nul l ;
Obj ect eqpt Obj =nul l ;
t l 1t ype = managedObj ect . get User Pr oper t y( " t l 1t ype" ) ;
i nvObj = TL1Swi t chUt i l . syncSendCommand( ( TL1Node) managedObj ect , " RTRV-
I NVENTORY" , " " ) ;
i f ( i nvObj == nul l )
{
r et ur n managedObj ect ;
}
eqpt Obj = TL1Swi t chUt i l . syncSendCommand( ( TL1Node) managedObj ect , " RTRV- EQPT" ,
" ALL" ) ;
Vect or i nvPr opVect or , eqpt Pr opVect or =nul l ;
AcmeMSUNode devi ce=nul l ;
i f ( i nvObj i nst anceof TL1ResponseMessage)
{
TL1ResponseMessage r epl y=( TL1ResponseMessage) i nvObj ;
i f ( r epl y==nul l | | r epl y. get Text Bl ock( ) ==nul l )
{
r et ur n nul l ;
}
devi ce=cr eat eTL1Node( managedObj ect ) ;
addObj ect ( devi ce) ;
i nvPr opVect or = get Pr opVect or ( r epl y) ;
}
el se
{
Syst em. out . pr i nt l n( " SOME Ot her obj ect obt : " +
i nvObj . get Cl ass( ) . get Name( ) + " VALUE: " + i nvObj ) ;
r et ur n nul l ;
}

AcmeMSUShel f shel f =cr eat eShel f ( devi ce) ;
AdventNet Inc. 46

TL1 Tutorial

addObj ect ( shel f ) ;
i f ( eqpt Obj i nst anceof TL1ResponseMessage)
{
TL1ResponseMessage r epl y=( TL1ResponseMessage) eqpt Obj ;
i f ( r epl y! =nul l && r epl y. get Text Bl ock( ) ! =nul l )
{
eqpt Pr opVect or =get Pr opVect or ( r epl y) ;
}
}
i f ( i nvPr opVect or ! =nul l && eqpt Pr opVect or ! =nul l )
{
f or ( i nt i =0; i <i nvPr opVect or . si ze( ) ; i ++)
{
Pr oper t i es pr op = ( Pr oper t i es) i nvPr opVect or . el ement At ( i ) ;
addSl ot s( i +1, devi ce, shel f , pr op, eqpt Pr opVect or , t opoApi ) ;
}
}
el se
{
{
Pr oper t i es i nvPr op=( Pr oper t i es) i nvPr opVect or . el ement At ( i ) ;
addEmpt ySl ot s( shel f , i nvPr op, i +1) ;
}
}
managedObj ect =nul l ;

Add the following custom code in the AcmeMSUDiscFilter at the end of the filter class and before the
last "}".

pr i vat e Vect or get Pr opVect or ( TL1ResponseMessage r esp)
{
Vect or sl ot Names = r esp. get Text Bl ock( ) . get TL1Li neLi st ( ) ;
Vect or i nvent or y=new Vect or ( ) ;
f or ( i nt i = 0; i < sl ot Names. si ze( ) ; i ++)
{
TL1Li ne cur r Li ne = ( TL1Li ne) sl ot Names. el ement At ( i ) ;
Pr oper t i es pr op =
TL1Swi t chUt i l . conver t Li neAsPr oper t i es( cur r Li ne) ;
i f ( ( pr op == nul l ) | | ( pr op. si ze( ) == 0) ) cont i nue;
i nvent or y. add( i , pr op) ;
}
r et ur n i nvent or y;
}
/ / - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
pr i vat e AcmeMSUNode cr eat eTL1Node( ManagedObj ect obj )
{
AcmeMSUNode devi ce = new AcmeMSUNode( ) ;
devi ce. set Name( obj . get Name( ) ) ;
devi ce. set Locat i on( " Cal i f or ni a" ) ;
devi ce. set Cont act ( " SysAdmi n" ) ;
devi ce. set Pr oper t i es( obj . get Pr oper t i es( ) ) ;
r et ur n devi ce;
}
/ / - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
pr i vat e AcmeMSUShel f cr eat eShel f ( AcmeMSUNode devi ce)
AdventNet Inc. 47

TL1 Tutorial

{
AcmeMSUShel f shel f =new AcmeMSUShel f ( ) ;
shel f . set Name( devi ce. get Name( ) +" _Shel f 1" ) ;
shel f . set Par ent Key( devi ce. get Name( ) ) ;
shel f . set Ser i al no( devi ce. get Name( ) +" Bank1" ) ;
r et ur n shel f ;
}
pr i vat e voi d addEmpt ySl ot s( AcmeMSUShel f shel f , Pr oper t i es i nvPr op,
i nt sl ot No) t hr ows com. advent net . nms. st or e. NmsSt or ageExcept i on,
com. advent net . management .
t r ansact i on. User Tr ansact i onExcept i on
{
St r i ng shel f Name = shel f . get Name( ) ;
AcmeMSUSl ot sl ot = new AcmeMSUSl ot ( ) ;
sl ot . set Name( shel f Name+" _" +i nvPr op. get Pr oper t y( " SLOTNAME" ) ) ;
sl ot . set Sl ot no( sl ot No) ;
sl ot . set St at e( " Empt y" ) ;
sl ot . set Di spl ayName( i nvPr op. get Pr oper t y( " SLOTNAME" ) ) ;
sl ot . set Par ent Key( shel f . get Name( ) ) ;
addObj ect ( sl ot ) ;
}
pr i vat e voi d addSl ot s( i nt sl ot No, AcmeMSUNode devi ce, AcmeMSUShel f
shel f , Pr oper t i es i nvPr op, Vect or eqpt Pr opVect or , TopoAPI api ) t hr ows
com. advent net . nms. st or e. NmsSt or ageExcept i on, com. advent net . management .
{
St r i ng sl ot Name = i nvPr op. get Pr oper t y( " SLOTNAME" ) ;
sl ot . set Name( shel f . get Name( ) +" _" +sl ot Name) ;
sl ot . set Sl ot Name( sl ot Name) ;

St r i ng name=" " ;
i f ( sl ot Name. equal sI gnor eCase( " SLT- 1" ) )
name=" CPU- 1" ;
el se
{
St r i ng numSt r = sl ot Name. subst r i ng( sl ot Name. i ndexOf ( " - " ) +1) ;
i nt num= I nt eger . par seI nt ( numSt r ) ;
name = " ST1- " +St r i ng. val ueOf ( num- 1) ;
}
f or ( i nt i =0; i <eqpt Pr opVect or . si ze( ) ; i ++)
{
Pr oper t i es eqpt Pr op = ( Pr oper t i es) eqpt Pr opVect or . el ement At ( i ) ;
St r i ng car dName = eqpt Pr op. get Pr oper t y( " f i el d0: 0" ) ;
i f ( car dName. equal sI gnor eCase( name) )
{
addCar d( sl ot , devi ce, eqpt Pr op, i nvPr op, api ) ;
br eak;
}
}
}
publ i c st at i c voi d addCar d( AcmeMSUSl ot sl ot , AcmeMSUNode
devi ce, Pr oper t i es eqpt Pr op, Pr oper t i es i nvPr op, TopoAPI api ) t hr ows
AdventNet Inc. 48

TL1 Tutorial

{
bool ean bool =t r ue;
i f ( eqpt Pr op. get Pr oper t y( " f i el d0: 0" ) . st ar t sWi t h( " CPU" ) )
{
bool =f al se;
}
AcmeMSUCar d car d = new AcmeMSUCar d( ) ;
car d. set Name( sl ot . get Name( ) +" _" +car dName) ;
car d. set Di spl ayName( car dName) ;
car d. set Devi ceName( devi ce. get Name( ) ) ;
car d. set Type( " acme_msu_car d_" +i nvPr op. get Pr oper t y
( " CRDTYPE" ) . t oLower Case( ) ) ;
car d. set CRDSN( i nvPr op. get Pr oper t y( " CRDSN" ) ) ;
car d. set MFDAT( i nvPr op. get Pr oper t y( " MFDAT" ) ) ;
car d. set Pr odNo( i nvPr op. get Pr oper t y( " PRODNO" ) ) ;
car d. set CRDREV( i nvPr op. get Pr oper t y( " CRDREV" ) ) ;
car d. set Pr i or i t y( eqpt Pr op. get Pr oper t y( " PRI ORI TY" ) ) ;
car d. set Car dName( car dName) ;
i f ( ( t l 1t ype ! = nul l ) && ( t l 1t ype. equal s( " t l 1node_gne" ) ) )
{
car d. set User Pr oper t y( " t l 1car dt ype" , " t l 1car d_gne" ) ;
}
i f ( i nvPr op. get Pr oper t y( " CRDTYPE" ) . equal sI gnor eCase( " ST1" ) )
{
car d. set ST1Type( eqpt Pr op. get Pr oper t y( " TYPE" ) ) ;
}
el se
{
car d. set ST1Type( " N/ A" ) ;
}

car d. set Par ent Key( sl ot . get Name( ) ) ;

addObj ect ( car d) ;
St r i ng[ ] car dChi l d = {car d. get Name( ) };
sl ot . addChi l dr enKeys( car dChi l d) ;
sl ot . set St at e( " Access" ) ;
t r y {
api . l ock( sl ot , Lockabl eObj ect . WRI TE_LOCK, 2) ;
api . updat eObj ect ( sl ot , t r ue, t r ue) ;
}
cat ch ( com. advent net . management . t r ansact i on.
User Tr ansact i onExcept i on ut e)
{
Syst em. er r . pr i nt l n( " Except i on whi l e updat i ng t he
obj ect : " +sl ot . get Name( ) +" \ n" + ut e) ;
ut e. pr i nt St ackTr ace( ) ;
t hr ow ut e;
}
cat ch ( com. advent net . nms. st or e. NmsSt or ageExcept i on nse)
{
obj ect : " + sl ot . get Name( ) +" \ n" +nse) ;
nse. pr i nt St ackTr ace( ) ;
t hr ow nse;
}
cat ch ( Remot eExcept i on r e)
{
AdventNet Inc. 49

TL1 Tutorial

obj ect : " + sl ot . get Name( ) +" \ n" +r e) ;
r e. pr i nt St ackTr ace( ) ;
}
cat ch ( com. advent net . nms. ut i l . AccessDeni edExcept i on ade)
{
obj ect : " + sl ot . get Name( ) +" \ n" +ade) ;
ade. pr i nt St ackTr ace( ) ;
}
cat ch( Except i on e)
{
Syst em. er r . pr i nt l n( " Er r or whi l e updat i ng obj ect " +sl ot ) ;
e. pr i nt St ackTr ace( ) ;
}
i f ( bool ) / / Thi s check i s made si nce t her e i s no por t f or CPU car d
{
addPor t ( devi ce, car d, api ) ;
}

}
pr i vat e st at i c voi d addPor t ( AcmeMSUNode devi ce ,
AcmeMSUCar d car d, TopoAPI api ) t hr ows com. advent net .
nms. st or e. NmsSt or ageExcept i on, com. advent net .
management . t r ansact i on. User Tr ansact i onExcept i on
{
AcmeMSUPor t por t = new AcmeMSUPor t ( ) ;
i nt por t No = 1; / / Cur r ent l y onl y one por t i s assumed per car d.
St r i ng por t Name = car d. get Car dName( ) +" - " +St r i ng. val ueOf ( por t No) ;
por t . set Name( car d. get Name( ) +" - " +por t No) ;
por t . set Di spl ayName( car d. get Di spl ayName( ) +" - " +por t No) ;
por t . set Por t No( por t No) ;
por t . set Por t Name( por t Name) ;
por t . set Devi ceName( devi ce. get Name( ) ) ;
por t . set Par ent Key( car d. get Name( ) ) ;
addObj ect ( por t ) ;

i f ( t l 1t ype ! = nul l && t l 1t ype. equal s( " t l 1node_gne" ) )
{
por t . set User Pr oper t y( " t l 1por t t ype" , " t l 1por t _gne" ) ;
}

f or ( i nt i =0; i <5; i ++)
{
addChannel ( i +1, por t , devi ce) ;
}
}
pr i vat e st at i c voi d addChannel ( i nt chNo , AcmeMSUPor t
por t , AcmeMSUNode devi ce) t hr ows com. advent net . nms. st or e.
NmsSt or ageExcept i on, com. advent net .
{
Channel channel = new Channel ( ) ;
St r i ng channel Name = por t . get Por t Name( ) +" - " +chNo;
channel . set Name( devi ce. get Name( ) +channel Name) ;
channel . set Di spl ayName( channel Name) ;
St r i ng por t Name=por t . get Name( ) ;
channel . set Channel Number ( chNo) ;
channel . set Par ent Key( por t Name) ;
addObj ect ( channel ) ;
}
AdventNet Inc. 50

TL1 Tutorial

pr i vat e st at i c voi d addObj ect ( ManagedObj ect obj ) t hr ows
com. advent net . nms. st or e. NmsSt or ageExcept i on, com. advent net .
{
t r y
{
TopoAPI api = ( TopoAPI ) NmsUt i l . get API ( " TopoAPI " ) ;
api . addObj ect ( obj ) ;
}
cat ch
( com. advent net . management . t r ansact i on. User Tr ansact i onExcept i on ut e)
{
Syst em. er r . pr i nt l n( " Except i on whi l e addi ng t he obj ect " +
obj . get Name( ) +" \ n" +ut e) ;
t hr ow ut e;
}
{
obj . get Name( ) +" \ n" +nse) ;
t hr ow nse;
}
{
obj . get Name( ) +" \ n" +r e) ;
}
cat ch( Except i on exp)
{
}
}

AdventNet Inc. 51

TL1 Tutorial

5.4 Creating Maps to Display AcmeMSU Devices

Creating Maps to Display AcmeMSU Devices

The AcmeMSU devices discovered need to be represented by images/icons. These representations
need to be laid out and displayed in a map.

Apart from this, individual Switch device is represented as an actual model of the physical equipment.
This is called Chassis view. In this view, the AcmeMSU device with Shelves, Slots, Cards, and Ports
are displayed in an exclusive map.

This chapter explains the procedure to achieve the following tasks using AdventNet Web NMS Studio:

Create new Map for the AcmeMSU devices using Map Filter.
Configure the filter in mapIcon.data file.
Creating Map-based Chassis View using Map Filter.

The map filter assigns the Map Symbols for each Slot and Card into a Map Container, capable of
containing map symbol children. The filter also sets the parentName property of the child symbol to its
containing parent symbol name. Map server generates one map symbol for each map in which the
ManagedObject is displayed. In this application, there is one map for every switch. So one map
symbol gets generated.
AdventNet Inc. 52

TL1 Tutorial

5.4.1 Creating Maps

Aim

To create custom map and map containers for the Switch objects and their components. This will also
include identifying the Layout to represent the Switch device components.

For details of Creating Map Filter of AdventNet Web NMS Studio, refer to the AdventNet Web NMS

Instructions
Follow the steps given below to define a Map filter

Step 1 : Invoking the Map Filter Wizard

Click on the node SERVICES > MAP > MAP FILTER. Right-click on the node and select New
menu item.

Step 2 : Map Filter Details

Provide the following details about the Map Filter:

Class Name - AcmeMSUMapFilter


Step 3 : Add the variables

Add the following variable for the respective criteria.

Criteria Variable Type Variable Name
Criteria1 String netmapname

Enter the values as given above and click Add button.


Step 4 : Defining Criteria

To add the next few criteria, select and right-click Criteria1 node in the tree. Select Create
Node option and proceed to add the nodes and their corresponding criteria.

Provide the following inputs to define criteria based map representation.
Click the Add button to declare Connectors/ Left Operand/ Operator/ Value.

Criteria flow Criteria
Criteria1 (index !=-1)
Criteria2 (managedObject instanceof AcmeMSUNode)
Criteria3 (managedObject instanceof AcmeMSUShelf)
Criteria4 (managedObject instanceof AcmeMSUSlot)
Criteria5 (managedObject instanceof AcmeMSUCard)
Criteria6 (managedObject instanceof AcmeMSUPort)

Click the Next button to proceed.
Step 5: Specify the Filter Properties
AdventNet Inc. 53

TL1 Tutorial

Modify the Filter Properties of the respective criteria.

Criteria1
Nil

Criteria2

Select Map instance from the Map components List

Property Name Property Value
mapName "Acme"+managedObject.getName()+".netmap"
label managedObject.getName()+"ChassisView"
anchored true
treeIconFileName images/ipn.png
mapSymbolRenderer com.adventnet.nms.mapui.MSUMapSymbolRenderer
autoplacement true
topology $tl1_components
currentTopology tl1_components

Criteria3

Select MapContainer instance from the Map components List.

name managedObject.getName()
label managedObject.getDisplayName()
objName managedObject.getName()

Criteria4


parentName managedObject.getParentKey()
mapName netmapname

Criteria5


mapName netmapname
Topology $tl1_components
CurrentTopology tl1_components

AdventNet Inc. 54

TL1 Tutorial

Criteria6

Select MapSymbol instance from the Map components List.

mapName netmapname

Click Next.

Step 6: View the summary of Criteria and Modified properties

In the Criteria and Modified Properties screen, check if the Properties are set in the right
order you want. If not, use the UP or DOWN buttons to set the order.
Click Next.


In the Source screen, check the generated source code for the Criteria and the Properties
defined.

Click Finish.

Adding custom codes
After this, the J ava source file is generated by the Wizard. You can add the custom code or modify the
existing code of the source using the J MACS editor directly as per your requirement.

The details of the custom code added to the Map filter class in discussed in the next topic.

Result
The map view illustrating the Containment relationship between the Switch object and their
components are ready.
AdventNet Inc. 55

TL1 Tutorial

5.4.2 Customizing the Map Filter Code

In this section, you can look at how to customize Map to display TL1 elements of a network.

Add the custom code in the Map filter in the appropriate locations as given below:

Add the following import statements in AcmeMSUMapFilter class.

i mpor t j ava. ut i l . *;
i mpor t com. advent net . nms. t opodb. ManagedObj ect ;
i mpor t com. advent net . nms. mapdb. *;
i mpor t j ava. sql . Ti me;
i mpor t j ava. sql . Dat e;
i mpor t j ava. sql . Ti mest amp;

Add the following variables in the AcmeMSUMapFilter before the
//<Begin_filterMapSymbols_Vector_ManagedObject_MapAPI> tag.

St r i ng moname=managedObj ect . get Name( ) ;
i nt i ndex=moname. i ndexOf ( " _Shel f " ) ;

Add the following custom code for Criteria1 after the //<UserCode_Begin_Criteria1_IF_START>
tag.

St r i ng mapname=moname. subst r i ng( 0, i ndex) ;
net mapname=" Acme" +mapname+" . net map" ;

Add the following code after the //Usercode_Begin_Criteria2_IF_START tag.

Vect or par ent Maps = ( ( AcmeMSUNode) managedObj ect ) . get Par ent Net s( ) ;
St r i ng par ent Map = " Net wor k Maps" ;
i f ( par ent Maps! =nul l && ! par ent Maps. i sEmpt y( ) )
{
par ent Map = ( St r i ng) par ent Maps. el ement At ( 0) ;
}

Add the following code after the //Usercode_Begin_Criteria2_IF_FINISH tag.

map0. put ( " par ent Node" , par ent Map+" . net map" ) ;

Add the following custom code, after the //<UserCode_Begin_Criteria3_PROPERTIES_FINISH>
tag, for the shelf object since the shelf is assumed to be a container which contains slots, cards, and
ports.

mapCont ai ner 0. set MapName( " Acme" +managedObj ect . get Par ent Key( ) +" . net map" ) ;
mapSymbol s. r emoveAl l El ement s( ) ;

Add the following custom code, after the //<UserCode_Begin_Criteria4_PROPERTIES_FINISH>
tag, for each and every AcmeMSUSlot discovered instead of adding a MapSymbol, since a slot is
assumed to be a container which contains a Card inside it.

mapCont ai ner 1. set User Pr oper t y( " sl ot number " , St r i ng. val ueOf ( ( ( AcmeMSUSl ot )
managedObj ect ) . get Sl ot no( ) ) ) ;

AdventNet Inc. 56

TL1 Tutorial

Add the following custom code for each and every AcmeMSUCard discovered instead of adding a
MapSymbol, since a card is assumed to be a container which contains a port inside it, also we set the
parent name to be the slot name so that the card will be added inside the slot.
Add the following custom code after the //<UserCode_Begin_Criteria5_IF_START> tag.

AcmeMSUCar d car dObj = ( AcmeMSUCar d) managedObj ect ;
St r i ng st 1Type = car dObj . get ST1Type( ) ;

Add the following custom code after the tag //<UserCode_Begin_Criteria5_PROPERTIES_FINISH>.

mapCont ai ner 2. set User Pr oper t y( " st 1t ype" , st 1Type) ;
AdventNet Inc. 57

TL1 Tutorial

5.4.3 Creating and Configuring other Map related files

Create/Configure the following files for viewing the ACME MSU Device Maps.

Create a Custom Map Layout for AcmeMSU Device.
Create a Custom Map Symbol Renderer Class.
Create a Custom Class for Chassis View of AcmeMSU device, extending NMS Map Applet.
Configure the Chassis Map.
Configure NMS Panels.

Creating Custom AcmeMSU Device Map Layout
This topic explains the layout to be adopted in the AcmeMSU device map.

In order to lay the shelf, slots, cards, and ports on the map for the switch, you have to write a Map
Symbol Layout class called the MSUMapSymbolLayout class.

Create this Symbol Layout class using other files option of the Studio project. Create the file with
dummy inputs. Copy the contents from the above given URL and overwrite completely in the newly
created file.

For details of Working with other files of AdventNet Web NMS Studio, refer to the AdventNet Web
NMS Studio documentation.

The description of the MSU Map Layout class is available in the Description of Custom AcmeMSU
Device Map layout topic of this document.

Creating Custom Map Symbol Renderer
This topic explains the Map Symbol Renderer to be adopted in the AcmeMSU device map.

You have to create the MSUMapSymbolRenderer class.

This, you have to create using other files option of the Studio project. Create the file with dummy
inputs. Copy the contents from the above given URL and overwrite completely in the newly created
file.


The description of the MSU Map Symbol Renderer class is available in the Description of Custom
Map Symbol Renderer topic of this document.

Creating Custom Class for AcmeMSU Chassis View
Creating a Class Extending Map Applet for AcmeMSU Chassis View
In order to customize the AcmeMSU Device's Chassis View, you have to write an Map Applet
extension class called the AcmeExtMapApplet class.

Create this class using other files option of the Studio project. Create the file with dummy inputs.
Copy the contents from the above given URL and overwrite completely in the newly created file.
For details of Working with other files of AdventNet Web NMS Studio, refer the AdventNet Web

The description of the AcmeMSU Map Applet class is available in the Description of Custom Class
for AcmeMSU Chassis View topic of this document.
AdventNet Inc. 58

TL1 Tutorial

Configuring the Chassis Map
This topic explains how to associate the map filters and objTypes to AcmeMSU device components.
Also the image that is associated with each component is mentioned in this file.

Follow the procedure given below:

Open the mapIcon.data file under <Project HOME>/WebNMS/conf directory in a text editor.
Append the following entries.

Note: The file mapIcon.data file must be opened only in a text editor separately.

<! - - Add t he f ol l owi ng el ement af t er t he r oot el ement , i . e. ,
<MAP_I CON_DATA> - - >

<OBJ TYPES
backgr ound
node=" 1"
net wor k=" 2"
gat eway=" 3"
sub- symbol =" 4"
si t e=" 5"
acme_msu_shel f =" 400"
acme_msu_sl ot =" 100"
acme_msu_car d_st 1=" 200"
acme_msu_por t _11=" 300" / >

<! - - Add t he f ol l owi ng nodes i n t he end, af t er t he def aul t nodes - - >

<DATA
TYPE=" acme_msu_shel f "
MAP_FI LTER=" com. advent net . nms. t ut or i al s. t l 1. AcmeMSUMapFi l t er "
menuName=" car dmenu"
obj Type=" 400" / >

<DATA
TYPE=" acme_msu_sl ot "
obj Type=" 100"
i conName=" empt ysl ot . png" / >

<DATA
TYPE=" acme_msu_car d_cpu"
obj Type=" 200"
i conName=" cpui o. png" / >

<DATA
TYPE=" acme_msu_car d_st 1"
AdventNet Inc. 59

TL1 Tutorial

obj Type=" 200"
menuName=" pr ovmenu" / >

<DATA
TYPE=" acme_msu_por t "
menuName=" cr ossconnect menu"
obj Type=" 300"
i conName=" l ed. png" / >

Configuring NMS Panels
To change the NMS Panels shown in the Left-side frame of the Web NMS Client, configure the
NmsPanels.conf file with appropriate data present in the <Project Home>/WebNMS/conf directory.

Using Studio to Configure NMS Panels
Configuring NMS Panels in this application was achieved with the help of the AdventNet Web NMS
Studio. Open the NmsPanels.conf file in the Other Files and add the nodes and their details.

You can add or edit the node or modify the existing node directly as per your requirement using the
UI. The UI is invoked by the right click menu items Add, Modify, and Delete .

For details of Working with XML files of AdventNet Web NMS Studio, refer to the AdventNet Web

Change the package name as given below for the MANAGED-OBJ ECT-FORM parameter in
NmsPanels.conf file.

<NMS_PANELS_CONF>
<PANEL NO- OF- MAPS- TO- BE- REMEMBERED=" 15" TREE- POPUP- MENU=" Cust om
Vi ews, f r ameopt i ons. xml , Tr eeOper at i ons. xml " MANAGED- OBJ ECT-
FORM=" com. advent net . nms. mapui . MapCust omPr op"
cl assName=" com. advent net . nms. t ut or i al s. t l 1. AcmeExt MapAppl et " DEFAULT- CLOSE-
OPERATI ON=" HI DE_ON_CLOSE" PROPERTI ES-
FORM=" com. advent net . nms. mapui . MapCust omPr op" PANEL- KEY=" MapAppl et " / >
</ NMS_PANELS_CONF>

AdventNet Inc. 60

TL1 Tutorial

5.5 Managing the Alerts of AcmeMSU Device

Managing the Alerts of AcmeMSU Device

To receive, process the failures in the managed network elements (i.e., AcmeMSU devices) and
present it in a meaningful form, you have to implement Fault management service of AdventNet Web
NMS. The AcmeMSU device notifies any abnormality in the operations, parameters and failures to the
AcmeMSU Manager application in the form of Autonomous Messages.

Status Polling of AcmeMSU Device
You have to ensure that AcmeMSU Manager gets the status of the AcmeMSU device and its
components periodically. This will be updated in the database and displayed in the Client.

The tutorial explains how to customize the Fault management features.

The Correlating events topic explains how to minimize the clutter due to multiple related event
and alarms.
The Status propagation topic deals in a detailed manner on how to notify failure events to
affected components above in the hierarchy.
AdventNet Inc. 61

TL1 Tutorial

5.5.1 Correlating Events

Creating Event Correlation Filter Class

In order to correlate events and failures of the AcmeMSU device, you have to write an event filter
class called the MSUEventFilter class.

Create this filter class using other files option of the Studio project. Create the file with dummy inputs.


This Event filter you will use for correlating the Events from ports to cards, slots, shelves, and nodes.

The description of the Event filter class is available in the Description of MSU Event Correlation
Filter Class topic of this document.
AdventNet Inc. 62

TL1 Tutorial

5.5.2 Status Propagation

Using Studio to Configure Status Propagation Filter

Adding the Status propagation filter used in this application was achieved with the help of the
AdventNet Web NMS Studio. Open the propagation.filters file in the Other Files and add the nodes
and their details.



Add the following node to the propagation.filters file.

<PROPAGATI ON_FI LTERS>
<FI LTER cl assName=" com. advent net . nms. t ut or i al s. t l 1. St at usPr opagat i on" / >
</ PROPAGATI ON_FI LTERS>

In order to set up alarm propagation class, called StatusPropagation class, configure it as given in
the above node as Filter class. In order to invoke this class an entry has to be given in the
propagation.filters file under <Web NMS Home>/conf directory.

Creating Status Propagation Filter Class

In order to set up status propagation, you have to write an alarm propagation filter class called
StatusPropagation class.

Create this filter class using other files option of the Studio project. Create the file with dummy inputs.

This status propagation filter you will use for propagating status from ports to cards, slots, shelves,
and nodes.

The description of the Status Propagation filter class is available in the Description of AcmeMSU
Status Propagation Filter Class topic of this document.

AdventNet Inc. 63

TL1 Tutorial

5.6 Fetching Device Status Periodically

You need to ensure that the status of the Managed Objects are monitored and displayed in the Client
UI.

For each type of device, Web NMS performs status polling of these devices based on the
configuration.
For each managed object, it invokes the status polling specified by the configuration, which may be a
standard operation such as pinging the device already supported by Web NMS or a custom polling
that is needed for a specific device or component.

You can override the status polling code for your managed object. You will see how the Port object is
used, for which you will poll the operational status of an interface corresponding to the port number on
a card.

The custom code for achieving the above task is added to the Port object as explained in the
Customizing Port object topic of this tutorial document.
AdventNet Inc. 64

TL1 Tutorial

5.6.1 Status Polling for Card

The description of the Custom Code for the Status Polling of Card Managed Object is available in the
Description of Custom Code for Status Polling of Card topic of this document.

Add the following imports in AcmeMSUCard MO Class.

i mpor t com. advent net . t l 1. message. TL1Text Bl ock;

Add the following Custom Code after the //<End_Variable_Declarations> tag.

publ i c AcmeMSUCar d( )
{
set Cl assname( " AcmeMSUCar d" ) ;
set Pol l I nt er val ( 300) ;
}

Add the following Custom Code before the //<Begin_checkStatus> tag.

{
t r y
{
AcmeMSUNode myswi t ch =
( AcmeMSUNode) t opoapi . get ByName( get Devi ceName( ) ) ;
St r i ng car dName =
get Name( ) . subst r i ng( get Par ent Key( ) . l engt h( ) +1) ;
Obj ect r esul t Obj = TL1Swi t chUt i l . syncSendCommand( myswi t ch,
" RTRV- EQPT" , car dName) ;
i f ( r esul t Obj == nul l )
{
}
i f ( r esul t Obj i nst anceof TL1ResponseMessage)
{
TL1ResponseMessage r epl y = ( TL1ResponseMessage) r esul t Obj ;
St r i ng cmdCode = r epl y. get ResponseI d( ) . get Compl et i onCode( ) ;
i nt st at us = get St at us( ) ;
i f ( cmdCode. equal s( TL1ResponseMessage. COMPLETED) )
{
st at us = 5;
}
el se
i f ( cmdCode. equal s( TL1ResponseMessage. DELAYED_ACTI VATI ON) )
{
st at us = 4;
}
el se i f ( cmdCode. equal s( TL1ResponseMessage. PARTI AL_SUCCESS) )
{
st at us = 3;
}
AdventNet Inc. 65

TL1 Tutorial

el se i f ( cmdCode. equal s( TL1ResponseMessage. DENI ED) )
{
st at us = 2;
}
el se i f ( cmdCode. equal s( TL1ResponseMessage. RETRI EVE) )
{
st at us = 2;
}
TL1Text Bl ock t ext Bl k = r epl y. get Text Bl ock( ) ;
i f ( t ext Bl k ! = nul l )
{
Vect or r esp = t ext Bl k. get TL1Li neLi st ( ) ;
i f ( r esp. si ze( ) == 0)
{
r et ur n st at us;
}
el se
{
TL1Li ne cur r Li ne = ( TL1Li ne) r esp. el ement At ( 0) ;
St r i ng st r = nul l ;
i f ( get Type( ) . equal sI gnor eCase( " CPU" ) )
{
st r = pr op. get Pr oper t y( " PST" ) ;
}
el se
{
}
i f ( st r ! = nul l )
{
st at us = sever i t yFor Car dSt at us( st r ) ;
}
}
}
i f ( st at us==1 | | st at us==4)
{
set Managed( f al se) ;
}
el se
{
set St at us( st at us) ;
}

}
{
}

AdventNet Inc. 66

TL1 Tutorial

5.6.2 Status Polling for Port

The description of the Custom Code for the Status Polling of Port Managed Object is available in the
Description of Custom Code for Status Polling of Port topic of this document.

Add the following imports in AcmeMSUPort MO Class.


Add the following Custom Code after the //<End_Variable_Declarations> tag.

publ i c AcmeMSUPor t ( )
{
set Type( " acme_msu_por t " ) ;
set Cl assname( " AcmeMSUPor t " ) ;
set Pol l I nt er val ( 300) ;
}

Add the following Custom Code before the //<Begin_checkStatus> tag.

{
t r y
{
AcmeMSUNode mySwi t ch =
AcmeMSUCar d car d =
( AcmeMSUCar d) t opoapi . get ByName( get Par ent Key( ) ) ;
St r i ng por t Name =
get Name( ) . subst r i ng( car d. get Par ent Key( ) . l engt h( ) +1) ;
Obj ect r esul t Obj = TL1Swi t chUt i l . syncSendCommand( mySwi t ch,
" RTRV- FAC" , por t Name) ;
{
}
{
{
st at us = 5;
}
el se
{
st at us = 4;
}
AdventNet Inc. 67

TL1 Tutorial

{
st at us = 3;
}
{
st at us = 2;
}
{
st at us = 2;
}
{
i f ( r esp. si ze( ) == 0)
{
r et ur n st at us;
}
el se
{
St r i ng st r = pr op. get Pr oper t y( " PST" ) ;
{
st at us =
TL1Swi t chUt i l . sever i t yFor Car dSt at us( st r ) ;
i f ( st at us==- 1)
st at us=get St at us( ) ;
}
}
}
}
{
}

AdventNet Inc. 68

TL1 Tutorial

5.7 Performance Monitoring of the AcmeMSU Device

The Performance Management permits the AcmeMSU device to accumulate data to validate the
integrity of incoming electrical and optical data. This data is then used to calculate performance
parameters for each entity being monitored. These parameters can then be used to identify potential
trouble, to locate a fault, for tariffs and for preventive maintenance.

For all performance monitoring parameters, data is accumulated for two time periods, 15 minutes and
day (24 hours).

The PM parameters for the current 15-minute, and 32 previous 15-minute periods are maintained.
For the day periods, the PM data for 1 current, and 7 previous day periods is maintained.

The following Performance parameters are monitored for the T1 line:

CVL - Code Violations (Line)
ESL - Errored Seconds (Line)
SESL - Severely Errored Seconds (Line)
LOSSL - Loss Of Signal Seconds (Line)

The following Performance parameters are monitored for the T1 path:

CVP - Code Violations (Path)
ESP - Errored Seconds (Path)
SESP - Severely Errored Seconds (Path)
AISSP - Alarm Indication Signal Seconds (Path)
SASP - Severely Errored Frame / Alarm indication
signal Seconds (Path)
CSSP - Controlled Slip Seconds (Path)
UASP - UnAvailable Seconds (Path)
FCP - Failure Count (Path)

In the case of this tutorial application, only ESL,SESL,LOSSL,ESP,CSSP, PST and SST parameters
are monitored.
AdventNet Inc. 69

TL1 Tutorial

5.7.1 Performance Management

This section explains how to customize the performance for the AcmeMSU device.

Using Studio to Configure the Performance Parameters of AcmeMSU Device to
be Polled

Adding the Performance parameters to be polled for this application will be with the help of the
AdventNet Web NMS Studio. Follow steps to edit the Polling.conf file and add the nodes and their
details.

Click on the node Services > Performance > Polling.conf.

The Performance service wizard of the Studio provides the facility to create and edit the nodes of the
conf file and its details (which are in XML format). You can add or edit the node or modify the existing
node directly as per your requirement using the UI. The UI is invoked by the right click menu items
Add, Modify, and Delete .

For details of Working with Configuration files of AdventNet Web NMS Studio, refer to the

In this application create three polling objects to represent the port, card, and the node.
Append the following lines to perform the data collection for the port in the Polling.conf file.

<POLLI NG_OBJ ECT name=" acme_msu_por t " >
<MATCH_CRI TERI A>
<MO_PROPERTI ES>
<STRI NG_TYPE pr oper t y=" t ype" condi t i on=" equal s"
val ue=" acme_msu_por t " / >
</ MO_PROPERTI ES>
</ MATCH_CRI TERI A>
<DATA_COLLECTI ON pol l i ngPer i od=" 300" >
<DATA_TO_POLL dat aI dent i f i er =" RTRV- PM: : ${por t Name}: ; "
pr ot ocol =" TL1" t ype=" mul t i pl e" name=" Por t _Dol _I nt eger "
r esponse=" ESL, SESL, LOSSL, ESP, CSSP" / >
</ DATA_COLLECTI ON>
</ POLLI NG_OBJ ECT>

Similarly to collect data for the card the following entries have been appended in the Polling.conf file.

<POLLI NG_OBJ ECT name=" acme_msu_car d" >
<MATCH_CRI TERI A>
<MO_PROPERTI ES>
<STRI NG_TYPE pr oper t y=" t ype" condi t i on=" st ar t sWi t h"
val ue=" acme_msu_car d_" / >
</ MO_PROPERTI ES>
<DATA_TO_POLL dat aI dent i f i er =" RTRV- EQPT: : ${car dName}: ; "
pr ot ocol =" TL1" t ype=" mul t i pl e" name=" Por t _Dol _St r i ng"
r esponse=" PST, SST" / >

AdventNet Inc. 70

TL1 Tutorial

In order to collect data for the node as a whole, append the following entries in the Polling.conf file.

<POLLI NG_OBJ ECT name=" acme_msu_node" >
<MATCH_CRI TERI A>
<MO_PROPERTI ES>
val ue=" acme_msu_node" / >
</ MO_PROPERTI ES>
<DATA_COLLECTI ON pol l i ngPer i od=" 300" pr ot ocol =" TL1" >
<DATA_TO_POLL dat aI dent i f i er =" RTRV- EQPT: : ALL: ; " t ype=" mul t i pl e"
name=" Eqpt _ALL_St r i ng" r esponse=" PST, SST" component I d=" 0" / >
<DATA_TO_POLL dat aI dent i f i er =" RTRV- PM: : ALL: ; " t ype=" mul t i pl e"
name=" Por t _ALL_I nt eger " r esponse=" ESL, SESL, LOSSL, ESP, CSSP"
component I d=" 0" / >

AdventNet Inc. 71

TL1 Tutorial

5.8 Provisioning the AcmeMSU Device

To show the features of the provisioning module two examples have been taken in this tutorial
application.

Modifying the Managed Object properties
Static Cross Connect

To perform any provisioning operation three tasks need to be performed :

You need to write a template which takes care of all the inputs required for the provisioning
operation.
You need to associate the template with a menu, so that it can be invoked from the client.
You require to write a Template filter or Post Provisioning or a Pre Provisioning Filter to
perform additional operations.

In this chapter, the above example tasks are explained in detail.
AdventNet Inc. 72

TL1 Tutorial

5.8.1 Modifying the Managed Object Property

In this example, you will see how you can change some of the managed object properties of a card
through provisioning.

In this tutorial application, you will change the priority of the card and also change the status of the
card, i.e., make the card in service or out of service.

To carryout the provisioning task of Modifying the Managed Object Property, carryout the following
steps.

Writing a Provisioning Template
Creating Pre-Provisioning Filter
Processing the Result Using Post Provisioning Filter


The first step is to write a template. AdventNet provides XML-based Templates. For this application,
an XML Template called ChangeCardType must be created.

For easy development, you can take the file available in the ready-built project and place it under
otherfiles of the application that you are building. The file is available in <Web NMS
Home>/StudioTools/Studio/projects/TL1_Tutorial/otherfiles directory.

Note:The DTD reference cannot be provided in the XML editor that opens in Studio.
Include the reference manually after you create the file. The reference is given in the code
snippet below, but will not be visible when you open in Studio.

Using Studio to Generate Template

Create a file called ChangeCardType in the Other Files and add the nodes and their details.
You can add or edit the node or modify the existing node directly as per your requirement using
the UI. The UI is invoked by the right click menu items Add, Modify, and Delete .
For details of Working with XML files of AdventNet Web NMS Studio, refer to the AdventNet

Add the following node to the ChangeCardType file.

<?xml ver si on=" 1. 0" encodi ng=" UTF- 8" ?>
<! DOCTYPE Templ at e SYSTEM " Templ at e. dt d" >
<Templ at e name=" ChangeCar dType" owner =" r oot " di spl ayFor ms=" t ab"
aut oDer egi st er =" t r ue" >
<St age l abel =" 3#" >


MOFi el d=" car dName" def aul t =" " useI nvent or ySer vi ce=" TopoAPI " / >
MOFi el d=" devi ceName" def aul t =" " useI nvent or ySer vi ce=" TopoAPI " / >
<I nvent or yI nput i d=" 5#" MOName=" $Templ at ePar am$Host " MOFi el d=" CRDSN"
<I nvent or yI nput i d=" 6#" MOName=" $Templ at ePar am$Host " MOFi el d=" pr odNo"
<I nvent or yI nput i d=" 7#" MOName=" $Templ at ePar am$Host " MOFi el d=" CRDREV"
AdventNet Inc. 73

TL1 Tutorial


<For mt i t l e=" Conf i gur at i on" descr i pt i on=" Thi s t empl at e enabl es t o
change t he pr i or i t y and st at us of t he car d" i d=" 3#" >
<User I nput i d=" 1#" name=" car dname" l abel =" CARD NAME"
def aul t =" $I nvent or yI nput $1#" edi t abl e=" f al se" r equi r ed=" f al se" / >
<User I nput i d=" 6#" name=" cr dsn" l abel =" CRDSN"
<User I nput i d=" 7#" name=" mf dat " l abel =" MFDAT"
<User I nput i d=" 8#" name=" pr odno" l abel =" PRODNO"
<User I nput i d=" 9#" name=" cr dr ev" l abel =" CRDREV"
<User I nput i d=" 3#" name=" pr i or i t y" l abel =" PRI ORI TY"
def aul t =" $I nvent or yI nput $2#" edi t abl e=" f al se" r equi r ed=" f al se" >
<Qual i f i er t ype=" choi ce" >
<Enumname=" 1" val ue=" 1" / >
</ Qual i f i er >
</ User I nput >
<User I nput i d=" 5#" name=" st at us" l abel =" PST" def aul t =" I S"
edi t abl e=" f al se" r equi r ed=" f al se" >
<Qual i f i er t ype=" choi ce" >
<Enumname=" I S" val ue=" I S" / >
<Enumname=" OOS" val ue=" OOS" / >
</ Qual i f i er >
</ User I nput >
</ For m>
<Conf i gTask t askName=" Edi t Car dPr ops" i sNewTask=" t r ue"
i sOver wr i t e=" t r ue" i sSequent i al =" f al se" per si st ence=" t r ue"
devi ceResul t =" f al se" i sTempl at e=" f al se" r ol l backNeeded=" f al se"
ver si on=" 1. 0" >
<Pr ot ocol Map name=" t l 1" >
<Devi ce host =" $I nvent or yI nput $4#" por t =" 9099" / >
</ Pr ot ocol Map>
<! - - conf i gur at i on at t r i but es - - >
<At t r i but e i dent i f i er =" ED- EQPT" commandCode=" ED- EQPT" t ar get I D=" "
accessI D=" $I nvent or yI nput $3#" gener al Bl ock=" "
messagePayLoadBl ock=" PRI ORI TY=$User I nput $3#" / >
messagePayLoadBl ock=" PST=$User I nput $5#" / >
</ Conf i gTask>
</ St age>
</ Templ at e>

Creating and Configuring Pre-Provisioning Filter

Create TL1GatewayPreProvisioningFilter.java file using other files option of the Studio project.
Create the file with dummy inputs. Copy the contents from the above given URL and overwrite
completely in the newly created file.


AdventNet Inc. 74

TL1 Tutorial

Configuring the Pre-Provisioning Filter topic

To invoke this class, entry has to be given in the ProvisioningFilters.xml file within the
<PreProvisioningFilters> tag. This file is present under <Project HOME>/WebNMS/conf directory.

. . . . . . . . .
<Pr ePr ovi si oni ngFi l t er s>
<Pr ePr ovi si oni ngFi l t er t empl at e=" AcmeCr ossConnect "
cl ass=" com. advent net . nms. t ut or i al s. t l 1. TL1Gat ewayPr ePr ovi si oni ngFi l t er " / >
<Pr ePr ovi si oni ngFi l t er t empl at e=" ChangeCar dType"
. . . . . . . . . .

Processing the Result Using Post Provisioning Filter

After the provisioning activity gets completed (whether successful or not), one may need to do specific
custom functions to complete the provisioning operation. Post-provisioning filters provide this
capability.

In this tutorial application, if the configuration result is successful it would set the priority of the card.
Also it would set the status of the card. The ChangeCard.java file acts as the PostProvisioning Filter.

Create ChangeCard.java file using other files option of the Studio project.
Create the file with dummy inputs. Copy the contents from the above given URL and overwrite
completely in your file.

Configuring the Post-Provisioning Filter topic

To invoke this class, entry has to be given in the ProvisioningFilters.xml file within the
<PostProvisioningFilters> tag. This file is present under <Project HOME>/WebNMS/conf directory.

. . . . . . . .
<Post Pr ovi si oni ngFi l t er s>
<Post Pr ovi si oni ngFi l t er t empl at e=" ChangeCar dType"
cl ass=" com. advent net . nms. t ut or i al s. t l 1. ChangeCar d" / >
<Post Pr ovi si oni ngFi l t er t empl at e=" i nv_ne_f or m_conf i g_updat e"
cl ass=" t est . Post Pr ovi si oni ngFi l t er Exampl e" / >
</ Post Pr ovi si oni ngFi l t er s>
. . . . . . .

For the details of configuring both the Pre and Post Provisioning Filters, refer the Configuring
Provisioning Filters topic

AdventNet Inc. 75

TL1 Tutorial

5.8.2 Creating a Cross Connection

In this section, you would see the second provisioning example that is establishing static cross
connection between the Channels of a Port.

To carryout the provisioning task of Creating a Cross Connection, carryout the following steps.

Creating Custom Classes for Provisioning

The first step is to write a template. AdventNet provides XML-based Templates. For this application,
an XML Template called AcmeCrossConnect must be created.

For easy development, you can take the file available in the ready-built project and place it under
otherfiles of the application that you are building. The file is available in <Web NMS
Home>/StudioTools/Studio/projects/TL1_Tutorial/otherfiles directory.

Note: The DTD reference cannot be provided in the XML editor that opens in Studio.
Include the reference manually after you create the file. The reference is given in the code
snippet below, but will not be visible when you open in Studio. The files
AcmeCrossConnect.xml, CrossConnectUI.java, CrossConnectUtil.java must be loaded in
OTHERFILES.

Using Studio to Generate Template

Create a file called AcmeCrossConnect in the Other Files and add the nodes and their
details.

You can add or edit the node or modify the existing node directly as per your requirement using
the UI. The UI is invoked by the right click menu items Add, Modify, and Delete .

For details of Working with XML files of AdventNet Web NMS Studio, refer to the AdventNet

Add the following node to the AcmeCrossConnect file.

<Templ at e name=" AcmeCr ossConnect " owner =" r oot " di spl ayFor ms=" t ab"
<Conf i gTask t askName=" AcmeCr ossConnect Task" i sNewTask=" t r ue"
ver si on=" 1. 0" >
<Devi ce host =" l ocal host " por t =" 9099" / >
</ Pr ot ocol Map>
<! - - conf i gur at i on at t r i but es - - >
<At t r i but e i dent i f i er =" ENT- CRS- T0" commandCode=" ENT- CRS- T0"
t ar get I D=" " accessI D=" ST1- 1- 1- 1, ST1- 1- 1- 2" gener al Bl ock=" "
messagePayLoadBl ock=" TYPE=DATA, MODE=2WAY, NAME=CUSTOMER1, PST=I S" / >
</ Conf i gTask>

<MOUpdat e MOName=" Conn1"
AdventNet Inc. 76

TL1 Tutorial

MOCl ass=" com. advent net . nms. t ut or i al s. t l 1. Cr ossConnect i on" i sNew=" t r ue"
when=" onSuccess" >
<Pr oper t y name=" sour ce" val ue=" ST1- 1- 1- 1" / >
<Pr oper t y name=" dest i nat i on" val ue=" ST1- 1- 1- 2" / >
<Pr oper t y name=" bandWi dt h" val ue=" 20MB" / >
<Pr oper t y name=" devi ceName" val ue=" host Name" / >
</ MOUpdat e>
<MOUpdat e MOName=" ST1- 1- 1- 1"
MOCl ass=" com. advent net . t ut or i al s. t l 1. Channel " i sNew=" f al se"
when=" onSuccess" >
<Pr oper t y name=" connect i on" val ue=" unknown" / >
</ MOUpdat e>

</ St age>
</ Templ at e>

Creating Custom Classes for Provisioning
The CrossConnectUI.java and CrossConnectUtil.java are the two classes that are responsible for
the UI representation and establishment of the cross connect.

Create CrossConnectUI.java and CrossConnectUtil.java files using other files option of the Studio
project. Create the files with dummy inputs. Copy the contents from the above given URLs and
overwrite completely in your files.


For the details of configuring both the Pre and Post Provisioning Filters, refer the Configuring
Provisioning Filters topic

AdventNet Inc. 77

TL1 Tutorial

5.8.3 Configuring Provisioning Files

Carryout the following Provisioning Files configurations.

Configuring the Provisioning Filters
Associating the Template With a Menu
Adding Template.dtd file for Provisioning

Configuring the Provisioning Filters
Adding the Provisioning filter used in this application was achieved with the help of the AdventNet
Web NMS Studio. Open the ProvisioningFilters.xml file in the Provisioning Service node and add
the nodes and their details.



Add the following node to the ProvisioningFilters.xml file.

<Pr ovi si oni ngFi l t er s>
<Templ at eFi l t er s>
<Templ at eFi l t er t empl at e=" i nv_ne_f or m_conf i g_updat e"
cl ass=" t est . Templ at eFi l t er Exampl e" / >
</ Templ at eFi l t er s>
<Post Pr ovi si oni ngFi l t er s>
<Post Pr ovi si oni ngFi l t er t empl at e=" ChangeCar dType"
cl ass=" com. advent net . nms. t ut or i al s. t l 1. ChangeCar d" / >
<Post Pr ovi si oni ngFi l t er t empl at e=" i nv_ne_f or m_conf i g_updat e"
cl ass=" t est . Post Pr ovi si oni ngFi l t er Exampl e" / >
</ Post Pr ovi si oni ngFi l t er s>
<Pr ePr ovi si oni ngFi l t er s>
<Pr ePr ovi si oni ngFi l t er t empl at e=" AcmeCr ossConnect "
<Pr ePr ovi si oni ngFi l t er t empl at e=" ChangeCar dType"
<Pr ePr ovi si oni ngFi l t er t empl at e=" i nv_ne_f or m_conf i g_updat e"
cl ass=" t est . Pr ePr ovi si oni ngFi l t er Exampl e" / >
</ Pr ePr ovi si oni ngFi l t er s>
</ Pr ovi si oni ngFi l t er s>

Associating the Template With a Menu
Configure Provisioning Menu

ChangeCardType

To invoke ChangeCardType template from the client you associate it with a menu. For this purpose,
the provmenu.xml file under the <Web NMS Home>mapdata/menus directory is provided.

The entry for associating the menu is provided in the provmenu.xml file .

AdventNet Inc. 78

TL1 Tutorial

Open the provmenu.xml file under <Web NMS HOME>/mapdata/menus directory in a text
editor.

Note: This file is not supported in the Studio, you can create/edit the file only in a text
editor separately.

<MENU name=" MSUPr ov" owner =" r oot " gr oup=" user s" >
<MENU- I TEM name=" Pr ovi si on" >
<J AVA- UI act i on_t ype=" openf r ame"
act i on_val ue=" t est . pr ovi si oni ng. Templ at eNmsFr ame?Host =${name}&
Templ at eName=ChangeCar dType& " >
</ J AVA- UI >
</ MENU- I TEM>
</ MENU>

CrossConnectUI

To invoke CrossConnectUI class from the Client, the crossconnectmenu.xml file has been
provided under the <Web NMS Home>mapdata/menus directory of this tutorial. The entries in this file
are shown below:

<?xml ver si on=" 1. 0" ?>
<! DOCTYPE MENU SYSTEM " menu. dt d" >
<MENU
name=" Cr ossConnect "
owner =" r oot "
gr oup=" user s" >
<MENU- I TEM
name = " Managed Obj ect Pr oper t i es"
act i on_t ype=" f unct i on"
act i on_val ue=" Managed Obj ect Pr oper t i es" >
</ MENU- I TEM>
<MENU- I TEM
name=" Cr ossConnect " >
<J AVA- UI
act i on_t ype=" I NVOKE_CLASS"
act i on_val ue=" com. advent net . nms. t ut or i al s. t l 1. Cr ossConnect UI ?
Host =${obj Name}& par ent Name=${par ent Name}& " >
</ J AVA- UI >
</ MENU- I TEM>
<MENU- I TEM
name=" Al er t s"
act i on_t ype=" openpanel "
act i on_val ue=" Al er t Appl et ?FI LTER_ENTI TY=${obj Name}*" / >
</ MENU>

Configure mapIcon.data file

The pre-built Web NMS Frame (TemplateNmsFrame) is used to open the template. The Host
(managed object which is associated with this menu) and the template that needs to be opened are
passed as arguments to this class.

Open the mapIcon.data file under <Project HOME>/WebNMS/conf directory in a text editor.

The entry for provmenu.xml menu is provided in the mapIcon.data file.
AdventNet Inc. 79

TL1 Tutorial

<DATA TYPE=" acme_msu_car d_st 1"
MAP_FI LTER=" com. advent net . nms. t ut or i al s. t l 1. AcmeMSUMapFi l t er " obj Type=" 200"
menuName=" pr ovmenu" / >

The entry for crossconnectmenu.xml menu is provided in the mapIcon.data file.

<DATA TYPE=" acme_msu_por t _t 1" MAP_FI LTER=" com. acme. msu. MSUMapFi l t er "
menuName=" cr ossconnect menu" obj Type=" 300" i conName=" l ed. png" / >

Adding Template.dtd file for Provisioning

In order to define the contents of the XML files in this case it is provisioning templates, you have to
create a dtd (Document Type Definition) file called the Template.dtd file.

Follow the procedure given below:
Create the Template.dtd file under <Project HOME>/WebNMS/otherfiles directory in a text
editor.
Copy the contents from the URL given above and completely overwrite in the newly created
files.

Warning: The file Template.dtd file must be opened only in a text editor separately. Do
not open and edit this file in Studio.

Bundle the Template.dtd in the Other Resources and set <Project
Home>/WebNMS/provisioningtemplates as Destination directory.

AdventNet Inc. 80

TL1 Tutorial

5.9 Client-Server Communication

5.9.1 Creating Client Server Communication Class

Creating Client Server Communication Classes using Studio
Configuring Client Server Communication Classes

Creating Client Server Communication Class using Studio
The data from the client are sent to the server through the common socket. This is handled in the
AcmeMsuClientSocketConn.java class. For detailed description refer Detailed Description of
Provisioning Client Server Communication Code topic of this document.

Creating Client Server Communication Classes using Studio
AcmeSocketSessionConnBE.java
AcmeSocketServerConnBE.java

Creating Utility Class for Client Server Communication using Studio
TL1SwitchUtil.java

Create all the above classes using other files option of the Studio project. Create the files with
dummy inputs. Copy the contents from the above given URLs and overwrite completely in your files.

Configuring Client Server Communication for Provisioning
Server Configuration - Editing NmsProcessesBE.conf File
The Studio provides a normal text Editor to edit NmsProcessesBE.conf file.

For details of Working with Configuration files of AdventNet Web NMS Studio, refer to the

Click on the node Services > Server_Configuration > NmsProcessesBE.conf.

Parameters of NmsProcessesBE.conf File

In the configuration file, the fully qualified class name of your implementation of
com.adventnet.nms.util.RunProcessInterface should be specified against the keyword
PROCESS, and the parameters for the module have to be specified against the keyword
ARGS.

Make the following entry in the conf file. To keep listening for client requests
AcmeMsuSocketServerConnBE class is started as a process, when the server is started.
For this make an entry in the NmsProcessesBE.conf file.

#j ava com. advent net . nms. t ut or i al s. t l 1. AcmeMsuSocket Ser ver ConnBE
PROCESS
com. advent net . nms. t ut or i al s. t l 1. AcmeMsuSocket Ser ver ConnBE
ARGS NULL

AdventNet Inc. 81

TL1 Tutorial

5.10 Re-branding

In building your AcmeMSU Manager, you may wish to customize the basic user interface functions.
AdventNet Web NMS supports such customization for creating new products in multiple ways. To
illustrate how this can be done, you will make a few changes to the user interface to build an TL1
Element Manager that you will call as AcmeMSU Manager. These are only a subset of the many
changes that can be made to the user interface for specific applications.

Aim

This section explains how to re-brand the application that is built to suit the customers requirements.
Re-branding includes internationalization, changing the name of the product, its version, splash
images, logo images, etc.

For details of Using i18N Editor tool of AdventNet Web NMS Studio, refer to the AdventNet Web

For details of Re-branding the Project of AdventNet Web NMS Studio, refer to the AdventNet Web

Internationalization is achieved using i18N Editor

Step 1: Invoking the I18nEditor

Select the node TL1_User. Proceed to the menu Tools > I18nEditor.

Step 2: Selecting Entities to be Modified

Select EnglishToNative.properties file from <Web NMS Home>/StudioTools/Studio/projects/
TL1_Tutorial/WebNMS/html directory. Right-click on the nodes to be modified and then specify
the new entry for it. The details of the change are explained below.

Change the value of the following Property Keys

<PROMINENT_KEY>AdventNet - AcmeMSU
<PROMINENT_KEY>Web NMS - MSU
<PROMINENT_KEY>Version x.x - 1.0
<PROMINENT_KEY>WebNMS Version - MSU Release 1.0
<PROMINENT_KEY>Product Name - Acme
<PROMINENT_KEY>WebNMS Server modules
started...
- Acme MSU Server modules started
successfully...
<PROMINENT_KEY>AdventNet Inc - Acme Inc

Step 3: Closing the i18N Editor

Select File > Save menu item.
Select File > Exit menu item.

Re-branding is achieved using the Re-branding tool.

The images logopane.png and logo.png in the <Web NMS Home>/images directory
represent the AdventNet company and the Web NMS product respectively in the Client.
Replace these logos with the Acme logo for Re-branding to take effect.

AdventNet Inc. 82

TL1 Tutorial

Invoking the Rebranding tool

Select the node TL1_Tutorial. Proceed to the menu Tools > Rebranding Tool.
Click Browse button besides the parameters node and select the appropriate value.
All the attributes of the node with their default values are displayed.

Change the values for the Entries as specified in the table below:

Re-branded Entities

Entity Name Values
Logo Icon acme.png
Frame Icon logo.png
Splash Image acmemsu.png
Progressbar Foreground Color 0-0-255
Progressbar Background Color 255-255-255
Logo URL www.adventnet.com

Configuring clientparameters.conf
Change the value of the following parameters in clientparameters.conf as specified below: This file
is available in <Project Home>/WebNMS/conf directory. Open the file in an editor and make the
required changes.

INIT_PANEL="TL1-MAP.netmap"
MAP_LAYOUT_CLASSES="com.adventnet.nms.mapui.MSUMapSymbolLayout"

Result

The AdventNet Web NMS is re-branded as AcmeMSU Manager.

The final step toward creating AcmeMSU Manager is to follow in the next chapter - Packaging and
Installation.
AdventNet Inc. 83

TL1 Tutorial

5.11 Creating Menus

Map Menus

You have to create the following Map Menu files for XML Devices.

cardmenu.xml
crossconnectmenu.xml
provmenu.xml
tl1menu.xml

Create these below mentioned XML files using other files option of the Studio project.

Create the files. Add the entries as given in the files from the respective URLs given below and save
the newly created files.

cardmenu.xml
provmenu.xml
tl1menu.xml

AdventNet Inc. 84

TL1 Tutorial

5.12 Packaging the Project

This topic explains the process of compiling and packaging the Studio project.

Compile the Project
Importing Client-side Classes as J AR
Package the Application

Compile the Project
After building the project, save it, and compile it.

Select the File > Save Project menu from the Studio.
Select the Project > Compile menu from the Studio.

Importing Client-side Classes as JAR
You have to pack the client-side classes of this application into a J AR file. Import the J AR into the
Studio Project of this application.

Before importing, you have to create the J AR file.

To create the J AR file, follow the steps given below:

1. Create a J AR file of the client-side classes to pack the classes into NAR.
2. Using Notepad or Word pad application, create a Shell / Batch file with the contents given
below:

cd CLASSES

set AUTH_PATH=com/ advent net / nms/ t ut or i al s/ t l 1
set CLI ENT_PATH=com/ advent net / nms/ mapui

%J AVA_HOME%/ bi n/ j ar - cvf AcmeExt MapAppl et . j ar
%AUTH_PATH%/ AcmeExt MapAppl et . cl ass %AUTH_PATH%/ Cr ossConnect UI . cl ass
%AUTH_PATH%/ Cr ossConnect UI $1. cl ass %AUTH_PATH%/ Cr ossConnect Ut i l . cl ass
%CLI ENT_PATH%/ MSUMapSymbol Layout . cl ass
%CLI ENT_PATH%/ MSUMapSymbol Render er . cl ass >> out put . t xt

3. Save the file named as createClientJar.bat.
4. Execute the bat/sh file to create the J AR. You can find the AcmeExtMapApplet.jar created
under the <Project Home> directory.
For Linux/Solaris system, create the shell file with above content with appropriate modification
and create the J AR file.
5. Now invoke the Deployment Wizard. Run the DeploymentWizard.bat/.sh file in the <Web
NMS Home>/bin directory.
6. In the Deployment Options, select the Deploy Client Application option.
7. Select the AcmeExtMapApplet.jar with the help of Browse button.
8. Select a deployable class type from the combo box. The class to be selected should of type
NMS Panel. Select AcmeExtMapApplet for deployment.
9. Set the destination directory. Enter NMS Panel Key as MapApplet.
10. Click Next button twice and click Finish button.
11. Now the created J AR is available with name of deployable class name selected, in the
destination directory.
AdventNet Inc. 85

TL1 Tutorial

Import this J AR to Studio Project. The menu needed during the time of deployment will be
dummymenu.xml (menu file name), menu name (dummymenu), menu item name (dummy). Select
only the panel menu information screen.

Package the Application
After compiling the project, package the application into a NAR file.

For details of Packaging Studio Applications of AdventNet Web NMS Studio, refer to the AdventNet

Select the Project > Package menu from the Studio.

Package Wizard comes up and carry out the packaging in 8 steps.

1. Project and NAR Details - Enter the Nar File Name as TL1_User.nar, Destination Directory,
and README File Name and click Next button.
2. Select Services - Select the Services you have configured so far in the project and click Next
button.
3. Database Details - Select the database. Enter the database details URL, Driver Name, User
Name, Password, Trans-Connection, and Non Trans-Connection and click Next button.
4. Map and List Icons - Select the Map Icon to represent the type of device (switch, printer
etc).This project uses pc.png located in <Web NMS Home>images directory to represent a
node. Select List Icons to represent severity of the device and click Next button. The icons for
this project are selected from <Web NMS Home>icons directory. Note that, if you enable the
Transparent option, you can just choose one icon and the severity will be rendered
automatically.
5. Other Resources - Select the menus and images needed to bundled in the NAR.
In the Resource Path, select the NmsPanels.conf and in the Target Directory enter ./conf.
Click Add button.
Using the same procedure add Polling.conf file and click Next button.
6. Additional JARs - Add the additional J ARs required and click Next button.
7. Client NARs - Add the required Client NARs imported using Import NAR Wizard and click
Next button.
8. Create NAR - In this project, we have selected Complete Packaging so that files pertaining
to all Services are packaged. Select Selective Packaging option to package the files for the
selected Services only. This will package the dependent files (conf files, classes, jars etc.)
also using certain algorithm. Click Finish.

This will generate a NAR file called TL1_User.nar. You can deploy this NAR directly into Web NMS to
install the application.

Including Menu Files

The files that need to be included for menus are listed below.

File Name Location
cardmenu.xml
provmenu.xml
tl1menu.xml

Source Directory : <Web NMS
Home>/StudioTools/Studio/projects/TL1_Tutorial/WebNMS/mapdata/menus
Destination Directory : <Web NMS
Home>/StudioTools/Studio/projects/TL1_User/WebNMS/mapdata/menus

Include the mentioned files in the specified location and then proceed with packaging the project.

AdventNet Inc. 86

TL1 Tutorial

6.0 Fast Track implementation

This topic will guide you through shortcut to the tutorial, if you are unable to complete the Tutorial
Project.

It will also guide you, if you want to try quick modifications in the available project and check the
results.

Successful completion of Project
After the building of application is complete, compile the project and package it as a NAR file. If you
are able to create the NAR successfully then skip this topic.

Try your requirements quickly in the Project
If you want to try your requirements in the Studio project on your own efforts, then you can use the
Studio project of this application which is bundled in AdventNet Web NMS Studio.

The Studio project of the application comes bundled in AdventNet Web NMS Studio in the following
URL:

<Web NMS Home>/StudioTools/Studio/projects/TL1_Tutorial.proj

In this you have two options:

1. Compiling without modifications.
2. Compiling with modifications.

First option

Open the Project in AdventNet Web NMS Studio.
Compile the Project.
Package the Project as (You will be using the ready built application
TL1_Tutorial1.1.nar) NAR file.

Second Option

Open the project in AdventNet Web NMS Studio.
Carryout the Studio supported changes in the project.
Compile the Project.
Package the Project as (You will be using the ready built application
TL1_Tutorial1.1.nar) NAR file.

Using the instructions given in the Installing the application section, deploy the ready built
application TL1_Tutorial1.1.nar file.
Run the Application.
View the Result. If you have modified the Project, test the application for the desired result.

Note: If you find difficulty in opening the Project, in the Project Properties check Web
NMS Home in the General tab screen and Class Path of various J AR files in the Compiler
tab screen. These will be having the values in which they were developed.
Change both the parameters with respect to your Web NMS Installation.

AdventNet Inc. 87

TL1 Tutorial

7.0 Installation and testing

7.1 Installation Notes

Installing the Application
To install the tutorial application,

Stop the Web NMS Server if it is running.
Run the DeploymentWizard.bat/.sh file under <Web NMS HOME>/bin directory and also
ensure that the server is not running.
Select Install button in the screen.
Click Browse button in the NAR INSTALLER pop-up screen.
Select the TL1_User.nar available in the <Web NMS HOME>/tutorials/tl1_tutorial/ems
directory from the File Chooser pop-up screen and click the Select button.
Click OK button in the NAR INSTALLER pop-up screen. The NmsPwsNarInstaller screen
will pop up.
Select the Application Database (in which you want to run the tutorial) listed from the combo
box.
Click Next button.
In this screen, click Install button.
This will install and show the status in the progress bar. See that the progress is 100%.
Click Close button.
Now the installation is complete. The entries TL1_Tutorial1.0.nar and AcmeExtMapApplet will
be found.
Click Exit button to quit the Deployment Wizard.
Reinitialize Web NMS using reinitialize_nms.bat/.sh. Reinitialize Web NMS Database option
dialog pops up. Select Yes option in the option dialog for reinitializing Web NMS and click OK
in the confirmation dialog.

Caution:
This tutorial will function only if Web NMS is reinitialized. Therefore, after installing the
tutorial, reinitialize Web NMS.
Ensure you use separate Web NMS installation for tutorial application development and
installation.
Do not experiment on Web NMS deployed in real world.

When this tutorial application is installed, the existing files which require changes, from the installed
Web NMS are backed up. However, when you uninstall this tutorial application, the files modified will
be restored from the backup.

Uninstalling the Application
To uninstall the tutorial application,

Run the DeploymentWizard.bat/.sh file under <Web NMS HOME>/bin directory.
In the Uninstall section,
Select the TL1_Tutorial entry
Click Uninstall button in the screen.
On clicking Uninstall button, NmsPwsNarUninstaller screen will pop up.
In that, click Uninstall button.
This will uninstall and show the status in the progress bar. See that the progress is 100%.
Click Close button.
Now the uninstallation is complete.
Click Exit button to quit the Deployment Wizard.
AdventNet Inc. 88

TL1 Tutorial

Modifying the Application
If you want to modify the application and try out other features, you can edit the Studio project of this
application bundled with this tutorial.

You can open the project <Web NMS Home>/StudioTools/Studio/projects/TL1_User.proj in the
AdventNet Web NMS Studio.

Make the changes (supported by the AdventNet Web NMS Studio) to the project as per your
requirement.
Compile the project and package it into NAR.

Now, uninstall the existing installed NAR and install the new NAR generated with your changes.

Caution: Uninstalling the original NAR is mandatory as only one Studio NAR is permitted
to be deployed in AdventNet Web NMS.

For complete details of Working with AdventNet Web NMS Studio, refer to the AdventNet Web NMS

Note: To install the NAR for the Application that you have created, you must select
TL1_User1.0.nar.

Note: After installing the NAR, in the AcmeCrossConnect.xml and
ChangeCardType.xml present under <Web NMS Home>/provisioningtemplates following
tag should be added before the <Template>tag.
The above will enable you to work with the provisioning in the TL1 application.

AdventNet Inc. 89

TL1 Tutorial

7.2 Testing the Application

After installing TL1_User project NAR in Web NMS, set the testing environment as mentioned below.
Once discovery process completes, you will be able to see the ACME MSU device discovered under
the TL1 Panels Map of Client.

Setting Up Environment for Testing

Please follow the listed steps in order to test this application.

Running the Simulator

Starting simulator with single Agent
To start the simulator, open a command line window. Change directory to <Web NMS
Home>/StudioTools/ClientBuilder/bin. Run the startCmdTL1Agent.bat/sh file -c "<Web
NMS Home>/tutorials/tl1_tutorial/AdventNetTL1Simulator/Agents/Acme-MSU/Acme-
MSU.prp" as argument. Give absolute path of the prp file in the argument. The Agent will run
in the default Port 8000.
The command will like the one as given below:

st ar t CmdTL1Agent . bat - c " <Web NMS
Home>/ t ut or i al s/ t l 1_t ut or i al / Advent Net TL1Si mul at or / Agent s/ Acme-
MSU/ Acme- MSU. pr p"

Starting simulator with multiple Agents
To start the simulator, open a command line window. Change directory to <Web NMS
Home>/StudioTools/ClientBuilder/bin. Run the startCmdTL1GNE.bat/sh file -m "<Web NMS
Home>/tutorials/tl1_tutorial/AdventNetTL1Simulator/MultipleAgent1.txt" -p 9091 as
arguments. Give absolute path of the txt file in the argument.
The command for the multiple agents in port 9091 will like the one as given below:

st ar t CmdTL1GNE. bat - m" <Web NMS
Home>/ t ut or i al s/ t l 1_t ut or i al / Advent Net TL1Si mul at or / Mul t i pl eAgent 1. t xt "
- p 9091

To start the Agents in multiple ports, run the above command in two more separate command
line windows. Configure the configuration files of the devices according to your requirement in
the MultipleAgent1.txt, MultipleAgent2.txt, and MultipleAgent3.txt file in the <Web NMS
Home>/tutorials/tl1_tutorial/AdventNetTL1Simulator directory. Configure the configuration
files of Device1 to Device4 in the MultipleAgent1.txt, Device5 and Device6 in the
MultipleAgent2.txt, and Device7 and Device8 in the MultipleAgent3.txt Target IDs.


- p 9092


- p 9093

AdventNet Inc. 90

TL1 Tutorial

Sending Autonomous Messages

To test the autonomous messages from the agent, right-click the TL1Node under TL1-
Panels.
From the Acme-MSU menu item, select ALM Card or ALM Port. This would send an Input
Message based Autonomous Message.
A UI will appear with the response from the agent.

Configure the tl1seed.file

Use the Discovery Configurator tool to configure the tl1seed.file.
Invoke the tool by running the DiscoveryConfigurator.bat file present in the <Web NMS
Home>/bin directory. Select the tl1seed.file.
Enter the IP Address and Port of the Agent. For using the Discovery Configurator tool, refer
to the Configuring Discovery of TL1 Devices in Administrator Guide.
For Terminal Server support, refer to the example_tl1seed.file and configure the tl1seed.file
as explained in the examples of example_tl1seed.file.

Alternate Configuration of tl1seed.file

Configuration of tl1seed.file for single TL1 device

Copy the following into the tl1seed.file.

<TO_DI SCOVERI P
t l 1por t =" 10000"
t ype=" TL1Node"
di ct i onar y=" def aul t . xml "
connect i onHandl er =" com. advent net . nms. t opodb. t l 1.
TL1Bl ankConnHandl er "
MessageRat i onal i zer =" com. advent net . nms. t ut or i al s. t l 1.
MessageRat i onal i zer I mpl " >
<GROUP devi ceGr oupName=" Acme- MSU"
t l 1por t =" 8000"
t ype=" acme_msu_node" >
<l ogi nCommand
command=" ACT- USER: : ROOT: : : PUBLI C; " / >

<st at pol l Command
command=" RTRV- I P: : ETHER: ; " / >


</ GROUP>
</ TO_DI SCOVERI P>

Before the </TL1DISCOVERY> tag.
In the IP tag, modify the ipaddress values as the IP Address of the machines and the
tl1port values as Ports in which the TL1 Agents are running.
AdventNet Inc. 91

TL1 Tutorial

Configuration of tl1seed.file for multiple TL1 devices in multiple ports

Copy the following into the tl1seed.file.

<TO_DI SCOVERI P
t l 1por t =" 9091"
t ype=" TL1Node"
connect i onHandl er = " com. advent net . nms. t opodb. t l 1.
TL1Bl ankConnHandl er " MessageRat i onal i zer =" com. advent net . nms. t ut or i al s.
t l 1. MessageRat i onal i zer I mpl " >
<GROUP devi ceGr oupName=" CHUNGHWA"
t l 1por t =" 9091"
t ype= " acme_msu_node" >
<l ogi nCommand

<GNE i paddr ess=" 192. 168. 4. 103" t l 1por t =" 9091" >
<GATEWAY_PROP
connect i onHandl er = " com. advent net . nms. t opodb.
t l 1. TL1Bl ankConnHandl er " MessageRat i onal i zer =
" com. advent net . nms. t ut or i al s.
<l ogi nCommand

</ GATEWAY_PROP>
<TI D t i d= " Devi ce1" >
<l ogi nCommand
command=" ACT- USER: DEVI CE1: ROOT: : : PUBLI C; " / >
</ TI D>
<TI D t i d=" Devi ce2" >
<l ogi nCommand
</ TI D>
<l ogi nCommand
</ TI D>
<l ogi nCommand
</ TI D>
</ GNE>
<GATEWAY_PROP
connect i onHandl er = " com. advent net . nms. t opodb. t l 1. TL1Bl ankConnHandl er "
MessageRat i onal i zer =" com. advent net . nms. t ut or i al s.
<l ogi nCommand
AdventNet Inc. 92

TL1 Tutorial


</ GATEWAY_PROP>
<l ogi nCommand
</ TI D>
<l ogi nCommand
</ TI D>
</ GNE>
<GATEWAY_PROP
connect i onHandl er = " com. advent net . nms. t opodb.
t l 1. TL1Bl ankConnHandl er " MessageRat i onal i zer =" com. advent net . nms. t ut or i al s.
<l ogi nCommand

</ GATEWAY_PROP>
<l ogi nCommand
</ TI D>
<l ogi nCommand
</ TI D>
</ GNE>
</ GROUP>
</ TO_DI SCOVERI P>

Before the tag </TL1DISCOVERY>.
In the IP tag, modify the ipaddress values as the IP Address of the machines and the
tl1port values as Ports in which the TL1 Agents are running.

Leave the rest of the values as it is.
Save the tl1seed.file.

This tutorial discovers all the TL1 Devices configured in the tl1seed.file and also discovers the
various cards and slots installed in those devices.

If the machines in which the TL1 Simulated Agent and Web NMS are running, are in different
networks, then configure the seed.file as given below.

AdventNet Inc. 93

TL1 Tutorial

Configure the seed.file

Use the Discovery Configurator tool to configure SNMP devices in the seed.file.
Invoke the tool by running the DiscoveryConfigurator.bat/sh file present in the
<Web NMS Home>/bin directory. Select the SNMP Devices.
Enter the IP Address and Port of the Agent. For using the Discovery Configurator
tool, refer to the Configuring Discovery of SNMP Devices topic in Administrator
Guide.

Alternate Configuration of seed.file.

Copy the following into the seed.file.

<TO_DI SCOVERI P>


</ TO_DI SCOVERI P>

Before the </SEED> tag.
Modify the NODE_ID values as the IP Address of the machines in which the TL1
Agents are running and set the NETMASK values accordingly.
Leave the rest of the values as it is.
Save the seed.file.

Testing Output in Web NMS

Start NMS

Before starting the Web NMS server, you have to set the agent. Refer to Setting up
Environment for Testing for details.
Reinitialize and start the Web NMS Server.
Start the NMS Toolkit, by invoking startNmsToolkit.bat/.sh file in the <Web NMS HOME>
directory.
Click Start NMS Server icon in the NMS Toolkit.

Viewing the result

Once the server is up and running, start the J ava client by executing the
startApplicationClient.bat/sh.
OR
Connect a Browser or Application client to the NMS Server in port 9090.

Log in root against user and public against password.

The splash screen that comes up with the progress bar at the bottom will now show ACME
MSU Manager instead of the default splash screen.
In the left-side frame, you will see the map tree. Select TL1-Panels node from the tree.
Check whether ACME MSU Node discovered has been displayed under the TL-Map and TL1-
Topo-Map tree node.

You can also use the HTML client for this application.

Displaying ACME MSU Devices in a separate Map

The TL1-Map / TL1-Topo-Map is a default map in which the ACME MSU Devices will be
displayed. The following image is a snapshot taken from the application, which shows the TL1-
Map, where all the ACME MSU devices are laid out in the map.

Right-click the ACME MSU device nodes and select View Chassis. You can see the Chassis
view of the individual ACME MSU device.
AdventNet Inc. 94

TL1 Tutorial

Chassis View of ACME MSU Device

The Chassis view of ACME MSU device shows the various components of a ACME MSU
device. The screen shot for the same is given below.

The chassis view shows a shelf with eleven slots. Each slot has a card associated with it. You
can find three types of cards, viz., CPU Card, ST1 CSU Card, and ST1 DSX Card. Each card
contains a status icon and one port and CPU Card has no port.

Autonomous Messages from the ACME MSU Device

Send Autonomous Messages from the ACME MSU Agent Simulator, using the Acme-MSU
menu item, select ALM Card or ALM Port. This would send an Input Message based
Autonomous Message. A UI will appear with the response from the agent. Select the TL1-
Events node under Fault Management node in the tree. You can find events displayed in the
right-side frame.

Configuring ACME MSU Device Parameters through Provisioning
Templates

Change Card Type

The configuration application is used to configure ACME MSU device Cards. Right-click on a
Card in the ACME MSU device node in map and select Change Card Type. Following screen
pops up. You can change the PRIORITY and PST (Primary Status) of the card and see the
effect in the Card MO Properties.

AdventNet Inc. 95

TL1 Tutorial

Cross Connect
The configuration application is used to configure a Port of ACME MSU device. Right-click on a
Port of a Card in the ACME MSU device node in map and select Cross Connect. Following
screen pops up. You can connect one of the first five Channels in the Source to one of the first
five Channels in the Destination and the effect cannot be noticed visibly anywhere.

AdventNet Inc. 96

TL1 Tutorial

8.0 Known Issues

When this application is installed, it replaces some of the existing conf files with the new ones needed
for this tutorial. If the user has made any changes in the already existing filters, then the changes will
not take effect during the tutorial session. Though all the original conf files will be restored once the
tutorial is uninstalled.

For the cross connect example currently the cross connection can be established between the first
five channels of a port only. The user has to configure the TL1Simulator by editing the Acme-
MSU_inputcode.xml file and also slightly modify the AcmeMSUDiscFilter.java for establishing more
cross connections.

AdventNet Inc. 97

TL1 Tutorial

9.0 Trouble Shooting Tips

Problem Reason Solution
In the individual Switch
Map, the components
overlap one another
The Layout for the map has not
been set properly.
Check whether the specified layout is
present in the clientparameters.conf
file under <Web NMS HOME>/conf
directory.
No chassis view in the
client.
The response for the command
sent might be timed out. This may
happen if the ManagementServer
does not respond to the command
sent.
Reinitialize and start the server
again.
NAR may not have been installed. Install the TL1_Tutorial1.0.nar
TL1 Agent may not be running. Start the TL1 Agent Simulator.
In the application, the
device is not discovered
as TL1 Device The seed.file and tl1seed.file may
not have been configured.
Configure the seed.file and
tl1seed.file with proper entries.
The entries in the seed.file may
not be retained after starting the
server.
Ensure that the entries in the
seed.file are retained after starting
the server. Event after carrying out the
above procedure, the
device is not discovered
as TL1 Device
The entries in tl1seed.file may be
incomplete or improper.
Ensure none of the entries in
tl1seed.file is incomplete or
improper. Improper or incomplete
entries will stop the discovery
process.
When the Web NMS
Server is started, the
entries that were made in
the seed.file are not
retained.
When the Web NMS Server is
started, improper or incomplete
entries in the seed.file will be
deleted.
Ensure the entries in seed.file are
complete and proper.
The TL1-Panels exist in the
tree even after un-installing
the TL1_Tutorial1.0.nar.
The entries that are made in the
seed.file and tl1seed.file after the
NAR installation are retained even
after un-installing the NAR.
Ensure that the entries that are made
in the seed.file and tl1seed.file after
the NAR installation are removed
after un-installing the NAR.
After un-installing the
TL1_Tutorial1.0.nar, the
entries in the seed.file and
tl1seed.file are not
restored with pre-
installation values.
-
Manually restore the entries in the
seed.file and tl1seed.file to the pre-
installation values.
The Terminal Agent may not be
running.
Start the Terminal Agent, if it is not
running.
The entries for two Terminal
Agents may not be there in the
tl1seed.file
Make the entries for two Terminal
Agents in the tl1seed.file
Started two Terminal
Agents, but only one is
getting discovered.
The device entries may not be
there for two Agents in
MultipleAgent.xml file.
Make the device entries for two
Agents in MultipleAgent.xml file.
Ensure that the tl1seed.file and
MultipleAgent.xml file entries are
matching.
Event after carrying out the
above procedure, the
discovery of two Terminal
Agents takes too long time.
Disabling Local Net discovery and
adding entries in the seed.file will
speed up the discovery of
intended Terminal Agents.
In the seed.file, select the attribute
DISCOVERY_LOCALNET and set
value as false. Make the entries for
two Terminal Agents in the seed.file
AdventNet Inc. 98

TL1 Tutorial

Cross Connection could
not be established.
Out of 20 Channels listed as
Source and Destination Channels,
only the first five can be
configured.
Giving a Connection Name is
Mandatory.
Ensure you select the first five
channels in the Source and
Destination Channels options.
Also ensure that you give a
Connection Name.
It takes a long time for the
major alarms to be
generated when a GAS
Object is disconnected.
-
After selecting Disconnect Device
Ring menu, click Update Status
menu for faster alarm generation.
In the Chassis View, the
colour of the LEDs of the
Card is not getting
changed.
-
Ensure that the Device is not in
Unmanaged State.

AdventNet Inc. 99

TL1 Tutorial

10.0 Description of Custom Code and Class Files

10.1 Description of Discovery Filter Custom Code

10.1.1 Customizing the Discovery Filter Code

In this section, you can look at how to customize discovery to discover TL1 elements of a network
device. You proceed with the example you have modeled earlier and show how to extend the
discovery and populate the database with the network elements you have modeled.

AcmeMSU Discovery Filter
The discovery filter AcmeMSUDiscFilter class, which will try to identify the list of slots, cards, ports,
and channels present in the device.

The filter sends a syncSend request to the device requesting for the inventory details from the device.
This will help us in identifying the list of slots present in the device.

Obj ect i nvObj =nul l ;
Obj ect eqpt Obj =nul l ;

The result Object here is expected to be a TL1ResponseMessage object. If the object is null, then it
means that there has been some problem while communicating to the device for requesting the
inventory. So in that case we do return the object as we obtained.

t l 1t ype = managedObj ect . get User Pr oper t y( " t l 1t ype" ) ;
i nvObj = TL1Swi t chUt i l . syncSendCommand( ( TL1Node) managedObj ect , " RTRV-
I NVENTORY" , " " ) ;
i f ( i nvObj == nul l )
{
r et ur n managedObj ect ;
}

Once the result object from the inventory command is obtained, the filter will send a syncSend request
to the device for the equipment details. The equipment details give the total number of cards in the
device and its health.

eqpt Obj = TL1Swi t chUt i l . syncSendCommand( ( TL1Node) obj , " RTRV- EQPT" , " ALL" ) ;

A check is made if the result object is an instance of TL1ResponceMessage. If true and if the text
block of the resultObject is not null the createTL1Node() method is called where a switch object is
created. The object is added to the database in the addObject method. 0 Also the getPropVector
method is called with the TL1Responce message as the argument. In this method, the response
message is parsed and each of the TL1Line is converted into properties by using the static utility
method convertLineToProperties of TL1SwitchUtil. These properties are stored in a vector and the
vector is returned.

Vect or i nvPr opVect or , eqpt Pr opVect or =nul l ;
AcmeMSUNode devi ce=nul l ;
i f ( i nvObj i nst anceof TL1ResponseMessage)
{
TL1ResponseMessage r epl y=( TL1ResponseMessage) i nvObj ;
i f ( r epl y==nul l | | r epl y. get Text Bl ock( ) ==nul l )
{
r et ur n nul l ;
}
devi ce=cr eat eTL1Node( managedObj ect ) ;
addObj ect ( devi ce) ;
AdventNet Inc. 100

TL1 Tutorial

i nvPr opVect or = get Pr opVect or ( r epl y) ;
}
el se
{
Syst em. out . pr i nt l n( " SOME Ot her obj ect obt : " + i nvObj . get Cl ass( ) . get Name( )
+ " VALUE: " + i nvObj ) ;
r et ur n nul l ;
}

Creating Custom Map and associating it with the Switch are dealt in later topics.
The createShelf method, with the switch object as the parameter, will be called to create Shelf
Object, after creating a switch object and associating it with a map. In this method the name and
serialno of the shelf is set and to obtain the container relationship, the switch object is associated as
the parent key.

AcmeMSUShel f shel f =cr eat eShel f ( devi ce) ;
addObj ect ( shel f ) ;
i f ( eqpt Obj i nst anceof TL1ResponseMessage)
{
TL1ResponseMessage r epl y=( TL1ResponseMessage) eqpt Obj ;
i f ( r epl y! =nul l && r epl y. get Text Bl ock( ) ! =nul l )
{
eqptPropVector=getPropVector(reply);
}
}

After adding the shelf, the property vector is obtained for the RTRV-EQPT result object similar to the
inventory result object, i.e. by calling the getPropVector method.

eqpt Pr opVect or =get Pr opVect or ( r epl y) ;

The other components such as slots, cards, ports and channels are created by calling the addSlots,
addCard, addPort, and the addChannel method. The following chapters describe these methods in
detail.

The filter creates AcmeMSUNode object based on the properties of the TL1Node discovered.

For example, TL1Line could be

"ST1-1::CRDTYPE=ST1,CRDSN=23,MFDAT=01/25/2000,PRODNO=712800,CRDREV=A0"

The following lines of code convert the response message to a property vector.
The codes appearing hereafter are appended after the
//<End_filterObject_ManagedObject_TopoAPI> tag in the file.

pr i vat e Vect or get Pr opVect or ( TL1ResponseMessage r esp)
{
Vect or sl ot Names = r esp. get Text Bl ock( ) . get TL1Li neLi st ( ) ;
Vect or i nvent or y=new Vect or ( ) ;
f or ( i nt i = 0; i < sl ot Names. si ze( ) ; i ++)
{
TL1Li ne cur r Li ne = ( TL1Li ne) sl ot Names. el ement At ( i ) ;
i f ( ( pr op == nul l ) | | ( pr op. si ze( ) == 0) ) cont i nue;
i nvent or y. add( i , pr op) ;
}
r et ur n i nvent or y;
}
AdventNet Inc. 101

TL1 Tutorial

10.1.2 Adding Device Components - Part1

After obtaining the equipment property vector, a check is made if the invPropVector and
eqptPropVector are not null. This check is made because if the response for the RTRV-EQPT is null,
then we add empty slots corresponding to the details obtained from the RTRV-INVENTORY
command.

i f ( i nvPr opVect or ! =nul l && eqpt Pr opVect or ! =nul l )
{
{
Pr oper t i es pr op = ( Pr oper t i es) i nvPr opVect or . el ement At ( i ) ;
addSl ot s( i +1, devi ce, shel f , pr op, eqpt Pr opVect or ) ;
}
}
el se
{
{
Pr oper t i es i nvPr op=( Pr oper t i es) i nvPr opVect or . el ement At ( i ) ;
addEmpt ySl ot s( shel f , i nvPr op, i +1) ;
}
}
managedObj ect =nul l ;

In order to add the slots, the filter traverse the invPropVector and for each of the properties the filter
calls the addSlots method. The arguments for the addSlots method being the slotNo, tl1switch, shelf,
prop, and eqptPropVector. This method sets the name, the state (empty/Access), the display name
and the parent key. The parent key for slot is assigned as shelf. The slot object is added to the
database by calling the addObject method. After adding the slot object, the filter obtains the card for
this particular slot. This is done because there are certain restrictions in the TL1 Device like the first
slot is meant for CPU card only. Also this is helpful for leaving the slots empty when there is no
response for the card in the RTRV-EQPT command. Once the filter has the card name, the filter
traverses the eqptVector in order to look for the particular card. Then the filter calls the addCard
method with the slot, device(TL1Switch), eqptProp, and the invProp as the parameters.

pr i vat e voi d addSl ot s( i nt sl ot No, AcmeMSUNode devi ce, AcmeMSUShel f shel f ,
Pr oper t i es i nvPr op, Vect or
eqpt Pr opVect or )
{
sl ot . set Name( shel f . get Name( ) +" _" +i nvPr op. get Pr oper t y( " SLOTNAME" ) ) ;
sl ot . set Sl ot Name( sl ot Name) ;
St r i ng sl ot Name=i nvPr op. get Pr oper t y( " SLOTNAME" ) ;
St r i ng name=" " ;
i f ( sl ot Name. equal sI gnor eCase( " SLT- 1" ) )
name=" CPU- 1" ;
el se
{
St r i ng numSt r = sl ot Name. subst r i ng( sl ot Name. i ndexOf ( " - " ) +1) ;
name = " ST1- " +St r i ng. val ueOf ( num- 1) ;
}
f or ( i nt i =0; i <eqpt Pr opVect or . si ze( ) ; i ++)
AdventNet Inc. 102

TL1 Tutorial

{
Pr oper t i es eqpt Pr op = ( Pr oper t i es) eqpt Pr opVect or . el ement At ( i ) ;
i f ( car dName. equal sI gnor eCase( name) )
{
addCar d( sl ot , devi ce, eqpt Pr op, i nvPr op) ;
br eak;
}
}
}

The addCard method sets different parameters for the card. Each attribute of the invProp(CRDTYPE,
MFDAT, CRDSN, etc.) is set as a card parameter. There is a special parameter ST1Type for the card
because the ST1 card can be of two types, i.e., DSX or CSU. Since the card object has been added,
the filter sets the state for the slot as Access. As the CPU card does not contain any port, there is a
boolean variable bool for making this check. In order to show the status of the card, there is a check
for the PST attribute in the eqptProp. The severityForCardStatus method is called which returns the
corresponding severity integer of the PST attribute. When the value of the PST attribute is either
OOSMT or RESET the card is unmanaged. For all other values, the corresponding severity is set.
Once all the parameters have been set, the card object is added to the database by calling the
addObject method.

Other than the CPU card for all the other cards, the addPort method is called, with the device
(TL1Switch) and card as the input parameters.

publ i c st at i c voi d addCar d( AcmeMSUSl ot sl ot , AcmeMSUNode devi ce,
Pr oper t i es eqpt Pr op, Pr oper t i es i nvPr op, TopoAPI api ) t hr ows
{
bool ean bool =t r ue;
i f ( eqpt Pr op. get Pr oper t y( " f i el d0: 0" ) . st ar t sWi t h( " CPU" ) )
{
bool =f al se;
}
AcmeMSUCar d car d = new AcmeMSUCar d( ) ;
car d. set Name( sl ot . get Name( ) +" _" +car dName) ;
car d. set Di spl ayName( car dName) ;
car d. set Devi ceName( devi ce. get Name( ) ) ;
car d. set Type( " acme_msu_car d_" +i nvPr op. get Pr oper t y( " CRDTYPE" ) .
t oLower Case( ) ) ;
car d. set CRDSN( i nvPr op. get Pr oper t y( " CRDSN" ) ) ;
car d. set MFDAT( i nvPr op. get Pr oper t y( " MFDAT" ) ) ;
car d. set Pr odNo( i nvPr op. get Pr oper t y( " PRODNO" ) ) ;
car d. set CRDREV( i nvPr op. get Pr oper t y( " CRDREV" ) ) ;
car d. set Pr i or i t y( eqpt Pr op. get Pr oper t y( " PRI ORI TY" ) ) ;
car d. set Car dName( car dName) ;
i f ( ( t l 1t ype ! = nul l ) && ( t l 1t ype. equal s( " t l 1node_gne" ) ) )
{
car d. set User Pr oper t y( " t l 1car dt ype" , " t l 1car d_gne" ) ;
}
i f ( i nvPr op. get Pr oper t y( " CRDTYPE" ) . equal sI gnor eCase( " ST1" ) )
{
car d. set ST1Type( eqpt Pr op. get Pr oper t y( " TYPE" ) ) ;
}
el se
{
car d. set ST1Type( " N/ A" ) ;
}
AdventNet Inc. 103

TL1 Tutorial

car d. set Par ent Key( sl ot . get Name( ) ) ;
addObj ect ( car d) ;
St r i ng[ ] car dChi l d = {car d. get Name( ) };
sl ot . addChi l dr enKeys( car dChi l d) ;
sl ot . set St at e( " Access" ) ;
t r y {
}
cat ch
{
Syst em. er r . pr i nt l n( " Except i on whi l e updat i ng t he obj ect : "
+sl ot . get Name( ) +" \ n" + ut e) ;
t hr ow ut e;
}
{
Syst em. er r . pr i nt l n( " Except i on whi l e updat i ng t he obj ect : " +
sl ot . get Name( ) +" \ n" +nse) ;
t hr ow nse;
}
{
sl ot . get Name( ) +" \ n" +r e) ;
}
cat ch ( com. advent net . nms. ut i l . AccessDeni edExcept i on ade)
{
sl ot . get Name( ) +" \ n" +ade) ;
ade. pr i nt St ackTr ace( ) ;
}
cat ch( Except i on e)
{
Syst em. er r . pr i nt l n( " Er r or whi l e updat i ng obj ect " +sl ot ) ;
e. pr i nt St ackTr ace( ) ;
}
i f ( bool ) / / Thi s check i s made si nce t her e i s no por t f or CPU car d
{
addPor t ( devi ce, car d, api ) ;
}

}

In the addPort method, the name, displayName, portNo, portName, deviceName, and the parent key
for the port object are set. In this tutorial application, it is assumed that there is only one port per card.
The addObject method adds the port object to the database.

For each port, the filter will add Channels by calling the addChannel method.

pr i vat e voi d addPor t ( AcmeMSUNode devi ce , AcmeMSUCar d car d)
{
AcmeMSUPor t por t = new AcmeMSUPor t ( ) ;
i nt por t No = 1; / / Cur r ent l y onl y one por t i s assumed per car d.
por t . set Name( car d. get Name( ) +" - " +por t No) ;
AdventNet Inc. 104

TL1 Tutorial

por t . set Di spl ayName( car d. get Di spl ayName( ) +" - " +por t No) ;
por t . set Por t No( por t No) ;
por t . set Por t Name( car d. get Di spl ayName( ) +" - " +por t No) ;
por t . set Devi ceName( devi ce. get Name( ) ) ;
por t . set Par ent Key( car d. get Name( ) ) ;
addObj ect ( por t ) ;
i f ( t l 1t ype ! = nul l && t l 1t ype. equal s( " t l 1node_gne" ) )
{
por t . set User Pr oper t y( " t l 1por t t ype" , " t l 1por t _gne" ) ;
}
f or ( i nt i =0; i <5; i ++)
{
addChannel ( i +1, por t , devi ce) ;
}
}

In the addChannel method, the name, channel number, and the parentKey are set for the Channel
and added to the database.

pr i vat e st at i c voi d addChannel ( i nt chNo , AcmeMSUPor t por t ,
AcmeMSUNode devi ce) t hr ows
{
Channel channel = new Channel ( ) ;
St r i ng channel Name = por t . get Por t Name( ) +" - " +chNo;
channel . set Name( devi ce. get Name( ) +channel Name) ;
channel . set Di spl ayName( channel Name) ;
St r i ng por t Name=por t . get Name( ) ;
channel . set Channel Number ( chNo) ;
channel . set Par ent Key( por t Name) ;
addObj ect ( channel ) ;
}
AdventNet Inc. 105

TL1 Tutorial

10.1.3 Adding Device Components - Part2

The Managed Object is added to the database and this method is database transaction compliant.
This will catch the exceptions occurring while adding the Managed Object to the database.

pr i vat e st at i c voi d addObj ect ( ManagedObj ect obj ) t hr ows
{
t r y
{
api . addObj ect ( obj ) ;
}
cat ch
{
obj . get Name( ) +" \ n" +ut e) ;
t hr ow ut e;
}
{
obj . get Name( ) +" \ n" +nse) ;
t hr ow nse;
}
{
obj . get Name( ) +" \ n" +r e) ;
}
cat ch( Except i on exp)
{
}
}

pr i vat e voi d addEmpt ySl ot s( AcmeMSUShel f shel f , Pr oper t i es
i nvPr op, i nt sl ot No) t hr ows
{
St r i ng shel f Name = shel f . get Name( ) ;
sl ot . set Name( shel f Name+" _" +i nvPr op. get Pr oper t y( " SLOTNAME" ) ) ;
}

AdventNet Inc. 106

TL1 Tutorial

pr i vat e AcmeMSUNode cr eat eTL1Node( ManagedObj ect obj )
{
AcmeMSUNode devi ce = new AcmeMSUNode( ) ;
devi ce. set Name( obj . get Name( ) ) ;
devi ce. set Locat i on( " Cal i f or ni a" ) ;
devi ce. set Cont act ( " SysAdmi n" ) ;
devi ce. set Pr oper t i es( obj . get Pr oper t i es( ) ) ;
r et ur n devi ce;
}

pr i vat e AcmeMSUShel f cr eat eShel f ( AcmeMSUNode devi ce)
{
AcmeMSUShel f shel f =new AcmeMSUShel f ( ) ;
shel f . set Name( devi ce. get Name( ) +" _Shel f 1" ) ;
shel f . set Par ent Key( devi ce. get Name( ) ) ;
shel f . set Ser i al no( devi ce. get Name( ) +" Bank1" ) ;
r et ur n shel f ;
}
AdventNet Inc. 107

TL1 Tutorial

10.2 Description of Map related files

10.2.1 Description of AcmeMSU Device Map Layout Class

In setting up the custom Chassis map to represent the AsmeMSUNode, you will be using a custom
layout.

This layout supports the placement of shelf, slots, cards, and ports on the map for the switch. Since
the simple layouts such as grid, ring, etc. are insufficient for this purpose, you will implement a new
layout class and plug it into the Web NMS maps. Also this layout relies on the map container
hierarchy, which you have implemented in the map filter MSUMapFilter, for laying out the switch
components. You have associated different layouts for the shelf, slots, cards, and ports based on the
objTypes that are set in the mapIcon.data file. The doLayout method accepts mapSymbol vector,
the width and height of the MapContainerComponent and the objType as the input parameters.

Any custom layout should implement the AutoLayout interface and overwrite the layoutMap method.

The basic idea behind this layout is to get the mapContainer width and height, i.e., vw and vh. Then
get the total number of symbols that will be appearing on this mapContainer, i.e., calculate the size of
the symbols vector. Once you have the total width of the container and the number of components in
that container, you can easily calculate the size of each component. Once the individual component
size is obtained, assign this size to the MapSymbolComponent. One thing that is to be kept in mind is
that, since the parent-child containment relationship is set for the device component containers, the
size of MapContainerComponent will keep differing, i.e., when you lay out the slots, the
MapContainerComponent will be the shelf and for cards it will be the slot. So, while laying out the
slots, the width and height of the MapContainerComponent would be the size of the shelf.

To leave some gap on the sides, a constant is added to the number of symbols.

publ i c voi d l ayout Map( MapCont ai ner Component model , i nt dept h)
{
Vect or symbol s = ( Vect or ) model . get Symbol s( ) ;
i nt numSymbol s = symbol s. si ze( ) ;
i nt vw = model . get Wi dt h( ) ;
i nt vh = model . get Hei ght ( ) ;
i f ( ( numSymbol s <= 0) | | ( vw <= 0) | | ( vh <= 0) )
r et ur n;

MapSymbol Component symb = ( MapSymbol Component )
symbol s. el ement At ( 0) ;
i nt t ype = symb. get Obj Type( ) ;
doLayout ( symbol s, vw, vh, t ype) ;

}

pr i vat e voi d doLayout ( Vect or symbol s, i nt vw, i nt vh, i nt t ype)
{
i nt num= symbol s. si ze( ) ;
i f ( t ype==400) / / Layout f or shel f
{
f or ( i nt i =0; i <num; i ++)
{
MapSymbol Component obj = ( MapSymbol Component )
symbol s. el ement At ( i ) ;

obj . di m. wi dt h=vw;
obj . di m. hei ght =vh;
obj . p=new Poi nt ( 0, 0) ;
}
AdventNet Inc. 108

TL1 Tutorial

}
i f ( t ype==100)
{
/ / The i dea behi nd di vi di ng by +. 5 i s t o di vi de l eave some
gap on t he l ef t
/ / and r i ght si de of t he shel f , spanni ng 1 car d wi dt h.
i nt sl ot Wi dt h=( i nt ) ( vw/ ( num+0. 5) ) ;
i nt sl ot Hei ght =vh*2/ 3;
i nt par t Wi dt h = 0; / / Denot es t he par t i t i on wi dt h
i nt l ef t Gap = ( vw- ( ( num*sl ot Wi dt h) +( ( num-
1) *par t Wi dt h) ) ) / 2;
f or ( i nt i =0; i <num; i ++)
{
MapSymbol Component
obj =( MapSymbol Component ) symbol s. el ement At ( i ) ;
obj . di m. wi dt h = sl ot Wi dt h;
obj . di m. hei ght = sl ot Hei ght ;
obj . p = new
Poi nt ( ( l ef t Gap+i *( obj . di m. wi dt h+par t Wi dt h) ) , ( ( vh- obj . di m. hei ght ) / 2) ) ;
}

}
i f ( t ype==200)
{
i f ( num! =1)
{
Syst em. out . pr i nt l n( " Number of car ds not equal t o 1" ) ;
}
el se
{
f or ( i nt i =0; i <num; i ++)
{
St r i ng st 1Type = obj . get User Pr oper t y( " st 1t ype" ) ;
i f ( st 1Type. equal sI gnor eCase( " DSX" ) )
{
obj . set I conName( " cl ki o. png" ) ;
}
i f ( st 1Type. equal sI gnor eCase( " CSU" ) )
{
obj . set I conName( " t ei o. png" ) ;
}
obj . di m. wi dt h = vw;
obj . di m. hei ght = vh;
obj . p = new Poi nt ( 0, 0) ;
}
}
}
i f ( t ype==300)
{
i nt car dWi dt h = vw*5/ 6;
/ / The i dea behi nd di vi di ng by +2 i s t o di vi de l eave some
gap on t he l ef t
/ / and r i ght si de of t he shel f , spanni ng 1 car d wi dt h.
i nt car dHei ght = ( i nt ) vh/ ( 20) ; / / The LED i s exepect ed t o
be 1/ 20 of t he car d hei ght .

i f ( car dHei ght < car dWi dt h)
{
AdventNet Inc. 109

TL1 Tutorial

car dHei ght = car dWi dt h*2/ 3;
}
el se
{
car dWi dt h = car dHei ght ;
}
f or ( i nt i =0; i <num; i ++)
{
i f ( obj . get Obj Type( ) == 0) cont i nue;

obj . set Wi dt h( car dWi dt h) ;
obj . set Hei ght ( car dHei ght ) ;
obj . set X( vw/ 2 - obj . get Wi dt h( ) / 2) ;
obj . set Y( ( i nt ) ( obj . get Hei ght ( ) *2. 5) ) ;
}
}

}

In the getName method, the class returns a string that specifies the name of this layout.

publ i c St r i ng get Name( )
{
r et ur n " t l 1_component s" ;
}
AdventNet Inc. 110

TL1 Tutorial

10.2.2 Description of AcmeMSU Device Map Symbol
Renderer Class

Once you have written the layout for the application, the next step is to write a renderer. A renderer as
its name suggests renders the layout, i.e., associates certain label string for each component, marking
the component when the user selects a particular component, and painting the component with
different colors.

This renderer extends the MapSymbolRendererImpl class and overrides the paintIcon,
paintShapeAndSeverity, and paintLabelString methods.

The paintIcon method paints four dark squares at each corner of the component to show that the
component is selected. The following lines show the code for achieving this.

i f ( sel ect ed)
{
g. set Col or ( Col or . bl ack) ;
i nt or gsi ze = d. hei ght ;
i f ( d. wi dt h < or gsi ze)
{
or gsi ze = d. wi dt h;
}
i nt mar kHt = or gsi ze/ 5;
i f ( mar kHt < 5) mar kHt = 5;
g. f i l l Rect ( p. x- mar kHt , p. y- mar kHt , mar kHt , mar kHt ) ;
g. f i l l Rect ( p. x+d. wi dt h, p. y- mar kHt , mar kHt , mar kHt ) ;
g. f i l l Rect ( p. x- mar kHt , p. y+d. hei ght , mar kHt , mar kHt ) ;
g. f i l l Rect ( p. x+d. wi dt h, p. y+d. hei ght , mar kHt , mar kHt ) ;
}

The paintShapeAndSeverity method associates an icon for the shelf and also paints the background
of the cards and ports to show their status. The cards and ports are differentiated based on their
objTypes which are set in the mapIcon.data file. Since the NMS automatically paints the background
of the components based on their status, use this color (the bg parameter of this method) to set the
color of the component.
For showing the LEDs for port and card keep the LED portion in the card image and the port image as
transparent. This is a unique feature of the Application. When painting the background, the
corresponding color becomes automatically visible. Sample code for the card is shown below. Similar
approach is taken for the port.

el se i f ( t ype == 200) / / I f i t i s a car d
{
g. set Col or ( bg) ;
g. f i l l Rect ( p. x, p. y, d. wi dt h, d. hei ght ) ;
}

The paintLabelString method calls the super class paintLabelString method to associate a label for
each component except the shelf and the port.

i f ( t ype==200)
{
f ont = new Font ( s0, Font . BOLD| Font . PLAI N, mapSymbol . get Wi dt h( ) / 5) ;
g. set Font ( f ont ) ;
super . pai nt Label St r i ng( g, mapSymbol , s0, p, f ont ) ;
}
AdventNet Inc. 111

TL1 Tutorial

10.2.3 Description of AcmeMSU Map Applet Extension
Class with Complete Code

package com. advent net . nms. t ut or i al s. t l 1;
i mpor t com. advent net . nms. mapui . MapAppl et ;
i mpor t com. advent net . nms. mapui . Edi t abl eMap;
publ i c cl ass AcmeExt MapAppl et ext ends MapAppl et
{
publ i c AcmeExt MapAppl et ( )
{
}
publ i c voi d const r uct UI ( Edi t abl eMap emap)
{
super . const r uct UI ( emap) ;
i f ( cur r ent MapVi ewed. st ar t sWi t h( " Acme" ) )
{
emap. hi deTool Bar ( ) ;
}
}
}
AdventNet Inc. 112

TL1 Tutorial

10.3 Description of Fault Management related files

10.3.1 Description of MSU Event Correlation Filter Class

AdventNet Web NMS supports two forms of event correlation, time-correlation and grouping of failed
elements.

The first results in multiple events over time on any given component being correlated to a
single alert in Web NMS.
The second relates multiple alerts into an alert group, based on the alert group field in the
alert.

For grouping of failed components, we use the Alert group field to relate alerts on multiple
components where the failures have a common cause. The user sees only one alert from each group
and can see the failures or alerts in that group when he opens up the alert details.

Since Web NMS is not aware of the slot, card, port configuration in the device, it cannot correlate an
autonomous message from the device to the respective card / slot / port. For this purpose we write an
event filter. In this Event Filter we are doing three jobs.

Identifying the corresponding slot/ card/ port to be updated based on the Autonomous
Messages.
Parsing and retrieving the status of the object from the text block and setting the correct
severity for the event.
Generating an event for this particular card or port.

First, we check for the events which belong to the autonomous message category. From this event
the autonomous message is extracted by using the getUserProperty method. Some special
characters are removed from this autonomous message by calling the findAndReplace method and
the parseAutonomousMessageText method is called with the event and the message as the
parameters.

publ i c Event f i l t er ( Event event )
{
St r i ng cat egor y = event . get Cat egor y( ) ;
i f ( cat egor y == nul l ) r et ur n event ;
i f ( cat egor y. equal sI gnor eCase( " t opol ogy" ) )
{
TopoAPI t api = ( TopoAPI ) NmsUt i l . get API ( " TopoAPI " ) ;
i f ( t api == nul l ) r et ur n event ;
St r i ng obj name = event . get Sour ce( ) ;
i f ( obj name == nul l ) r et ur n event ;
ManagedObj ect obj = nul l ;
t r y {
obj = t api . get ByName( obj name) ;

} cat ch ( Except i on r ex)
{
r et ur n event ;
}
i f ( obj == nul l ) r et ur n event ;
i f ( ( obj i nst anceof AcmeMSUNode) | |
( obj i nst anceof AcmeMSUShel f ) | |
( obj i nst anceof AcmeMSUSl ot ) | |
( obj i nst anceof AcmeMSUCar d) | |
( obj i nst anceof AcmeMSUPor t ) | |
( obj i nst anceof Channel ) ) {
event . set User Pr oper t y( " agent Pr ot ocol " , " TL1" ) ;
r et ur n event ;
AdventNet Inc. 113

TL1 Tutorial

}
/ / r et ur n event ;
}
el se i f ( cat egor y. equal sI gnor eCase( " TL1Aut onomousMessage" ) )
{
St r i ng aut oMessage = event . get Devi ceNot i f i cat i on( ) . t oSt r i ng( ) ;
i f ( aut oMessage ! = nul l )
{
aut oMessage = f i ndAndRepl ace( aut oMessage, " <CR>\ n" , " \ r " ) ;
aut oMessage = f i ndAndRepl ace( aut oMessage, " <LF>" , " \ n" ) ;
event = par seAut onomousMessageText ( event , aut oMessage) ;
}
}
r et ur n event ;
}

In the parseAutonomousMessageText method we use the TL1AutonomousMessageParser class to
parse the response.

publ i c com. advent net . nms. al er t db. Al er t f i l t er ( com. advent net .
nms. al er t db. Al er t a) {
r et ur n a;
}
pr i vat e Event par seAut onomousMessageText ( Event event , St r i ng t ext )
{
t r y
{
TL1Aut onomousMessagePar ser par ser =
new TL1Aut onomousMessagePar ser ( t ext ) ;
TL1Text Bl ock t ext Bl k = par ser . get Text Bl ock( ) ;
Vect or vect = t ext Bl k. get TL1Li neLi st ( ) ;
St r i ng host = event . get Sour ce( ) ;
Event API evAPI = ( Event API ) NmsUt i l . get API ( " Event API " ) ;
f or ( i nt i = 0; i < vect . si ze( ) ; i ++)
{
TL1Li ne cur r Li ne = ( TL1Li ne) vect . el ement At ( i ) ;
St r i ng car dName = pr op. get Pr oper t y( " f i el d0: 0" ) ;
St r i ng sl ot Name=" " ;
i f ( car dName. equal sI gnor eCase( " SYS" ) | | car dName.
equal sI gnor eCase( " DOWNLOAD COMPLETE" ) )
{
r et ur n event ;
}

Here, we are doing the first job, i.e., getting the card/port name from the Autonomous message and
then getting the corresponding managed object for that particular card or port by using the
getByName method of Topo API.

i f ( car dName. st ar t sWi t h( " CPU" ) )
{
sl ot Name = " SLT- 1" ;
}
el se
{
St r i ng numSt r = car dName. subst r i ng( car dName. i ndexOf ( " -
" ) +1) ;
i f ( numSt r . i ndexOf ( " - " ) ! = - 1)
AdventNet Inc. 114

TL1 Tutorial

{
numSt r =numSt r . subst r i ng( 0, numSt r . i ndexOf ( " - " ) ) ;
}
sl ot Name = " SLT- " +St r i ng. val ueOf ( num+1) ;
}
St r i ng sl t Name = host +" _" +" Shel f 1" +" _" +sl ot Name;
St r i ng host Name =
host +" _" +" Shel f 1" +" _" +sl ot Name+" _" +car dName;
ManagedObj ect sl ot Obj = api . get ByName( sl t Name) ;
ManagedObj ect obj = api . get ByName( host Name) ;

Here, we are doing the second job mentioned, i.e., Getting the equivalent severity from the message
and accordingly set the status of the card/port. But before setting the severity we check if the
managed object is an instance of AcmeMSUCard or PortInTL1Card and proceed accordingly.

When the managed object is an instance of AcmeMSUCard, you get the severity string and the failure
type where severity string represents the level of severity and the failure type (the cause of failure).
When the failure type is CRDRMVD, i.e., when the card is removed the particular card is deleted from
the database. Correspondingly the card gets removed in the chassis view as the map database is
notified about the card being removed from the topology database.

This scenario is shown in the image given below:

Note: In the above image, ST1 cards 7 and 10 are removed.

For all the other cases, we set the status of the card based on the severityStr.

Once the status is set, the third work of the event filter is accomplished, i.e., an event is created and
added to the EventAPI.

AdventNet Inc. 115

TL1 Tutorial

i f ( obj i nst anceof AcmeMSUCar d)
{
AcmeMSUSl ot sl ot = ( AcmeMSUSl ot ) sl ot Obj ;
AcmeMSUCar d car d = ( AcmeMSUCar d) obj ;
St r i ng sever i t ySt r = pr op. get Pr oper t y( " f i el d1: 0" ) ;
St r i ng f ai l ur eType = pr op. get Pr oper t y( " f i el d1: 1" ) ;
i nt sev = get EqvSever i t y( sever i t ySt r ) ;
i f ( f ai l ur eType. equal sI gnor eCase( " CRDRMVD" ) &&
sever i t ySt r . equal sI gnor eCase( " MJ " ) )
{
St r i ng sevSt r =
Sever i t yI nf o. get I nst ance( ) . get Name( sev) ;
I nput Event i nEvent = new I nput Event
( car d. get Cl assname( ) ,
" The car d " + car d. get Name( ) +" i s r emoved" ,
sevSt r , car d. get Name( ) ,
car d. get Name( ) , car d. get Name( ) ) ;
i nEvent . set User Pr oper t y( " agent Pr ot ocol " , " TL1" ) ;
i nEvent . set Gr oupName( car d. get Devi ceName( ) ) ;
t r y
{
evAPI . addEvent ( i nEvent ) ;
}cat ch( Remot eExcept i on r ex)
{
Syst em. out . pr i nt l n( " Event coul d not be
gener at ed f or f ai l ed car d" ) ;
}
api . del et eObj ect AndSubEl ement s( car d. get Name( ) ) ;
t r y
{
}cat ch( AccessDeni edExcept i on e)
{
Syst em. er r . pr i nt l n( " Er r or whi l e
updat i ng t he car d obj ect " ) ;
}
}

el se
{
St r i ng sevSt r =
( car d. get Cl assname( ) , " The car d " + car d. get Name( ) +" has f ai l ed" ,
sevSt r , car d. get Name( ) , car d. get Name( ) ,
car d. get Name( ) ) ;
i nEvent . set Gr oupName( car d. get Devi ceName( ) ) ;
t r y
{
{
Syst em. out . pr i nt l n( " Event coul d not
be gener at ed f or f ai l ed car d" ) ;
}
}
}
AdventNet Inc. 116

TL1 Tutorial

i f ( obj i nst anceof AcmeMSUPor t )
{
AcmeMSUPor t por t = ( AcmeMSUPor t ) obj ;
St r i ng sever i t ySt r = pr op. get Pr oper t y( " f i el d1: 0" ) ;
i nt sev = get EqvSever i t y( sever i t ySt r ) ;
St r i ng sevSt r =
( por t . get Cl assname( ) , " The por t " +por t . get Name( ) +" has f ai l ed " ,
sevSt r , por t . get Name( ) ,
por t . get Name( ) , por t . get Name( ) ) ;
i nEvent . set Gr oupName( por t . get Devi ceName( ) ) ;
t r y
{
}cat ch( Remot eExcept i on e)
{
Syst em. er r . pr i nt l n( " Event coul d not be sent f or
f ai l ed por t " ) ;
}
}
}

Similar to the card when the managed object is an instance of AcmeMSUPort, the status is set
accordingly and an event is generated.
AdventNet Inc. 117

TL1 Tutorial

10.3.2 Description of AcmeMSU Alarm Propagation Filter
Class

Propagation filters need to implement the PropagationFilter interface in the
com.adventnet.nms.alertdb package. These filters implement the applyPropagation() method,
whose argument is a reduced version of the Alert. The reason for a reduced version is to reduce the
amount of data being passed around. Using AlertAPI, we would get the complete Alert from the mini
alert.

/ ** Thi s i s t he f i l t er met hod cal l ed t o pr opogat e each al er t **/
publ i c voi d appl yPr opagat i on( Mi ni Al er t mi ni Al er t ) {
i f ( mi ni Al er t == nul l ) r et ur n;
i nt sev = mi ni Al er t . get Sever i t y( ) ;
i f ( ! Sever i t yI nf o. get I nst ance( ) . cont ai ns( sev) | |
Sever i t yI nf o. get I nst ance( ) . i sNoCr i t i cal i t y( sev) | |
Sever i t yI nf o. get I nst ance( ) . i sUnknown( sev) | |
Sever i t yI nf o. get I nst ance( ) . i sI nf o( sev) | |
( Sever i t yI nf o. get I nst ance( ) . get Speci al Pur poseSever i t y( ) ==
sev) )
r et ur n;
St r i ng sour ce = mi ni Al er t . get Sour ce( ) ;
i f ( sour ce == nul l ) r et ur n;
TopoAPI t opo_api = ( TopoAPI ) NmsUt i l . get API ( " TopoAPI " ) ;
t r y {
ManagedObj ect obj = t opo_api . get ByName( sour ce) ;
i f ( obj == nul l ) r et ur n;
/ / We' l l f i r st see i f i t ' s a por t , car d, sl ot , or shel f
i f ( ! ( obj i nst anceof AcmeMSUSl ot ) && ! ( obj i nst anceof
AcmeMSUCar d) && ! ( obj i nst anceof AcmeMSUPor t ) && ! ( obj i nst anceof
AcmeMSUShel f ) )
{
r et ur n;
}
/ / We need t o f et ch t he compl et e al er t , e. g. t o get t he gr oup
name
Al er t al er t =( ( Al er t API ) ( NmsUt i l . get API ( " Al er t API " ) ) ) . get Al er t
( mi ni Al er t . get Ent i t y( ) ) ;

Once the Alert is obtained, we will propagate the Alert one level at a time.

pr opagat eToCont ai ner ( al er t , obj , t opo_api ) ;

In this method, first we would get the parentKey of the managedObject. A check is made if the status
of the parent is different from that of the current object. If the status of both are same nothing is done.
If the status of both are different an input event is generated for the parent. In this method the status is
propagated from the port to the card and from card to the node.

/ **
* Pr opagat e t he al er t up t he cont ai ner hi er ar chy, i . e. t o
* t he par ent cont ai ner .
**/
voi d pr opagat eToCont ai ner ( Al er t al er t , ManagedObj ect obj , TopoAPI t opo_api )
t hr ows j ava. r mi . Remot eExcept i on
{
St r i ng par ent Key=" unknown" ;
{
par ent Key = obj . get Par ent Key( ) ;
AdventNet Inc. 118

TL1 Tutorial

}
{
par ent Key = ( ( AcmeMSUCar d) obj ) . get Devi ceName( ) ;
}
i f ( par ent Key == nul l )
{
/ / no cont ai ner or par ent er r or
Syst em. er r . pr i nt l n( " No par ent Key r ef er ence. Er r or : " +
obj . get Name( ) ) ;
r et ur n;
}
ManagedObj ect par ent = t opo_api . get ByName( par ent Key) ;
i f ( par ent == nul l )
{
Syst em. er r . pr i nt l n( " Par ent obj ect : " +par ent Key+" not f ound f or
obj ect : " +obj . get Name( ) ) ;
r et ur n;
}
{
i f ( par ent . get St at us( ) == al er t . get Sever i t y( ) )
{
r et ur n;
}
el se
{
sendEvent ( par ent Key, al er t . get Sever i t y( ) , al er t , par ent ) ;
}
}
{
AcmeMSUNode devi ce = ( AcmeMSUNode) par ent ;
i nt par ent St at us = devi ce. checkSt at us( ) ;
sendEvent ( par ent Key, par ent St at us, al er t , par ent ) ;

}
}
pr i vat e voi d sendEvent ( St r i ng sour ce, i nt st at us, Al er t al er t ,
ManagedObj ect par ent )
{
I nput Event event = new I nput Event ( par ent . get Cl assname( ) , / / use cl ass
as cat egor y

" One or mor e of t he obj ect s i n t hi s " +par ent . get Type( ) +" have f ai l ed" ,
par ent . get St at usCol or ( st at us) sour ce, sour ce, sour ce) ;
event . set User Pr oper t y( " agent Pr ot ocol " , " TL1" ) ;
event . set Gr oupName( al er t . get Gr oupName( ) ) ; / / t o gr oup al er t s
t r y
{
( ( Event API ) NmsUt i l . get API ( " Event API " ) ) . addEvent ( event ) ;
{
}
}
}
AdventNet Inc. 119

TL1 Tutorial

10.4 Description of Status Polling Custom Code

10.4.1 Description of Custom Code for Status Polling of
Card

Add the following Custom Code to accomplish status polling of the AcmeMSUCard managed object in
the AcmeMSUCard object class at the end before the last "}".

The status polling for the AcmeMSUCard object is also done in the same way as it is done for the
port. Except that the command sent here is RTRV-EQPT with the access id as the card name instead
of RTRV-FAC command.

First the name of the card is obtained and then for this card the RTRV-EQPT command is sent.

{
t r y
{
AcmeMSUNode myswi t ch =
St r i ng car dName =
get Name( ) . subst r i ng( get Par ent Key( ) . l engt h( ) +1) ;
Obj ect r esul t Obj = TL1Swi t chUt i l . syncSendCommand( myswi t ch,
" RTRV- EQPT" , car dName) ;
{
}
{
{
st at us = 5;
}
el se
{
st at us = 4;
}
{
st at us = 3;
}
{
st at us = 2;
}
{
st at us = 2;
}
{
AdventNet Inc. 120

TL1 Tutorial

i f ( r esp. si ze( ) == 0)
{
r et ur n st at us;
}
el se
{
St r i ng st r = nul l ;
i f ( get Type( ) . equal sI gnor eCase( " CPU" ) )
{
}
el se
{
}
{
}
}
}
i f ( st at us==1 | | st at us==4)
{
set Managed( f al se) ;
}
el se
{
}

}
{
}

Now, similar to the check status of the port first the status is set based upon the completion code.
Then from the response message the value of the PST/ST (PST for CPU card and ST for ST1 card) is
obtained and correspondingly the status is set.
AdventNet Inc. 121

TL1 Tutorial

10.4.2 Description of Custom Code for Status Polling of
Port

Once you have defined managed objects for the components of your network, you also need to
ensure the status of these objects is monitored and communicated to users. Status polling is needed,
and Web NMS supports flexible status polling of your devices and components.

For each type of device, Web NMS performs status polling of these devices based on the
configuration.

For each managed object, it invokes the status polling specified by the configuration, which may be a
standard operation like pinging the device already supported by Web NMS or a custom polling that is
needed for a specific device or component.

We can also override the status polling code for your managed object. We will illustrate an example
using the Port object & the same approach is handled to identify the status of the card object too. The
Status of the port is identified by using the RTRV-FAC command (Retrieve Facility command, which
has been already mentioned in the Command Set provided).

Add the following imports in AcmeMSUPort MO Class.


Add the following Custom Code to accomplish status polling of the AcmeMSUPort managed object in
the AcmeMSUPort object class at the end before the last "}".

The method below in the managed object class is called whenever status polling of this object is
scheduled. Using this method, you can directly control what happens when status polling is to be
done for this object. Also each managed object can be configured to support failure counts, i.e.
allowing multiple failures before a managed object failure is reported to the system. This is done by
using the setFailureThreshold() method in the ManagedObject class. The code snippet of the
checkStatus method is given below

publ i c i nt checkSt at us( )
{
t r y
{
AcmeMSUNode mySwi t ch =
AcmeMSUCar d car d =
( AcmeMSUCar d) t opoapi . get ByName( get Par ent Key( ) ) ;
St r i ng por t Name =
get Name( ) . subst r i ng( car d. get Par ent Key( ) . l engt h( ) +1) ;
Obj ect r esul t Obj = TL1Swi t chUt i l . syncSendCommand( mySwi t ch,
" RTRV- FAC" , por t Name) ;
{
}

AdventNet Inc. 122

TL1 Tutorial

Here we are executing the RTRV-FAC command to the device with the port name as the accessid, we
are sending it via the Management Server, which has been explained earlier in this tutorial.

{

First Identify the severity with the Response completion status.

{
/ / Par se And I dent i f y St at us.
st at us = 5;
}
el se i f ( cmdCode. equal s( TL1ResponseMessage. DELAYED_ACTI VATI ON) )
{
st at us = 4;
}
{
st at us = 3;
}
{
st at us = 2;
}
{
st at us = 2;
}
{
Vect or r esp = t ext Bl k. get Out put Text ( ) ;
i f ( r esp. si ze( ) == 0)
{
r et ur n st at us;
}
el se
{
TL1Li ne cur r Li ne = ( TL1Li ne) sl ot Names. el ement At ( 0) ;
Pr oper t i es pr op = TL1Swi t chUt i l . conver t Li neAsPr oper t i es( cur r Li ne) ;

Convert the TL1Line in the response as properties and get the value of PST variable which defines
the status of the port. (whether it is in service / it is out of service etc., and get the corresponding
severity and set it as the severity for the port.

St r i ng st r = pr op. get Pr oper t y( " PST" ) ;
{
}
}
}

AdventNet Inc. 123

TL1 Tutorial

The severityForCardStatus method where based on the value of the PST value an integer showing
the status of port is returned is given below

pr i vat e i nt sever i t yFor Car dSt at us( St r i ng st r )
{
i f ( st r . equal sI gnor eCase( " I S" ) )
{
r et ur n 5;
}
el se i f ( st r . equal sI gnor eCase( " OOSMT" ) )
{
r et ur n 4;
}
el se i f ( st r . equal sI gnor eCase( " OOS" ) )
{
r et ur n 2;
}
el se i f ( st r . equal sI gnor eCase( " RESET" ) )
{
r et ur n 1;
}
}

Based on this return value a status update message is generated by the server. The fields of the
generated event are based on the values in the managed object.
AdventNet Inc. 124

TL1 Tutorial

10.5 Description of Performance Management
Configuration

You will customize the performance by configuring the Polling.conf file. This file is present under
<Web NMS HOME>/conf directory. As explained in the TL1 Command Set topic of Appendix you
would use the RTRV-PM and RTRV-EQPT command to do the performance Management for ports
and cards respectively.

In this application create three polling objects to represent the port, card, and the node. Append the
following lines to perform the data collection for the port in the Polling.conf file.

<POLLI NG_OBJ ECT name=" acme_msu_por t " >
<MATCH_CRI TERI A>
<MO_PROPERTI ES>
val ue=" acme_msu_por t " / >
</ MO_PROPERTI ES>
<DATA_TO_POLL dat aI dent i f i er =" RTRV- PM: : ${por t Name}: ; "
pr ot ocol =" TL1" t ype=" mul t i pl e" name=" Por t _Dol _I nt eger "
r esponse=" ESL, SESL, LOSSL, ESP, CSSP" / >

In order to filter out the port objects, the managed object property "TYPE" is used which was set in the
discovery filter (AcmeMSUDiscFilter). The match criteria are given within the <MATCH_CRITERIA>
tag . The command, protocol, name, and the parameters for polling are specified in the
<DATA_TO_POLL>tag.

For specifying the port name in the command Web NMS provides "$" support . This considerably
reduces the time of specifying command for each port. For this, the port object should just have
"portName" as a column which would give the name of the port. This value gets substituted in the
place of $ {portName}and the command is executed.

Similarly to collect data for the card the following entries have been appended in the Polling.conf file.

<POLLI NG_OBJ ECT name=" acme_msu_car d" >
<MATCH_CRI TERI A>
<MO_PROPERTI ES>
<STRI NG_TYPE pr oper t y=" t ype" condi t i on=" st ar t sWi t h"
val ue=" acme_msu_car d_" / >
</ MO_PROPERTI ES>
<DATA_TO_POLL dat aI dent i f i er =" RTRV- EQPT: : ${car dName}: ; "
pr ot ocol =" TL1" t ype=" mul t i pl e" name=" Por t _Dol _St r i ng"
r esponse=" PST, SST" / >

Here the card object should just have "cardName" as a column which would return the name of the
card. Also because there are two types of cards, the match criteria have been given as "type
startsWith acme_msu_card" .

AdventNet Inc. 125

TL1 Tutorial

In order to collect data for the node as a whole, append the following entries in the Polling.conf file.

<POLLI NG_OBJ ECT name=" acme_msu_node" >
<MATCH_CRI TERI A>
<MO_PROPERTI ES>
val ue=" acme_msu_node" / >
</ MO_PROPERTI ES>
<DATA_COLLECTI ON pol l i ngPer i od=" 300" pr ot ocol =" TL1" >
<DATA_TO_POLL dat aI dent i f i er =" RTRV- EQPT: : ALL: ; " t ype=" mul t i pl e"
name=" Eqpt _ALL_St r i ng" r esponse=" PST, SST" component I d=" 0" / >
<DATA_TO_POLL dat aI dent i f i er =" RTRV- PM: : ALL: ; " t ype=" mul t i pl e"
name=" Por t _ALL_I nt eger " r esponse=" ESL, SESL, LOSSL, ESP, CSSP"
component I d=" 0" / >

To collect data for TL1 protocol, the provider for the protocol must be plugged in. For this purpose, a
TL1 protocol provider TL1DataCollecterAsync has been provided.
AdventNet Inc. 126

TL1 Tutorial

10.6 Description of Provisioning Files

10.6.1 Description of ChangeCardType Provisioning
Template

<! DOCTYPE Templ at e ( Vi ew Sour ce f or f ul l doct ype. . . ) >
<Templ at e name=" ChangeCar dType" owner =" r oot " di spl ayFor ms=" t ab"
<I nvent or yI nput i d=" 1#" MOName=" $Templ at ePar am$Host " MOFi el d=" name"
<I nvent or yI nput i d=" 2#" MOName=" $Templ at ePar am$Host " MOFi el d=" pr i or i t y"
<I nvent or yI nput i d=" 3#" MOName=" $Templ at ePar am$Host " MOFi el d=" car dName"
<I nvent or yI nput i d=" 4#" MOName=" $Templ at ePar am$Host " MOFi el d=" devi ceName"
<I nvent or yI nput i d=" 5#" MOName=" $Templ at ePar am$Host " MOFi el d=" CRDSN"
<I nvent or yI nput i d=" 6#" MOName=" $Templ at ePar am$Host " MOFi el d=" pr odNo"
<I nvent or yI nput i d=" 7#" MOName=" $Templ at ePar am$Host " MOFi el d=" CRDREV"


In this template you will get the name, priority, cardName, deviceName, CRDSN, PRODNO,
CRDREV, MFDAT, and the tl1cardtype of the card from the database. For this purpose the entries are
given within the <InventoryInput> tag. The MOName attribute contains the name of the Managed
Object and MOField contains the name of the ManagedObject property that needs to be obtained.

<For mt i t l e=" Conf i gur at i on" descr i pt i on=" Thi s t empl at e enabl es t o change
t he pr i or i t y and st at us of t he car d" i d=" 3#" >
<User I nput i d=" 1#" name=" car dname" l abel =" CARD NAME"
<User I nput i d=" 6#" name=" cr dsn" l abel =" CRDSN"
<User I nput i d=" 7#" name=" mf dat " l abel =" MFDAT"
<User I nput i d=" 8#" name=" pr odno" l abel =" PRODNO"
<User I nput i d=" 9#" name=" cr dr ev" l abel =" CRDREV"
- <User I nput i d=" 3#" name=" pr i or i t y" l abel =" PRI ORI TY"
def aul t =" $I nvent or yI nput $2#" edi t abl e=" f al se" r equi r ed=" f al se" >
- <Qual i f i er t ype=" choi ce" >
</ Qual i f i er >
</ User I nput >
- <User I nput i d=" 5#" name=" st at us" l abel =" PST" def aul t =" I S"
edi t abl e=" f al se" r equi r ed=" f al se" >
- <Qual i f i er t ype=" choi ce" >
<Enumname=" I S" val ue=" I S" / >
<Enumname=" OOS" val ue=" OOS" / >
</ Qual i f i er >
</ User I nput >
</ For m>
AdventNet Inc. 127

TL1 Tutorial

Next, the form is created wherein the UserInputs are specified. This is specified within the Form tag.
You create seven UserInputs each for the name, serial number of the card, manufacturing date of the
card, production number of the card, card revision, priority, and the status of the card. These
UserInputs would appear as label and text fields on the template.

<Conf i gTask t askName=" Edi t Car dPr ops" i sNewTask=" t r ue" i sOver wr i t e=" t r ue"
i sSequent i al =" f al se" per si st ence=" t r ue" devi ceResul t =" f al se"
i sTempl at e=" f al se" r ol l backNeeded=" f al se" ver si on=" 1. 0" >
- <Pr ot ocol Map name=" t l 1" >
<Devi ce host =" $I nvent or yI nput $4#" por t =" 9099" / >
</ Pr ot ocol Map>
- <! - - conf i gur at i on at t r i but es
- - >
messagePayLoadBl ock=" PRI ORI TY=$User I nput $3#" / >
messagePayLoadBl ock=" PST=$User I nput $5#" / >
</ Conf i gTask>
</ St age>
</ Templ at e>

Then, in the ConfigTask tag specify the commands that will be used to perform the provisioning. You
would name the config task as EditCardProps and specify the protocol as TL1.

Since you are changing the priority of the card, you will use the ED-EQPT command. Then, the status
is set for the card again by executing the ED-EQPT command.

AdventNet Inc. 128

TL1 Tutorial

10.6.2 Description of AcmeCrossConnect Provisioning
Template

For the cross connect example, a template AcmeCrossConnect.xml has been provided. In this file
you set the config task. For the cross connect example, the ENT-CRS-T0 command is used to
establish cross connection and the DLT-CRS-T0 command is used to delete the existing cross
connection. This template would be used to send the command to the agent.

<! DOCTYPE Templ at e ( Vi ew Sour ce f or f ul l doct ype. . . ) >
<Templ at e name=" AcmeCr ossConnect " owner =" r oot " di spl ayFor ms=" t ab"
<Conf i gTask t askName=" AcmeCr ossConnect Task" i sNewTask=" t r ue"
ver si on=" 1. 0" >
<Devi ce host =" l ocal host " por t =" 9099" / >
</ Pr ot ocol Map>
<! - - conf i gur at i on at t r i but es
- - >
<At t r i but e i dent i f i er =" ENT- CRS- T0" commandCode=" ENT- CRS- T0" t ar get I D=" "
accessI D=" ST1- 1- 1- 1, ST1- 1- 1- 2" gener al Bl ock=" "
messagePayLoadBl ock=" TYPE=DATA, MODE=2WAY, NAME=CUSTOMER1, PST=I S" / >
</ Conf i gTask>

The CrossConnectUI.java and CrossConnectUtil.java are the two classes that are responsible for
the UI representation and establishment of the cross connect.

The CrossConnectUI.java class mainly concentrates on the UI representation. The command is sent
to the agent in the CrossConnectUtil.java class.

You would concentrate on how the ProvisioningAPI handle is obtained and the template is sent for
provisioning after setting the various attributes. You will also see how the TopoAPI method calls are
made from the server to the client using the client server communication.

You get the ProvisioningAPI handle in the client through RMI.

URL BE_Ur l = NmsCl i ent Ut i l . appl et . get CodeBase( ) ;
St r i ng BEHost Name = " l ocal host " ;
BEHost Name = BE_Ur l . get Host ( ) ;

The name of the system, where the server is running, will be derived from the output of
getCodeBase() method of NmsUtil. The template is sent for provisioning in the syncSendCommand
method of CrossConnectUtil.java class. In this method, the template is obtained.

xml Temp = pr API . get Templ at e( " AcmeCr ossConnect " ) ;
t emp = new Templ at e( xml Temp) ;

Once the template is obtained, it is parsed to get the various attributes of the config task. These
attributes are set based on the action selected by the user in the cross connect UI.

AdventNet Inc. 129

TL1 Tutorial

Vect or t askVect = t emp. get Conf i gTasks( ) ;
f or ( i nt t v=0; t v<t askVect . si ze( ) ; t v++)
{
Conf i gTask ct = ( Conf i gTask) t askVect . el ement At ( t v) ;
Devi ce[ ] devAr r = ct . get Devi ces( ) ;
devAr r [ 0] . set At t r i but e( " host " , i paddr ess) ;
devAr r [ 0] . set At t r i but e( " por t " , t l 1por t ) ;
At t r i but e[ ] at t r i b = ct . get Conf i gAt t r i but es( ) ;
at t r i b[ 0] . set At t r i but e( " i dent i f i er " , commandCode) ;
at t r i b[ 0] . set At t r i but e( " commandCode" , commandCode) ;
at t r i b[ 0] . set At t r i but e( " t ar get I D" , t i d) ;
at t r i b[ 0] . set At t r i but e( " accessI D" , ai d) ;
i f ( act i on. equal sI gnor eCase( " connect " ) )
{
at t r i b[ 0] . set At t r i but e( " messagePayLoadBl ock" , " TYPE=" +t ype+" ,
MODE=" +mode+" , NAME=" +connName+" , PST=I S" ) ;
}
el se
{
at t r i b[ 0] . set At t r i but e( " messagePayLoadBl ock" , " " ) ;
}
}
}

After setting the various attributes, the template is sent for provisioning. The provisionNow() method
of ProvisioningAPI is used to send the template for provisioning.

i d = pr API . pr ovi si onNow( t emp. t oSt r i ng( ) ) ;

Specified template is synchronously executed. Clients supply the fully populated templates which are
used by the server to execute the provisioning operation. The returned XML (i.e., TemplateResult in
string format) has the complete results of what was provisioned. From this XML template result, the
TemplateResult is created.

t empRes = new Templ at eResul t ( i d) ;

From this result template, the provisioning status is obtained and returned.

St r i ng st at us = t empRes. get St at us( ) ;
AdventNet Inc. 130

TL1 Tutorial

10.6.3 Description of Post Provisioning Filter Class

Once the Apply button is selected from the template, the set of config tasks is sent to the device.
After the provisioning activity gets completed (whether successful or not), one may need to do specific
custom functions to complete the provisioning operation. Post-provisioning filters provide this
capability. In this tutorial application, if the configuration result is successful it would set the priority of
the card. Also it would set the status of the card. The ChangeCard.java file acts as the
PostProvisioning Filter.

The post provisioning filter should implement the PostProvisioningFilter interface. Therefore define
the following method.

public TemplateResult postProvision(TemplateResult templateResult,Template) throws
OperationFailedException

The completely populated template is passed here and the template result contains the results of the
each configuration task that is executed. This method will check for the status of the provisioning task
by getting the value returned by the status attribute. The status attribute in the template returns
FAILED, if any one of the configuration tasks has failed. If all the configuration tasks were successful,
then FINISHED is returned.

If the status is FAILED, the filter will return the template.

publ i c Templ at eResul t post Pr ovi si on( Templ at eResul t
t empl at eResul t , Templ at e t empl at e) t hr ows Oper at i onFai l edExcept i on
{
Templ at e f ul l Templ at e = t empl at e;
Pr ovi si oni ngAPI I mpl pr ov = nul l ;
/ / We wi l l check f or t he r esul t st at us. I f t he st at us i s f ai l ed we
wi l l j ust r et ur n t he t empl at e r esul t .
i f ( f ul l Templ at e. get At t r i but e( " st at us" ) . equal sI gnor eCase( " FAI LED" ) )
{
r et ur n t empl at eResul t ;
}

If the status is not FAILED, the filter will parse the template and store the different values.

Vect or i nvI nput Vect = f ul l Templ at e. get I nvent or yI nput s( ) ;
f or ( i nt i =0; i <i nvI nput Vect . si ze( ) ; i ++)
{
I nvent or yI nput i nvI nput =
( I nvent or yI nput ) i nvI nput Vect . el ement At ( i ) ;
St r i ng moFi el d = i nvI nput . get MOFi el d( ) ;
i f ( moFi el d. equal sI gnor eCase( " name" ) )
{
car dMOName = i nvI nput . get At t r i but e( " val ue" ) ;
}
i f ( moFi el d. equal sI gnor eCase( " car dName" ) )
{
car dname = i nvI nput . get At t r i but e( " val ue" ) ;
}
i f ( moFi el d. equal sI gnor eCase( " devi ceName" ) )
{
devi ceName = i nvI nput . get At t r i but e( " val ue" ) ;
}
i f ( moFi el d. equal sI gnor eCase( " pr i or i t y" ) )
{
act Pr i or i t y = i nvI nput . get At t r i but e( " val ue" ) ;
}
AdventNet Inc. 131

TL1 Tutorial

}
Vect or f or mVect = f ul l Templ at e. get For ms( ) ;
f or ( i nt s=0; s<f or mVect . si ze( ) ; s++)
{
For mf or m= ( For m) f or mVect . el ement At ( s) ;
Vect or user I nput Vect = f or m. get User I nput s( ) ;
f or ( i nt x=0; x<user I nput Vect . si ze( ) ; x++)
{
User I nput uI nput = ( User I nput ) user I nput Vect . el ement At ( x) ;
St r i ng i nput Name = uI nput . get Name( ) ;
i f ( i nput Name. equal sI gnor eCase( " pr i or i t y" ) )
{
pr i or i t y = uI nput . get Val ue( ) ;
}
i f ( i nput Name. equal sI gnor eCase( " st at us" ) )
{
st at us = uI nput . get Val ue( ) ;
}
}
}

The filter will get corresponding card managed object from the name of the card.

AcmeMSUCar d car dObj = ( AcmeMSUCar d) api . get ByName( car dMOName) ;

The filter will check if the current card priority and the selected priority are different. If different, it
would set the priority of the card.

i f ( ! act Pr i or i t y. equal sI gnor eCase( pr i or i t y) )
{
car dObj . set Pr i or i t y( pr i or i t y) ;
api . l ock( car dObj , Lockabl eObj ect . WRI TE_LOCK, 2) ;
api . updat eObj ect ( car dObj , t r ue, t r ue) ;
}

Also, based on the PST value selected from the template, an event is generated for the card.

i f ( st at us. equal sI gnor eCase( " I S" ) )
{
i nt car dSt at us=5;
St r i ng sev =
Sever i t yI nf o. get I nst ance( ) . get Name( car dSt at us) ;
I nput Event i nEvent = new I nput Event ( car dObj . get Cl assname( ) ,
" St at us updat i on t hr ough conf i gur at i on" ,
sev, car dObj . get Name( ) , car dObj . get Name( ) ,
car dObj . get Name( ) ) ;

i nEvent . set Gr oupName( car dObj . get Devi ceName( ) ) ;
t r y
{
( ( Event API ) NmsUt i l . get API ( " Event API " ) ) .
addEvent ( i nEvent ) ;
{
Syst em. out . pr i nt l n( " Event coul d not be gener at ed f or
f ai l ed car d" ) ;
}
}
AdventNet Inc. 132

TL1 Tutorial

10.7 Description of Client Server Communication Code

To use the common socket, the AcmeMsuClientSocketConn class must implement the
SocketConnection interface. Therefore, overwrite the close and receive methods. To get the
responses back from the server, the class must register itself with the MainSocketClient.

Pur eCl i ent Ut i l s. commonSocket . r egi st er For Responses( t hi s, MSU_I D) ;

The class registers itself with a unique ID which helps in identifying correct client requests. First the
send method calls the server. The syncSend method is called and the method name and the required
parameters are passed as arguments. These data are serialized and sent to the server through the
common socket.

byt e[ ] r esul t Byt eAr r =
Pur eCl i ent Ut i l s. commonSocket . syncSend( MSU_I D, r et Dat a) ;

For the server to handle requests from the client, the class has to implement
SocketServerConnectionBE. This is done in the AcmeMsuSocketServerConnBE.java file. First
the class registers itself with the MainSocketServerBE .

Pur eSer ver Ut i l sBE. ser ver Socket BE. r egi st er For Responses( t hi s) ;

This class gets notification about the client requests through its init method.

In init method, to handle the client requests, the AcmeMsuSocketSessionConnBE.java is
instantiated. This class implements the SocketSessionConnectionBE interface. To get packets from
the client, this class registers itself with the MainSocketSessionBE.

publ i c AcmeMsuSocket Sessi onConnBE( Mai nSocket Sessi onBE mai nSocket Sessi on)
{
mssbe=mai nSocket Sessi on;
mssbe. r egi st er For Responses( t hi s, ACME_MSU) ;
}

The receive method is called whenever a packet arrives from the client. In this method, the data that
come in the form of a byte array are deserialized into a Vector. The method name along with the
parameters is obtained. The topoAPI handle is created and the method is executed. Based on the
result the properties resultProp is created. This property is again serialized and the
sendDataToClient method is called.

r esul t _byt e=NmsUt i l . ser i al i zePr oper t i es( r esul t Pr op) ;
sendDat aToCl i ent ( SYNC_SEND, uni queI d, r esul t _byt e) ;

In this method, the processed data are sent back to the client through the MainSocketSessionBE.

mssbe. send( ACME_MSU, uni queI d, r et Dat a) ;

AdventNet Inc. 133

TL1 Tutorial

11.0 Appendix

11.1 TL1 Command Set used in the Application

ACME MSU TL1 MESSAGE SET

Login Command

ACT-USER::ROOT:::[PUBLIC];

FACTORY 2001-05-12 04:13:07
M COMPLD
;

Activates an user login session.

Logout Command

CANC-USER:::;

FACTORY 2001-05-12 04:23:12
M COMPLD
;

Cancels (terminates) a login session on the channel that the command is entered.

Retrieve Network Element Information Command

RTRV-NE:::;

FACTORY 2001-05-12 04:17:29
M COMPLD
"-1:FACTORY"
;

The command is to retrieve the NE local node or target node identification information.

Retrieve System Inventory Command

RTRV-INVENTORY:::;

FACTORY 2001-05-12 01:44:43
M COMPLD

"CPU-1::CRDTYPE=CPU,CRDSN=57,MFDAT=01/24/2000,PRODNO=712700,CRDREV=A2"
"SLT-1::CRDTYPE=ST1,CRDSN=23,MFDAT=01/25/2000,PRODNO=712800,CRDREV=A0"
;

The command gives the slots and the details about the card in that slot. This data is used for creating
the slot object in the discovery filter.
AdventNet Inc. 134

TL1 Tutorial

Retrieve Card Settings Command

RTRV-EQPT::ALL:;

FACTORY 2001-05-12 01:53:13
M COMPLD
"CPU-1:::PST=IS"
"ST1-1::PRIORITY=1,TYPE=DSX,WKMOD=WK,ST=IS"
"ST1-3::PRIORITY=1,TYPE=CSU,WKMOD=WK,ST=IS"
"ST1-6::PRIORITY=1,TYPE=DSX,WKMOD=WK,ST=OOS"
"ST1-7::PRIORITY=1,TYPE=CSU,WKMOD=WK,ST=IS"
"ST1-9::PRIORITY=1,TYPE=CSU,WKMOD=WK,ST=OOS"
;

The command gives the entire card settings for the device . This data is used for creating the card
objects in the discovery filter.

Retrieve Card Settings For A Particular Card

RTRV-EQPT::ST1-1:;

FACTORY 2001-05-12 02:46:11
M COMPLD
"ST1-1::PRIORITY=1,TYPE=DSX,WKMOD=WK,PST=IS"
;

(Similarly RTRV-EQPT command responds for the requests for any specific card defined in the
inventory list)

The command gives the card settings for a particular card . The data (value of PST i.e the primary
status) is used for setting the status of the card.

Delete Card Command

DLT-EQPT::ST1-4:;

FACTORY 2001-05-12 02:49:38
M COMPLD
;

(Similar responses for other possible access id's to DLT-EQPT command)

The command is to delete previously provisioned parameters and settings of a specific logic card in
the device. In this tutorial the result from this command is used in the post provisioning filter class for
the provisioning example explained later.

Create Equipment Command

ENT-EQPT::ST1-4::::TYPE=DSX;

FACTORY 2001-05-12 02:48:20
M COMPLD
;

(Similar responses for other possible access id's to ENT-EQPT command)

AdventNet Inc. 135

TL1 Tutorial

The command is to provision a logic card with parameters and settings for any of the logic cards of
the device. In this tutorial the result from this command is used in the post provisioning filter class for
the provisioning example explained later.

Edit Card Settings Command

ED-EQPT::ST1-4::::TYPE=CSU;

FACTORY 2001-05-12 03:23:59
M COMPLD

The command is to edit previously-provisioned parameters and settings of a specific logic card in the
device. The command is used in the provisioning example explained later in this tutorial.

Retrieve Facity Data Command

RTRV-FAC::ST1-8-1:;

FACTORY 2001-05-12 04:27:02
M COMPLD
"ST1-8-1::LINECDE=B8ZS,LINELEN=0-133,FRM=D4,FDL=OFF:PST=OOS,
SST=FLT&IDLE,IPSTATE=OFF""
;

The command is to retrieve facility data ( port data). The command is used in this tutorial to get the
status of the port by checking for the PST value. This has been implemented in the check status
method of the AcmeMSUPort class.

Retrieve (View) Alarms Command For A Specific Card

RTRV-ALM::ST1-8:;

FACTORY 2001-05-12 04:28:59
M COMPLD
"ST1-8-1,T1:MJ ,LOS,SA,2001-05-12,01-51-14,,:"
"ST1-8-1,T1:MJ ,LOF,SA,2001-05-12,01-51-18,,MASK:"
"ST1-8-1,T1:MJ ,CGA-RED,SA,2001-05-12,01-51-15,,:"
;

The command is to retrieve the system alarms for a specific card of the device. The command is sent
as an autonomous message from the simulator.

Retrieve (View) Alarms Command For All Cards

RTRV-ALM::ALL:;

FACTORY 2001-05-12 04:30:03
M COMPLD
"ST1-7-1,T1:MJ ,LOS,SA,2001-05-12,01-47-28,,:"
"ST1-7-1,T1:MJ ,LOF,SA,2001-05-12,01-47-32,,MASK:"
"ST1-7-1,T1:MJ ,CGA-RED,SA,2001-05-12,01-47-28,,:"
"ST1-8-1,T1:MJ ,LOS,SA,2001-05-12,01-51-14,,:"
"ST1-8-1,T1:MJ ,LOF,SA,2001-05-12,01-51-18,,MASK:"
"ST1-8-1,T1:MJ ,CGA-RED,SA,2001-05-12,01-51-15,,:"
"ST1-10,EQPT:MJ ,IO_CARD_MISSING,SA,2001-05-12,01-51-43,,:"
"ST1-10-1,T1:MJ ,LOS,SA,2001-05-12,01-51-43,,MASK:"
"ST1-10-1,T1:MJ ,LOF,SA,2001-05-12,01-51-45,,MASK:"
"ST1-10-1,T1:MJ ,CGA-RED,SA,2001-05-12,01-51-43,,MASK:"
"SYS,SYS:MN,POWER_A_FAIL,NSA,2001-05-12,01-04-12,,:"
;

The command gives the alarms for all the cards.

AdventNet Inc. 136

TL1 Tutorial

Retrieve performance Counts Command

RTRV-PM::ST1-8-1:::,,,,15-MIN,,0;

FACTORY 2001-05-12 04:35:08
M COMPLD
"ST1-8-1,T1:ESL,305,NA,NEND,RX,15-MIN,0"
"ST1-8-1,T1:SESL,306,NA,NEND,RX,15-MIN,0"
"ST1-8-1,T1:LOSSL,306,NA,NEND,RX,15-MIN,0"
"ST1-8-1,T1:ESP,11,NA,NEND,RX,15-MIN,0"
"ST1-8-1,T1:CSSP,11,NA,NEND,RX,15-MIN,0"
;

The command is to retrieve performance monitoring data on a particular port.

AUTONOMOUS MESSAGES

FACTORY 2001-05-12 04:39:42
** 230 REPT ALM T1
"ST1-8-1:MJ ,LOS,SA,2001-05-12,04-39-42,,:\"SLT LOSS OF SIGNAL\""
;

This Autonomous Message is received when a card is faulty with Loss of Signal.

FACTORY 2001-05-12 04:39:05
** 228 REPT ALM EQPT
"ST1-8:MJ ,CRDRMVD,SA,2001-05-12,04-39-04,,:\"ST1 CARD MISSING\""
;

This Autonomous Message is received when a card is missing.

FACTORY 2001-05-12 04:13:07
AA 0 REPT EVT SESSION
"SYS:LOGON,CL,2001-05-12,04-13-07,,,,:\"PRIVATE SYSTEM
UNAUTHORIZED USERS MAY BE PROSECUTED\""
;

This Autonomous Message is received when an unauthorized Login is attempted.
AdventNet Inc. 137

TL1 Tutorial

11.2 TL1 Basics

Transaction Language1 (TL1) is a network management protocol used for managing
Telecommunication networks. TL1 facilitates communication between a managed device (a device
with TL1 agent), and a TL1 manager. The TL1 agent on the managed device serves to provide
access to data stored on the managed device. The TL1 manager uses this access to monitor and
control the managed device. TL1 protocol communicates via TCP. Data (TL1 Messages) are sent and
received in the form of byte stream.

Types of Messages
TL1 specifies four types of messages as follows.

Input Command Messages
Acknowledgements
Output Response Messages
Autonomous Messages

An Input command message is a message from an OS or other source (i.e. manager) to an Network
Element.(NE). (i.e. agent). The message requests the NE to perform some action.

An acknowledgement is a short reply from the NE indicating that an input command message is being
acted upon or has been immediately rejected. The essential purpose of an acknowledgement is to
reassure a human user that a command that takes a long time to execute has been received by the
NE.

An output response message is a detailed reply (or set of replies) to an input command message. It
contains information indicating whether the command was executed successfully and any data that
needs to be returned to the OS/user.

An autonomous message is one generated by the NE either on a periodic timed basis or to report
some unusual occurrence.
AdventNet Inc. 138

TL1 Tutorial

11.2.1 Message Structure

This section explains the format and structure of different types of TL1 messages (Input, Output,
Acknowledge, Autonomous) as defined by the BellCore specifications. This section is very important
for those users who would like to understand and analyze the TL1 messages exchanged between the
TL1 Manager and the Agent.

On a broader level, TL1 Messages can be logically categorized into two types, namely Input and
Output messages. The output message can be either Response, Autonomous or Acknowledgement
messages. All messages have their own format and structure.

AdventNet Inc. 139

TL1 Tutorial

11.2.2 Input Message

General Format

The general structure of a TL1 input message is of the form
<command_code>:<staging_parameter_blocks>:<message_payload_block>;

Command Code
It determines the action to be taken at the NE as a result of receiving the input message. Each
command must begin with a command code consisting of a mandatory verb followed by up to two
optional identifiers,each separated by hyphen.

<command code> ::= <verb>[-<modifier>[-<modifiers>]]

Verb identifies the action to be taken at the NE as a result of receiving a TL1 message from an OS.
The command code modifiers are optional depending upon the specific command and application
domain. The first modifier identifies where the action is to be applied in the NE. The second modifier
may be used to further define the identity of the object upon which the action is to be taken.

For example, a <verb>-EQPT can be used to indicate that an action, specified by the value of the
verb, is to be taken on an equipment object. A <verb>-T0 indicates an action is being taken on DS0
circuit.

As another example, for switching NE's, the command <verb>-<administrative view>indicates an
action is to be taken on an object entity within the specific administrative view of the switching NE
database.

Another example is shown to illustrate how the second modifier is used. The command DLT-CRS-T0
will disconnect (DLT) one or more cross connected (CRS) DS0 object entities (T0).The modifier CRS
is further defined to identify T0 object entities.

Staging Parameter Block
These are a series of four data blocks following the command code that provide information to
establish and uniquely identify an object entity within an NE to be managed by a remote OS and to
specify certain options as to how the input command is to be executed in the NE. The structure of the
staging parameter blocks consists of the following series:

:[<targetidentifier>]:<accessidentifier(s)>:<correlationtag>:[<general block>]:

Each block may have one or more specifically defined parameters. The parameters within each
staging block may either be position-defined or name-defined.

Target Identifier Block

An input message associated with the management of a particular object may be directly
addressed to an NE or it may be routed to or through one or more intermediate NE's. The
Target IDentification code (TID ) parameter block provides the capability within the TL1
message format to perform network routing tasks. The presence of the TID in all input
commands is a requirement,but its value may be null (represented by two successive colons).

The TID block contains a single position-defined parameter that identifies the end-target NE to which
the input command is directed. The value of TID may be any valid simple or compound TL1 identifier
or text string limited to 20 characters.

AdventNet Inc. 140

TL1 Tutorial

Access Identifier Block

The Access IDentifier (AID) block normally contains one or more parameters that uniquely
identifies the entity within the target NE to be acted upon by the input message. Typical
examples of entities addressed by the AID parameter values are:
o Circuits and common equipment modules having hierarchical relationships.
o Record entities within the context of an administrative view of the NE database.
o Test session and Test Access Point aliases.

Correlation Tag (CTAG)

It contains one position defined parameter to serve as a means of correlating an input
command with its associated output response. The OS assigns an arbitrary non-zero CTAG
value and it is the responsibility of the NE to copy this value into the output response
associated with that input command. The value of CTAG must either be a TL1 identifier or a
non-zero decimal number consisting of not more than six characters.

General Block (GB): It includes support parameters whose values affect the way in which
the input command is to be executed in the NE. The presence of GB in all input commands is
a requirement but its value may be null (represented by two successive colons).
The form of the General Block is :
:[[<delay activation parameters>],[<contingency flag>],[<indirect data retrieval identifier>]]:

Delay Activation is a function whereby an input message may be stored in a message pending buffer
at the NE for final execution at some later time. The Delay Activation function is provided by a set of
parameters within the GB of the form :

[ON=]<order no.>,[DATE=]<date>,[TIME]<time>

Contingency Flag parameter is a boolean data type within the GB that indicates,when set true,a
dependent relationship among the several records specified in the AID data block of a multi-unit
command. If CF is false, partial installation of the records in a multi unit message may be completed
with a report sent to the OS listing the records that were not successfully installed in a database.

Indirect Data Retrieval Indicator is a functional capability by which information may be retrieved from
more than one linked administrative view by a single RTRV command.

Message Payload Block
This block indicates the subject matter of the message. This section may consists of zero or more
data blocks in the form.
(:<Px>(,<Px>)*)*;
where Px represents a data item. Each data block is delimited by colons (:) and the last terminated by
a semicolon (;). Each data block may have an unlimited number of data items,each delimited by
commas (,). The data items within a data block may be either name-defined (<keyword>=<value>) or
position-defined where values are specified and the keyword is implied by its position in the data
block.
AdventNet Inc. 141

TL1 Tutorial

11.2.3 Output Response Message

General Format
A TL1 output response message is the response to a TL1 Input Command message. The general
structure of a TL1 output response message is of the form :

<header><response identification>[<text block>] <termination>

which consists of a optional text block and all the other blocks are essential.

Header
The Header represents information common to all output response.

<cr><lf><lf>^^^<sid>^<year>-<month>-<day>^<hour>:<minute>:<second>

It contains System identifier <sid>, date and time stamps.<sid>is restricted to 20 characters
maximum and identifies the NE generating the message. The syntax of <sid>is any TL1 identifier or
text string. The <year><month><day>construct represent the day in which the output response is
generated. The <hour><minute><second>construct represent the time at which the output response
is generated.

Response Identification
The form of the response identification is :

<cr><lf>M^^<ctag>^<completion code>

This construct consists of three components namely the character M, a correlation Tag and a
completion code. The character M signifies that the message is the response to the input command.
The ctag must be the same as that of the input message in order to associate the response with the
proper input command.
The various completion codes are described below.

COMPLD
Total successful execution of the input command.

DENY
Total denial of the input command.

PRTL
Partial successful execution of the input command. This response code is valid when the ctag in
the general block is FALSE.

DELAY
Successful queuing of the input command submitted for delayed activation.

RTRV
Output response of a input retrieve command that retrieves extensive amount of information from the
NE and uses more time for processing.

Text Block
The optional [<text block>] is used to represent information specific to the particular autonomous
message. The format of the text block is as follows:

((<cr><lf>^^^<unquoted line>) | (<cr><lf>^^^<quoted line>) | (<cr><lf>^^^<comment>))
AdventNet Inc. 142

TL1 Tutorial

It consists of three components namely unquoted line,quoted line and comment. Both quoted and
unquoted lines consists of text that is parsable, while comment is not. The most popular usage of
unquoted line is for representing error codes in some response messages. The quoted line consists of
parsable text and shall be preceded and followed by double quotes. The comment line is used to
allow free format text. It should be preceded by (/*) and followed by (*/).

Terminator
The form of the terminator is :

<cr><lf>( ; | >)

The semicolon (;) character indicates the termination of the output message and greater than (>)
character indicates more output associated with this response will follow under another header. Since
the size of the output message should not exceed 4096 bytes, it is important to split the response into
blocks with the same Ctag.

Example

Assume that the input command

RTRV-NETYPE:Source::100; was issued, a typical NE output message will look like the following:

<cr><lf><lf>
^^^Source^04-04-04^05:05:05<cr><lf>
M^^100^COMPLD<cr><lf>
^^^"NORTEL,OPTera Metro 3000 MSP Series NP,ABC,REL0900"<cr><lf>
;

where '^' indicates space character.
AdventNet Inc. 143

TL1 Tutorial

11.2.4 Acknowledgement Message

General Format

An acknowledgement is a brief output message generated in response to an input command
message. An NE may optionally have the ability to turn on or off acknowledgements via a Standard
input command, Custom command, or message from a local terminal. In general, an
acknowledgement is later followed by an output response message to the command. However, in
some circumstances,an acknowledgement is the only output message triggered by a command. An
acknowledgement should be used if an output response message to the command cannot be
transmitted within two seconds of its receipt.

The format of an acknowledgement is as follows:

<acknowledgement code>^<ctag><cr><lf>
<

The acknowledgement code identifies the reason for the acknowledgement. The CTAG identifies the
associated input command. The less than (<) character is the acknowledgement terminator.

Acknowledgement Codes
The valid values for acknowledgment codes and their meanings are given below.

IP - In Progress and PF - Printout Follows
The request has been initiated. These acknowledgements should produce output messages
that give a termination report or results of the command along with termination report. They
are used often for test and access messages requiring a long execution time. These
acknowledgements are often followed by either Completed or Denied response messages.

OK - All Right
The command was received and the requested action was initiated and completed. In
addition, OK is used in response to a command that has been cancelled by inclusion of the
CAN (Cancel) character.

NA - No Acknowledgement
This command is sent if initiation or execution of the requested command is not possible.
Under abnormal conditions, NA is sent when command has been accepted but control of the
processing has been lost. It can also be used to respond in circumstances if the command is
garbled during transmission. If the CTAG value of the command could not be determined,
then Zero (0) should be used as a CTAG value for the acknowledgement.

NG - No Good (Not Used)
The command is valid but the requested action conflicts with current system or equipment
status. For inadequate system resources use RL instead of NG. This acknowledgement code
is seldom used because specific error codes in output response messages can be employed
to signify the same information. It can be used if desired.

RL - Repeat Later
The requested action cannot be executed due to unavailable system resources caused by
system overload, excessive queue lengths, busy programs etc. The command can be sent at
later times for any response.

Example

IP 25 <

where IP indicates request is in progress and 25 indicates CTAG value as that of the input message.
AdventNet Inc. 144

TL1 Tutorial

11.2.5 Autonomous Message

An Autonomous message is a message that is sent from the NE to the appropriate OS without having
an explicit input message associated with it.

Typical scenarios where autonomous messages are used include :

Reporting of alarmed or non-alarmed trouble events.
Reporting of scheduled diagnostic tests in the NE.
Reporting of Performance Monitoring data.
Reporting of a change in the NE's database.
Periodic reporting of selected NE conditions.

General Format
The general structure of a TL1 Autonomous message is:

<header><auto id>[ <text block>] <terminator>

Here the text block is the optional field and all other fields are essential.

Header

The Header represents information common to all output response and autonomous
messages. It contains System identifier <sid>, date and time stamps.

<cr><lf><lf>^^^<sid>^<year>-<month>-<day>^<hour>:<minute>:<second>

It contains System identifier <sid>, date and time stamps.<sid>is restricted to 20 characters
maximum and identifies the NE generating the message. The syntax of <sid>is any TL1
identifier or text string. The <year><month><day>construct represent the day in which the
output response is generated. The <hour><minute><second>construct represent the time at
which the output response is generated.

AutoID

It indicates the severity and the nature of the Autonomous message. The <Auto id> entry for
an autonomous message is of the form

<cr><lf><almcde>^<atag>^<verb>[^<modifier>[^<modifier>]]

Where <almcde> is the alarm code. It can be any of the following based on the severity of the
autonomous message.

Alarm code and Description

*C : Critical Alarm
** : Major Alarm
*^ : Minor Alarm
A^ : Non-Alarm Message

If Multiple Alarms are reported in the same message, the alarm code is the highest severity of
those being reported.

<atag>is the Autonomously Generated Correlation Tag. It is assigned by the NE, must be
sequential and must be included in all autonomously generated messages. It allows an OS to
AdventNet Inc. 145

TL1 Tutorial

correlate spontaneous outputs triggered by a common problem and also to identify whether the
OS has failed to receive any output.

<verb>[^<modifier>[^<modifier>]] entry identifies the nature of the spontaneous output. The
first identifier is a required entry and indicates the message verb. The autonomous message
can have two optional modifiers separated by space character.

Text Block
The optional [<text block>] is used to represent information specific to the particular autonomous
message. The format of the text block is as follows :

(<cr><lf>^^^<unquoted line>)|(<cr><lf>^^^<quoted line>)|(<cr><lf>^^^<comment>)

It consists of three components namely unquoted line, quoted line and comment. Both quoted and
unquoted lines consists of text that is parsable, while comment is not.

Terminator
The terminator block has the form
<cr><lf> ( ; | >)

This is required for all TL1 message types.

Example

<cr><lf><lf>
^^^SPFGX507 99-01-01 06:06:06 <CR><lf>
A^^123^REPT^ALM^COM <cr><lf>
^^^"SP:MJ ,INT,NSA,01-01,06-06-06,NEND,NA:\"Disk Full\"" <cr><lf>
;
where '^' symbol indicates Space
AdventNet Inc. 146

TL1 Tutorial

12.0 Other tutorials

AdventNet Web NMS is vast in its capability to serve its different class of users. It would be hard for
anyone to understand all of its features at one time. We strongly recommend you to go through some
of our other tutorials to get of feel of what could be done on our Web NMS.

Building an Element Management System

This tutorial provides working illustrative examples to guide the developer through designing an EMS.
Design aspects and the usage of Web NMS tools to simplify the development of an EMS are
elaborated here.

Building an EMS with CORBA as Southbound Interface

This tutorial explains how developer can build Element Management Systems, which support CORBA
as the southbound interface. In this tutorial, we have used TR-005 and TR-035 standards specified by
the ANSI T1M1 forum. It explains, how developer can implement the Working Text, WT-046 Version
3.0 as specified in the DSL forum.

CORBA Northbound tutorial

This CORBA Northbound Tutorial shows how easily AdventNet Web Network Management System
(NMS) can be used for distributed NMS applications by providing CORBA northbound support to
interact with other Northbound Operational Support Systems (OSS).

XML Southbound tutorial

This tutorial builds an EMS with the information got from an XML enabled device. From the
responses received the EMS chassis is built and some other functions are included.
AdventNet Inc. 147

Tl1 Tutorial

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tl1 Tutorial

Uploaded by

Copyright:

Available Formats

TL1 Tutorial

You might also like