Table Of Contents
EMS TUTORIAL ... 3
1.1 Foreword... 4
1.2 Introduction ... 8
1.3 EMS Tutorial Tour... 10
1.4 Application Overview ... 11
2. TRY IT YOURSELF ... 14
3. APPLICATION DESIGN ... 19
4. MODELING THE MANAGED RESOURCES... 22
4.1 Detailed Resource Modeling... 25
5. IMPLEMENTATION ... 28
5.1 Creating EMS Project ... 30
5.2 Modeling the Switch and Its Components ... 31
5.2.1 Managed Resource Modeling... 32
5.2.2 Customizing TrunkPort Object... 35
5.2.3 Customizing Port Object for Status Polling... 36
5.2.4 Customizing Other Objects... 38
5.3 Discovering Switch Devices... 39
5.3.1 Creating Discovery Filter ... 41
5.3.2 Customizing Discovery Filter Code... 42
5.3.3 Adding Device Components in Database ... 45
5.3.4 Adding Trunk Objects in Database ... 50
5.3.5 Making Database Transaction Rollback Compliant... 53
5.6 Configuring the Switch... 69
5.6.1 Switch Configuration ... 70
5.7 Client-side Implementation ... 72
5.7.1 Building Chassis ... 73
5.7.1.1 Designing Main Screen... 77
5.7.1.2 Designing Shelf Screen ... 80
5.7.1.2 .1 Designing Access Card ... 81
5.7.1.2 .2 Designing Trunk Card ... 90
5.7.1.2.3 Building Property Screen... 97
5.7.1.3 Chassis Configuration... 103
5.7.1.4 Compiling and Packaging the Application... 105
5.7.2 Building Configuration Screen ... 107
5.7.2.1 Designing Main Screen - Switch Configuration Screen... 110
5.7.2.2. Designing Panels for Main Screen... 116
5.7.2.2.1 Designing System Configuration Panel ... 117
5.7.2.2.2 Designing Spanning Tree Details Panel... 119
5.7.2.2.3 Designing Port Parameters Panel ... 121
5.7.2.3 Integrating Panels and Adding Actions for Button... 125
5.7.2.4 Compiling and Packaging the Application... 131
5.8 Packaging the Project... 133
5.9 Making the Switch configuration secured ... 134
5.9.1 Using Authorization Service to implement Security... 136
5.9.2 Customizing Configuration screen code to implement Security ... 138
5.10 Re-branding ... 139
6. FAST TRACK IMPLEMENTATION ... 140
7. DEPLOYMENT AND TESTING ... 141
7.1 Installation Notes ... 141
7.2 Testing the Application ... 143
8. HOW DOES THE APPLICATION WORK? ... 145
9. KNOWN ISSUES ... 149
10. TROUBLE SHOOTING TIPS ... 150
11. GLOSSARY ... 152
EMS Tutorial
Element Management System
AdventNet Web NMS Tutorial
Version 1.0
A simple guide to developers on how to build an Element Management
System on AdventNet Web NMS 5 using the AdventNet Web NMS Eclipse
Plugin.
AdventNet, Inc. 4900 Hopyard Rd., Suite 310 Pleasanton, CA 94588, USA Phone: +1-925-924-9500 Fax : +1-925-924-9600 http://www.adventnet.com [email protected]1.1 Foreword
AdventNet Web NMS aims at providing real world network management solutions to telecommunications 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.
EMS tutorial will demonstrate how the above market expectations are met by AdventNet Web NMS. • Real World Network Management Solutions
• Why AdventNet Web NMS • Application Life Cycle
Real World Network Management Solutions
Real world network 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.
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 manage your custom equipment. Eclipse, Integrated Development Environment is a widely used open source development
environment. AdventNet now provides WebNMSEclipsePlugin which will seamlessly plug into the Eclipse IDE and provide you with a powerful suite of Wizards and Tools that help you to develop your management application very fast.
This in turn brings host of benefits:
• The time taken to deploy the application is lesser compared to the conventional development and deployment techniques.
• It supports user from the level of novice to professional. The webnms plugin has wizards that auto generate the required stub code as well as place entries in respective configuration files making the development easier.
• It liberates the user to concentrate on the business logic or the domain specific requirements rather than learning the configurations for the WebNMS framework.
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: Packaging
Step 4: Deploying
Step 5: Rebranding the management solution Step 6: Testing
The following diagram gives an overview of the experience of building management solutions with the AdventNet Web NMS.
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 and hence the managed system can be modeled. 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 be easily accomplished by using the Model Managed Object Wizard of
AdventNet WebNMS EclipsePlugin. It helps you walk through the steps in terms of the object that needs to be extended, the new attributes of your network element, adding properties for the MO and it also configures hibernate mapping properties for the MO. The Generate Java Source Wizard, will take the mapping file generated earlier as input and auto-generate the Bean/POJO code for the Modeled ManagedObject.
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: Packaging
You can package your application resources alone as a NAR (NMS Archive file) that can be installed over the AdventNet Web NMS.
Step 4: Deploying
The nar for Project created using the Package Properties Wizard in the Eclipse Plugin has to be installed over Web NMS. This task can be performed using the Nar Installer present in the Deployment Wizard. The Installer wizard with an easy- to- use interface helps you walk through the process of installing the nar.
You can invoke the Deployment Wizard by using the WebNMS > Tools > Deployment Wizard menu.
Step 5: Rebranding the Management Solution
You can rebrand the application to display the name of your company, the name of your product, and your logos.
Rebranding cannot be done within the EMS project created in Eclipse. It has to be done directly in the Web NMS Installation. To do Rebranding, invoke <Web NMS
Step 6: 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. The EMS Project created using the WebNMS Eclipse Plugin makes it easy to handle upgrades.
1.2 Introduction
The purpose of this tutorial is to guide you through designing an EMS and provide working, illustrative examples to help you understand the choices to be made during development. This describes how AdventNet Web NMS EclipsePlugin can be used to simplify the development of an EMS.
The Tutorial
Consider a real life scenario wherein you need to manage five Switches, which support SNMP. This tutorial will help you achieve the same by using AdventNet Web NMS by building an EMS (Element Management System) to manage the Switches.
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 EclipsePlugin to suit your needs. Using AdventNet Web NMS EclipsePlugin the EMS application is just a few clicks away requiring you to incorporate only your network specific business logic. This makes the development faster.
This tutorial helps you to build only a sample application. In which, it adopts a generic network device (i.e., a Switch, which supports SNMP) 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 using the AdventNet Web NMS.
Prerequisites
To develop this tutorial application, you will need a good knowledge of Network Management System and basic Java Programming.
Knowledge of 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 EclipsePlugin and AdventNet Web NMS. For detailed information, refer to the Web sites listed below:
1. AdventNet WebNMS Eclipse Plugin Guide - 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
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://www.adventnet.com/products/webnms/tutorials/ems_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
Courier New Code snippet
Courier New Bold Italic Highlighting important code snippets
At the end of the tutorial
You will learn how to
• Build an EMS by customizing AdventNet Web NMS with the help of AdventNet Web NMS EclipsePlugin.
• Model Objects.
• Achieve Fault, Configuration, Performance and Security managements, and Discovery of network elements.
1.3 EMS Tutorial Tour
Welcome to the EMS Tutorial Tour
This tutorial is in three stages.1. In Stage One, you are provided with the ready built application. For a quick look at what the application is all about, you can straight away deploy the application in AdventNet Web NMS and experience the outcome of the application before getting into building the application on your own. Refer the Try it yourself topic for Stage One of this tour.
2. In Stage Two, you are guided to build the application yourself. You are provided with
elaborate details about building the Application using the AdventNet Web NMS EclipsePlugin. Refer the Detailed Implementation section in full for Stage Two of this tour.
3. In Stage Three, you are provided with the ready built project. Refer the Fast Track
Implementation section in full for Stage Three of this tour. You can also experiment with the Project. Open the Project in AdventNet Web NMS Eclipse Plugin and make the changes, customize, add new features etc., as per your requirement, compile and package it. Deploy it in AdventNet Web NMS. You can see the effect of changes you done in the application. Hope you will enjoy this tour and experience easy and quick Application development.
The following flow-line diagram has image mapping to the corresponding topics.
1.4 Application Overview
In this section, an overview of the Tutorial Application is provided.
Normally, while building an EMS you would require external Switches simulator or real Switches (which in any case is not advisable) to run and view the result of the example application. However in this tutorial to avoid external dependencies the tutorial has been modeled/designed to convert the first five network elements discovered which support SNMP, as SNMP Switches. The discovered
elements will be modeled as customized Switch objects and predefined slots, cards, etc. are also added.
The tutorial application provides information on how to develop an EMS to manage the five Switches. 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 : Element Management System Version of Web NMS
used
: Web NMS Release 5
Compatibility with other Versions
: Not compatible with previous versions of Web NMS
Tools used and their Versions
: Eclipse 3.3 along with the AdventNet WebNMSEclipse Plugin
Platform-specific requirements
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 Switch and component Objects • Discovering Switch devices
• Customizing Maps to display the Switches • Managing Alerts of Switch and its components • Configuring the Switch
• Making the Switch configuration secured • Rebranding AdventNet Web NMS as your EMS
Modeling the Switch and component Objects
In AdventNet Web NMS, the managed device data is stored in the database for persistency. For storing the managed devices' data into a database, you need to model the managed device and it's components.
The tutorial explains how the first five SNMP Nodes discovered are modeled as switches. In order to simulate a real time switch, the related components objects like 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 SNMP Switch device and it's sub components.
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 filter out the first five SNMP 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.
Customizing 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.
The discovered switches are drawn on the map using a custom map layout. The various components of the switch are shown in the Chassis view.
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 customize the Fault management features.
• The Trap handling topic explains how to process traps effectively. • The Status polling topic deals in a detailed manner on how to carryout
Configuring the Switch
AdventNet Web NMS enables you to configure the network devices, where you can also schedule a task to get executed at any convenient time. If the configuration of the device does not succeed then the previous settings of the device can be restored. All the configuration information (tasks) are cached in a XML file which can be reused.
The tutorial illustrates how Configuration Management can be implemented to configure the modeled Switch components.
Making the Switch configuration secured
AdventNet Web NMS implements Security management using the Authorization Service. The tutorial implements Security management using the Authorization Service of Web NMS.
Rebranding AdventNet Web NMS as your EMS
The tutorial re-brands AdventNet Web NMS into Acme EMS. The logo, images etc., can be replaced with your own. You have the i18N tool for internationalisation of various UI reference of AdventNet and Web NMS. With these the EMS developed can be easily re-branded.
2. Try It Yourself
In this section, the steps to deploy the ready built application are provided. This would help you run the application by yourself and view the results.
The steps involved are • Before You Begin
• Get the Application's NAR File
• Deploy the NAR in AdventNet Web NMS • Start NMS
• View the Result
Before You Begin
• Download an evaluation copy of AdventNet Web NMS 5. • Get it installed in your machine.
For pertinent information, refer to the following document resources in the Installation Guide of AdventNet Web NMS 5
• System Requirements • Startup Options
Get the Ready Built application
The working example comes bundled with AdventNet Web NMS, as a NAR file. The NAR is actually the ready-built application. Another alternative is to download the latest version of the tutorial from the AdventNet Web site and use the NAR in it.
a. Use the bundled application
The working example comes bundled along with AdventNet Web NMS, as a NAR file.
OR
b. Download the latest version
You can download the latest version from the Web site at the following URL:
http://www.adventnet.com/products/webnms/tutorials/ems_tutorial.zip
Unzip the zip file in the <Web NMS HOME> directory.
Select the NAR file mentioned below from the <Web NMS HOME>/tutorials/ems_tutorial directory.
EMS_Tutorial1.0.nar
Deploy the Application in AdventNet Web NMS
Start NMS
Prior to installing the NAR, if the server was running, Stop the server then Reinitialize the WebNMS
server and Now start the server.
To Reinitialize WebNMS Server, Run reinitialize_nms.bat under <WebNMS Home>/bin directory. (or) To reinitialize the Server from the launcher, it is essential to add EMS_Tutorial_Server.jar in the classpath. Follow the below steps to add EMS_Tutorial_Server.jar in the classpath.
• Start the Web NMS Launcher, by invoking WebNMSLauncher.bat/sh file in the <Web
NMSHOME> directory. In the WebNMS Launcher, Select Options->Settings menu. Settings dialog screen is opened. In this dialog, select "Reinitialize Web NMS" in the left side tree. "ClassPath" details will be seen in the Right-side panel.
• Click on the Add button, a line will be added in the ClassPath text area, Now click on the button "...", this will allow you to browse and select the EMS_Tutorial_Server.jar from the <WebNMS Home>/NetMonitor/build directory. Now, This jar will get added in the classpath. • Next click OK to Save the settings.
• Now, Invoke the "Reinitialize Web NMS" icon in the Web NMS Launcher to reinitialize the server.
Start the WebNMS Server by running startnms.sh/bat under <WebNMS Home>/bin directory. Alternatively you can also start the server from Web NMS Launcher. To start the Web NMS Server from the launcher, it is essential to add EMS_Tutorial_Server.jar in the classpath. Follow the below steps to add EMS_Tutorial_Server.jar in the classpath.
• Start the Web NMS Launcher, by invoking WebNMSLauncher.bat/sh file in the <Web
NMSHOME> directory. In the WebNMS Launcher, Select Options->Settings menu. Settings dialog screen is opened. In this dialog, select "Start Web NMS Server" in the left side tree. "ClassPath" details will be seen in the Right-side panel.
• Click on the Add button, a line will be added in the ClassPath text area, Now click on the button "...", this will allow you to browse and select the EMS_Tutorial_Server.jar from the <WebNMS Home>/NetMonitor/build directory. Now, This jar will get added in the classpath. • Next click OK to Save the settings.
• Now, Invoke the "Start Web NMS Server" icon in the Web NMS Launcher to Start the server.
View the Result
Connect a Browser or Application client to the Web NMS Server in port 9090 as follows: Browser Client : Enter http://<host-name or IP>:9090 in the address bar
Application Client : Double-click Application Client icon from the Web NMS Launcher. Alternatively you can also start the client by running startApplicationClient.bat under <WebNMS Home>/bin directory.
On double-clicking the individual Switch nodes, you can see the Chassis view of the individual switches.
The Switch elements have right-click menu with four menu items, viz., Alerts, Events,
Configuration, Chassis View. Select Chassis View menu item will display the Chassis view
Chassis View of the Switch Device
The Chassis view of Switch device shows the various components of an individual switch. The diagram is given below. If there is any problem in viewing the Chassis View, kindly refer the section TroubleShooting Tips
The map shows a shelf with 16 slots numbered (0-15). Each slot has a card associated with it. The alternate cards are modeled as empty. The cards, which contain only one port are called Trunk Ports and four such Trunk Ports are added to the switch. The remaining cards contain four Access Ports.
You can view the Alerts, Events, and Properties of the individual sub-components of the Switch (i.e., Card and Port).
Alerts from the Switch Device and Sub-components and Its Propagation
Right-click a device and select Alerts from the pop-up menu to see its alerts. 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.Configuring the Switch and Sub-components parameters
In this application, the configuration management has been used to configure the modeled switches. The following GUI pops up on clicking configure switches option after selecting the switches you wish to configure from the switches map.
If there is any problem in viewing the Configuration View, kindly refer the section TroubleShooting Tips
Secured Configuration of the Switch
Right-click the device and select Configuration from the pop-up menu to see the Switch Configuration screen. The Configuration Management screen is used to demonstrate the security feature based on the operation assigned to the user. The image below has two of the tabs removed, which indicates that the user is a normal user and has no permission to change the Spanning tree and Port parameters of the switch. If you log in as an administrator, the STP and PortParameters tab will be available.
3. 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.
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 • Configuring the Switch Device
• Rebranding AdventNet Web NMS as your EMS
Managed Resource Modeling
Objective
Modeling a device enables you to represent the various attributes and the behavior of the corresponding physical device and its components in a convenient way so as to reflect their current state at any time. The EMS stores these persistent data in the database.
Modeling the Switch and its components 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:
Switch serialno, location
Shelf serialno
Slot slotno, state
Card serialno, cardType
Port portno, speed, snmpInterface, switchnode Access Port remoteID, remoteStatus, portType
Trunk Port trunk, remotePortID, portType
Tasks
• Create a Discovery Filter defining the containment hierarchy of the device and its components.
The Role of Eclipse Plugin
The DiscoveryFilter Creation Wizard will help you to 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 Switch Device and Its Components in the Map
Objective
To graphically represent the Switch Devices and its components, illustrating the Containment hierarchy, in the map view of Web NMS Client.
Tasks
• Create a criteria map to filter out all the Switches and display in a separate map • Create a MapFilter class that will create links to visually represent the Trunk objects
connecting the switches on the criteria map The Role of Eclipse Plugin
Using the MapFilter Creation Wizard, all the above tasks can be completed.
Managing the Events and Alerts of Switch and Its Components
Objective
To monitor and manage the failures in the system effectively including, polling the Switch Device and its components periodically for their status and thereby take preventive action where necessary.
Tasks
• Convert the failure notifications (Traps) into meaningful Events. • Check the Device Status by polling the devices.
The Role of Eclipse Plugin
Using the TrapFilter Creation Wizard, it is easy to create a Trap Filter that filters the traps and converts them into meaningful Events which can be managed.
The Managed Object is modeled to check the status of the device.
Configuring the Switch Device
Objective
The EMS 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
The Role of Eclipse Plugin
The Configuration Wizard of Client Builder is used to configure tasks and set Device lists where the tasks have to be executed.
Rebranding AdventNet Web NMS as your EMS
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, Acme EMS).
Tasks
• Replace the existing AdventNet & Web NMS images and logo with Acme. Internationalize the text and buttons that appear in the Client of the EMS.
The Role of Eclipse Plugin
Rebranding cannot be done within the EMS project created in Eclipse. It has to be done
directly in the Web NMS Installation. To do Rebranding, invoke <Web NMS Home>\bin\developertools>startRebrandingTool.bat
4. Modeling the Managed Resources
This topic concentrates on various aspects involved in the design of Managed Object. The various aspects covered are listed below:
• What Are the Different Methods Available to Design Managed Resources? • How is the Web NMS Core Object Resource Modeled?
• An Example Modeling of Object Resources for This Application • Class Diagram of Managed Resources of EMS Application • Naming Convention Used in Modeling the Managed Resources
What Are the Different Methods Available to Design Managed Resources?
We have two choices for our design of managed elements.1. Using the dynamic properties of Web NMS Managed Objects. 2. Extending the existing Managed Objects.
The former is a quick solution requiring minimal design effort but a cumbersome design. The later is a cleaner design. The second choice will serve our application needs better, because it provides a neat design. This approach also results in a better table structure for storing our objects in an RDBMS. Hence, the second approach is adopted in this tutorial.
How is the Web NMS Core Object Resource Modeled?
The core Object model of AdventNet Web NMS is simple and is easy to learn and extend for each application. The elements of the core model are designed for IP networks and are sufficient to represent common IP networks. However, for most specific applications, e.g., the management of a cable modem system, the model will be extended.
The topology database has the following base elements:
ManagedObject : The base class of all objects in the Topology database.
TopoObject : The base class of all IP objects in the Topology database.
Network : This object represents an IP network.
Node : This object represents an IP network node.
SNMP Node : This object represents an IP network node with an SNMP Agent.
IP Address : This object represents an IP interface.
An Example Modeling of Object Resources for This Application
Let us look at an example of modeling a complex network device, consisting of shelves, slots, cards, and ports. This generic example will illustrate the modeling procedure. The EMS tutorial application models a switch with associated shelves, slots, cards, and ports. The following relationships are assumed between the Managed Objects:
Switch : This represents a manageable switch that is initially discovered via
SNMP, i.e., Web NMS finds it as an SNMP Node in the network or is manually added by an operator.
Shelf : The switch consists of one or more shelves. For this example, we will
work with only one shelf, though the example can be extended to multiple shelves.
Slot : Each shelf consists of 16 slots, which are numbered 0-15.
Card : Each slot consists of a card, which can be of different types. In this
example, we will work with only one card type. The card object has a field called Card type to specify the card type.
Port : Each card can have multiple ports. A port can be an access port or a
trunk port.
AccessPort : The AccessPort class is a subclass of port and models a port on an
access card.
TrunkPort : The TrunkPort class is a subclass of port and models a port on a trunk
card.
Trunk : This models a link between switches, i.e., a trunk connecting two
switches.
These components are modeled in the Web NMS topology database and these definitions are used to build an EMS functionality into our application.
Class Diagram of Managed Resources of EMS Application
Naming Convention 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:
<switchname>_Shelf<N1>_Slot<N2>_Card_Port<N3>
where <switchname> will be the name of the switch and <N1>, <N2> and <N3> are numbers to identify the ManagedObject within a container.
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. We will create a set of objects based on this model and start with the discovery or manual addition of the switch. In the example code provided, we assume the first five SNMP Nodes to be switches instead of looking for specific switches.
Managed Object Parent-Child Containment Relationship
In our EMS example model, the many-to-one containment relationship needs to be modeled across the device components. That is, cards are contained within a slot, slots within a shelf, and shelves within a switch. For mapping this relationship, we use the parent-children modeling feature available in the ManagedObject class.
The containment relationship can be captured in out component classes just by setting the
isContainer property of the parent component to true and setting/storing the parent object's
name/key in the child component object using the setParentKey() method. 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, with its parentKey property set appropriately, are added to the database.
In the discovery filter while adding the following parent components, the isContainer property has been set to true:
• Switch • Shelf • Slot • Card
Note: Another benefit of this ManagedObject property, namely ParentKey is, it
allows for quick look up of the component object hierarchy as required when propagating alarms.
4.1 Detailed Resource Modeling
For each of the components of the network device, we have created a ManagedObject subclass. The following list captures the properties we have provided in each component we modeled, i.e., the ManagedObject subclasses.
Switch serialno, location
Shelf serialno
Slot slotno, state
Card serialno, cardType
Port portno, speed, snmpInterface, switchnode
AccessPort remoteID, remoteStatus, portType
TrunkPort trunk, remotePortID, portType
Trunk source, destination, srcPort, destPort, bandwidth
Switch
The Switch object will extend an SNMP Node object instead of ManagedObject directly. This is because our example assumes the switch supports SNMP and will be discovered as an SNMP Node. In your case, if the switch does not support SNMP you may extend node or ManagedObject directly as appropriate. We will provide the following additional properties in the switch, in addition to what is available in an SNMP Node class:
Location : The physical location of the switch.
Serial number
: The serial number of the switch.
Shelf
The Shelf object will extend ManagedObject. We will provide the following additional properties in the shelf, in addition to what is available in a ManagedObject class:
Serial number
: The serial number of the shelf.
Slot
We will create a ManagedObject subclass to model the Slot. We will provide the following additional properties in the slot object, in addition to what is available in a ManagedObject class:
Port
The Port object is also directly sub classed from ManagedObject. To capture the containment of ports in switches, we will add a property to capture this relationship. We do not keep a reference to the switch, but rather store the key that identifies the switch that we can query from the database. We will provide the following additional properties in the port object, in addition to what is available in a ManagedObject class.
SNMP Interface
: The network interface object (IP Address) associated with this port, if any.
Port number : The port number is the identification of position on the card.
Speed : The data transaction speed of the Port
Switch Node : The Switch Node to which the Port belongs.
Note: The Switch Node property will help us in querying for all ports of a particular
type belonging to a switch, as we do in the discovery filter for linking switches using trunks.
We add this property to this port object so that we can make the query quickly and easily. But this is not a must. We can also get the TrunkPorts of a given switch by traversing/scanning recursively across the containment hierarchy using the
getChildrenKeys() method of the ManagedObject. Or we can also use SQL queries, fired from the discovery filter, under database mode. Only the query will be
somewhat complicated.
AccessPort
The AccessPort object is sub classed from Port. We will provide the following additional properties in the AccessPort object, in addition to what is available in the port class:
Remote ID : An identifier for what is connected to this AccessPort. Could be an
equipment serial number or location of a customer site where the access device is.
Remote Status
: The status of the device connecting to this AccessPort.
portType : Denotes the type of port used (Here, it is Access Port)
TrunkPort
The TrunkPort object is sub classed from port. We will provide the following additional properties in TrunkPort object, in addition to what is available in the port class:
Trunk : The trunk that terminates on this port. This is a reference to the trunk
object.
Remote Port ID
: The ID of the remote port at the other end of an attached trunk.
Trunk
The Trunk object is sub classed from ManagedObject. We will provide the following additional properties in the trunk object, in addition to what is available in the ManagedObject class:
Source : The switch that one end of this trunk terminates. No fundamental
distinction is made between source and destination here.
Destination : The switch that one end of this trunk terminates.
Source Port : The port on which this trunk terminates.
Destination Port
: The port on which this trunk terminates, i.e., the port on the destination switch.
5. Implementation
This tutorial application has been created using AdventNet Web NMS Eclipse Plugin. This comes bundled with AdventNet Web NMS.
Using AdventNet Web NMS Eclipse Plugin
The AdventNet Web NMS Eclipse Plugin can be deployed in your Eclipse IDE installation, then a new type of project "EMS Development project" will be added to the Eclipse IDE. For this tutorial you can now create a new EMS Development project in Eclipse and customise the WebNMS services in this project. 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 Eclipse Plugin 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.
Implementation overview
Model the Managed Resource
Model your Switch 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 Model Managed Object Wizard. In the end, you will get the Managed Resource's class and the corresponding Hibernate mapping file.
Build Discovery-related Files Using Discovery Service
Create a Discovery filter to discover the Switch objects you have modeled in the previous task. Invoke the DiscoveryFilter Creation Wizard and enter the Package Name and Filter
ClassName. 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
Modify maps.conf file to add Custom Map. Create a Map filter to display the discovered Switches. Add custom code in this filter to represent the Trunk object as a link between the switches in the map. Configure mapIcon.data file to specify map iconName, its corresponding device type and the menuName. Create a Chassis view and other related screens for the Switch using Chassis Wizard.
Build Fault Management-related Files Using Fault Service
Create a Trap filter to process the traps. Add Custom code to handle Addition of Card and Deletion of Card. Model the managed object to check the device status (a method in the Managed Object class to check the status; here, it is the checkStatus() method) .
Build Configuration-related Screens Using Configuration Wizard
Configure Authorization to Various Users Using Security Administration
Tool
The Security Administration screen contains two nodes under Security - Groups and Users. Create groups and users for the respective nodes as shown below:
Groups -> Users Admin Users -> guest root
Configure authorization for the Users to carryout various operations using the Security Administrator Tool.
Rebrand the Application Using the Rebranding Tool and i18N Editor
Tools
Change the splash image, logo, and frame icons etc. in the Rebranding tool and Company Name, Product, and Version in the i18N Editor tool.
5.1 Creating EMS Project
The first step toward any implementation using the AdventNet Web NMS Eclipse Plugin is to create a EMS Development Project. The project stores all the information that are essential for developing the application.
Starting Eclipse IDE
Install the Eclipse version 3.3 in your machine. Get the latest Web NMS - Eclipse plugin
(WebNMSEclipsePlugin.jar file) from <Web NMS Home>/StudioTools/Studio/jars directory and
unzip this jar file in the <Eclipse Installed directory.> and then Start Eclipse IDE.
Please note that you will need to run eclipse using JDK 1.5 or above. You can use the command mentioned below to start eclipse after deploying the plugin:
eclipse -vm <jdk1.5 home>\bin\java
For details on Creating Project, refer to the Web NMS EclipsePlugin Guide.
Instructions
Follow the steps given below to create the project.
Step 1: Invoke the Project Wizard
Select File > New > Create EMS Project menu to invoke the EMS Development Project Wizard.
Step 2: Add Project Details
Provide the following details about the EMS Project.
Enter the Project Name and Web NMS Home to create a new EMS Development Project. Here the "Enable Web-Client Support" can be left unchecked as in this tutorial, it is not necessary to incorporate any web-client related changes.
Project Name - EMS_Project
Web NMS Home - C:\AdventNet\WebNMS
Enable Web-Client Support Leave it unchecked
Click Finish.
You will find the created project under the Package Explorer tree
Result
The Workspace for the Project is now created. Using the Model Managed Object Wizard, we will see how to model the Switch Device and its components in the next section. You can proceed with modeling the device. You can also invoke the wizard by clicking WebNMS > Modeling > Model
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 behavior of the physical device and subcomponents are modeled as attributes of the objects. By controlling/monitoring the attributes of the objects, the physical device can be managed by the 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 real life device, its components, status, and behavior into a network management application manageable form. This is achieved by modeling them as Managed Resources.
In this example application, we have taken a generic Switch. The Switch holds four Access card. Each Access card has four ports and these ports are used to connect the devices, which require the service of the switch. The Switch holds another four Trunk cards. Each Trunk card has one port and it is used for connecting this Switch to another Switch.
The following table lists the Real life device/components, which are required to be modeled as Managed Resources, the core Web NMS Resources which are extended in order to represent these Resources, and the Properties which are mapped to the status/behaviour of the physical
device/subcomponent.
Managed
Resource
Core Web NMS Resource
Properties to Be
Managed
Switch com.adventnet.nms.topodb.SnmpNode serialno, location Shelf com.adventnet.nms.topodb.ManagedObject serialno Slot com.adventnet.nms.topodb.ManagedObject slotno, stateCard com.adventnet.nms.topodb.ManagedObject serialno, cardType Port com.adventnet.nms.topodb.ManagedObject portno, speed,
snmpInterface, switchnode
Access Port com.adventnet.nms.tutorials.ems.Port remoteID, remoteStatus, portType
Trunk Port com.adventnet.nms.tutorials.ems.Port trunk, remotePortID, portType
Trunk com.adventnet.nms.topodb.ManagedObject source, destination, srcPort, destPort, bandwidth
Refer to the Detailed resource modeling topic in Appendix to this document, for more explanation about the Modeled Resources and their Properties.
5.2.1 Managed Resource Modeling
Aim
The Switch 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 on Creating Managed Resource , refer to the Web NMS EclipsePlugin Guide.
Instructions
The Switch system consists of seven major components. The components with a short description is given below.
Switch : This represents a manageable switch that is initially discovered via SNMP, i.e., Web NMS finds it as an SNMP Node in the network or is manually added by an operator. Shelf : The switch consists of one or more shelves. For this example we will work with only
one shelf, though the example can be extended to multiple shelves. Slot : Each shelf consists of 16 slots, which are numbered 0-15.
Card : Each slot consists of a card, which can be of different types. In this example, we will work with only one card type. The card object has a field called Card type to specify the card type.
Port : Each card can have multiple ports.
AccessPort : A port can be an access port or a trunk port. The AccessPort class is a subclass of port and models a port on an access card.
TrunkPort : This is a subclass of port and models a port on a trunk card.
Trunk : This models a link between switches, i.e., a trunk connecting two switches.
Steps to Model Switch
Step 1: Invoke Model Managed Object Wizard
You can invoke the Wizard by clicking the WebNMS > Modeling > Model Managed Object menu. Specify the Package Name and Extended Object Name details in Step1 of the Model Managed Object Wizard.
Package Name com.adventnet.nms.tutorials.ems Modeled Object Name Switch
Click Next to proceed.
Step 2 : Component MO Table Details
In the Component MO Table Details screen, select Topo for the Select Module option, select
com.adventnet.nms.topodb.SnmpNode from the drop down list for the Parent MO/Extended Object Name option. Fill the Discriminator Value as Switch. For this project, leave the following
entries "Is dynamic update required", "Is select before update required", "Enable lazy fetching", "Is dynamic insert required", "Mark superclass as abstract" unchecked.
Step 3: Managed Resource Attributes Preview
In the MO Property Details screen, click Add button to add properties for the MO. The columns
PropertyName, Type, Column, Length will become editable. Enter the Location (String) and Serial
Number (String). Select the row of the property and click Delete button to delete the property. Alternatively, the properties of the managed object can also be selected from a MIB file. Click
Attribute Selection button, to select attributes for MO from a MIB.
In the Attribute Selection screen, to load the required MIB, click Load MIB button. Open the MIB tree and select the required MIB tree node. Once the required node is selected, Add button in the center of the screen will be enabled and the description about the selected node will be displayed in the Description text box. Now Click Add Button and then click on Save Button.The selected MIB node will appear in the Selected Attributes text box. To remove the attributes from the Selected Attributes list, select the attribute(s) in Selected Attributes list and click Delete button.
Step 4: Adding custom code
Click Finish to complete MO Modeling.You will find the Hibernate mapping file for this modeled MO under <Your Project>/Referenced Libraries/resources/classes/hbnlib/<Package of MO>/ <Modeled MO>.hbm.xml in the Project Explorer window.
After this, the Java source (i.e. the Pojo class) can be auto-generated using this mapping file by the Generate Java Source Wizard. You can add the custom code or modify the auto-generated pojo code using the editor directly as per your requirement.
Follow the above steps to model the Shelf, Slot, Card, Port, AccessPort, TrunkPort, and Trunk as per the table given below. The attribute types are specified against the properties.
Managed
Resource Parent Resource Properties to Be Managed
Shelf com.adventnet.nms.topodb.ManagedObject serialno (String)
Slot com.adventnet.nms.topodb.ManagedObject slotno (int), state (String) Card com.adventnet.nms.topodb.ManagedObject serialno (String), cardType
(String) Port com.adventnet.nms.topodb.ManagedObject
portno (int), speed (int), snmpInterface (String), switchnode (String) AccessPort com.adventnet.nms.tutorials.ems.Port remoteID (String), remoteStatus (String), portType (String)
• In Java Source Generator screen , select the Xml file (multiple Xml files can also be selected) for Generating Java Source and click >> button.
• Select the source folder to generate the Java source. • Click OK.
Compile the Shelf, Slot, Card, Port, AccessPort, TrunkPort, and Trunk nodes.
The details of the custom code meant for TrunkPort object added to the Managed Resource class are discussed in the next topic.
5.2.2 Customizing TrunkPort Object
Custom Code Specific to the Tutorial Application Requirements - TrunkPort
In addition to the properties provided, you have to provide two convenience methods,getRemotePort() and getRemoteStatus(), which are useful for quickly getting a handle on the remote port at the other end of an attached trunk.
Before you proceed to add the user code, specify the following imports for this class: import java.sql.*;
import com.adventnet.nms.severity.SeverityInfo; import com.adventnet.nms.topodb.TopoAPI;
import com.adventnet.nms.util.NmsUtil;
For providing the above two convenience methods, you have to write the custom code in the
TrunkPort source file directly.
Add the User code as given below at the end before the last "}": public TrunkPort getRemotePort()
{
if (trunk == null) return null; try {
Trunk trunkObj = (Trunk)((TopoAPI)
NmsUtil.getAPI("TopoAPI")).getByName(trunk); if (trunkObj == null) return null;
if (getName().equals(trunkObj.getSrcPort())) return (TrunkPort) ( (TopoAPI)(NmsUtil.getAPI("TopoAPI"))).getByName(trunkObj. getDestPort()); if (getName().equals(trunkObj.getDestPort())) return (TrunkPort) ((TopoAPI)(NmsUtil.getAPI("TopoAPI"))).getByName(trunkObj. getSrcPort()); }
catch (Exception ex) {
System.err.println("Exception getting remote port: "+ex); ex.printStackTrace();
5.2.3 Customizing Port Object for Status Polling
Custom Code Specific to the Tutorial Application Requirements - Port
For providing the status polling function, you have to write the custom code in the Port source file directly.Imports to the class are:
import java.sql.*; import com.adventnet.nms.severity.SeverityInfo; import com.adventnet.nms.severity.SeverityIterator; import com.adventnet.nms.topodb.TopoAPI; import com.adventnet.nms.util.NmsUtil; import com.adventnet.snmp.beans.SnmpTarget;
The default constructor will be auto-generated with only the setClassname("Port"); call inside it. Add the lines as below to set the Type property and the PollInterval property inside the constructor:
public Port() { setType("Port"); setClassname("Port"); setPollInterval(300); }
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. Here you have two methods for the status polling of Port object. The actual status polling is done by the second method
checkObjStatus() below, which is invoked by the first checkStatus() which overrides the super class method.
Add the User code as given below at the end before the last "}":
/** This does the real check to the managed object **/ int checkObjStatus()
{
// As an example, we'll use the interface status, ifOperStatus, // of the node as the status of the port. We'll use the
// port number to check status of the port.
// Alarm propagation will be used to notify containers
if ((switchnode == null) || (switchnode.equals("unknown"))) { TopoAPI tapi = (TopoAPI)NmsUtil.getAPI("TopoAPI");
String temp = getParentKey(); for (int i = 0; i < 3; i++) { try {
if (temp != null) temp =
tapi.getByName(temp).getParentKey(); } catch (Exception ex) {
System.err.println("Exception fetching the parent "+ "switch of the port: " +getName()+ex); return
} }
switchnode = temp; }
SnmpTarget target = new SnmpTarget(); target.setTargetHost(switchnode); int index = portno+1;
target.setObjectID("ifOperStatus."+index); String status = target.snmpGet();
if (status == null) {
SeverityIterator s_iter = SeverityInfo.getInstance().getIterator(); s_iter.moveToHighest(SeverityInfo.LEFT); // Default. So optional. return s_iter.getPreviousCriticality(); // MAJOR severity }
if (status.equals("1") || status.startsWith("up")) {
return SeverityInfo.getInstance().getClear(); // CLEAR severity }
SeverityIterator s_iter = SeverityInfo.getInstance().getIterator(); s_iter.moveToHighest(SeverityInfo.LEFT); // Default. So optional. return s_iter.getPreviousCriticality(); // MAJOR severity } // end checkObjStatus()
//End User Code
The check is done to see that the interface is operational for the given index corresponding to the port number on the card.
Based on the 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.
Note: When the devices are status polled at periodic interval, the output may be
either
• Status Up Events (in which case, the default severity will be Clear) • Status Down Events (in which case, the default severity will be Major)
5.2.4 Customizing Other Objects
Custom Code Specific to the Tutorial Application Requirements
Provide the following user code after the Variable Declarations for the corresponding objects to setup a unique map icon for the objects.
Switch
public Switch() { setType("Switch"); setClassname("Switch"); }Shelf
public Shelf() { setType("Shelf"); setClassname("Shelf"); }Slot
public Slot() { setType("Slot"); setClassname("Slot"); }Card
public Card() { setType("Card"); setClassname("Card"); }Trunk
public Trunk() { setType("Trunk"); setClassname("Trunk"); }Result
All the Managed Resources were created and customizations were also done. The Next task is to define a Discovery Filter to discover the Switch components.
5.3 Discovering Switch Devices
After modeling the Managed Resource, you need to make the EMS to discover the Switch 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 convert the first five SNMP Devices discovered into Switches. This filter retrieves the details of the (imaginary) Switches 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 identifies the first five SNMP devices as Switches and adds components such as shelves, slots, cards, etc.
The filter passes through only the SNMP objects. It will drop all non-SNMP objects. If this filter returns, the corresponding object will be dropped and not added to the database.
You require to restrict the number of switches to a maximum of five. For this purpose, the filter will check the database. To ensure this, the filter needs to detect warm start and add switches, only if the database has less than five switches. For this, write the custom code. Also, the filter needs to collect this information before it checks the managed object for interface so that it filters out the interface objects that do not correspond to the Switches that are added.
Refer to the Discovery Filter Flowchart for a pictorial representation of Discovery filter class code implementation.
This chapter will explain 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 Eclipse Plugin.
The following topics explain the procedure using AdventNet Web NMS Eclipse Plugin in detail: • Creating the Discovery Filter to discover the Switch devices
• Adding Custom code in the source of Discovery Filter, to the achieve the following tasks: o Customizing Discovery Filter Code to Carryout Warm Start check
o Adding Device components into the database
o Adding Trunk objects into the database
5.3.1 Creating Discovery Filter
Aim
To create a discovery filter to discover the Switch Device and its components and to set the properties for the discovered Managed Resources. The components of the Switch device are discovered by querying the Agent.
Instructions to Create a Discovery Filter
The Discovery Filter adds the discovered device as Managed Resources. This simple discovery filter will generate only stub code for discovering a single device and adding to database. It aslo generates some utility methods for querying the SNMP device for properties of the ManagedObject.
Use the Create Discovery Filter wizard to discover a single device, which is modelled as a managed object. With the filter created using this wizard, you can discover a device, which is not having any sub components. For details on Creating Discovery Filter , refer to the Web NMS EclipsePlugin Guide.
Follow the steps given below to discover the Switch Device and its components.
Step 1: Invoke the DiscoveryFilter Creation Wizard
Select WebNMS > Filters > Discovery > Create Basic Discovery Filter menu.
Step 2: Enter the Discovery Filter Details
Provide the following details about the discovery filter.
Package Name - com.adventnet.nms.tutorials.ems Filter ClassName - SwitchDiscoveryFilter
Click Finish.
You will find the <Discovery Filter class> under <Your Project>/source folder in the Project Explorer window. You can add the custom code or modify the existing code of the source using the editor directly as per your requirement.
The corresponding entry for this Discovery Filter implementation class will be inserted in the
discovery.filters file present in <Your Project>/resources/conf directory. You can rearrange the order of the discover filter entry in this file as per your requirement as each Managed Object discovered in WebNMS will be passed through all the discovery filters listed in the discovery.filters conf file.
5.3.2 Customizing Discovery Filter Code
Custom code specific to the tutorial application requirements - Part I
The following part illustrates how to layer discovery over the Web NMS IP discovery.Variable Declaration:
Add the following variable declaration above the filterObject method:
/** Counter for the number of switches added. **/ int switch_count = 0;
/** Used in warm start for fetching the switches already added. **/
Vector switch_name_vect = null; /** Warm start indicator. **/ boolean warmstart = false; Now we come to implementing the filterObject method.
Step1: Defining the criteria for processing the object
Add the code snippet given below to check if Switch objects are already present in the topology database when the WebNMS server undergoes a warmstart. As this example converts only the first 5 SNMPNodes to Switch objects we will check the number of switch objects in the database and device whenever we need to further process this MO as a Switch. Add the below code in the filterObject method before creating the instance of the modeled object.
try {
if ((switch_count == 0) && (topoApi.getNumNodes() > 0)) {
warmstart = true;
//Only first five SNMP Nodes are added as
switches, so we check if Switch objects are already present in the database
Properties prop = new Properties(); prop.put("Type", "Switch");
switch_name_vect = topoApi.getObjectNamesWithProps(prop);
switch_count = switch_name_vect.size();
NmsLogMgr.TOPOUSER.log("Discovery - Warm Start :: "
+ "Number of switches already in database: "
+ switch_count, Log.DEBUG); if ((switch_name_vect == null)
|| (switch_name_vect.size() == 0)) {
System.err.println("Error in Warm Start check. "
+ "Vector of switch names is null or zero.");
} }
} catch (RemoteException e1) {
// TODO Auto-generated catch block e1.printStackTrace();
if ((warmstart)) {
// We will have the first 5 SnmpNodes as carrier class // switches for this example.
if(((!(switch_name_vect.contains(mo.getName())))&&(switch_count >=5))) { return mo; } }
Next we handle the scenario when there is a Cold Start of the WebNMS server. Here when the filterObject method is called for the new MO, we need to check if 5 Switches are already present in the database, in which case the mo should be returned without processing it as a Switch. Add the below code to achieve this. This part of the code should follow the above code.
if (switch_count >= 5)
return mo; //we are not going to convert this as a switch.
Step 2: Add the code to create a new instance of the Switch object fill its
properties by quering the device
This part of the code should follow the above code.
//Start the code to add the switch object. switch_count++;
Switch theSwitch = new Switch(); theSwitch.setName(mo.getName()); theSwitch.setTester("max"); theSwitch.setIsContainer(true); // Get the properties of object. Properties p = mo.getProperties();
// Set the properties of switch. First remove some of the props // e.g. the class name does not apply
