Technical Tips
Offers useful tips on development using AdventNet Web NMS.
TechTips#19 - Discovering objects in
a Device having parallel hierarchy
The Custom Discovery Filter in Studio provides the logic
in discovering objects, that have parallel hierarchy and additionally
supports discovering components in the device, that are pluggable
at runtime.
To create a Custom Discovery Filter right click on the Discovery
Filter node and choose "New". In the invoked, "Select
Discovery Type" dialog choose "Custom Discovery"
and press <Enter>.
The Custom Discovery Filter for devices having parallel hierarchies,
discovers objects in the first level along with its children
components. It then proceeds to discover the second set of
components in the next hierarchy along with its children components.
The loop continues until all the components in different hierarchies
are discovered.
For example a Device having the following hierarchy
- DslamDevice
- DslamSlot (15 slots)
- DslamCard (ATMCard, CPU Card)
- FanTray
where the DslamSlot and FanTray are in the same hierarchy,
the discovery engine discovers the objects in the following
order.
- Discovers DslamDevice
- Discovers all the 15 DslamSlots
- Discovers ATM/CPU Card
- Discovers DslamPort
- Discovers FanTray
For more details read the section Custom Discovery Filter
--------------------------
TechTips#18 - Creating a Client side
file in Studio
New files can be created or the existing project files can
be modified in Web NMS Studio.
To create a Client side java file in Studio
- Right click on the OtherFiles node and choose "New"
- From the "Choose File Type" combo box choose
"Client Java".
- Specify the name of the file and other details in the
New File Dialog.
By default, the client side files after NAR installation
are placed in Web NMS Client classpath. For bundling additional
Client side jars, provide entries in the "Additional
Jars " screen of Packager wizard with Client option checked.
For more details read the section "Working with other
Files Node".
--------------------------
TechTips#17 - Reordering the execution
of filters in the .conf file
In Web NMS Studio, files (xml, java, conf, txt, etc.) can
be created and edited. All source files generated in the Project
and configuration files copied to the workspace can be viewed,
edited and user code can be added as required.
For each filter created in Studio, an entry is added in the
respective .conf file. To reorder the execution of the filters
- Select the respective .conf file from the Project Tree
- Right click on the filter node to be reordered and choose
the option "Move Up/Down" to move the filter one
level up/down. To move the filter more than one level up/down,
use the option "Copy" and "Paste".
- Save the file.
For more details read the section "Working
with XML Editor".
--------------------------
TechTips#16 - Steps to Prevent Modified
JSP File from Being Overwritten
If you have modified a specific .jsp file by either adding
an entry or by modifying an existing entry then, you need
to ensure that the file is not overwritten on applying Web
NMS Service Packs (SP). Please follow the below given steps
to prevent the modified JSP file from getting overwritten
on applying an JSP.
Let us assume that you have modified a file namely DateInput.jsp
located in <Web NMS Home>/webclient/common/jsp directory.
To prevent this file from getting overwritten do the following,
Rename the file to DateInput1.jsp.
Make a copy of the corresponding "struts-config.xml"
file and rename it as struts-config1.xml file inside the same
<Web NMS Home>/webclient/common/conf directory.
Replace the entry of the "DateInput.jsp" file
in the struts-config1.xml file with DateInput1.jsp for the
specific <action>...</action> tag as shown below.
You can remove the unnecessary <action>...</action>
tags pertaining to other JSP files in the struts-config1.xml
file.
<action-mappings>
..
<action
path="/DateInput" type="com.adventnet.nms.webclient.common.DateInputAction">
<forward name="datecomponent" path="/webclient/common/jsp/DateInput1.jsp"/>
</action>
..
</action-mappings>
Modify the web.xml file located in <Web NMS Home>/WEB-INF
directory with the following entry.
<init-param>
<param-name>config</param-name>
<param-value>/webclient/common/conf/struts-config.xml,webclient/common/conf/struts-config1.xml</param-value>
</init-param>
As per the entries given above, the DateInput1.jsp file is
invoked in the Web Client when triggered.
--------------------------
TechTips#15 - Configuring event correlation
in the central server
Distributed Mediation Servers (DMS) are servers that can
be deployed along with Central Web NMS Server in large scale
or remotely distributed networks. Each Distributed Mediation
Server performs network-facing functions for a segment of
the network. The collected data can then be correlated to
transfer relevant information to the Central Web NMS Server.
Thus compared to a centralized data collection, deployment
with Distributed Mediation Servers builds a scalable and highly
available system. DMS forms a part of AdventNet Web NMS Remote
Monitoring Edition (RME).
By default, event correlation happens in the Distributed
Mediation Server, and only those events corresponding to the
alarm are sent to the central server. So all the events are
not sent to the central server.
Event correlation can be configured to happen in the central
server using NmsProcessesBE.conf file. The details of the
parameters and its corresponding values that must be provided
as input are given below.
- Process Name : Remote Probe
- Package Structure : com.adventnet.nms.extranet.remote.operations.server.probe.RemoteProbe
- Argument to be passed: ENABLE_ALERTFILTER
- Argument Value: False
After the changes are made, restart the DMS. All the events
generated henceforth will be sent to the central server. Already
existing events will not be sent to the central server.
In the same process, if the value of argument SEND_EVENTS_IMMEDIATE
is set to true,
the events are sent immediately to the central server.
For more information about Distributed Mediation Server please
refer to the online documentation.
--------------------------
TechTips#14 - Enabling syslog monitoring
in router and redirecting the log messages to the Web NMS
server
Syslog Monitoring feature enables monitoring of log messages
across different systems so that events can be generated based
on the occurrence of specific messages. By monitoring the
log messages, the system that generates these log messages
can be monitored for performance deviations and faults. Thus
any fault condition in the system is reflected in the log
messages and the syslog monitoring feature escalates it to
the management application. The AdventNet Web NMS Server acts
as the centralized Syslog server.
Following are the steps to enable syslog monitoring in a
router and redirect the log messages to the syslog server.
- Telnet to the router machine as telnet <router>
- Type the command enable at the prompt to set to 'enable'
mode.
- You will be prompted to enter the password. Enter the
correct password.
- Now, type the command config at the prompt.
- Choose terminal configuration.
- After this, type logging <IP address of the host device
where NMS server is running> at the command prompt. For
example, logging <192.168.5.120>. This is done to
enable forwarding of messages to the Web NMS server.
After the above steps are performed, the router logs the
syslog messages onto the server at port 514.
For more information about Syslog Monitoring feature pack
please refer to the online documentation.
--------------------------
TechTips#13 Adding a new process to the
existing list of processes in Windows 2000 system
Systems and Applications Monitoring feature enables a management
application to discover and monitor system resources and mission
critical applications in a network along with the devices.
System resources like CPU, Memory, etc. and applications such
as database servers, mail servers, web servers, etc. are monitored.
It also monitors the processes running in the systems.
Along with the default set of processes, you can add new
processes that need to be monitored by the management application.
Following are the steps to add a new process.
- From the menubar, select Tools >Runtime Administration
> Application> App Data Colln> HostResource.
- Select any resource type, say Windows2000. The corresponding
protocol (CLI for Unix, WMI for Windows) is loaded in the
Resource Type Properties column in the right, in the Select
Protocol combo box.
- From the Resource Configuration column, select the Process
tab.
- Click the Add button. A wizard pops up where you must
specify the process attributes.
- Provide the following details:
- Process Name: The name of the process. Example: Oracle
Description: The process description. Example: Monitoring
Oracle
- Match Value (mandatory): The output of a command executed
is compared with the value provided here. If it matches,
the process specified here will be added. For example,
Enter the match value as oracle.exe
- Column Number: Enter the column that needs to be
parsed. Example:1
- MatchCriteria : A condition is given here to match
the output with the match value provided. Example: equals
- Severity: An event of the specified severity will
be generated if the match criteria are not satisfied.
Example: critical
- Click Apply
The new process will be added to the list of processes that
will be monitored for Windows 2000 device types. You can configure
data collection from the main user interface.
For more information about Systems and Applications Monitoring
feature pack please refer to the online
documentation.
--------------------------
TechTips#12 - Recovering the Client
Builder project files from Backup
While building applications using Client Builder, whenever
a project is saved, the tool takes a backup of the source,
configuration, and project files. When the project files are
accidentally lost, the files can be retrieved from the backup
directory available under the <Client Builder Home>/projects/<Project
Name>/BackUp directory. For more details, refer to the
section on Screen
and Source Backup of the Source generation page of help
documentation.
--------------------------
TechTips#11 - Building a client screen
with a table showing data from multiple SNMP tables
While building a configuration screen, there could be a need
to show a screen with a table showing data available from
different tables of an SNMP agent. The data from two different
tables of an SNMP Agent need to be collated and displayed
in a single table.
The Virtual Table Model facility of the AdventNet Web NMS
Client Builder can be used to achieve the above said purpose.
For details on how to use this function, refer to the page
of the Client Builder document that explains about Virtual
Table Model. Note that this will work only for tables
having one-to-one dependent relationships.
--------------------------
TechTips#10 - Executing a configuration
task without storing it to the data store
Generally a configuration task that is defined is stored
before execution so that it can be re-used, but in few cases
it might not be required. AdventNet Web NMS provides an option
to execute a given task with or without storing in the task
before execution. The setPersistence(boolean) method of TaskGenerator
is used to specify if the task should be stored or not.
The task XML is generated using the method getTask() of TaskGenerator.
This XML is then passed to the method executeTask() of ConfigClientAPI
for execution. The task is stored before execution depending
upon the values of the methods setPersistence(boolean) and
the setNewTask(boolean) of the TaskGenerator. If setNewTask(boolean)
and setPersistence(boolean) methods are set to "true",
then the task will be saved, while executing. If setNewTask(boolean)
is set to "true" and setPersistence(boolean) is
set to "false", then the task will not be saved.
Note that the persistence property will be in effect only
if the method setNewTask(boolean) of TaskGenerator is set
to "true".
The following code snippet can be used to implement that same:
//Code Snippet for not storing the task in the database before
execution
TaskGenerator tg = new TaskGenerator();
String taskXML = tg.getTask();
tg.setPersistence(false);
tg.setNewTask(true);
ConfigClientAPI.saveTask(taskXML);
--------------------------
TechTips#9 - Removing the map toolbar
from the AdventNet Web NMS client
By default, any map in the AdventNet Web NMS application
client is associated with a toolbar. In scenarios where this
toolbar is not required and should be removed, it can be achieved
by invoking through the hideToolBar() method of com.adventnet.nms.mapui.EditableMap.
The following are the steps to be followed to achieve this:
- Write a class extending the MapApplet.
- Override the constructUI(EditableMap) method which adds
the EditableMap to the MapApplet.
- Invoke the hideToolBar() method of the Editable Map, this
method will remove the Toolbar from the EditableMap.
- Compile this class and have it in the application client
CLASSPATH.
- Modify the entry in the NmsPanels.conf file in the Panel
tag for the MapApplet class and specify the customized class
name.
The above steps would ensure that the toolbar in the map
internal frame is removed globally.
--------------------------
TechTips#8 - Sending mail notification
about BE Failover
In the event of primary BE server failure, AdventNet Web
NMS can be configured to notify the administrators through
email. AdventNet Web NMS automatically sends an email to the
configured recipient while the Failover occurs.
The mechanism is that when a Secondary Server detects the
failure of Primary Server, the Secondary Server will send
an email notification as specified in Failover.xml. The Failover.xml
file available in the <Web NMS Home>/conf directory
of Secondary Server has to be configured to provide values
for SMTP_SERVER, TO_ADDRESS and FROM_ADDRESS parameters.
For more details, refer to the “Configurable options”
section in the BE Failover page of AdventNet Web NMS documentation.
--------------------------
TechTips#7 - Persisting objects to the
AdventNet Web NMS DB
Web NMS supports persistence of user defined objects apart
from MO or Event/Alert extensions. These objects could be
any application specific object definition unrelated to any
of the Web NMS module objects and their extensions. Please
follow the below mentioned simple steps to persist the user-defined
object in the database using UserStorageAPI.
- Use the object to relational tool present under <Web
NMS Home>/bin directory and feed the class file of the
object to be persisted.
- The tool generates the relational class for the object
and other configuration entries like schema definitions.
- Append the contents of the generated files to DatabaseSchema.conf,
DatabaseAliases.conf and relationalclasses.conf files present
in <Web NMS Home>/conf directory.
- Edit the Relational<classname>.java file (if required).
- Compile Relational<classname>.java over the <Web
NMS Home>/classes directory
Now using the methods of the UserStorageAPI, the object can
be added, updated or deleted to the Web NMS database. The
following code snippet can be used to gain access to the UserStorageAPI
instance.
UserStorageAPI userStAp.i=(UserStorageAPI)Naming.lookup("//[NMSServer]/UserStorageAPI");
Please note that the UserStorageAPI can be accessed in both
the same JVM and different JVM. For more information, refer
to the Using UserStorageAPI page of the Web NMS Developer
guide documentation.
--------------------------
TechTips#6 - Adding additional resources
required for the application while packaging Studio projects
Typically an application built over Web NMS using Studio
requires additional resources such as jar files, image files
etc. In such cases it is necessary to bundle and deploy the
resources along with the application. The Packager Wizard
in Studio provides an option to bundle such resources during
packaging.
After the Studio project is complete and compiled successfully,
invoke the Packager Wizard, to create a NAR file for deployment.
In step 5 of the Packager Wizard, specify the additional resources
to be packaged. For each resource file, a target directory
should be specified. The target directory (that will finally
contain the Resource file) should be relative to <Web NMS
Home>. The Packager Wizard automatically bundles the additional
resources and during installation over Web NMS, all the Resource
files get automatically placed in the specified target directory.
For more information on Packaging refer to refer Packaging
Additional Resources of Web NMS Studio documentation.
--------------------------
TechTips#5 - Securing the RMI objects
bound in the server
Web NMS can be started in RMI secure mode to restrict access
to the RMI objects bound in the server.
In RMI secure mode, the RMI object will not be bounded in
the RMI registry. It will be stored internally in the server
JVM. The remote object can be obtained only by providing proper
authorization information. By default, the secure mode will
be disabled. The user can enable it by setting the parameter
“ENABLE_RMI_SECURITY” in serverparameters.conf file
to “TRUE”.
In order to secure the user-defined RMI objects that are
bounded in the server, the user must follow the below mentioned
steps.
1. The RMI objects must implement com.adventnet.nms.util.CommonModuleAPI.
2. Bind the object using com.adventnet.nms.util.NmsUtil.bindObjectInRegistry()
method.
This will secure the object and the user will not be able
to access the RMI object from the RMI registry. In order to
get the instance of a secured object, the user must follow
the below mentioned steps.
1. Get the instance of RMIAccessAPI using Naming.lookup().
2. Get the instance of the required API by providing a valid
user name and password using Challenge-Handshake mechanism.
Sample of code that is used to get the remote object instance
is given below:
String challenge = rmiAccessAPI.getChallenge(user);
String key = AuthUtil.getChallengeKey(user, password, challenge);
AuthTicket ticket = new AuthTicket();
ticket.setKey(key);
Remote remoteApi = rmiAccessAPI.getAPI(user, ticket, lookupName);
For more information, refer the Javadocs of RMIAccessAPI.
--------------------------
TechTips#4 - Customizing the event to
alarm correlation logic
In Web NMS, the event to alarm correlation logic is controlled
through the implementation of EventToAlertCorrelator interface
that is specified in the nmsInterfaces.conf file. Web NMS
provides a default implementation of this interface. In order
to extend the default logic or to implement different correlation
logic, users should provide implementation for this interface.
The createNewAlert (Event) and the createUpdatedAlert (Event,
Alert) methods in this interface should be implemented for
this purpose.
For the new implementation to take effect, edit the nmsInterfaces.conf
file present under <Web NMS Home>/conf directory to
specify the name of this implementation class for the “eventCorrelator”
parameter. For more information on alarm correlation, refer
to the following topic in Developer guide, Event
to alert correlator.
--------------------------
TechTips#3 - Deploying different Client
Builder applications and Studio project as a single NAR in
Web NMS
Web NMS facilitates both Client and Server side customization
through Client Builder and Web NMS Studio respectively.
All client side customizations such as building screens for
Chassis, Fault, Performance and Configuration Management can
be done using Client Builder and all server side customizations
such as resource modeling, discovery, mapping etc. can be
done using Studio. During deployment, these application screens
and the Studio project need not be bundled and installed separately
in Web NMS. Web NMS Studio supports importing the Client Builder
applications into the Studio project using Import NAR Wizard.
Choose Tools ->Import NAR from the Studio main menu to
launch the Import NAR Wizard.
During packaging of the Studio project, all Client Builder
application NARs imported in the project are packaged along
with the Studio application to form a single Studio NAR. The
Studio NAR can then be installed over Web NMS using the NAR
Installer.
The Importing
Client Applications page of Studio help documentation
details the steps involved in importing the client builder
applications. For more information, refer Deploying
Studio Applications section of Studio help documentation.
--------------------------
TechTips#2 - Forwarding traps to north-bound
systems
Web NMS provides functionality to filter and process various
protocol specific notifications like traps, TL1 autonomous
messages etc. These messages can also be forwarded to other
northbound systems with little customization. This article
gives pointers to the customization required for forwarding
these notifications to other systems.
In case of SNMP traps, all the SNMP traps received by Web
NMS will be passed through trap filters. The customization
required to forward these trap to other systems from Web NMS
can be implemented in one of the trap filters. Refer to the
topic of Configuring
Trap Filters in the Web NMS Developer guide for more information
about trap filters.
Web NMS bundles an example that implements such a trap filter
to forward traps to other systems. The example is available
in <Web NMS Home>/examples/FaultManagement/trap_forward/
directory. The example illustrates an implementation of a
trap filter, which forwards traps to other managers. The trap
filter obtains the IP address of the destination manager and
port by reading a configuration file. Refer the README.html
file available in the example directory for more details on
this example.
In case of TL1, all the TL1 autonomous messages received
by Web NMS server will be passed through TL1 notification
filters. By implementing the notification-forwarding logic
in a TL1NotificationFilter, as explained in the SNMP trap-forwarding
example, TL1 messages can also be forwarded to other systems.
For more information, kindly refer to the topic of Filtering
Autonomous Messages in Web NMS Developer guide.
--------------------------
TechTips#1 - Creating user-specific views
with scope definitions
WWeb NMS custom view scope framework allows to define scope
based on criteria for user-specific views to control the objects
being displayed in that view. For example, using custom view
scope framework, a user can be allowed just to view only the
events or alarms from a particular network (or any such criteria),
thus restricting the scope of the user. It is also possible
that a single user can have different scope definitions for
different module views.
Following are steps that are involved in creating a user-specific
view with scope definitions.
Using Security Administration UI, create a user-group. Security
Administration UI can be invoked by choosing Tools -->
Security Administration from Web NMS application client.
Select the group that is created and select the “Custom
View Scope for Group” tab.
After choosing the module from the combo box in the view,
click “Add Authorized Scope” button to specify the
scope criteria, e.g., isSNMP=”true”.
Now, the group is assigned with an authorization scope for
the selected module views.
Create a user and assign the user to this group.
Now, the new user created for the above said group, can only
view the objects within the scope defined for the applicable
module views.
For more information about custom view scope, refer the Group
and Scope Settings page of the Security Administration
book in Web NMS Administrator guide.
